本文へ移動
← 記事一覧へ

解説・作例 · 要件定義 ·

AIと要件定義の質問を作る

「検索を便利に」の4行から、次の打ち合わせで聞くことを整理する。

この記事の目次

「検索を便利にしてほしい」と頼まれたら、何を作ればよいでしょうか。検索欄を大きくする、絞り込みを増やす、AI検索にする。どれも案にはなりますが、要望の一文だけでは選べません。

AIには、仕様を埋めてもらう前に、確かめるべきことを整理してもらう使い方があります。この記事では、社内資料検索の架空の要望から、次の打ち合わせに持っていく質問を作ります。最初の比較表は記事側の作例です。末尾には、同じ依頼文と4行の要望を実際に渡したときの応答も載せます。

要望の言葉を、決まった仕様にしない

GOV.UKのユーザーニーズの指針は、利用者が達成したいことや困りごとを調べ、解決手段をニーズそのものと混同しないよう案内しています。利用者から得ていない提案は、調査が必要な仮定として扱います。Learning about users and their needs

これを要件の打ち合わせに使うなら、「どの機能を付けるか」へ進む前に、どの作業で何に困るかを確かめます。AIが挙げた質問も調査の候補であり、質問を作っただけで利用者のニーズを確認したことにはなりません。

作例:4行の要望から質問を作る

元の要望は次の4行です。まだ利用者への聞き取りはしていないものとします。

[1] 営業向けの資料検索を便利にしたい。
[2] 欲しい資料がなかなか見つからない、と営業から聞いた。
[3] 古い資料は検索に出したくない。
[4] 来月から使えるとうれしい。

次は、この要望から作る質問の例です。「検索が遅い」「古い=1年以上前」など、元の文にない条件を確定させないようにします。

元の言葉 確かめる質問 答えで変わる判断
資料検索を便利にしたい どの仕事の、どの場面で資料を探しますか? 最初に対象とする作業
なかなか見つからない 最後に探した資料と、そのとき使った言葉・探し方を見せてもらえますか? 資料の不足、名称の違い、操作の問題などを切り分ける
古い資料は出したくない 「古い」は更新日で決まりますか? それとも差し替え済み・利用終了などの状態ですか? 日付による除外か、版や状態の管理か
来月から使えるとうれしい いつ、どの作業で使う予定ですか? まず必要な範囲と、その日を動かせるかを教えてください 必要な時期と初回の範囲

この作例の「来月」は、依頼が書かれた日付も分からない表現です。AIが現在の日付から月を埋めるより、必要な日を依頼者に確認する質問を残します。

AIに頼む範囲を小さく決める

次の依頼文に、先ほどの4行を続けて渡します。実際の資料を使う場合は、利用するサービスに渡せる範囲へ置き換えてください。

以下の要望を、次の打ち合わせで確認する質問へ整理してください。

・元の文にない仕様、数値、期限、担当者を決めないでください。
・書かれていることと、あなたの推測を区別してください。
・質問は重要なものを最大4つに絞ってください。
・各質問に「対応する元の行」「答えによって変わる判断」を付けてください。
・機能一覧や完成した要件定義書にはしないでください。
・要望が空、または判断材料がない場合は、不足する情報を示してください。

要望:

4つは、この短い打ち合わせのための上限です。すべての案件で十分な数という意味ではありません。最初の質問で別の問題が見つかれば、調査対象や質問を見直します。

出力は、次の点を元の4行と照合します。

  • 「古い」を、AIが勝手に日数へ変えていないか。
  • 「見つからない」を、応答速度だけの問題と決めていないか。
  • 「来月」を、確定した納期として書いていないか。
  • 質問への回答を、すでに得た事実のように書いていないか。

たとえば「検索結果を2秒以内に表示する」という条件が出てきても、要望にはその数字がありません。性能目標として採用する前に、待ち時間が問題なのか、どう測るかを確認します。

回答を得たら、次の判断へつなぐ

「古い資料」の質問に、担当者から「日付が古くても現行版なら使う。差し替え済みの版だけ除外したい」と答えがあったとします。これも架空の回答です。

ここで初めて、更新日だけで資料を除外する案が合わないと判断できます。一方、どの資料が差し替え済みか、誰がその状態を更新するかは、まだ決まっていません。回答から分かったことと、次に確かめることを分けます。

確認できたこと:古い日付ではなく、差し替え済みの版を検索対象から外したい。
採用しない案:更新日が一定期間より前なら一律に除外する。
次に確認すること:版の状態はどこに記録され、誰が更新するか。

AIが質問を作れることと、要件が決まることは別です。この使い方の成果物は、もっともらしい仕様書ではなく、判断につながる質問です。

要件全体の整理は要件定義の始め方、決まった条件を確認可能な形にするなら受け入れ条件の書き方へ進めます。利用者への聞き方自体を見直す場合は、インタビューの質問を見直すも参考にしてください。

実際に渡すと、何が返ったか

2026年9月15日、この記事の依頼文に4行の要望を続け、Codexの別の作業エージェントへ渡しました。この記事の比較表や会話履歴は渡していません。実行は1回で、追い質問や応答の選び直しはしていません。入力は架空の要望です。

応答は、元の行との対応を付けた4行の質問表でした。たとえば、「古い資料」については次の質問が返りました。

「古い資料」は、何を基準に判断しますか?

日数や機能を勝手に決めず、基準を聞く形になっています。一方、利用開始の希望には次の質問が返りました。

「来月から使える」は希望ですか、それとも必須の期限ですか? その時点で、どの困りごとが解消されている必要がありますか?

この一行には、期限の強さと、最初に解消したい困りごとの二つが入っています。4行の表でも、聞くことが4つとは限りません。 打ち合わせでは一つずつ聞き、具体的な日付も確認する必要があります。今回の応答には「何月何日から使うか」を直接聞く質問はありませんでした。

この1回で確認できたのは、入力にない日付や判定基準を確定せず、質問候補を返したことです。別の入力でも同じ結果になるか、聞き取りの時間が短くなるかは分かりません。使うときは、表の行数だけでなく、質問が一度に聞ける大きさか、判断に必要な情報が残っていないかを見直してください。

Loading...