AI が要件書をチェック、でも最終判断は人間が必要

『要件書』って、ソフトウェア開発の世界では特別な意味があるの？普通の仕様書とは違うもの？

要件書と仕様書、言葉は近いですが微妙に違う立場なんですよね。 要件書は「クライアントが何を求めているのか」という、ビジネス側の声を拾ったもの。 発注者が「こういう課題を解きたい」「こういう体験を提供したい」と書く。 つまり「何をつくるべきか」という問題の定義です。 仕様書は、その要件をもとに、エンジニアが「どうやってつくるか」を詰めたもの。 画面のレイアウト、データベース構造、通信の仕様など、 実装の具体的な設計が書かれている。 記事の実験がこだわるのは前者、つまり要件書の質の判定です。 なぜなら、ここで間違えると、後ろの工程がすべて狂うから。 「実装は完璧だったのに、そもそも求められていたものじゃなかった」 という悲劇はよくある話。 だから要件書の判定には、単なるチェックリスト走査ではなく、 「発注者の本当の課題は何か」「衝突している要望の優先度は」 という文脈への潜り込みが要るんです。 その領域では人間の経験が、まだ AI には代替えできない領域と言えそうです。

要件書の質が悪いと、その後どんなトラブルが起きるんだろう？納期遅れとか、完成後の修正とか、現場にはどう影響する？

要件書が甘いと、開発の途中で「あ、こういう意図だったのか」という再発見が延々と続くんですよね。 たとえば「ユーザー情報を管理する機能」という一行だけあったとします。エンジニアが実装を始めて初めて、クライアント側の人間に「削除した情報は何年保持するんですか」「複数の部門にまたがるユーザーをどう扱うんですか」と質問する。その度に手を止めて、設計をやり直す。最初の要件書に「背景にある事情」が書かれていなかったから、想像で埋めていた部分が次々ズレていく。 結果として、納期遅れは避けられません。ただそれ以上に厄介なのは、完成後に「実は違う使い方をしたい」と現場から声が上がることです。なぜなら、クライアント側も最初の曖昧な要件書から、実装物を見てはじめて「あ、これじゃ運用できない」と気づくから。すると修正の繰り返し。それが積もると、システムは肥大化し、保守も難しくなっていく。 つまり質の悪い要件書は、単なる「最初のミス」ではなく、その後の開発全体に遅延と手戻りの連鎖を引き起こす仕掛けになってしまうという言い方もできそうです。

この実験が今タイミングで行われたってことは、これまでエンジニアの主観による判定で問題が起きてたってこと？それとも、AI 技術の進化で初めて試せるようになったから？

実は両方起きているんですよね。要件書の質の問題自体は昔からあって、プロジェクトの失敗原因の上位に「要件定義が曖昧だった」が常に来ていた。エンジニアの主観に頼る以上、経験差による見落としや、時間に追われて浅いチェックになることは避けられなかった。 ただそれでも「AI を試してみようか」という実験が最近になって増えたのは、やはり AI の精度が実務レベルに達したからだと言えそうです。数年前のテキスト処理 AI では、「明確に書かれているか」といった言語的な判定が不安定だったはず。いまは大規模言語モデルが文脈を読み込む能力を持つようになって、「本当に役立つのか」を問う実験にようやく値する段階になった。 興味深いのは、この実験がそこまで AI を褒めていないこと。むしろ「AI が完全に取って代わることはない」と明言している。つまり企業側も、AI が銀の弾丸だと期待しているのではなく、人間の弱点を補う道具として真摯に検証しているのかもしれません。要件定義という昔からの課題に、ようやく「試行錯誤する余裕」が生まれた段階に見えます。

これって『機械は正確だが融通がきかない、人間は不完全だけど文脈が読める』っていう、AI と人間の役割分担の典型例なんじゃないの？

その通りなんですが、ここで注目しておきたいのは、この「典型例」が実は想像より難しい局面を示しているということです。 要件書のチェックって、一見すると単純な「エラー探し」に見えますよね。だから AI に向いていそうに思える。でも実験が明かしたのは、エラーと判断ミスの境界が曖昧だということ。「テストできるか」という基準 AI は機械的に判定できますが、「複数の要望が衝突したとき」の判断は、その背後にある営業戦略や顧客の本当のニーズまで汲み取る必要がある。つまり何が「良い要件」なのかを決めるのは、基準そのものではなく、その基準をいつ柔軟に曲げるかという人間の判断なんです。 よくある「AI は補助的な役割」という説明だと、人間がいずれ判断を手放しそうな心配も出てくる。でもこの実験が面白いのは、逆にそれが不可能であることを示している点です。責任を取る側の判断抜きに、仕事は完結しないということが、技術実験で裏付けられた形になってる、と言えそうです。

AI がチェックを入れることで、判定が速くなる代わりに『失われるもの』ってあるのかな？たとえば、エンジニアが要件と向き合う中で得ていた経験とか、判断力の育成とか。

良い指摘ですね。AI が手間を減らすと同時に、そのプロセスの中で人間が鍛えられていた部分が削ぎ落とされるかもしれない。 実験結果を見ると、AI は「文法や構造的な問題」を速く見つけます。つまり、エンジニアがこれまで時間をかけて丁寧に読む中で身につけていた「細部への眼力」を、AI に外注することになる。その積み重ねって、実はすごく重要で、要件書を何十冊と読むうちに「この書き方は後で必ずボタンの掛け違えが起きる」というパターン認識が無意識に形成されてきたんです。 AI がその部分を担当するようになると、若いエンジニアは「細かい問題はAIが見つけてくれるから」と、読み込みの深さを手放してしまう可能性がある。そして記事で指摘されている「文脈の読み取り」や「複数要望の衝突判断」は、実はそうした細部への目利きがあってこそ成立していた面もあります。 AI を入れるなら、むしろ逆に「人間は AI では判断できない部分に集中する」という意識的な切り分けが必要になってくるのかもしれません。そうしないと、効率化と引き換えに、判断力を持った次世代エンジニアの育成が静かに失われていく、という事態が起きうると言えそうです。