要件定義はなぜ失敗する?「言った言わない」を防ぐ現場の合意形成術

要件定義はなぜ失敗する?「言った言わない」を防ぐ現場の合意形成術

※本ページはプロモーションが含まれています。

システム開発の現場で、最もトラブルが起きやすく、かつプロジェクトの運命を左右するのが「要件定義」です。

「顧客の要望通りに作ったはずなのに、完成間近で『こんなはずじゃなかった』と言われた」「仕様がいつまでも決まらず、スケジュールだけが過ぎていく……」

そんな経験はありませんか?要件定義の本当のゴールは、綺麗な書類を作ることではなく、顧客とエンジニアの間で「何を作り、何を作らないか」の認識を1ミリのズレもなく合わせることにあります。

今回は、現場で数多くのプロジェクトに関わってきた経験から導き出した、トラブルを未然に防ぎ、スムーズに開発へバトンを渡すための「合意形成の極意」を解説します。

目次

はじめに:要件定義の成否がプロジェクトの「楽」を決める

要件定義とは、一言で言えば「何を解決するために、どんなシステムを作るか」を定義する工程です。

ここで認識がズレると、後工程の設計や開発で必ず「手戻り」が発生します。開発が進んでからの修正は、要件定義時の修正に比べて数十倍のコストと時間がかかります。

つまり、要件定義を丁寧に行うことは、未来の自分たちを楽にするための「最強の防衛策」なのです。

現場でよくある「要件定義の失敗」3選

なぜ要件定義は失敗するのでしょうか。多くの現場で繰り返されている「負のパターン」を知っておきましょう。

① 顧客の「全部やりたい」をそのまま引き受けてしまう

顧客は「あれもこれも」と夢を語ります。しかし、予算と納期には限りがあります。優先順位をつけずにすべてを受け入れると、結局どれも中途半端な「使いにくいシステム」が出来上がってしまいます。

② 専門用語の壁で、認識がズレたまま進んでしまう

エンジニアが「DBの排他制御が……」と話し、顧客が分かったふりをして頷く。この小さなズレが、リリース直前の致命的なバグ(仕様漏れ)として牙を剥きます。

③ 結局、誰が何をいつ決めるのかが曖昧

「後で検討しましょう」という言葉が積み重なり、最終的に誰も決断を下さないまま開発が始まってしまうパターンです。

明日から使える!「言った言わない」を防ぐ3つのコツ

① 「やらないこと」リストを共有する

要件定義書には「やること」ばかりが並びがちですが、実は「やらないこと(対象外)」を明記する方が重要です。「この機能は、今回の予算内では対応しません」と文書に残し、合意を得ておくことで、後からの「追加要望」を論理的に断る盾になります。

「やらないこと」は抽象的に書いても意味がありません。例えば決済機能なら、「クレジットカード決済、コンビニ決済、PayPay決済には対応しますが、銀行振込および代引き決済は対象外とします」というように、選択肢を並べて線引きを明確にします。

IT語り部

「やらないこと」は具体的に書くのがコツです。「銀行振込・代引きは対象外」「会計ソフト連携は対象外、CSV手動ダウンロードで対応」のように書いておけば、後から要望が来ても冷静に立ち返れます。

② 議事録に「決定した理由」も残す

「A案に決まった」という結論だけでなく、「なぜB案ではなくA案にしたのか」という経緯を1行添えてください。数ヶ月後、顧客の担当者が変わったり記憶が薄れたりした際に、この「理由」が強力な証拠になります。

この「理由」を残す場所は議事録に限りません。基本設計書にも決定理由を明記しておく、あるいはチケット管理システムを使っているなら検討過程を示すチケットへのリンクを貼っておくなど、複数の場所に「なぜ」を残しておくことが、担当者交代への一番の備えになります。

IT語り部

数ヶ月も経てば、決定理由は本人でも忘れます。議事録・基本設計書・チケットのどこかに「なぜ」を残しておくことが、担当者交代への一番の備えです。

③ 図解で「完成イメージ」と「対象範囲」をすり合わせる

言葉や文字だけの説明には限界があります。簡易的な画面イメージ(モックアップ)を見せながら、「このボタンを押すと、この画面に飛びますね?」と確認してください。視覚的な情報は、どんな説明文よりも正確に認識を一致させてくれます。

また、画面単位のモックアップだけでなく、システム全体の構成を示す概要図を共有することも重要です。「今回のシステムがどこからどこまでを対象にしているか」を1枚の図で示すことで、①で明記した「やらないことリスト」の内容が、より直感的に伝わるようになります。

IT語り部

モックアップは画面仕様の認識合わせに効きますが、それだけでは不十分です。システム全体の概要図も用意し、「今回はこの範囲まで」を直感的に伝えましょう。

一歩踏み込んだ提案が「一目置かれるSE」を作る

デキるSEは、単に要望を聞くだけでなく、一歩踏み込んだ提案をしています。顧客が「このボタンが欲しい」と言ったとき、そのまま作るのは二流です。一流は「なぜそのボタンが必要なのですか?何に困っているのですか?」と真の悩みを掘り下げます。

掘り下げてみると、実はボタンを作るよりも「データの並び順を変えるだけ」で解決する場合もあります。顧客の「手段」ではなく「目的」にフォーカスすることで、工数を減らしつつ、より価値の高い提案ができるようになります。

まとめ:正しい手法を学んで、現場のストレスを減らそう

要件定義は、顧客との「共同作業」です。綺麗なドキュメントを作ることよりも、相手と同じ未来をイメージできているかを常に確認してください。「共通言語」でお互いの認識を確認し合うプロセスこそが、プロジェクトを成功に導く鍵となります。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

30年現役エンジニア。NWエンジニアからPG、PMを経て現在はアーキテクトへ。発注側・元請けから下請けまで全ての立場を経験し、数人月から数千人月のプロジェクトを歩いてきました。

インフラからアプリ、管理まで一通りこなす「技術寄りの何でも屋」です。商流の裏表を知る実体験から、エンジニアが消耗せず「楽に、賢く、一生モノの仕事」を続けていくためのヒントを発信しています。

目次