なぜ要件定義は失敗するのか

要件定義が終わったはずなのに、なぜ手戻りが起きるのか

システム開発の現場で、こんな経験をしたことはないでしょうか。

ヒアリングは十分やりました。議事録も取りました。要件定義書も一通り書き上げました。顧客にも確認してもらって、「問題ありません」という言葉ももらいました。それなのに、開発が進んだ段階で突然こんな声が上がります。

「あ、この画面、承認フローが必要なんですが、入ってますか？」 「ここ、スマホからも使えないといけないんですよね」 「このデータ、月次で集計するんじゃなくて、リアルタイムで見たいんですけど」

要件定義は終わったはずでした。なのに、なぜこうなるのでしょうか。

長年この仕事をしていると、手戻りの原因を「ヒアリングが足りなかった」「確認を怠った」という個人の問題に帰着させる場面によく出くわします。しかし、それは本当の原因ではありません。もっと根の深いところに問題があります。

今回は、要件定義がなぜ失敗するのか、その構造的な理由を整理します。

「聞いた」と「引き出せた」は、まったく別の話です

まず前提として確認しておきたいことがあります。

顧客は、自分が本当に必要なものを言語化できていない場合がほとんどです。これは顧客の能力の問題ではありません。人間というのは、自分が当たり前だと思っていることをわざわざ口にしない生き物だからです。

また、頭の中にイメージがあっても、それを言葉にすることは難しく、聞かれたことを体系立てて説明するのはさらに難しいものです。 

たとえば、「月次レポートを自動化したい」という要望があったとします。この言葉の裏には、何が隠れているでしょうか。

• 誰がそのレポートを見るのか
• どんなフォーマットで出力するのか
• 締め日のタイミングで自動実行されるのか、手動で出力するのか
• 過去データの修正が発生したとき、再発行するのか
• 承認フローは必要か
• 外部システムへ連動するか

これらを顧客は丁寧に説明してくれません。なぜなら、「当然そこまで含まれているだろう」と思っているか、あるいはそもそもそこまで説明する必要性に、考えが及んでいないかのどちらかだからです。

SEがヒアリングで「どんな機能が必要ですか？」と聞いた場合、顧客が答えるのは「意識的に言語化できていること」だけです。意識の外にあるものは、聞かれても出てきません。

「聞いた」という事実と、「必要な情報を引き出せた」という事実は、まったく別のことです。この違いを理解していないと、どれだけ丁寧にヒアリングをしても、構造的に欠落が生まれ続けます。

確認まで取ったのに、漏れた――ある現場での実話

これは私自身が経験した話です。

ある投資顧問会社で、顧客向け報告書を作成するシステムを構築したときのことです。要件定義は一通り終わり、実際に使われている複数種類の報告書も入手していました。念を押して「出力すべき報告書はこれで全部ですね？」と確認を取り、「全部です」という合意も得ました。

しかし、システムが完成し運用が始まってから、ユーザーからこんな質問が来ました。

「A社向けの月間報告書は、どうやって出すのですか？」

月間報告書なら出ますよ、と答えると、こう返ってきました。

「いやいや、A社向けは書式が違うんですよ」

そのとき初めて分かりました。「月間報告書」というカテゴリの中に、取引先によって異なる書式が3種類存在していたのです。担当者にとっては当然のことでしたから、「報告書の種類を教えてください」という問いに対して、書式の違いまで思い至らなかった。聞いた側も、まさかカテゴリ内にバリエーションがあるとは想定していなかった。

「全部です」という合意は、嘘ではありませんでした。担当者は本当にそう思っていたのです。3種類の書式は全て「月間報告書」という名の帳票に違いなかった。しかし現実には漏れていたのです。

ヒアリングをした。実物の資料も集めた。最後に確認まで取った。それでも漏れるのが、暗黙知に起因する欠落の怖さです。

暗黙知が、見えない欠落をつくります

この問題の本質は「暗黙知」にあります。

顧客の組織には、長年の業務の中で蓄積された「言葉にしていないルール」が必ず存在します。「このデータは経理部長だけが見られる」「月末は処理が集中するから夜間バッチを避けたい」「この取引先だけ特別な与信判断をしている」といった話は、聞かれなければ出てきません。組織の中では全員が知っている当たり前のことが、外部であるSEには見えません。

さらに難しいのは、この暗黙知は「存在すること自体が見えない」という点です。

普通の欠落なら、要件定義書を読んで「ここの記載がない」と気づけます。しかし暗黙知に起因する欠落は、書かれていないことが問題なのではなく、「書くべきだったことを誰も認識していなかった」という状態です。自分のメモや議事録、要件定義書を何度読み返しても、その欠落には気づけません。

先ほどの報告書の例で言えば、要件定義書には「月間報告書の出力機能」と書いてあります。書いてある。だから読んでも欠落に気づけない。A社向けの特殊書式という情報が、最初から存在しないものとして扱われているからです。

これが「構造的な欠落」と呼ばれるものです。ヒアリングの量や質の問題ではなく、プロセスの設計上、見えなくなってしまう欠落があります。

この構造的な欠落が、後工程になってから「そういえば……」という形で浮上してきます。開発が進んでから出てくるから被害が大きくなります。仕様変更のコストは、要件定義段階の修正コストの数倍から数十倍になるという話は、業界内では常識と言ってもいいでしょう。

「要件定義が終わった」とはどういう状態か、誰も定義していません

もう一つ、根本的な問題があります。

「要件定義が完了した」という状態を、どうやって判断しているのでしょうか。

多くの現場では、この問いに明確に答えられません。「一通り書けた」「顧客にOKをもらった」「レビューが終わった」

それぞれの判断基準はあっても、「完了した」と言えるための客観的な基準が存在しないのです。

これは非常に危険な状態です。完了の基準がなければ、終わりを決めるのは「なんとなく十分だろう」という感覚になります。その感覚が合っているかどうかを確認する手段がないまま、次の工程に進みます。

これはちょうど、テストをせずにリリースするようなものです。「動くはず」という感覚で本番に出す。それが要件定義フェーズで起きています。

コードにはツールによる自動チェックやテストという仕組みがあります。設計書には設計レビューという工程があります。しかし要件定義には、その品質を客観的に測る仕組みが、多くの現場に存在しません。

ベテランのSEであれば、長年の経験から「ここが抜けそうだ」という勘が働きます。しかし初級のSEにはその勘がありません。さらに言えば、ベテランであっても担当するドメインが変われば、その勘が活かせないことすらあります。勘を持つ人間が関与しなければ品質が担保されない、しかしその勘は万能でもない。これが要件定義における属人性の正体です。 

AIが下流工程を担う時代に、何が起きるか

ここ数年で、AIが設計書やコードを生成する力は急速に上がっています。仕様書を渡せばコードが出てくる時代が、実用レベルで始まりつつあります。

これは何を意味するでしょうか。

下流工程の自動化が進めば進むほど、上流工程の品質がダイレクトに結果に影響するようになります。曖昧な仕様書を渡せば、曖昧なコードが大量に生成されます。欠落のある要件定義を入力すれば、欠落のあるシステムが高速に出来上がります。

今まで下流工程で「なんとかしていた」部分。つまり、実装段階でのSEの解釈や補完、テスト段階での暗黙的な仕様の補足が、AIに置き換わると機能しなくなります。人間が補正していた部分をAIは補正しません。あるものをあるとおりに処理するだけです。

つまり、AIが下流を担う世界では、要件定義の欠落がそのままシステムの欠落になります。バッファがなくなるわけです。

逆に言えば、要件定義の品質を上げることが、開発全体の品質に直結する度合いが、これまでより格段に高くなります。

初級SEにとって、これは「要件定義は上流の話だから、まだ自分には関係ない」では済まなくなってきていることを意味します。AI時代のシステム開発において、要件定義のスキルは、すべてのSEに求められる基礎技術になりつつあります。

問題の構造を、整理しておきましょう

ここまでの話を整理すると、要件定義が失敗する原因は次の3つの層から成っています。

第一層：引き出せていない 

顧客の暗黙知は、聞かれなければ出てきません。仮にイメージがあっても言語化は難しく、体系立てて説明することはさらに難しいものです。そしてSE側も、ドメインの知識がなければ「何を聞くべきか」自体が分からない。ヒアリングで「聞く」という行為だけでは、意識の外にある要求は浮上してこないのです。 

第二層：欠落に気づけない 

構造的な欠落は、定義書の中に「不在」として現れます。書かれていないことの存在に、書いた本人は気づきにくく、自分のメモや議事録、要件定義書を何度読み返しても、その欠落には気づけません。第三者レビューや経験者の勘に頼らざるを得ない構造になっていますが、ベテランであってもドメインが変われば、その勘が活かせないことすらあります。 

第三層：完了の基準がない 「終わった」を判断する客観的な指標がなく、感覚と経験に依存しています。品質を測る仕組みがないまま次の工程に進みます。

この3層の問題は、それぞれが独立しているのではなく、連鎖しています。引き出せなければ欠落が生まれ、欠落に気づけなければ完了判断が狂い、完了の基準がなければ引き出しきれたかどうかも分かりません。

「勘」に頼る構造から抜け出すために

この問題を個人の努力で解決しようとすることには、限界があります。「もっとよく聞く」「もっと丁寧に書く」「もっと経験を積む」

それ自体は正しいですが、構造的な問題を個人の努力で補うアプローチは、スケールしません。

ベテランが必ず関与できるプロジェクトばかりではありません。初級SEが要件定義を任される場面は増える一方です。AIが下流を担う分、上流に人的リソースが集中する傾向は今後さらに強まるでしょう。

「うちのチームにはベテランがいるから大丈夫」は、もはやリスク管理の答えになりません。

必要なのは、「勘」ではなく「仕組み」です。経験がなくても、一定水準の要件定義が可能になる仕組み。欠落の存在を検出できる仕組み。完了度を客観的に測れる仕組み。

次回以降、要求と要件の違いから始まり、品質の測り方、AIを活用した要件定義の新しいアプローチまで、順を追って整理していきます。要件定義を「勘に頼るフェーズ」から脱却させるための考え方を、具体的に見ていきましょう。