AIで要件定義を効率化する方法｜上流の手戻りをなくす進め方

要件定義とは、システムで「何を実現するか」を関係者の合意のもとで明確にする工程です。よく似た言葉に「要求定義」があります。利用者側の「やりたいこと（要求）」を集める段階を要求定義、それを開発側で「実現すること（要件）」として関係者間で合意・確定する段階を要件定義と区別することがあります。つまり、要件定義が担うのは「現場の要望」を「実現可能な要件」へ橋渡しし、関係者で合意することです。

要件定義で決めた一つの仕様は、設計の段階で設計書に書き起こされ、実装の段階でソースコードに変換され、テストの段階ではテストケースの前提として使われます。要件定義の内容は、工程が進むごとに複数の成果物へ形を変えながら複製されていくということです。この構造のもとでは、間違いが見つかるタイミングによって直す範囲が変わります。要件定義の段階で見つかれば、直すべきものは要件定義書一つですが、設計が終わった後なら設計書も、実装が終わった後ならソースコードも、テストが終わった後ならテストケースも直すことになります。工程が進むほど、一つの間違いが複製された先の数だけ直す箇所が増えていきます。これが、発覚が遅いほど修正コストが膨らむ理由です。

要件定義工程で定義する内容は、大まかには次のように整理できます。

• 業務要件：対象業務のあるべき姿（目的・業務フロー・業務ルールなど）
• 機能要件：システムが提供する機能そのもの（画面・帳票・処理など、何ができるか）
• 非機能要件：性能・可用性・セキュリティ・拡張性・運用・保守性など、機能以外で満たすべき品質
• 制約・前提：予算・期限・既存システムとの連携など、検討の前提となる条件

これらを整理、文書化した成果物が要件定義書です。とりわけ非機能要件は、画面や帳票と違って目に見えにくいぶん議論から漏れやすく、「動くけれど遅い」「運用に支障が出る」といった問題の温床になります。記載が曖昧だったり抜け漏れがあったりすると、後工程での解釈ブレを生み、それがそのまま手戻りに直結します。

要件定義でつまずき、後工程の手戻りにつながるケースは、おおむね次の5パターンに集約されます。

1. 要件の抜け漏れ・矛盾：例外ケースや非機能要件（性能・運用・セキュリティなど）が見落とされ、テストや運用フェーズで初めて発覚する。要件どうしが食い違ったまま進み、後で「どちらが正か」を巡って手戻りになる。
2. 目的のブレ・スコープの膨張：「なぜ作るのか」が曖昧なまま機能の議論が先行し、要望を足し続けた結果、要件が肥大化する。気づけば当初の目的から外れた機能が並ぶ。
3. 暗黙知の属人化：業務の前提やノウハウが特定の担当者の頭の中だけにあり、言語化・共有されない。担当者が異動・退職すると、その瞬間に要件の根拠が失われ、空洞化する。
4. ヒアリング不足・認識ギャップ：業務部門への聞き取りが浅く、現場の本当の要求を引き出せない。発注側と開発側で前提がズレたまま進み、完成後に「思っていたものと違う」となる。
5. ドキュメント品質のばらつき：書き手によって粒度や観点が異なり、レビューや後工程で解釈が割れる。要件定義書が「人によって読み方が変わる文書」になってしまう。

これら5つに共通するのは、結局のところ「人手と経験への依存」です。ベテランが丁寧に進めれば防げても、属人的で再現性が低い——ここが根本の課題です。逆に言えば、この「人手・経験頼み」の部分を仕組みで補強できれば、要件定義は大きく安定します。

AIを使うと、これらの「人手・経験頼み」の部分を体系的に支援できます。抜け漏れや認識のズレ、目的のブレを上流で減らせれば、後工程の手戻りが減り、結果としてプロジェクト全体が効率化します。前章で挙げた5つの落とし穴、すなわち抜け漏れ・矛盾、目的のブレ、暗黙知の属人化、ヒアリング不足、ドキュメントのばらつきを念頭に、それぞれをAIでどう補強するかを、代表的な5つのアプローチとして整理します。

要件定義のなかでも、認識のズレが起きやすいのが画面（UI）の要件です。文章だけで「こういう画面が欲しい」と伝えても、出来上がりを見て初めて「イメージと違う」となる。画面要件定義の典型的な失敗です。言葉より絵で合意したほうが速い領域だからこそ、ここはAIの効果が出やすいポイントといえます。

AIを使う場合、画面まわりの要件定義は、おおむね次のような流れで進められます。

1. 既存画面や手書きラフを取り込む：既存システムの画面キャプチャや、ホワイトボードのラフスケッチをAIへのインプットとして読み込ませる。
2. 画面要件定義書を生成する：キャプチャや要望から、項目・操作・遷移といった画面要件定義書のドラフトをAIに起こさせます。人は不足要件を追記します。
3. 画面モックアップを生成する：定義書をもとに、AIで完成形に近い画面イメージ（モックアップ）を生成します。
4. その場で指摘・追加要件を反映する：実際の画面を見ながら「ここはボタンを分けたい」「この項目は必須に」と指摘し、要件を更新します。
5. 指摘を成果物に反映してループを回す：モックへの指摘を、画面要件定義書や基本設計といった関連成果物へ反映し、必要なら再びモックアップ生成へ戻ります。

ポイントは、「文章 → いきなり実装」ではなく、「文章 → 要件の整理 → モックアップ → 指摘 → 成果物へ反映」という短いループを素早く回すことです。完成イメージを早期に見せて合意できれば、実装後の「思っていたものと違う」という手戻りを未然に防げます。UI/UXに関わる要件ほど、この“見える化のループ”が効果的です。

→画面要件定義書やモックアップの自動生成は、LaKeel Bluの画面設計エージェントで実現できます

要件定義は、おおむね次のような流れで進みます。ここまで見てきたAIの活用ポイントを、それぞれ場面ごとに使うだけでなく、この流れ全体の中に位置づけると効果が高まります。各工程でAIがどう使えるかを、あわせて見ていきましょう。

1. 現状把握：既存業務や既存システム（As-Is）を把握し、前提条件を整理する。AIには既存資料や既存システムの読み解きを補助させる。
2. ヒアリング・壁打ち：業務部門と対話し、曖昧な要求を深掘りする。AIとの壁打ちで問いの抜け漏れを防ぎ、確認すべき論点を洗い出す。
3. 要件の構造化：引き出した要求を要件項目へ落とし込む。AIに抜け漏れや矛盾の点検をさせ、構造の穴を埋める。
4. 要件定義書のドラフト生成：構造化した情報をテンプレートに沿って文書化する。ドラフト生成をAIに任せ、人は妥当性の確認に集中する。
5. レビュー・課題管理：成果物を多角的にレビューし、課題・決定事項を一元管理して品質を担保する。また、観点を指定したAIレビューと、議事録・決定事項の整理を組み合わせる。

ただし実際のプロジェクトでは、これらのステップは一方向ではなく、発見に応じて前工程に戻ることが頻繁に起きます。

重要なのは、この5ステップを分断せず、つなげてAIを活用できるかどうかです。各ステップでバラバラにAIを使っても、ステップ間で情報を人が手作業で受け渡すことになり、そこで要件の抜け漏れや認識のズレが生まれます。「現状把握で分かったこと」を「ヒアリングの論点」に、「ヒアリングの結論」を「構造化」に、と前の成果を次へ引き継げれば、こうしたロスを防げます。工程をまたいで品質を保つことが、結果として全体の効率化にもつながります。

ここまでの進め方は、要件をある程度まとめてから設計・実装へ渡すウォーターフォール型を念頭に置いています。ただ、開発手法によって要件定義の「回し方」は変わります。AIを使ううえでも、自社のやり方に合わせて取り入れることが重要です。

要件定義の実務は、今もWord・Excel・PowerPointでの手作業が中心で、そこに汎用のAIチャットを部分的に取り入れている、というのが多くの現場の実態でしょう。ここまで紹介したAIの活用法も、こうした個別の手段の一つとして、一つひとつは実践できます。ただ要件定義は「現状把握 → ヒアリング・壁打ち → 要件の構造化 → ドラフト生成 → レビュー・課題管理」と工程が連なるため、各工程を個別の手段でこなすだけでは、工程間の引き継ぎを人がつなぐことになり、効果は限定的です。

そこで、これらをまとめてAIエージェントに担わせ、自律的に進める解決アプローチが登場しています。その一例が、ラキールの「LaKeel Blu」です。

中核のプロジェクトリードエージェントが唯一の窓口となり、壁打ち（要件の深掘り）・ドキュメント生成・レビュー・会議アシスタント（議事録作成）・課題管理・現行解析・画面設計といった専門エージェントを束ね、要件定義から基本設計までの上流工程を一気通貫で支援します。通常は、対象システムや過去の決定といった前提を、工程が変わるたびにプロンプトで指示し直す必要があります。LaKeel Bluではこうした前提や決定事項を保持することができるため、長いプロンプトを毎回書かなくても、工程をまたいで引き継げるのが特徴です。

さらにLaKeel Bluは、次の3つの知識源を組み合わせることで、上流工程を支援します。

• AI（LLM）の知識：設計パターンやベストプラクティスなど一般的な知見。
• 自社の情報：社内ドキュメント・規定・業務プロセス・既存システム資産など、その企業固有の情報。
• 有識者の情報：熟練者の暗黙知・経験に基づく判断基準。

これら3つの知識をもとにするため、自社の実態に即した精度の高い支援が実現可能です。さらに、LaKeel Bluを使うと、要件定義から基本設計までの上流工程で、AIエージェントとやりとりした内容や生成した成果物が記録として残るため、これまで個人の頭の中にあった業務ノウハウが、ドキュメントとして形式化され、組織の資産になっていきます。

3つの知識源を組み合わせる強みが特によく表れるのが、システムのモダナイゼーションです。長年の改修でブラックボックス化した既存システムを、AIが解析して「何をしているか」を読み解き、現状（As-Is）の整理までを大きく補助します。一方で、「なぜこの仕様なのか」という業務上の背景はコードには残っておらず、担当者の頭の中にしかありません。LaKeel Bluは、AIが解析した既存システムの仕様と、担当者から引き出した業務知識を同じ場で突き合わせ、あるべき姿（To-Be）の要件定義へとつなげます。しかも、その過程でのやりとりや判断が記録として残るため、これまで一部の担当者に依存していた既存システムの知識が、組織の資産として形になっていきます。長年のブラックボックス化が解消され、新しいシステムでは同じ属人化を繰り返さずに済むのです。

先ほど触れた画面の認識合わせも、このアプローチの一部です。既存画面のスクリーンショットから画面要件定義書とモックアップを短時間で生成し、その場で指摘・反映するループで進められます。

導入による変化は、たとえば次のようなBefore/Afterで整理できます。

ただし、AIエージェントが工程を補助しても、業務要件の妥当性判断・ステークホルダーとの合意・例外業務の意思決定は人が担う前提であり、LaKeel Bluはその補助に徹します。

本記事で見てきたように、AIによる要件定義の効率化は、単なる「ドキュメント作成の時短」や「人手の削減」にとどまりません。 今回紹介した失敗の原因、すなわち抜け漏れ・矛盾、目的のブレ、暗黙知の属人化、ヒアリング不足、ドキュメント品質のばらつきは、「優秀な担当者がその場にいるかどうか」でプロジェクトの成否が左右される、という構造的な問題に行き着きます。だとすれば、本当に解くべき課題は「速く書くこと」ではありません。特定のベテランの勘や経験に依存していた要件定義の質を、仕組みとして支え、組織に残していくこと。この“脱・属人化”こそ、AI活用が起こすべき本質的な役割です。速さは、その結果として後からついてきます。行動に移すなら、いきなり全工程をAI化しようとせず、自社の最も弱い一点から始めるのが現実的です。ヒアリングで暗黙知を引き出せているか、非機能要件の抜け漏れ・矛盾をチェックできているか、要件定義書の粒度は標準化されているか、議事録・決定事項を追跡できているか、既存システムの仕様を把握できているか。特に属人化している工程をひとつ選び、AIによる壁打ちや抜け漏れ検出を試す。それが、再現性のある第一歩になります。