要件定義のヒアリング｜7つの質問
目次
ヒアリングが終わったのに、要件が決まっていない。そんな会議は珍しくない。
参加者は「申請を簡単にしたい」「承認を速くしたい」と話している。議 事録も残っている。ところが開発側が画面や権限を設計しようとすると、締め日、代理承認、差し戻し、保存期間が分からない。聞いた量は多いのに、実装できる判断が足りないのだ。
要件定義のヒアリングシートは、質問を漏れなく並べるためだけの道具ではない。要望を、業務ルール、例外、データ、品質条件、受け入れ条件へ変換する作業台である。ここでは、初回から詳細化まで繰り返し使える7つの質問に絞って整理する。
要件定義のヒアリングシートで分ける4種類
回答を一つのメモ欄へ詰めると、事実と希望が混ざる。AIで議事録を単に要約するだけでは、この混在は解けない。シートには、少なくとも次の4種類を別の列で持たせたい。
- 現状の事実：誰が、いつ、何を使い、何件処理しているか
- 将来の要望：どう変えたいか、何を減らしたいか
- 合意したルール：システムが守る条件と判断基準
- 未決事項：誰が、いつまでに決めるか
たとえば「承認を自動化したい」は要望である。「10万円未満かつ登録済み取引先なら部門長承認を省略する」まで決まるとルールになる。金額の境界を誰が承認するか不明なら、そこは未決事項だ。
IPAの要件定義解説でも、ニーズや課題を分析し、ビジネス要求とシステム化要求を文書化して合意する流れが示されている。ユーザのための要件定義ガイド 第2版では、要件定義で作る文書と注意点も整理されている。会話をそのまま清書するのではなく、要求を実装可能な条件へ変える工程が必要になる。
要件定義で確認する7つの質問
ヒアリングでは、次の7つを同じ順番で確認する。回答が曖昧なところは推測で埋めず、未決事項として担当者と期限を残す。
質問1：何を、どれだけ改善したいか
最初に機能を聞かない。「この取り組みが成功したと判断できる状態」を聞く。
- 現在、どの作業に何分かかっているか
- 月に何件あり、繁忙期は何件まで増えるか
- どのミスや待ち時間を減らしたいか
- いつまでに、どの水準へ変えたいか
- 速度、正確性、コストが衝突したら何を優先するか
「便利にする」では、優先順位も受け入れテストも作れない。「月末の申請確認を2営業日以内に終える」「入力不備による差 し戻しを月20件から5件以下へ減らす」なら、設計案を比較できる。
数字が取れない場合は、無理に作らない。計測方法と計測期間を未決事項として置く。根拠のない改善率を要件へ書くより、基準値がない事実を残すほうが安全だ。
質問2：誰が、どのきっかけで始めるか
業務名だけでは、利用者と権限が決まらない。開始条件と登場人物を一緒に聞く。
- 誰が処理を開始するか
- 何が届いたら開始するか
- 入力、確認、承認、監査を誰が担うか
- 代理担当や兼務者はいるか
- 社外の利用者や連携先はあるか
「経費精算を行う」なら、社員が領収書を受け取った時点で始まるのか、月末にまとめて始まるのかで通知や締め処理が変わる。申請者、直属上長、経理、監査担当では、見える情報と操作できる範囲も異なる。
人名ではなく役割で記録するのがコツだ。担当者が異動しても要件を維持できる。決裁者と実務担当の違いは、ステークホルダーの分析で先に整理しておくと聞き漏らしが減る。
質問3：通常はどの順番で進むか
正常系を一文で済ませず、開始から完了までを動詞で並べる。
- 申請者が証憑を登録する
- システムが必須項目と重複を確認する
- 上長が内容を承認する
- 経理が勘定科目と支払日を確定する
- 会計システムへ連携する
各段階で「入力」「判断」「出力」を聞く。上長は何を見て承認するのか。経理は何を修正できるのか。会計連携が成功したことを、どの状態で確認するのか。処理の箱だけでなく、箱の間を流れる情報まで押さえる。
複数システムをまたぐ場合は、データフロー図の書き方を併用すると、手入力、ファイル受け渡し、API連携の境界が見えやすい。
質問4：例外と禁止をどう扱うか
通常の流れだけを聞くと、実装後に例外が噴き出す。次の切り口で、過去に困ったケースを具体的に聞く。
- 金額、件数、期限が境界を超えたらどうするか
- 必須データが欠けたら止めるか、仮登録を許すか
- 承認者が不在なら誰へ回すか
- 連携先が停止したら再試行するか、手作業へ戻すか
- 誰にも許可しない操作は何か
- 締め後の修正や取消を誰が承認するか
「原則として受け付けない」では不十分だ。例外を許可する役割、必要な理由、記録する履歴、通知先まで決める。
禁止条件も重要である。自分の申請を自分で承認できない、支払確定後は金額を直接変更できない、監査ログは一般利用者が削除できない。禁止が明確だと、権限とテストの抜けが減る。AI要件定義で例外条件を先に決める方法もあわせて確認してほしい。
質問5：どのデータを正とするか
同じ「取引先名」でも、営業管理、会計、表計算に別の値があるかもしれない。項目名だけでなく、出どころと品質責任を聞く。
- 正式な値を持つシステムはどれか
- 誰が登録し、誰が修正を承認するか
- 必須、任意、形式、桁数、単位は何か
- 重複や不整合をどう検知するか
- 何年間保存し、いつ削除するか
- 個人情報や機密情報を含むか
データの正本が決まらないまま連携を作ると、どちらの値で上書きするかを開発者が推測することになる。ヒアリングシートには「項目」「取得元」「更新者」「利用先」「保持期間」「不整合時の処理」を持たせる。
質問6 ：どの品質水準が必要か
機能の話に集中すると、速度、可用性、セキュリティ、運用性が後回しになる。ところが費用と構成へ大きく影響するのは、むしろこちらだ。
- 何秒以内なら業務に支障がないか
- 同時に何人、繁忙時に何件を処理するか
- 何時間止まると業務継続が難しいか
- 復旧までの許容時間と、失ってよいデータ量はどれくらいか
- 認証、権限、ログ、暗号化にどの水準が必要か
- 誰が監視し、障害時に誰へ連絡するか
「高速」「24時間利用可能」「安全」といった形容詞は避ける。業務への影響から水準を決める。
IPAの非機能要求グレードは、重要な項目から段階的に要求レベルを確認する考え方を示している。すべてを最高水準にせず、必要な理由と費用の釣り合いを見ながら選ぶ。公開されている要件定義書の標準テンプレートも、項目の抜けを確認する参考になる。ただし、政府向けの文書構成をそのまま民間案件へ当てはめるのではなく、案件規模に合わせて絞る。
質問7：何を確認したら完成とするか
最後に、受け入れ条件と判断者を決める。
- どの操作や結果を確認すれば要件を満たしたと判断するか
- 正常系だけでなく、どの例外を試すか
- 使用するテストデータは誰が用意するか
- 誰が確認し、誰が最終承認するか
- 不合格だった場合、修正と再確認をどう進めるか
「申請できること」では曖昧だ。「一般社員が領収書画像と必須5項目を登録すると受付番号が発行され、直属上長へ1分以内に通知される」のように、主体、条件、操作、結果を一つにつなぐ。
受け入れ条件から逆算すると、聞き足りない項目が見える。画面操作を早めに確かめる案件では、モックアップの作成ツールを選ぶ観点も受け入れ条件の具体化に役立つ。詳しい書き方はAI要件定義は受け入れ条件から逆算するで整理している。
回答を要件へ変換するシートの列
質問だけを並べたテンプレートは、会議後の変換作業が弱い。要件定義のヒアリングシートには次の列まで用意すると、回答を仕様へつなぎやすい。
- 質問ID
- 質問と確認したい理由
- 現状の事実
- 将来の要望
- 合意した業務ルール
- 例外・禁止条件
- 根拠資料または発言元
- 未決事項
- 判断責任者と期限
- 対応する要件ID
- 受け入れ条件
一つの回答から複数の要件が生まれる場合は、要件IDを分ける。反対に、同じ要件の根拠が複数の会議に散らばるなら、出典を複数ひも付ける。質問と要件の対応が追えると、後日の変更理由も説明しやすい。
記入例：代理承認の回答を要件へ変える
経費申請の「承認者が不在ならどうするか」を例に、シートを埋めてみよう。
- 質問ID：H-04
- 質問：承認者が休暇や出張で不在の場合、誰がいつ代理するか
- 現状の事実：申請が本人の復帰まで止まり、過去3か月の最長待機は3営業日
- 将来の要望：月末でも承認待ちを1営業日以内にしたい
- 合意したルール：申請から24時間後に本人へ再通知し、48時間後に登録済み代理者へ回す
- 例外・禁止：10万円以上は代理承認せず、部門責任者へ回す。申請者本人は代理者になれない
- 根拠：業務責任者への第2回ヒアリング、現行の職務権限規程
- 未決事項：代理者が未登録の場合の通知先
- 判断責任者と期限：経理責任者、次回レビューまで
- 要件ID：R-014
- 受け入れ条件：10万円未満の申請を48時間未処理にすると代理者へ割り当てられ、本人と代理者へ履歴付きで通知される
ここまで書けば、「代理承認機能が必要」という一行より設計しやすい。設計側ではR-014を、代理者マスター、割り当て処理、通知処理、監査ログへ分ける。テストでは通常の代理、金額超過、代理者未登録、自己承認の禁止を確認する。
追跡番号もつなげておく。たとえば、質問H-04 → 要件R-014 → 設計D-021 → テストT-038と記録する。金額境界が10万円から5万円へ変わったとき、影響する設計とテストを同じ経路で探せる。顧客と開発会社のレビューでも、「誰のどの回答から生まれた仕様か」を説明できる。
7つの質問すべてをこの粒度で埋める必要はない。費用、権限、外部連携、法令、受け入れに影響する回答から優先して要件IDへ変換する。単なる質問集ではなく、この変換欄と追跡番号があることが、実装へつながるヒアリングシートの違いになる。
AIには整理を任せ、判断は任せない
AIはヒアリングの準備と整理に向いている。既存資料から確認候補を抽出する。会議中の発言を事実、 要望、決定、未決へ分類する。似た回答をまとめ、矛盾を指摘する。要件IDと受け入れ条件の初稿を作る。ここまでは速い。
一方で、優先順位、例外の許可、費用とのトレードオフ、法務・セキュリティ判断は責任者が決める。AIが空欄を自然な文章で埋めると、未決事項が決定事項に見えてしまう。生成した内容には、根拠、確度、確認者を持たせたい。
Kakusillは、要件定義・設計ドキュメントをAIが理解できる構造に正規化し、仕様の品質とスピードを同時に引き上げるプロダクトである。ヒアリングシートも単独の表で終わらせず、要件、設計、受け入れ条件へ追跡できる形にすると価値が上がる。
7つの質問を一度で完璧に埋める必要はない。初回は目的、登場人物、通常フローを押さえる。次の回で例外、データ、品質水準を詰める。最後に受け入れ条件を確認する。空欄を隠さず、誰がいつ決めるかを残す。それが、聞いただけの会議を、実装できる要件定義へ変える。
要件定義のヒアリング結果を仕様へ変換しきれず困っているなら、株式会社Atsumellへ相談してほしい。業務フローの整理から、要件、例外、受け入れ条件の構造化まで一緒に進める。
