会話の記録を仕事に使う
要件定義ヒアリングの質問例｜進め方と記録シート
システム開発やIT導入の要件定義で、利用部門から要望を聞き取るときの質問例と進め方です。要望・業務ルール・制約の分け方、非機能要件の聞き方、要件候補一覧の記入例を紹介します。
公開日：更新日：執筆・運営：Klang AI AB
どのヒアリングか：業務・要件定義・営業の違い
「ヒアリング」は目的によって、聞く相手も残す成果物も変わります。このページが扱うのは「（このページ）」の行です。
要件定義の前に業務ヒアリングを行っておくと、「今の仕事のどこで困っているか」を根拠に要件を議論できます。現状が分からないまま要望だけを集めると、使われない機能が増えやすくなります。
| 種類 | 目的 | 主に聞く相手 | 成果物 |
|---|---|---|---|
| 業務ヒアリング | 今の仕事の流れと例外を把握する | 現場の担当者 | 業務フロー・現状把握シート |
| 要件定義ヒアリング（このページ） | システムやITに求める条件を決める | 利用部門・管理者・情報システム担当 | 要件候補一覧・確認条件 |
| 営業・相談のヒアリング | 顧客の課題と導入条件を聞く | 見込み顧客・相談者 | ヒアリングシート・商談記録 |
要件定義ヒアリングの進め方：4回に分ける例
一度の会議ですべてを聞こうとすると、目的と細かい画面の話が混ざります。以下は、利用部門との聞き取りを4回に分けた一例です。
- 01
1回目：目的と成功の条件
今回の変更で何ができるようになれば成功か、誰がそれを判断するかを聞きます。機能の話はまだしません。
- 02
2回目：現在の業務と例外
直近の一件を始まりから説明してもらい、例外・差し戻し・手作業の確認を拾います。業務ヒアリングの結果があれば、それを確認する形で進めます。
- 03
3回目：要望と制約
欲しい機能、変えられない条件（期限・既存システム・規程）、利用者の役割を聞き、要求・業務ルール・制約・実現案に分けて記録します。
- 04
4回目：要件候補の読み合わせ
要件候補一覧を見せ、根拠の発言と確認状態を一行ずつ確かめます。未決の項目には、確認者と判断の時期を書きます。確かめた候補は、要件定義書の機能要件・非機能要件・未決事項の章に移します。
要件定義ヒアリングの質問リスト（観点別）
要件定義ヒアリングは、欲しい機能を並べるだけの場ではありません。誰の何を変えるのか、現在の仕事と制約から確かめます。
| 観点 | 最初の質問例 | 見せてもらうもの・追加確認 |
|---|---|---|
| 目的 | 何ができるようになると、今回の変更は成功ですか。 | 判断する人と確認の方法 |
| 現状 | 直近の1件を、始まりから説明してもらえますか。 | 個人情報を除いた帳票や画面 |
| 例外 | 通常どおり進まなかった例はありますか。 | 差し戻し・承認・やり直しの経緯 |
| 利用者 | 誰が、どんな条件で使いますか。 | 役割と利用場面 |
| 制約 | 変えられない条件は何ですか。 | 期限・既存の仕組み・運用上の制約 |
| 確認 | 今日の話のうち、誰の確認が必要ですか。 | 確認先と未決事項 |
聞き取りだけで確定せず、資料や実際の作業と照合します。組織で定めた要件定義・合意の手順を優先してください。
要望の分類方法：要求・業務ルール・制約・実現案
同じ会話でも、すべてが承認済み要件とは限りません。架空の受注管理の発言を分類します。
| 発言 | 記録する区分 | 次の確認 |
|---|---|---|
| 『翌朝までに一覧が必要』 | 利用場面・要求候補 | いつ、誰が、何を判断する一覧か |
| 『20万円以上は承認が必要』 | 業務ルールの候補 | 正式な規程と適用例外 |
| 『今の認証基盤は変えられない』 | 制約の候補 | 確認した担当部署 |
| 『赤いボタンにしたい』 | 実現方法の提案 | 解決したい問題は何か |
| 『CSVで出せると助かる』 | 要望 | 出力先・項目・頻度・必要性 |
| 『来週から使うと決めたわけではない』 | 未決定の確認 | 開始日は保留として残す |
区分は検討のための整理です。発言者の肩書きだけで確定とみなさず、決定権限と承認状態を別に記録します。
要件候補一覧の作り方（発言から追えるCSV）
一つの行で、元の発言、要件候補、対象範囲、確認条件、決定者を結びます。時刻がない資料は資料名・項目番号を使います。
| 候補ID | 根拠（架空） | 要件候補と確認 | 状態 |
|---|---|---|---|
| R-01 | 面談A 12:30『翌朝の集計に使う』 | 対象注文を日付で抽出。対象日付の定義は未確認 | 候補 |
| R-02 | 業務資料2章 | 金額条件に応じた承認。例外の確認が必要 | 確認中 |
| R-03 | 面談B 08:10『今回は帳票変更しない』 | 帳票改定は今回の対象外候補 | 範囲の承認待ち |
空欄をAIに埋めさせず、未確認事項を次の質問にします。このCSV自体が正式な要件定義書や契約の承認を示すものではありません。
要件候補一覧の作り方（発言から追えるCSV）のCSVをダウンロード（架空の記入例つき）部門間で要望が対立したときの整理方法
営業は入力を減らしたい、管理部門は承認情報を残したいという架空のケースです。片方の発言だけを採用しません。
| 立場 | 要望と理由 | 確認・判断すること |
|---|---|---|
| 営業 | 訪問後すぐ登録したいので入力を減らしたい | その時点で必須の情報は何か |
| 管理 | 承認の判断材料が不足すると差し戻す | 登録時と承認時で必要項目を分けられるか |
| 候補案 | 一時保存と承認申請を分ける | 業務・システム双方で実現可能か |
| 未決事項 | 申請時の必須項目と責任者 | 決定者に確認するまで確定しない |
記録欄：相反する要求／背景／共通の目的／案ごとの影響／確認担当／決定状態。単に『合意した』と要約せず、残った相違を残します。
非機能要件の聞き方：「速い」「安全」を測れる質問に変える
値をこちらで作らず、どの状況で何を確認するのかを聞きます。数値は回答を得るまで未確認です。
| 曖昧な要望 | 追加で聞くこと | 記録する形 |
|---|---|---|
| 速く表示したい | どの操作、データ量、同時利用条件で、どの待ち時間を許容するか | 操作＋条件＋確認方法＋目安（未確認可） |
| 常に使いたい | 必要な曜日・時間帯、停止時の代替手順は何か | 必要時間帯＋停止時の業務影響 |
| 安全に共有したい | 誰がどの情報を閲覧・変更できる必要があるか | 役割＋対象情報＋許される操作 |
| 大量に保存したい | 対象件数、増加量、保存の目的と期間は何か | 量＋期間＋管理担当 |
『応答は必ず1秒』のような条件を発言にないまま補いません。目標と保証、希望と承認済み条件も分けます。
要件変更の記録方法：元の判断を残して版を分ける
以下は架空のR-01の履歴です。後の発言があるだけで、前の合意が自動的に無効になるわけではありません。
| 版・日付 | 内容 | 状態と次の作業 |
|---|---|---|
| v0.1／10月6日 | 日次一覧を希望 | 候補・利用条件を確認 |
| v1.0／10月10日 | 確定した対象項目で日次出力 | 社内手順で承認済みの記録へ参照 |
| 変更依頼／10月13日 | 部署別の項目を追加したい | 影響と優先順位を確認 |
| 次の版 | 変更内容・理由・対象を記載 | 必要な承認後に確定 |
元の発言、変更理由、影響する項目、判断記録をひも付けます。議事録の修正と、要件そのものの変更を区別してください。
AIで要件候補を抽出するプロンプト例
会話にない仕様や責任者を補わせない指示例です。出力後に人が該当発言と資料を照合します。
| 架空の入力 | 候補出力 | 残す未確認点 |
|---|---|---|
| 12:30『翌朝の集計で一覧を使う』 | 日次一覧の候補／根拠12:30 | 項目・日付基準・確認条件 |
| 18:10『赤いボタンだとよいかも』 | 実現案の提案／根拠18:10 | 解決したい問題 |
| 22:00『開始日はまだ決めない』 | 開始日は未決定 | 確認者・判断時期 |
候補IDを付けた後も、確認済みと決定済みを混同しません。存在しない時刻や資料番号を出した行は採用せず、元の記録へ戻します。
この文字起こしから、要件定義の検討材料を抽出してください。 出力列：根拠の発言・時刻／区分（要求候補・業務ルール・制約・実現案・未決事項）／要件候補／対象範囲／確認が必要な質問。 発言にない仕様、数値、担当者、承認状態は作らず「未確認」としてください。 矛盾する発言は両方残し、後の発言だけを自動採用しないでください。 これは要件の確定ではなく、関係者が確認するための下書きです。
ヒアリングの録音から、要件候補の根拠へ戻る
要件定義の会議をKlangで録音または録音ファイルをアップロードして文字起こしすると、要件候補一覧の各行に「根拠の発言と時刻」を付けられます。後で「誰がそう言ったのか」と問われたときに、元の発言を再生して確かめられます。
- AIチャットで要望・制約の候補を拾い、人が分類を確かめる
- 矛盾する発言は両方残し、確認者に回す
- 会議の文字起こしはWord・Excel・CSVなどで書き出せる
よくある質問
要件定義ヒアリングでは、最初に何を聞けばよいですか？
「何ができるようになると、今回の変更は成功ですか」と目的から聞きます。続けて、直近の一件の業務の流れ、例外、利用者、変えられない制約、確認が必要な人を順に聞くと、要望を目的と結び付けて整理できます。
要望と要件は何が違いますか？
要望は利用者が話した「こうしたい」という希望で、要件は目的や制約と照らして関係者が確認し、作る・選ぶ条件として合意したものです。ヒアリングの場で出た内容は、承認されるまで要件候補として扱います。
非機能要件はどう聞けばよいですか？
「速く」「安全に」などの言葉を、どの操作・データ量・時間帯で、何を確認できればよいかという質問に変えます。数値の目安は相手から回答を得るまで未確認とし、聞き手が補わないようにします。
要件定義ヒアリングの議事録には何を残しますか？
発言者と時刻、発言の区分（要求候補・業務ルール・制約・実現案・未決事項）、要件候補、確認が必要な質問と確認者を残します。後から要件が変わった場合も、元の発言と判断の記録は消さずに版を分けます。