要件定義の「限界」をAIで超える — 日本のSIer現場で起きている変化
はじめに
「要件定義さえちゃんとできていれば」——SI業界でこのフレーズを聞いたことのない人はほぼいないだろう。
要件が曖昧なまま開発が始まり、終盤になってから「そんな仕様ではなかった」という話は、プロジェクトの失敗談の定番だ。PMが優秀でも、上流工程のドキュメントが充実していても、なぜかこの問題は繰り返される。
構造的な問題があるからだ。
そしていま、AIエージェントがこの構造に初めて本気で切り込もうとしている。
要件定義の3つの「構造的な壁」
まずは問題を整理しておく。要件定義における課題は大きく3つに分類できる。
壁1：暗黙知の言語化困難
「現場の人間が何を求めているか」は、実際に業務をやってみた人間にしかわからないことが多い。ヒアリングで聞き出せるのは「意識できている要件」だけであり、日常的に当たり前と思っていることは語られない。
これは個人の話術の問題ではなく、「無意識の知識は言語化できない」という認知の限界だ。
壁2：仕様書とシステムの乖離
要件定義フェーズで作成されたドキュメントは、開発が進むにつれて実態と乖離していく。設計変更・追加要望・バグ修正——それぞれの変更は行われても、仕様書への反映は後回しになる。
結果として、「ドキュメントを読んでも動いているシステムの仕様がわからない」という状態が生まれる。
壁3：属人化による引き継ぎコスト
優秀なSEやコンサルタントが担当したプロジェクトは品質が高い。しかしそのノウハウは個人の頭の中に蓄積され、担当者が変わると再利用できない。
要件定義のクオリティが「誰がやるか」に依存する構造は、スケーラビリティの観点で大きな問題だ。
AIはこの3つの壁にどう切り込むか
AIエージェントが要件定義の上流工程に入ることで、上記3つの壁に変化が生まれつつある。
1. ヒアリングの非線形化
従来のヒアリングは「質問リストに答えてもらう」線形な作業だった。AIを使うと、業務担当者が話している途中で矛盾点を即座に拾い上げ、深掘り質問を投げることができる。
たとえば「発注申請は部長承認で進む」と言われた直後に「ではAさんが出張中の場合は？」「システム障害で承認できない場合は？」と例外ケースを連鎖的に引き出す。これは人間のSEにも難しいことだが、AIは疲れないし、ルーティン的な質問を丁寧に繰り返せる。
2. 仕様書の「生きているドキュメント化」
コードや設計に変更が入るたびに、AIが差分を検知して仕様書の該当箇所を更新提案する。人間のエンジニアが「後で直そう」と思いながら忘れていく部分を、AIが継続的に追いかけることができる。
これは「ドキュメントを書くAI」 ではなく、「ドキュメントと実装の関係を監視するAI」という発想の転換だ。
3. パターン学習による標準化
複数のプロジェクトにまたがる要件定義の記述をAIに学習させると、「このユースケースに対してはこういう非機能要件を確認すべき」というパターンが蓄積される。
ベテランのノウハウを属人化させず、組織の資産として再利用可能にする——これがAIによる要件定義の最大の価値の一つだ。
RDRA・ユーザーストーリーとの組み合わせ
日本では近年、RDRA（Relationship-Driven Requirements Analysis）のような構造化された要件分析手法が再注目されている。これは、コンテキスト・サービス・ユーザー・業務の関係性を整理し、要件の漏れを防ぐアプローチだ。
AIとの相性がいい。
RDRAのような手法は「考え方の枠組み」を提供するが、それを埋める作業は膨大な時間がかかる。ここにAIを組み合わせることで、枠組みに従った質問を自動生成し、業務担当者との対話から要件をドキュメントに転写する速度が劇的に向上する。
ユーザーストーリーマッピングでも同様だ。ストーリーのカード出しから優先度の整理まで、AIが叩き台を作ることで、ワークショップの質が上がる。
重要なのは、AIが手法を「代替」するのではなく、手法の実行コストを下げるという役割を担うことだ。
落とし穴：「AIに任せすぎる」とどうなるか
ここで一点、現場で起きているリスクも共有したい。
AIが要件定義を「自動的に」こなせるという誤解が生まれると、人間のSEやコンサルタントが手を抜き始める。形式は整っているが、内容が薄い要件定義書が量産される。
AIが得意なのは「表現された情報の整理」であり、「業務の深い文脈理解」ではない。
現場の業務担当者が「AIが作った仕様書だから確認しなくていい」と思い始めると、暗黙知が依然として言語化されないまま開発に進んでしまう。
AIは要件定義の質を上げるツールであり、要件定義をなくすツールではない。
この認識のずれが、AIを要件定義に入れたはずなのにプロジェクトが失敗するパターンの一つになっている。
まとめ：構造を変えるには、ツールではなくプロセスの再設計が必要
AIが要件定義に貢献できる領域は 確実に広がっている。しかし本当の変化は、ツールを導入した瞬間に起きるのではなく、「AIを前提としたプロセス設計」を行ったときに起きる。
- ヒアリングをAI補完前提で設計する
- 仕様書をAIが更新できる形式で管理する
- レビューをAI vs 人間の二段階にする
こうした設計変更が伴ってはじめて、要件定義の構造的な壁が崩れ始める。
弊社では、要件定義をAIが理解できる構造に正規化するツール「Kakusill」を通じて、この変化を支援しています。「要件定義の見直しを検討している」「上流工程のAI活用を模索している」という場合は、ぜひ一度ご相談ください。
*この記事について、ご意見・ご感想はお問い合わせフォームからお気軽にどうぞ。*
