「プロジェクト失敗の原因は要件定義だった」——この総括を、プロジェクトの振り返りで、業界誌の調査で、SNSの議論で、100回は見聞きしてきました。そして多くの場合、こう続きます。「顧客の理解が進まなかった」「要件を出し切ってもらえなかった」。本コラムは、この診断の裏に隠れている基準を疑います。「正しくやれば、完璧な要件定義が書けたはずだ」という基準です。完璧な要件定義とは曖昧さを認めない要件定義のことですが、曖昧さがなくなるまで決め切られた文書は、もう要件定義ではなく設計です。ありえない完成形を基準に置いたまま、その差分を、答えを持っていない——持っている必要もない——顧客やオーナーからヒアリングで聞き出そうとしてきたことが、同じ失敗を三十年再生産してきました。AIが実装と突き合わせを安くした今、曖昧さは潰し切るものではなく、認めて抱えたまま、具体物の上で解いていくものに変わります。
「プロジェクト失敗の原因は要件定義にある」——この診断の歴史は長く、日経コンピュータの名物連載「動かないコンピュータ」が失敗プロジェクトの取材を始めたのが1981年、米Standish Groupの「CHAOSレポート」が頓挫の要因の筆頭級に不完全な要求を挙げたのが1994年です。以来、この種の調査で要件定義が上位から外れたことはほとんどなく、プロジェクトの振り返りでも業界誌でもSNSでも、この総括は今日も現役です。
そして、この診断にはほぼ決まった続きがあります。「顧客の理解が進まなかった」「要件を出し切ってもらえなかった」——責任の所在は、工程と、答えを出さなかった発注側に置かれます。
処方も決まっています。要件定義書のテンプレート整備、レビューの多段化、チェックリスト、ヒアリング技法の研修、要求工学の体系化、「超上流」という工程の新設。要するに、もっと完全に決め切るための道具立てです。
数十年分の処方を積んでなお、同じ診断が繰り返されている。処方がまだ足りないのではなく、診断が暗黙に置いている基準の側がおかしいのではないか——本コラムの立場はそちらです。
「要件定義が悪かった」という総括が成立するためには、一つの前提が要ります。正しくやれば、完璧な要件定義が書けたはずだという前提です。
では、完璧な要件定義とは何か。解釈のずれが起きない要件定義です。書かれていない挙動がなく、読む人によって意味が割れる記述がなく、後工程で「これはどういう意味か」という問いが発生しない文書。つまり、曖昧さを認めない文書です。
ここに矛盾があります。すべての挙動が決まっていて、曖昧さがゼロになるまで書き切られた文書——それはもう要件定義ではなく、設計です。画面がどう遷移し、例外で何が起き、データがどう流れるかまで確定していなければ、曖昧さは消えません。そしてそこまで書いたなら、それを要件定義と呼ぶ理由がありません。
要件定義は本来、「何のために作るか」「何ができれば業務が回るか」を決める工程であり、その先の決め方をまだ決めていないこと——曖昧さ——を構造的に含みます。曖昧さが残っているのは要件定義の不備ではなく、要件定義がまだ設計ではないことの、当たり前の帰結です。
だから「失敗の原因は要件定義の曖昧さだった」という総括は、正確に言い直すとこうなります。「要件定義という工程が、設計になり切れていなかった」。責められているのは工程の出来ではなく、工程の定義そのものです。ありえない完成形を基準に置けば、すべての要件定義は永遠に不合格であり、この診断は何回でも書けます。三十年繰り返されてきたのは、そういう仕組みです。
ひとことで言えば、要件定義という工程に、期待をかけすぎてきたのだと考えています。上流で完璧に決め切れば、以後の工程は安泰になる——工程一つに、プロジェクト全体の保険を担わせる期待です。診断が三十年変わらないのは、この期待が三十年、そのまま置かれてきたからです。
「完璧な要件定義」という基準は、実務にひとつの型を生みました。曖昧さを見つけたら、顧客に確認して潰すという型です。ヒアリングを重ね、QA表を往復させ、確認会議を開き、「ここはどうしますか」を積み上げていく。曖昧さの件数がゼロに近づくほど、要件定義の品質が上がったことになっています。
この型の前提を、一度確かめておく価値があります。質問を投げている相手——顧客の業務担当、事業のオーナー——は、システムの答えを持っているのでしょうか。
持っていません。そして、持っている必要もありません。彼らは業務のプロであって、システム設計のプロではない。「この画面の例外時の挙動はどうしますか」「このデータの整合はどちらに寄せますか」「ピーク時の同時アクセスは何件見込みますか」といった問いは、業務の言葉では存在しない問いです。存在しない問いを投げられた人も、会議の場では何かを答えます。こうして生まれるのが即席の答えです——その場で組み立てられ、業務の実態の裏付けを持たない回答。QA表の上では曖昧さが一件消え、要件定義書は「完璧」に一歩近づく。そして数ヶ月後、動くものが出た瞬間に覆ります。「言われた通りに作った」と「聞いていたものと違う」が、同じ事実の両面として衝突します。
答えられなければ答えられないで、「顧客の理解が進まない」「決めてもらえない」と議事録に記録されます。間違っているのは顧客ではありません。わかっていない人——わかっている必要もない人——から、答えを聞き出そうという思想の側です。
どちらの構図でも、顧客が業務のプロであることは変わらない。変わるのは、割り当てる役である。
聞き出す構図の中で、顧客は「答えの供給者」の役を割り当てられ、その役を果たせないと失敗の原因側に記録されます。顧客が本来果たせる役は別のところにあります。具体物を前にして、業務のプロとして判断することです。存在しない答えを言葉で求められると黙り込む担当者が、動く画面を触った瞬間に「実際の業務ではこう来る」「この場合はこうしないと回らない」と話し出す——この光景に覚えのある読者は多いはずです。
聞き出す型が三十年続いたのには、理由があります。実装が高価だった時代、動くものは工程の最後にしか存在しませんでした。具体物なしで曖昧さを潰すには、言葉で聞き出すしかない。そして曖昧さを残したまま設計・実装へ進めば、発覚は数ヶ月後の結合テストや受入になり、手戻りの費用は桁で増える。曖昧さを認めるわけにはいかない構造が先にあり、「完璧な要件定義」という基準は、その構造が要求したものでした。
生成AIが変えたのはここです。実装と突き合わせの値段が変わったことで、この構造の前提が崩れました。
一つ目。動くものが出るまでの時間が、月単位から日単位になりました。要件定義と並走して、捨てる前提の試作を出せます。仮説は、聞き出すものから、作り手が作って見せるものになります。顧客に投げるのは「どうしますか」ではなく、「こう考えたが、業務はこれで回るか」。存在しない答えを求める問いが、業務のプロが答えられる問いに変わります。
二つ目。要件定義書・設計書・テスト・実装のあいだの突き合わせを、AIが常時回せるようになりました。どこにどんな曖昧さが残っているか——この記述はテストに落とせない、この二つの記述は両立しない——を、工程の節目の人手レビューではなく、AIが列挙し続けられます。曖昧さは、急いで潰し切る対象ではなく、どこに何が残っているかを把握したまま抱えていられるものに変わります。どれを今決め、どれを動くもので詰め、どれをまだ決めずにおくか。この常時整合の組み方は仕様駆動か、テスト駆動か、評価駆動かに書いた通りです。
三つ目。把握したまま抱えられるようになった曖昧さは、測れるようになりました。解釈の幅——いわゆる行間の広さ——は、これまで定性的な感想でしか語れませんでした。「この要件定義書はふわっとしている」。それが本当かどうかは数ヶ月後に事故として判明し、しかも後からしか分かりません。AIを使うと、この幅を先に観測できます。同じ記述から、互いを参照させずに設計やテストケースを何通りも独立に導出させ、結果がどれだけ割れるかを見る。割れなければ行間は狭く、大きく割れればそこが広い。そして、どの記述で割れたかの一覧は、そのまま未決定事項の台帳になります。
これは、要件定義の出来を測る物差しの置き換えでもあります。曖昧さゼロという、不合格しか出ない基準の代わりに、どこに・どれだけの曖昧さが残っていて、要件定義フェーズ以後の難易度がどれだけ見えているかという基準。解釈の幅が広い記述の多い案件は、設計以後で割れる回数が多い案件です。測定の結果は見積もりと体制の入力になり、次章の仕分けの台帳になります。ただし、測れるのは文面に兆候がある曖昧さだけです。そもそも話題に上がっていない業務の実態は、どんな測り方でも文面からは出てきません。数字は下限であり、絶対値より推移と比較で使うものです。
三つとも、専用の基盤を組む話ではありません。Claude Codeのような開発エージェントの標準的な使い方の延長で始められるもので、当社が受託開発の仕組みに落とした構成はClaude Code プロジェクトパック公開に書いています。
即席の答えも解釈のずれも、混入自体はどの進め方でも起きる。違うのは、表に出るまでの距離である。
曖昧さを認めて進めても、発覚が早ければ事故になりません。構造がこう変わった以上、「曖昧さを認めない」という基準を維持する理由は、費用の側から消えています。
ここまでを「要件定義は曖昧でいい」と読むと、逆側に倒れます。曖昧さには種類があり、残してよいものと、先に決めないと事故になるものがあります。
先に決めるべきは、合意と決断の事項です。検収の基準、責任と費用の分界、業務ルールの確定——ここは「何が正しいか」ではなく「何を正とすることに双方が同意したか」の世界であり、動くものでは代替できません。そしてこれらは、ヒアリングで聞き出す対象ではなく、双方が決める対象です。顧客が答えを持っていないのは同じでも、ここでの正しい形は「持っていないから作り手が仮説を出す」ではなく、「持っていないからこそ、選択肢と影響を並べた上で、決めてもらう」になります。決めることは、業務の責任者にしかできない仕事だからです。
非機能要件は、この「先に決める」側の典型です。そして、聞き出す型の無理が最も分かりやすく出る領域でもあります。「可用性はどの水準が必要ですか」「目標復旧時間はどれくらいですか」——業務のプロがそのまま答えられる問いではありません。かといって、多くは動くもので詰めることもできません。性能のように試作の上で早期に実測できるものはあっても、可用性・運用・セキュリティの水準は、画面を触っても見えないからです。正しい形は、ここでも問いの向きを変えることです。作り手が業務の実態と標準——IPAの非機能要求グレードのような当てはめ先——から水準の仮説を組み、費用への影響と並べて提示し、業務の責任者に決めてもらう。水準の決断は費用の決断そのものであり、ここを曖昧なまま残すと、見積もりも体制も根拠を失います。
残りの曖昧さは、性質で処し方が分かれます。
曖昧さは不備ではなく、要件定義が構造的に含むものである。潰し切るのではなく、性質で処し方を選ぶ。
仕分けの基準は「その曖昧さを解くのは、合意か・判断か・測定か」。
この仕分けは、ウォーターフォールでAI駆動開発を回すに書いた「要件定義はあまり縮まない」という観測とも整合します。記述と整合はAIで速くなっても、合意と決断の比重が大きい部分は縮みにくい。縮まない部分こそが、要件定義に残る人の仕事の核です。
第3章で、顧客の役は「答えの供給者」ではなく「業務のプロの判断者」だと書きました。ただし、判断者の役は置くだけでは機能しません。見たこともない選択肢を前に、いきなり良い判断ができる人はいないからです。聞き出す思想をやめた後の実務は、判断に足る材料と場を、作り手が整えるところまで含みます。
出発点は、測った幅をリスクとして共有することです。「この記述は解釈が割れています。今決めることも、動くもので詰めることもできます。決めずに進めるなら、設計以後でここが割れる可能性を抱えます——いいですか」。この確認は、顧客に想像力を要求するのではなく、想像に材料を渡すコミュニケーションです。そしてこれを口頭の説明ではなく物証で行うために、AIの生成速度が効きます。人手では一案作るのが限界だったものを、並べて見せられるからです。
| 渡す材料 | 作るもの | 何が変わるか |
|---|---|---|
| 想像している幅 | 同じ記述からの解釈違いを並べた複数モック、決めなかった場合の分岐の見取り図 | 「どうしますか」が選択問題に変わる。決めない選択も、リスク込みの合意になる |
| 想像の具体化 | 業務の一日を再現するウォークスルー、現行業務の写し取り | ゼロから答える負担が、確認して直す負担に変わる |
| 想像を超えるもの | 聞かれていない代替案——制約を一つ外した「こうもできます」 | 期待の外側を見せることが、発注側の学習と信頼になる |
| 決定の記録 | 決定ごとの「決めたこと・捨てた選択肢・費用への影響」の一枚 | 決定権者は回を重ねるほど速くなり、記録は後日の振り返りの根拠になる |
ただし、この方向には分かりやすい失敗があります。作りすぎです。生成が安いからといってアウトプットを積み上げれば、顧客はレビューしきれず、読まれない資料への承認が積み重なります。読まれないまま押された承認は、責任の形をした空白です。
だから設計すべきは生成の量ではなく、人に見せる量です。生成は何案でも走らせてよい。しかし判断の場に載せる数は、承認する側のスループット——読んで、考えて、責任を持てる量——から逆算して絞ります。自明な矛盾の除去や案の予選はAI同士の突き合わせで済ませ、人の前には絞られた選択肢と差分だけを出す。第4章で測った解釈の幅は、ここで優先順位になります。幅の広い記述から順に判断の場へ載せ、狭いものは動くもので詰める側へ回す。
この積み重ねの先に、「あの要件定義は妥当だった」と後から言える状態があります。妥当性とは、予想が全部当たったことではありません。当時見えていた幅がリスクとして示され、決定権者が選び、その記録が残っていることです。要件が動いたときも、「あのとき見えていた範囲で、リスクを承知で選んだ」と言える。工程一つに保険を担わせる期待の代わりに置くべきものは、おそらくこの納得の仕組みです。
正直に付け加えると、この進め方は誰とでも成立するわけではありません。幅を測って見せる、仮説を組む、見せる量を絞る——どれも提供側のスキルに依存しますし、それ以前に、受託側が「ここはリスクがあります。いいですか」と口にできる力関係が要ります。言われたものを黙って作る関係の中では、幅を見せること自体が「不安を煽っている」と受け取られかねません。道具が安くなっても、この二つ——提供側の腕と、対等に話せる関係——は自動ではついてきません。逆に言えば、AI時代の発注先選びの基準は、ここに移るのだと思います。
整理します。
「プロジェクト失敗の原因は要件定義」という診断は、「正しくやれば完璧な要件定義が書けたはず」という基準を暗黙に置いていました。しかし曖昧さを認めない要件定義とは、すべてを決め切った文書——設計——のことであり、基準の側が工程の定義と矛盾しています。そのありえない完成形との差分を、答えを持っていない顧客やオーナーから聞き出して埋めようとする。答えられなければ「顧客の理解が進まない」と記録し、即席の答えは数ヶ月後に動くものの上で覆る。この型が、同じ失敗を再生産してきました。工程一つに全体の保険を担わせる期待が、その土台にあります。
AIが実装と突き合わせを安くした今、前提が変わりました。仮説は作り手が動くもので提示し、顧客には業務のプロとしての判断を求める。曖昧さは認めて抱えたまま、解釈の幅を測って以後の難易度を見立て、どれを今決め、どれを具体物で詰め、どれを基準で追うかを仕分ける。先に決めるのは、合意と決断が要る事項だけです。そして判断の場には、幅とリスクの材料を、承認できる量に絞って載せます。
だから、次の振り返りで「原因は要件定義だった」と書きそうになったときの問いは、こうなります。
その要件定義に求めていたのは、要件定義か、それとも設計か。
顧客に投げた問いは、業務のプロが答えられる問いだったか。答えを持たない人の即席の答えを、要件として固定していなかったか。
仮説を最初に形にして見せたのは、契約から何週間後だったか。
解釈の幅——行間の広さ——は、数ヶ月後の事故で判明する前に、測られていたか。
残っていた曖昧さのうち、先に決めるべきもの・動くもので詰めてよいもの・基準で追うしかないものは、仕分けられていたか。
顧客の判断には、幅とリスクの材料が、承認できる量で渡されていたか。決定の記録は残っていたか。
「顧客の理解が進まなかった」という総括は、次の案件でも同じ議事録を生みます。変わる必要があるのは顧客の理解ではなく、聞き出すという思想と、完璧という基準の側です。
Chapter Techでは、開発プロセスの現状分析から、要件定義の仕分けと突き合わせの設計、ルール整備、効果測定までの定着支援をAI Delivery Scope+として提供しています。自社の要件定義がどこで「設計」を求められているか、という見立ての段階からで構いません。お問い合わせからご相談ください。