要件ヒアリングの質問項目｜現状・例外・判断者を確認する聞き方
「どんな機能が欲しいですか」と聞くだけでは、現在の業務で困っている箇所や、例外時の処理が見えにくくなります。要件ヒアリングでは、直近の仕事を一つたどり、入力・判断・受け渡し・例外を確認することから始めます。
以下は社内申請を題材にした一般解説です。会話や条件は説明用で、実際の利用者の発言ではありません。聞き取った個人情報や機密情報は、許可された保存先と共有範囲で扱ってください。
機能の希望より先に、実際の流れを聞く
「普段どうしていますか」は入口として使えますが、回答が抽象的なら「最近の一件は、何を受け取ってから始まりましたか」と具体化します。規程上の標準手順と、実際の手順を別に記録します。
聞き手が先に答えを誘導しないことも大切です。「入力項目が多くて困っていますよね」ではなく、「どの場面で時間がかかりましたか」と聞きます。想定と違う話が出たら、仮説を守るために切り捨てず、何が違ったのかを確認します。
質問表は、現状から例外へ進む
| 観点 | 質問例 | 残したい情報 |
|---|---|---|
| 開始条件 | 最近の一件は、何をきっかけに始まりましたか | 起点と入力情報 |
| 手順 | その後、誰が何をしましたか | 作業順と受け渡し |
| 判断 | 承認・差戻しは何を見て決めますか | 判断条件と権限 |
| 例外 | 情報が足りない、担当者が不在のときはどうしましたか | 例外処理と代替窓口 |
| 頻度 | この処理は、どの範囲でどの程度ありますか | 母数・期間・概数か実績か |
| 困りごと | どこで止まり、誰へ影響しましたか | 現状の問題と影響 |
| 望む状態 | 何ができれば業務上の問題が減りますか | 達成したい結果 |
| 合意 | 条件を確定するのはどの役割ですか | 判断者と確認先 |
相手が分からない項目を無理に答えてもらう必要はありません。分からないものは確認先と期限を記録し、別の担当者へ聞きます。一人の回答を全拠点・全部門の標準として扱わないようにします。
発言を、そのまま確定した要件へ変えない
「通知が欲しい」という発言は、要求の入口です。何の状態を、誰へ、いつ、どの情報まで知らせる必要があるかを確かめます。メール通知が唯一の解決策とは限りません。
聞き取り後は、観察・発言、解釈、要件候補、未決を分けます。「承認の結果を確認するため何度も問い合わせた」は説明用の発言、「状況が見えないことが負担」というのは解釈です。要件候補として「申請者が処理状況を確認できる」と置き、対象・権限・例外を確認します。
解釈を含めて相手へ戻すときは、「この理解で合っていますか」と確認します。録音や文字起こしをする場合も、その可否と利用目的を事前に合意します。
話が広がったときは、優先する確認へ戻る
限られた時間で、すべての希望を深掘りする必要はありません。今回の範囲を決めるために必要な質問を先に用意し、関連するが別の話は保留一覧へ置きます。
ただし、新しい話が、当初の前提を覆す重大な例外なら、予定した質問順に固執しないでください。たとえば部門によって承認権限が違うと分かった場合、入力項目の細部より体制と対象範囲の確認を優先することがあります。
終わりには、確認できたことと未決を読み合わせます。相手に依頼する回答の内容・方法・期限を明らかにし、「後で資料をください」だけで済ませないようにします。
結果の整理表を、次の設計へ渡す
確認ID 対象業務 観察・発言 解釈 要件候補 例外 確認する役割 未決 根拠資料 合意状態要件候補には、受入条件を考えられるだけの具体性が必要です。一方、聞き取り段階で技術方式を決めつける必要はありません。業務上の必要性と技術的な実現方法を分け、双方の担当へ確認します。
ヒアリングの成果は質問の数ではなく、次の判断に必要な不明点が減ったことです。分からなかった事項を見える形で残すことも、有用な成果になります。
次に確認したい実務ガイド
PMO実務テンプレート・確認表の一覧から、目的に合う記事を探せます。
参考情報とこの記事の位置づけ
利用者の仕事や問題を深く理解するインタビューの考え方を確認しました。質問表は要件整理向けに独自作成しています。 GOV.UK Service Manual：Using In-depth Interviews（確認日：2026年10月11日）。記入例・確認表は当サイトが説明用に作成したもので、実在の案件・実績ではありません。
質問の使い分けも必要な作業に合わせて参照してください。
アイキャッチ写真：Headway / Unsplash。職場の実写ではなくイメージ写真です。
