要件定義レビューは間違い探しではない。5段階レベル分解とAI-Firstな分担設計

要件定義書のレビュー会議が、表記ゆれの指摘と誤字の修正で時間切れになった経験はないでしょうか。この記事では、レビューの観点を5段階のレベルに分解し、レベルごとにAIと人間の分担を設計することで、人間が「自社固有の文脈」と「意思決定」に集中できるレビューの組み立て方を解説します。あわせて、gaipackがこの考え方をどう実装しているかも紹介します。

なぜレビューが字句修正で終わるのか

要件定義レビューの目的は、間違い探しではなく、プロジェクトの失敗リスクを上流で摘み取ることです。ところが一度の会議で形式からビジネス価値まで全部を見ようとすると、指摘しやすい表記の問題に議論が吸い寄せられ、肝心の「そもそもこれを作る意味はあるか」まで到達しません。

この問題は、レビューの観点を分解し、順番と担当を設計すると解消に向かいます。まず観点の分解からです。

レビューの5段階レベル

レベル	名称	問い	指摘の例
Lv1	形式・整合性	正しく書かれているか	「顧客」と「クライアント」の混在。図にある承認ボタンが本文にない
Lv2	業務・機能充足	必要な機能が揃っているか	決済失敗時の画面遷移が未定義。データ削除のルールがない
Lv3	技術的実現性	今の技術・予算・期間で作れるか	連携先の外部システムが、定義されたデータ項目を本当に提供しているか
Lv4	品質・非機能	安定して使い続けられるか	権限設定の定義漏れ。障害時にエラーログで原因を特定できるか
Lv5	ビジネス価値	そもそも作る意味はあるか	開発費300万円の機能の利用頻度が年数回なら、簡易版で十分ではないか

レベルが上がるほど、判断に必要な文脈が増え、指摘の影響も大きくなります。Lv1の指摘は文書を直せば済みますが、Lv5の指摘はプロジェクトの方向を変えます。

レベル別にAIと人間の分担を決める

AIが生成した（あるいはAIで下書きした）要件定義書をレビューする場合、レベルごとにAIに任せる範囲を決めておくと、人間の工数を大きく削れます。目安となる分担は次の通りです。

レベル	AIに任せる	人間が担う
Lv1 形式	ほぼ100%。表記ゆれ・矛盾・誤字の検出と修正	修正結果を信じて読まない
Lv2 業務	標準フロー・標準的な異常系・データ型の網羅	「月末だけ特殊な承認ルートになる」といった自社固有の例外ルール
Lv3 技術	一般的なAPI仕様や技術の限界の調査	仕様書のない古い基幹システムと連携できるかという現場特有の制約
Lv4 品質	標準的なセキュリティ項目・バックアップ構成の点検	「この社内ツールに稼働率99.9%が本当に必要か」というコスト対リスクの決断
Lv5 価値	検討資料の清書、ROI計算の数式づくり	「これを今やる必要があるか」という経営判断と関係部署の利害調整

分担の線引きはシンプルです。教科書に載っている一般論はAIが得意で、学習データに存在しない自社特有の事情はAIには判断できません。「一般的なECサイトのカート機能として教科書通りか」はAIに聞けば足りますが、「在庫がないとき裏で別店舗から取り寄せる、という自社の特殊運用に対応しているか」は人間が確認するしかありません。

AI-to-AIレビューで人間の読む量を最小化する

分担を決めたら、フローに落とします。ポイントは、人間がレビューを始める前にAI同士で品質を上げ切ることです。

AIによるセルフ修正: 要件定義書を作成したAIとは別のAIモデルに、Lv1とLv2の標準的な範囲の矛盾や漏れをチェックさせ、修正まで済ませます。ここまでの修正内容を人間は読みません
AIによる「人間への質問状」作成: 「自社固有のルールや技術制約として、人間に確認が必要なポイントを抽出して」と指示し、確認事項のリストを作らせます
人間による差分と意思決定のレビュー: 人間は質問状の確認ポイントとLv5だけをレビューします。細かい文言は見ず、方向性の議論に時間を使います

このフローの狙いは、人間の読む対象を「AIが自信を持てなかった箇所」と「意思決定が必要な箇所」に絞ることです。全文を通読するレビューと比べて、確認の抜けを構造的に管理しながら、読む量を大幅に減らせます。

gaipackでの実装例：AIレビューハブ

gaipackのAIDD要件定義フェーズでは、この考え方を「AIレビューハブ」という仕組みで実装しています。PRDを材料に、AIが業務フロー図・画面遷移図・権限マトリクス・エッジケース一覧といった確認用の中間成果物20種（業務側9種・システム側11種）を自動生成し、人間はHTML化された成果物を目視でレビューします。

人間が見る観点は3つに絞られています。モレ（PRDに書いてあることが成果物にすべて出ているか）、混入（PRDに書いていないものが紛れ込んでいないか）、言い回し（名前・用語・数値がPRDと一致しているか）です。要件定義書の文章を通読して問題を探すのではなく、AIが観点別に展開した成果物と突き合わせる形にすることで、レビューの見落としを構造的に減らします。

品質チェック自体もAIが担い、元資料に対する網羅性、内部記述の整合性、差分に対する変更管理の3観点で検証した結果をS/A/B/Cで判定します。AIが整合性チェックと記述漏れを検出し、作成者が合格ラインまで修正し、確認者が承認する、という役割分担です。人間のレビューが「間違い探し」から「意思決定」に寄っていく構図は、前節のAI-to-AIフローと同じです。

会議は3回に分け、順番を逆にする

レビュー会議を分ける場合は、レベルの順番を逆にします。

第1回: ビジネス価値と実現性の確認（Lv5、Lv3）
第2回: 業務機能と非機能の確認（Lv2、Lv4）
第3回: 最終的な整合性と形式の確認（Lv1）

方向性が誤ったまま細部を磨いても手戻りになるだけなので、影響の大きいレベルから確定させます。レビュアーの人選も観点に合わせます。Lv5とLv2はビジネス部門、Lv3とLv4は開発リーダーやアーキテクト、Lv1はAIに任せた結果の最終確認だけをPMが行う、という分担が組みやすい形です。レビューの所要期間を甘く見積もらないことも実務上は効いてきます。gaipackの標準では、各レビューに最低1週間のバッファをスケジュールへ組み込みます。

「レビューを捨てる勇気」との付き合い方

AI-Firstなレビューには、AIの出力を読まずに信じる範囲を決める、という割り切りが含まれます。抵抗を感じる方もいると思いますが、逆に考えると、人間が全文を通読するレビューでも見落としは起きていて、その品質は読み手の集中力に依存していました。どの範囲をAIに任せ、どの範囲に人間の注意を集中させるかを明示的に設計する方が、リスクの管理としては誠実です。

守るべき一線は明確で、自社固有の文脈と意思決定は人間が手放さないことです。ここさえ守れば、残りの形式チェックと標準ケースの網羅はAIに委ねられます。

まとめ

原則	内容
レビューを5段階に分解する	形式・業務・技術・品質・価値で観点を分ける
影響の大きい順に確定させる	Lv5とLv3から始め、Lv1は最後に回す
一般論はAI、固有文脈は人間	教科書通りかはAIに聞き、自社の特殊事情は人間が守る
人間の前にAI同士で仕上げる	セルフ修正と質問状で、人間は差分と意思決定だけを読む
突き合わせでレビューする	文章の通読ではなく、AIが展開した成果物とのモレ・混入・言い回しの照合にする

gaipackでは、AIレビューハブを含む要件定義の支援をAIDD 要件定義として提供しており、要件定義の標準化で開発の手戻りを約66%削減した導入事例もあります。要件定義の品質でお悩みでしたら、お気軽にKDDIアイレットへお問い合わせください！