現場ヒアリングで集まる「探すのが面倒」「すぐ返したい」といった発言は、そのままシステム要件にはできません。発言の原文を残したうえで、現場の主張、観察された事実、業務上の仮説へ切り分け、テスト可能な判定条件を添えて関係者と合意を形成する手順が必要です。本稿では社内規程問い合わせ支援の架空案件をもとに、発言の受け付けから検証を経て合意を目指す台帳の整理例を示します。
発言をすぐ仕様にしない整理の基本
現場担当者から業務の困りごとを聞き取るとき、話された言葉をそのまま機能要件や画面設計の仕様書に書き写すと、後から想定と違うという齟齬が生じやすくなります。利用者が話す言葉には、実際に起きている事実だけでなく、個人的な感想や「こうしてほしい」という解決策の思い込みが混ざっているためです。まずは発言そのものを変えずに「原文」として残し、話者の役割や具体的な業務場面といった属性情報を別欄で管理して、同一の管理IDで紐づけて整理します。
聞き取った内容は、まだ裏付けが取れていない利用者の主張と、作業画面や履歴ログから確認できた観察事実に分けます。さらに、なぜその困りごとが起きているのかという作業上の理由を仮説として立て、それを解消するための具体的な仕組みを要件候補として組み立てます。発言の原文を加工せずに残し、推測と観察事実を明確に分ける作業が、仕様の食い違いを防ぐ基本姿勢となります。
本稿における要求と要件の整理は、IPAの『ユーザのための要件定義ガイド 第2版』をもとに解説されたIPA DX SQUARE『要件定義とは？』を参考にしています。同資料内のコラムでも触れられているとおり、JIS X 0166（国際規格ISO/IEC/IEEE 29148に準拠）では「requirement」が一括して要求または要件と訳されており、両者の区別に普遍的な標準定義はありません。同ガイドに準じて、ビジネス要求やシステム化要求を文書化し利害関係者と合意したものを実務上の「要件」と位置づけ、共通理解を作るための枠組みとして適用します。
現場で確認する場面と証拠の集め方
業務の困りごとを正しく把握するためには、抽象的な感想を聞くだけでなく、実際の業務の流れの中で「いつ、誰が、何を判断している場面か」を特定しなければなりません。同じ「検索が遅い」という言葉であっても、朝の定例作業中に発生しているのか、急ぎの問い合わせ対応中なのかによって、求められる応答速度や許容される確認手順は大きく異なります。
業務の文脈を細かく拾い上げる重要性は、現場実装を担うエンジニアの役割でも強調されています。FDE（Forward Deployed Engineer：現場展開型エンジニア）は、ビジネス側の文脈と開発側の実装を結びつける職種です。たとえばLayerXの公式エンジニアブログにおけるFDE募集解説では、前後の業務プロセスや暗黙知を深く理解し、ユーザーインタビューやログ解析を通じて実用的なAIワークフローへ落とし込む姿勢が紹介されています。これは同社固有の組織定義ですが、表面的な要望を聞くだけでは解くべき課題を見誤るという実務上の示唆を含んでいます。合意形成や判断単位の責任については、判断役割を整理した意思決定マトリクスの考え方を適用します。
ヒアリング台帳を作成する際は、観察事実の欄に「まだ証拠を取得していない」状態を明確に書き残すルールを設けます。現場で話を聞いた直後は、証拠は未取得であることが通常です。裏付けがない推測を確定事項のように扱わないために、仮説は「確かめる前の説明案」、要件候補は「関係者と合意する前の具体案」として定義し、調査が進んでいない項目が一目で判別できるように記録を管理します。
顧客ヒアリングにおいて、質問前の仮説立てと回答後の判断更新を練習したい場合は、顧客ヒアリングの練習問題（FDE自主教材）を活用してください。
自社の対象業務を整理する入り口として、AI自動化診断を活用できます。
3つの架空発言を要件候補へ変換する手順
ここからは、社内規程の問い合わせ窓口を運用する現場から出た3つの発言（R01「探すのが面倒」、R02「すぐ返したい」、R03「例外が不安」）をもとに整理手順を具体化します。なお、以下の例はすべて説明用の架空案件であり、実際の発言実績や実データに基づくものではありません。現在状態はいずれも「検証予定」です。
R01「探すのが面倒」の整理
窓口担当者が回答根拠を探す場面での発言です。安易にRAG（Retrieval-Augmented Generation：検索拡張生成。社内規程などの文書群を検索し、取得した関連箇所を生成AIに参照させて回答を作成する仕組み）の導入を即決せず、版管理や保管場所の整理も含めて検討します。解決手段を先に決めてしまうツール先行は、中小企業のAI導入 失敗パターン7選でも代表的なつまずきとして挙げられています。
- 主張（未確認）：規程の検索と根拠特定に過度な業務負担が生じている。
- 観察事実：証拠未取得（実査前）。
- 仮説：規程の版数や保管フォルダが分散しており、最新版の確認に迷いが生じている。
- 要件候補：照会に対する回答候補の提示時に、参照規程名・版数・該当箇所を表示する。
- 判定条件案（機能の動作確認）：合意されたテストケースにおいて、確認者が画面上で回答根拠の版数と該当箇所を正しく特定できること。
- 検証方法（課題解消の確認）：検索手順の実査と操作ログの確認により、根拠特定にかかる時間や迷いの発生状況を計測し、負担軽減につながるかを追加検証する。
R02「すぐ返したい」の整理
窓口担当者が一次回答を作成する場面での発言です。誤回答を防ぐため自動送信は行わず、窓口担当者の下書き作成後に窓口責任者が確認・送信する運用を前提とします。
- 主張（未確認）：回答準備に時間を要し、問い合わせ者への返答が遅れている。
- 観察事実：証拠未取得（実査前）。
- 仮説：下書き作成そのものよりも、回答作成後の責任者確認や差し戻し待ちが主な停滞要因である。
- 要件候補：下書き保存機能および確認待ちステータス表示を設け、システムによる外部への自動送信は範囲外とする。
- 判定条件案（機能の動作確認）：システムが候補文を外部へ自動送信せず、窓口責任者の確認待ちステータスへ正しく遷移すること。
- 検証方法（課題解消の確認）：下書き作成開始・確認依頼・確認完了・差し戻し・送信の時刻ログを計測し、作成時間と確認待ち時間の内訳を可視化して、確認待ち短縮に寄与するかを検証する。
R03「例外が不安」の整理
標準規程から外れる申請や問い合わせを受け付けた場面での発言です。
- 主張（未確認）：既存規程の記述だけでは対応可否を判断できない問い合わせが存在する。
- 観察事実：証拠未取得（実査前）。
- 仮説：規程に個別例外の判定基準や例外時のエスカレーション先が明記されていない。
- 要件候補：適用条件から外れる問い合わせに対し保留表示を行い、エスカレーション先窓口を提示する。
- 判定条件案（機能の動作確認）：合意された例外ケースにおいて、画面上に保留表示と所定の相談先が提示されること。
- 検証方法（課題解消の確認）：過去の例外案件ログを抽出・分類し、現場担当者が判断に迷うパターンを網羅できているかを業務責任者と確認する。
ヒアリング台帳の更新ルールと6つの状態
台帳で管理する状態は、直線的な進捗ステップではなく、検証や合意の状況に応じた分岐として扱います。本稿では「未確認」「検証予定」「合意待ち」「合意」「保留」「却下」の6つの状態を定義します。
- 未確認：発言の原文が記録され、事実確認や調査計画が未着手の初期状態。
- 検証予定：検証方法が策定され、実査やログ計測の実施待ち、または調査・結果整理を進めている状態（今回の3例の現在状態）。
- 合意待ち：確認担当によって仮説の検証結果、観察証拠、判定条件案、関係者への確認依頼が揃い、採用可否の判断を待っている状態。
- 合意：必要な関係者および合意判断者による採用判断、合意日、合意条件、判断根拠が記録された状態。
- 保留：前提条件の未充足、他システムの方針決定待ち、または関係者間の意見不一致により検討を一時中断した状態。
- 却下：検証の結果として課題が存在しないことが判明した、あるいは優先順位や他手段の採用によってシステム要件から外した状態。
保留となった項目は「再開条件」を記録し、条件が満たされた際に検証予定または合意待ちへ戻します。却下となった項目は行を物理削除せず、却下理由と証拠参照を残したうえで、必要に応じて後継IDを発行して新たな仮説を立て直します。
- 初期登録 未確認 現場の発言原文を記録し、話者や業務場面の属性を紐づけた初期状態
- 調査計画策定 検証予定 実査・ログ計測の計画を立て、確認担当が事実調査と結果整理を進める状態
- 証拠と判定条件案が充足 合意待ち 観察事実、要件候補、判定条件案、確認依頼が揃い、採否判断を待つ状態
- 関係者合意成立 合意 合意判断者および関係部署が採用を承認し、合意日と判断根拠を記録した状態
- 前提未充足・方針待ち・意見不一致 保留 検討を一時中断。再開条件を明記し、条件充足時に検証予定または合意待ちへ復帰
- 検証で課題否定・優先度外 却下 システム要件の対象外。物理削除せず理由と証拠を残し、必要に応じて後継IDを発行
保留時は再開条件を記録して待機し、却下時は行を削除せず不採用根拠を保持します。
以下の表は、配布している17列CSVの要約版（6列）です。確認担当と合意判断者を区別し、全例とも証拠未取得・未合意の「検証予定」として記録しています。
| ID | 原文 | 要件候補 | 判定条件案 | 確認担当 | 状態と証拠 |
|---|---|---|---|---|---|
| R01 | 探すのが面倒 | 照会に対する回答候補の提示時に参照規程名・版数・該当箇所を表示する | 合意されたテストケースにおいて確認者が回答根拠の版数と該当箇所を特定できること | 窓口担当リーダー | 検証予定（証拠未取得・未合意） |
| R02 | すぐ返したい | 下書き保存機能および確認待ちステータス表示を設け、システムによる外部への自動送信は範囲外とする | システムが候補文を外部へ自動送信せず、窓口責任者の確認フローへ正しく遷移すること | 窓口責任者 | 検証予定（証拠未取得・未合意） |
| R03 | 例外が不安 | 適用条件から外れる問い合わせに対し保留表示を行いエスカレーション先窓口を提示する | 合意された例外ケースにおいて画面上に保留表示と所定の相談先が提示されること | 業務責任者 | 検証予定（証拠未取得・未合意） |
上記の要約表に掲載した「確認担当」は、事実関係の調査やログ計測を主導する現場役割です。一方、要件採用の最終権限を持つ「合意判断者」や、合意日、合意条件といった合意管理項目は、17列台帳において個別に管理します。判断根拠は独立した列ではなく、証拠参照列とREADMEの変更履歴書式で残す設計としています。合意判断者1名だけの承認をもって現場全員の合意成立とみなすのではなく、関係部署間の運用合意が成立したことを確認したうえで「合意」へ更新します。合意後の検証計画や受入基準の詰め方については、運用引継ぎと完了条件の設計記事で詳しく扱っています。
例外処理と技術的実現性の確認手順
ヒアリング台帳を運用する中で、事実調査の結果として当初の仮説が成り立たないケースがあります。たとえば「版管理の混乱」を予想していたものの、ログを調べると単にポータルの検索画面の配置が見づらかっただけという場合です。このようなときは、要件候補を強引に確定させず、状態を一度「保留」または「却下」に変更し、新たな観察事実に基づいて仮説を立て直します。
また、現場担当者と業務責任者の間で意見が分かれることもあります。担当者は「即座に下書きを出してほしい」と望み、責任者は「誤回答の懸念があるため人間が最初から対応すべきだ」と考えるような場合です。このような食い違いが生じた際は、その場でどちらかの意見に決め打ちするのではなく、いったん機能の議論を止めて、誤回答が発生した際の影響度と許容範囲を業務責任者および関係部署と整理する手順を踏みます。
さらに、技術的な実現性に関する例外も存在します。規程に書かれていない暗黙のルールを推測させたいという要望が出た場合、直ちにデータ不存在と決めつけるのではなく、まず「社内のマニュアルや過去の判断履歴としてデータが存在するか、入手可能か」を確認します。確認の結果、判断根拠となる情報が存在しない、あるいは入手不可能であることが判明した場合に、台帳上で保留またはシステム化の対象外として整理します。
添付台帳の使い方とダウンロード
本稿で解説した整理手順を実務で利用できるよう、記入用のテンプレート、本文の3つの架空例を収録した台帳、および運用ルールをまとめた説明書を用意しました。
収録ファイルは以下の3点です（※ZIPファイルの到達、17列の台帳構成、初期状態［検証予定・証拠未取得・未合意］、READMEの状態規則は照合確認済み。実案件での実地検証および合意形成は未実施の設計例です）。
– interview_blank.csv：要件ヒアリングの項目を管理するための17列の空欄テンプレート
– interview_example.csv：本文で取り上げた3つの架空例を同一列順で記録した台帳サンプル
– README.md：台帳の各項目の定義、6つの状態遷移ルール、合意記録の残し方を解説した説明書
ヒアリング整理台帳一式（fde-requirements-interview.zip）をダウンロードする
空欄テンプレートを使用する際は、まず発言の原文をそのまま書き込みます。観察事実の欄は推測で埋めず、実際の画面や操作ログを確認できるまでは空欄または「証拠未取得」のままにしておくことが、実態に即した要件定義を行うための基本原則です。
よくある質問
要求と要件の違いはどのように整理すればよいですか
本稿ではIPAのDX SQUAREによる要件定義ガイドの解説に合わせ、利害関係者が業務上望んでいる要求事項を文書化し、関係者間で合意したものを要件として整理しています。ただしこれは実務を進めるための整理基準であり、すべての開発手法における普遍の定義ではありません。
利用者の発言内容はそのまま観察事実として扱えますか
利用者が発言した事象自体は事実ですが、発言内容そのものは裏付けが取れるまで未確認の主張として扱います。実際の画面ログや業務記録を調査し、客観的な証拠によって裏付けられた事項のみを観察事実欄へ記載して仮説の検証に用います。
定量的な数値目標が決まっていなくても要件候補を作成できますか
処理時間や削減率の目標数値が未確定であっても要件候補の作成は可能です。「自動送信せず確認待ちとする」といった動作条件や例外処理を先に定義し、数値目標は事前のログ計測や試行運用の結果を踏まえて合意形成を行う進め方が安全です。
検索に関する不満が現場から出た場合はRAGを導入すべきですか
現場から検索のしづらさに関する不満が出たからといって、直ちに社内規程を検索・参照するRAG（検索拡張生成）を採用する必要はありません。保管場所の散逸や古い版の混在が原因であれば、フォルダ構造の整理やファイル名規約の統一だけで解決する場合もあります。観察事実から原因を特定して技術方式を選定します。
参考資料
本稿の執筆にあたり参照した公開資料は以下のとおりです（最終確認日：2026-10-08）。
- IPA DX SQUARE『要件定義とは？』 ビジネス要求やシステム化要求を合意して要件へ落とし込む整理プロセスを参照しました。同資料のコラムで示されているとおり、要求と要件の区別は文脈による整理であり普遍的な標準定義ではない点に留意して整理しています。
- LayerX公式エンジニアブログ：FDE解説記事（2025-07-17公開） 前後工程の業務理解や暗黙知の抽出から実装につなげる役割の解説を参照しました。企業固有の職種解説であり、本稿のテンプレートの有効性を証明する資料ではありません。
業務の自動化や生成AIの適用に向けて対象業務を整理したい場合は、AI自動化診断をご活用ください。
