エンジニアの顧客ヒアリング｜課題理解のための質問4段階と実装に渡す確認メモ

「対応状況が分かる一覧を作ってほしい」。顧客からこう頼まれたとき、表示項目や検索条件だけを聞いて実装へ進めてよいでしょうか。まず確かめたいのは、誰が何を判断するための一覧で、今どこで仕事が止まっているかです。

エンジニアの顧客ヒアリングでは、前提確認、現状、困りごと、制約の順に質問し、聞けた事実と自分の解釈を分けて残します。課題理解の到達点は、機能の名前を決めることだけではありません。何を作れば役立つかを確かめる場面と、まだ決められないことを明らかにすることです。

「一覧がほしい」を受けたら、何を理解して帰るか

本記事では、担当者が対応状況を確認する一覧を依頼された、という説明用の仮定を使います。特定の企業や導入案件の事例ではありません。同じ「一覧」でも、担当者が次の処理を選ぶ画面なのか、管理者が滞留を調べる画面なのかによって、必要な情報は変わります。

打ち合わせの前に、「今回分かれば設計が進むこと」を短く書き出します。たとえば、一覧を開くきっかけ、見た後の行動、今その判断に使っている情報です。用意する仮説は「情報の更新が遅いのかもしれない」までにとどめ、質問の答えに埋め込まないようにします。

対象者の選定や調査全体の組み立ては、顧客インタビューの目的設定と対象者選びも参考になります。そのうえで、実装を担う人は「利用者が答えられること」と「管理者やデータの管理担当に確認すること」を分けて準備します。

前提確認→現状→困りごと→制約の順で聞く

以下の4段階は、聞き漏らしを点検するための本記事の整理です。会話の順番を固定する必要はありません。相手が困った場面を話し始めたら先に聞き、後で前提や制約へ戻ります。

前提確認：誰の、どの判断を扱うか

最初は「一覧を最初に開くのは、どの仕事をしている方ですか」「その方が判断した後、誰の仕事が進みますか」と聞きます。依頼者と利用者が違う場合は、利用者本人へ確認できる機会も相談します。「対応済み」「完了」といった言葉は、「何が終わった時点ですか」と意味を合わせます。

背景を調べていても、担当範囲は決めつけません。「今日は受付後の対応を伺う予定ですが、前後に確認した方がよい仕事はありますか」と入口をそろえます。記録の方法、閲覧者、録音の可否も説明し、AIで整理する予定があれば、その扱いも事前に確認します。

現状：直近の作業を始まりから完了までたどる

「普段はどうしていますか」に加え、「直近で状況を確認したとき、何を受け取って、最初に何を開きましたか」と具体的な経験を聞きます。続けて、参照した情報、判断、入力、次の人への引き渡しをたどります。共有可能な画面や空欄の帳票を使い、説明と実際の操作の対応を確認すると、抜けた工程を質問できます。

英国政府のインタビュー手引きでも、開かれた中立的な質問を用い、あるべき姿の一般論より具体的な経験を聞くことを勧めています。「一覧があれば楽ですよね」より、「確認が終わったと判断したのは、何を見たときですか」と聞く方が、判断に使う情報を確かめられます。

通常の処理を聞いたら、「情報がまだ届いていないときはどうしますか」「担当者が不在なら誰へ回しますか」と例外も聞きます。前の人の確認が終わらなければ次へ進めない箇所を、画面の操作と一緒に記録します。

困りごと：どこで止まり、誰に影響したか

「状況が見えない」という回答には、「最後にそう感じたのは、どんな場面でしたか」「何が分からず、次に何をしましたか」と続けます。探すのに手間がかかったのか、更新されていなかったのか、閲覧権限がなかったのかで、確かめる対象が変わります。

さらに「確認できなかったことで、誰のどんな作業が待ちましたか」「問題なく進んだときは何が違いましたか」と聞きます。頻度や所要時間が分からなければ、記憶から数字を作らず、後で照合できる記録と確認先を相談します。原因の仮説は必要ですが、聞き手が考えた理由を相手の回答として残さないことが大切です。

制約：何を変えてよく、誰が決めるか

最後は「この情報を正しいと決める担当は誰ですか」「更新する人と時点を変えられますか」「利用者ごとに見せられない情報はありますか」と、実装と運用の条件を聞きます。期限があるなら日付に加えて、その日に必要な理由と、間に合わせる対象を確認します。

答えられないことが出たら、「では変更可能として進めます」とは扱わず、確認する相手と回答が必要な時点を決めます。「不在時は管理者が代行できる」という回答も、業務上そうしたいという希望なのか、現在の規程や権限設定で可能なのかを確かめます。

聞き取りは「事実・解釈・未確認・合意」を分けて残す

会話を要約するだけだと、発言と設計者の推測が混ざります。確認メモには、対象の仕事と聞き取り日時に加え、各記述を何によって知ったかを書きます。担当者からの説明、画面で確認した動き、手順書にある決まりは区別しましょう。

たとえば、先ほどの仮定を使うと、次のように書き分けられます。これは記入方法の例であり、実際に聞き取った結果ではありません。

• 事実：担当者は、回答済みか分からないときに過去の連絡を探すと説明した。今回、実際の検索操作は確認していない。
• 解釈：一覧の有無に加えて、回答結果を記録する場所が分かりにくい可能性がある。設計者の仮説として扱う。
• 未確認：回答結果をどこへ記録する決まりか。業務の管理担当へ手順の提示を依頼し、画面項目を決める前に確認する。
• 合意：次回は、共有できる資料で通常の対応と差し戻し時の流れを確認する。回答状況の自動更新は、まだ実装範囲に含めない。

事実の欄に「担当者は困っている」とだけ書くより、本人が話した状況を残す方が次の質問につながります。原発言を残す場合は引用と要約を見分けられるようにし、録音を参照するなら該当箇所と閲覧できる範囲を付けます。発言内容そのものが正しいかを、別の資料で照合する必要もあります。

終了前には、「回答結果の記録先を確認してから表示項目を決める、という進め方でよいですか。違う点や補足はありますか」と確認します。理解の確認と、実装への着手承認を同じ質問で済ませないようにします。確認メモを送っただけの状態は合意済みにせず、誰がどこまで確認したかを残してください。

実装に渡すのは、機能名と確かめる場面の組

「対応状況一覧を作る」だけでは、実装者が何をもって完成とするか判断できません。聞き取りの確認後は、「どの利用者が、どの状態で、何を操作し、何を確認できればよいか」という場面に直します。

たとえば、「担当者が自分の未回答の対象を開き、最後の回答記録と更新時点を確認できる」「回答記録がなければ、完了と見分けられる表示にする」といった確認案です。これも説明用の案なので、顧客と対象や意味を合わせてから受入条件にします。表示が正しくても、元の記録が更新されない問題が残るなら、その運用も検討対象です。

renueとして重視したいのは、AI化や効率化を考える際にも、仕事の流れと判断のつながりを理解してから実装の範囲を決める姿勢です。情報を集める機能だけを作っても、誰が確認して次へ渡すかが抜ければ仕事は完結しません。聞き取った内容を実装後にも照合できる形にすることが、ヒアリングの役割です。

開発の前後を含む流れは、顧客課題から設計・実装・運用へつなぐ進め方で整理しています。また、顧客理解と実装を結ぶ対話を組織の育成課題として考える際には、エンジニア組織に向けた人材育成の支援範囲にも接点があります。練習では質問数だけでなく、次の実装判断に使える記録を作れたかを振り返るとよいでしょう。

AIで整理しても、未確認を埋めずに次の質問へ戻す

2026年3月24日の英国政府の公開報告では、複数の利用者調査文書からAIで知見を抽出し、一つずつ人が品質と文脈を確認した取り組みが紹介されています。さらに、既存の知見を利用者の行動の流れへ対応付け、仮定や根拠の不足が残る箇所について追加の調査方法を記録しています。

本記事で参照した英国政府の手引きと事例は、英国の行政サービスを対象としています。日本の企業に取り入れる際は、契約、情報管理規程、承認権限に合わせて記録・利用の条件を決める必要があります。ここで参考にするのは、記録から根拠をたどり、不足を次の確認につなげる進め方です。

AIで確認メモを整理する場合も、まず入力できる情報の範囲を決めます。そのうえで「記録に書かれた内容だけを分類し、解釈には元の記述を付け、答えのない項目は未確認として質問案にする」と指示します。整った文章になっていても、発言していない理由や、合意していない期限が加わっていないか、人が原記録と照合します。

質問を終える基準は、空欄がなくなることではありません。確かめた事実から何を実装でき、どこは回答を待つ必要があるかを説明できることです。前提、現状、困りごと、制約をたどり、確認メモを顧客と見直す。その往復によって、課題理解を実装で確かめられる形へ変えていきます。