はじめに
依頼メールや打ち合わせメモをAIに渡して「足りない点はありますか」と聞くと、長いリストが返ってきます。似た質問が何度も出てきて、半分ほどは開発側で決められることです。そのままお客様に送るわけにはいきません。
この記事では、要件の抜けを洗い出すときに使っている考え方を、テンプレートとして書き出します。中身は3つです。7分類ごとの確認観点の表、AIに質問を出させるプロンプトの例、AIが出した質問をエンジニアが絞り込む基準です。表だけ欲しい方は「1.」をそのままコピーして使ってください。
私たちが多くの案件で使っている開発フローでは、この洗い出しが最初のステップです（すべての案件で同じ形ではありません）。AIが質問を挙げ、エンジニアが絞り、お客様にしか答えられない質問だけを残します。答えの出ていない質問がある間は、仕様を確定しません。
この記事をざっくり図解
資料をAIツールに入れるのは、お客様の許可をいただいてからです。許可がない案件では、同じ7分類でエンジニアが手作業で洗い出します。時間はかかりますが、表の使い方は変わりません。
1. 7分類の確認観点テンプレート
分類を決めずに「抜けはないか」と聞くと、AIは目立つところばかり拾います。分類ごとに観点を渡すと、出てくる質問の粒度がそろいます。下の表は、分類ごとに「何を確かめるか」を並べたものです。質問の例は説明用で、特定の案件のものではありません。
| 分類 | 確かめる観点 | 質問の例 | 想定回答者 |
|---|---|---|---|
| データ | どこから来るか / 件数と増え方 / 重複や表記ゆれ / 移行する範囲と期間 / 保存期間と削除 | 取引先マスタは今どのシステムにあり、同じ会社が別コードで登録されていることはありますか | 現行システムの運用担当 |
| 承認 | 承認が要る条件 / 段数 / 不在時の代理 / 差し戻し後の扱い | 承認者が休暇中のとき、申請は（a）代理者に回る（b）戻るまで止まる、のどちらですか | 部門責任者 |
| 例外 | 一部取消 / 締め後の修正 / 返品・返金 / 手作業で回している例外 | 月次の締め処理のあとに金額の誤りが見つかった場合、今はどう直していますか | 日々その業務を行う担当 |
| 権限 | 役割の種類 / 拠点や部署での見える範囲 / 閲覧のみの役割 / 外部の人 | 他の拠点の実績を見てよい役割はどれですか | 管理職、セキュリティ担当 |
| 連携 | 相手のシステム / 方向 / タイミング（定時か即時か） / 失敗したときの再送 | 会計ソフトへの連携が失敗した場合、誰がいつ気づく必要がありますか | 情報システム担当 |
| 非機能 | 同時利用者数 / 応答時間の目安 / 稼働時間帯 / バックアップと復旧 | 夜間や休日にシステムが止まった場合、翌営業日の朝まで待てますか | 情報システム担当、管理職 |
| 対象外 | 今回作らない画面・帳票 / 後回しにする機能 / 既存のまま残す運用 | 打ち合わせで話に出た集計帳票のうち、今回のフェーズで作らないものはどれですか | 予算を決める方 |
「対象外」の行は、作らないものについての質問なので、AIもなかなか出してきません。ここが空のまま進むと、話に出たものはすべて範囲内だと受け取られます。
2. AIに質問を出させるプロンプトの例
プロンプトで決めているのは、出力の列です。特に「根拠の引用」と「聞かなかった場合の推測」の2列があると、あとの絞り込みが速くなります。以下は記事用に汎用化した例です。
あなたは要件定義の確認担当です。添付の依頼資料を読み、
まだ誰も決めていない点を、質問の形で挙げてください。
分類は次の7つに固定します。分類ごとに、requirements-gap-template.md の
「確かめる観点」を順に確認してください。
データ / 承認 / 例外 / 権限 / 連携 / 非機能 / 対象外
出力は次の列のMarkdown表にしてください。
| ID | 分類 | 質問 | 根拠の引用 | 聞かなかった場合の推測 | 想定回答者 |
ルール:
- 質問は、業務担当の方が読んで分かる言葉で書く。技術用語を使わない。
- 「根拠の引用」には、質問のきっかけになった資料の文をそのまま引用する。
資料に該当箇所がない場合は「なし（資料に記載がない）」と書く。
- 「聞かなかった場合の推測」には、開発チームが質問せずに進めたら
置いてしまう前提を書く。
- はい/いいえで答える質問は、選択肢の形にする。
- 資料に答えが書いてある点は、質問にしない。
「根拠の引用」を資料の原文に限っているのは、AIが資料にない内容を前提に質問を作ることがあるためです。引用があれば、エンジニアは原文に戻って確かめられます。
3. AIが出した質問を絞る基準
AIが出したリストは、お客様に送るリストより必ず長くなります。外すかどうかは、表の列を見ると判断しやすくなります。
| 外す・直す理由 | AIの出力のどこを見るか | 扱い |
|---|---|---|
| 開発チームが自分で決められる（ライブラリ、テーブル構成など） | 想定回答者が「開発チーム」、または質問に技術用語がある | 外して、設計判断として記録する |
| 資料にすでに答えがある | 根拠の引用を原文で読むと答えも書いてある | 外す |
| ほかの質問と重なっている | 同じ分類で、聞かなかった場合の推測が同じ | 1つにまとめる |
| どう答えてもらっても作るものが変わらない | 聞かなかった場合の推測を変えても、画面もデータも変わらない | 外す |
| 根拠がなく、観点からも説明できない | 根拠の引用が「なし」で、表の観点のどれにも当たらない | 本当に必要か読み直す |
残った質問は、想定回答者ごとに分けてお送りします。リスト全体をお一人に送ると、担当外の質問に「たぶん今と同じで」と答えていただくことになりやすいからです。
「聞かなかった場合の推測」の列は、お客様に送るリストにも残すことがあります。質問しない場合に何が起きるかが分かると、答える優先度を判断していただきやすくなります。
4. 回答を受け取ったあと
回答は要件定義書に反映し、回答のない質問は「未決」と明記します。推測で埋めて「決まったこと」にはしません。チャットでいただいた回答も、フィードバック管理のファイルかバックログに記録して、お客様に確認していただきます。
確定後に新しい疑問が出たときは、変更の手順で扱います。最初の質問リストで「対象外」をはっきりさせておくと、ここで揉めにくくなります。
このテンプレートでできないこと
- 資料に書かれていないルールは、AIからは質問になりません。「この取引先だけは上限を適用しない」といった取り決めは、業務担当の方へのヒアリングで出てきます。
- 答えられる方がお客様側にいない場合、よい質問でも仕様は推測で埋まります。
- ボタンの文言を1か所直すような小さな修正には、7分類の表は大げさです。
- 絞り込みを省いて長いリストを送ると、絞る作業をお客様に渡すことになります。
最後に
AIに質問を出させるところは速くなりましたが、どの質問を残すかは、相手の業務と開発の両方を知っている人が決めています。表の分類や観点は、扱う業務に合わせて足したり削ったりして使ってみてください。
参考文献
- VAON ブログ「AIで要件定義の抜け漏れを洗い出す 仕様確定前の質問リストの作り方」（発注側から見た質問リストの使い方）: https://vaon.com.vn/ja/blog/ai-requirements-gap-questions-before-spec-lock?utm_source=qiita&utm_medium=referral&utm_campaign=claude-code-workflow
- IPA「ユーザのための要件定義ガイド 第2版」: https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/youkenteigi20190912.html