・0 pv・6 min read
要件定義書をAIに壁打ちしてもらう：抜け漏れを防ぐ企画術
「完璧だと思った要件定義書」に潜む落とし穴
「要件定義はバッチリ！これで開発もスムーズに進むはず」
そう確信してプロジェクトを開始したものの、開発途中で「あれ？この場合の処理ってどうするんでしたっけ？」「この要件、実は矛盾してません？」といった問題が次々と発覚...
PM・システム企画として、こんな苦い経験はありませんか？
私も以前は、関係者との会議を重ね、詳細な要件定義書を作成したつもりでいました。しかし、実際には見えない抜け漏れが必ずと言っていいほど存在していたんです。
でも最近、生成AIを「壁打ちパートナー」として活用することで、要件定義の品質が劇的に向上しました。今日はその具体的な手法をお伝えします。
なぜ要件の抜け漏れは発生するのか？
まず、抜け漏れが生まれる根本原因を整理してみましょう。
原因1：思考の盲点（認知バイアス）
- 確証バイアス：自分の考えに合致する情報ばかりに注目してしまう
- アンカリング効果：最初に決めた方針に固執してしまう
- 楽観バイアス：「きっと大丈夫だろう」と思い込んでしまう
原因2：関係者とのコミュニケーション限界
- 限られた時間での要件ヒアリング
- 業務を知り尽くした担当者の「当たり前」の説明不足
- 複数部門間での認識のずれ
原因3：例外パターンの見落とし
- 正常系の処理ばかりに注目し、異常系を軽視
- 稀にしか発生しないケースの考慮不足
- システム間連携での境界処理の曖昧さ
AIを活用した「要件壁打ち」の5つの手法
手法1：悪魔の代弁者アプローチ
AIに批判的な視点から要件を検証してもらいます。
プロンプト例：
以下の要件定義について、批判的な視点で問題点を指摘してください。
特に以下の観点で厳しくチェックしてください：
1. 曖昧で解釈が分かれそうな記述はないか
2. 実現困難または非効率な要件はないか
3. 他の要件と矛盾する箇所はないか
4. 考慮されていない例外ケースはないか
あなたは経験豊富なシステムアナリストとして、
遠慮なく問題点を指摘してください。
【要件定義書】
[要件定義の内容をここに貼り付け]
実際の指摘例：
- 「『迅速に処理する』とありますが、具体的な処理時間の定義がありません」
- 「ユーザー登録の要件で、重複メールアドレス時の処理が明記されていません」
- 「決済処理の要件とキャンセル処理の要件で、在庫の扱いが矛盾しています」
手法2：ステークホルダー視点の切り替え
異なる立場の人の視点から要件を評価してもらいます。
プロンプト例：
以下の要件定義を、それぞれの立場から評価してください：
【エンドユーザーの視点】
・使いにくい点、分かりにくい点はないか
・期待する機能が不足していないか
【システム管理者の視点】
・運用・保守で困りそうな点はないか
・障害時の対応方法が明確か
【経営者の視点】
・ビジネス価値に繋がっているか
・コストに見合った効果が期待できるか
【開発者の視点】
・技術的に実現可能か
・開発効率を下げる要因はないか
【要件定義書】
[要件定義の内容をここに貼り付け]
手法3：シナリオベースの検証
具体的な利用シナリオを通じて要件の妥当性を確認します。
プロンプト例：
以下の要件定義に基づいて、具体的な利用シナリオを5つ作成してください。
そして、各シナリオで要件が不十分または問題となる点を指摘してください。
シナリオ作成の観点：
1. 典型的な正常ケース（2つ）
2. よくあるエラーケース（2つ）
3. 想定外の極端なケース（1つ）
【業務背景】
[システムの概要や業務内容]
【要件定義書】
[要件定義の内容をここに貼り付け]
手法4：時系列での整合性チェック
プロセス全体を時系列で追いかけて矛盾を発見します。
プロンプト例：
以下の要件定義について、業務プロセス全体を時系列で整理し、
各ステップで以下をチェックしてください：
1. 前のステップからの情報の引き継ぎは適切か
2. 各ステップで必要な判断材料は揃っているか
3. プロセスが止まってしまうケースはないか
4. 戻り処理やキャンセル処理は考慮されているか
【要件定義書】
[要件定義の内容をここに貼り付け]
手法5：非機能要件の洗い出し
機能要件に注目しがちな中で、非機能要件の不足をチェックします。
プロンプト例：
以下の機能要件を実現するために必要な非機能要件で、
記載が不足している項目を指摘してください。
チェック項目：
・性能要件（応答時間、スループット、同時接続数等）
・信頼性要件（稼働率、障害復旧時間等）
・セキュリティ要件（認証、認可、暗号化等）
・保守性要件（ログ、監視、バックアップ等）
・拡張性要件（将来的な機能追加、データ量増加等）
【機能要件】
[機能要件の内容をここに貼り付け]
実践事例：ECサイトリニューアルでの成果
プロジェクト概要
某中堅企業のECサイトリニューアル（会員数10万人、月間売上5000万円）
AI壁打ちで発見した主な問題
1. 決済処理の抜け漏れ
- 発見した問題：クレジットカードの有効期限切れ時の処理が未定義
- 影響予想：決済エラー時の顧客離脱、カスタマーサポート負荷増
- 対策：自動的な支払い方法変更促進フローを追加
2. 在庫管理の矛盾
- 発見した問題：予約販売商品と通常商品の在庫カウント方法が矛盾
- 影響予想：オーバーセル（売りすぎ）によるトラブル発生
- 対策：在庫種別ごとの管理ルールを明確化
3. 非機能要件の不足
- 発見した問題：セール時のアクセス集中に対する性能要件が未定義
- 影響予想：サイトダウンによる機会損失（推定月1000万円）
- 対策：ピーク時の性能要件とスケーリング方式を定義
結果
プロジェクト進行への効果：
- 開発中の仕様変更：70%削減（25件→8件）
- 受入テストでの不具合：60%削減（40件→16件）
- プロジェクト遅延：ゼロ（従来平均2ヶ月遅延）
リリース後の効果：
- 顧客からの問い合わせ：50%削減
- システム障害：80%削減
- 売上への貢献：想定通り達成
要件壁打ちのベストプラクティス
タイミング
- 要件定義書初稿完成後：全体的な壁打ちを実施
- 関係者レビュー前：事前に問題を洗い出し
- 開発開始直前：最終確認として実施
効果的な質問設計のコツ
1. 具体的で明確な指示を出す
❌ 悪い例：「この要件をチェックして」
✅ 良い例：「この要件を、セキュリティの観点で、
具体的な脅威を想定して問題点を3つ指摘してください」
2. 制約条件を明示する
✅ 良い例：「予算上限3000万円、開発期間6ヶ月という制約の中で、
この要件の実現可能性を評価してください」
3. 前提条件を共有する
✅ 良い例：「既存システム（Java/Oracle）との連携が必須という前提で、
技術的な実現方法での問題点を指摘してください」
チーム活用のポイント
個人作業フェーズ
- まず一人でAI壁打ちを実施
- 発見した問題点をリスト化
- 優先度付けと対応方針を検討
チーム検討フェーズ
- AIが指摘した問題をチームで議論
- 対応の必要性と方法を決定
- 要件定義書のアップデート実施
要件壁打ち用チェックリストテンプレート
基本チェック項目
1. 記述の明確性
- [ ] 曖昧な表現（「適切に」「迅速に」等）はないか
- [ ] 数値基準が明確に定義されているか
- [ ] 判定条件が具体的に記載されているか
2. 整合性
- [ ] 要件間の矛盾はないか
- [ ] 既存システムとの整合性は取れているか
- [ ] 法的制約との適合性は確認済みか
3. 完全性
- [ ] 正常系の処理は網羅されているか
- [ ] 異常系・例外系の処理は定義されているか
- [ ] 境界値での動作は明確か
4. 実現可能性
- [ ] 技術的に実現可能か
- [ ] 予算・期間の制約内で実現できるか
- [ ] 運用・保守体制で対応できるか
5. 非機能要件
- [ ] 性能要件は適切に定義されているか
- [ ] セキュリティ要件は十分か
- [ ] 運用・保守要件は明確かまとめ：AIとの協働で要件品質を革新する
要件定義書をAIに壁打ちしてもらうことは、単なるチェック作業ではありません。
多角的な視点で要件を見直し、潜在的な問題を早期発見し、プロジェクトリスクを大幅に削減する戦略的な手法です。
一人で考えていては絶対に気づけない問題を、AIという優秀なレビューアーが指摘してくれる。これほど心強いことはありません。
明日の要件定義から、ぜひAI壁打ちを試してみてください。きっと「なぜ今まで気づかなかったんだろう」という発見があるはずです。
そして、その発見が、プロジェクト成功への確実な一歩となるでしょう。
次回は「AIを使った設計レビュー：非技術者でも気づける設計の落とし穴」をお届け予定です。要件定義の次のステップである設計フェーズでの AI活用法を詳しく解説しますので、お楽しみに！