【保存版】初めての要件定義：ヒアリング質問テンプレート10選
「結局、何を作ればいいのか？」を最短で言語化する――
それが要件定義フェーズ最大の目的です。では、初対面のクライアントに どんな質問 を投げれば“ズレない仕様書”へたどり着けるのでしょうか。
1. 要件定義ヒアリングの全体像
- ビジネスゴールを理解する
- ユーザー像と利用シーンを描く
- 機能／非機能／制約を漏れなく洗い出す
- 優先順位と受け入れ基準を整理する
この流れを外すと、後工程（設計・開発）で「そもそも前提が違った…」と手戻りが発生。
良い質問は、後のすべてのコストを下げる投資 だと覚えておきましょう。
2. ヒアリング前に準備する 3 つのチェックポイント
| チェック | 具体アクション |
|---|---|
| 対象業務の流れ | 事前に現行業務フロー（AS-IS）を手に入れる／作成する |
| 関係者マップ | 決裁者・利用者・システム管理者をイニシャルで書き出す |
| 既存システム／資料 | 画面キャプチャ・ER図・契約書など過去ドキュメントを収集 |
3. “鉄板” 質問テンプレート 10 選
| # | カテゴリー | 質問例 | 補足／フォローアップ |
|---|---|---|---|
| Q1 | ビジネスゴール | 「今回のシステムで“何が変われば成功”だと言えますか？」 | KPI 数値・期間を聞くと測定基準が明確に |
| Q2 | 現状課題 | 「現在の業務で最も困っているポイントを 3 つ教えて下さい」 | 痛みの大きさ＝優先順位／投資対効果の指標 |
| Q3 | ユーザー像 | 「主な利用者は誰で、一日の利用シーンをステップで説明すると？」 | ペルソナ＋タイムラインで具体化 |
| Q4 | 必須機能 | 「“MUST” と “WANT” を分けると、最小構成は何になりますか？」 | MoSCoW/WSJF など優先フレームに落とし込む |
| Q5 | 非機能（性能） | 「ピーク時の同時アクセスと許容レスポンス時間は？」 | 規模見積り＆インフラ選定の基礎データ |
| Q6 | 非機能（セキュリティ） | 「取り扱うデータの機密性ランクと求める認証方式は？」 | 個人情報/機微データの有無を明確化 |
| Q7 | システム連携 | 「他システムとの入出力データ形式・タイミングは？」 | CSV・API・Webhook など I/F を早めに特定 |
| Q8 | 法規制／制約 | 「業界ガイドラインや社内規定で守るべきルールはありますか？」 | 電子帳簿保存法・GDPR など後出しを防止 |
| Q9 | 移行／リリース | 「いつ、どの業務から切り替えますか？並行運用は必要ですか？」 | データ移行計画・トレーニング計画と連動 |
| Q10 | 受け入れ基準 | 「テスト合格の判断は誰が、何を根拠に行いますか？」 | UAT シナリオと KPI の“ゴールテープ”を定義 |
4. テンプレート活用ステップ
- 質問リストを案件用にカスタマイズ
– 上の 10 質問を Google ドキュメントや Notion にコピーして補足欄を追加 - ヒアリングメモを“その場で”整理
– 口頭回答はリアルタイムでモザイク図（Miro など）に反映し全員で確認 - 24 時間以内にサマリ資料を共有
– 誤解の芽を早期に摘む。議事録は質問番号をキーに紐付けると読み返しやすい
5. よくある落とし穴 & 回避策
| 落とし穴 | ありがちパターン | 回避策 |
|---|---|---|
| 要件の“決め手”が存在しない | 決裁者が不在、発言権が分散 | RACI を先に作り「最終 Yes/No」を誰が出すか固定 |
| 要件が“膨張”していく | 初回ヒアリングがアイデア会議化 | “MUST/WANT” ラベルをリアルタイムで貼り、時間を区切る |
| 複数部門で回答が食い違う | 部門毎に前提が異なる | クロス部門ワークショップを設け、As-Is→To-Be を合意形成 |
6. まとめ：質問リストは“生き物”として育てる
- 案件ごとに加除修正 → ナレッジ化
- 回答例や失敗事例を脚注として追記
- Slack #downloads に最新版を常時アップ（←PMBASE コミュニティで実施中）
🚀 今日のアクション
- 上記 10 質問をコピペして自案件ヒアリングシートを作成
- 関係者マップを描いて“誰に何を聞くか”を当てはめる
- 初回ヒアリングを 30 分 × 2 セッションでブッキング
良い質問が、良い仕様書の 80% を決める。
PMBASE のテンプレートで、あなたの要件定義を“最短・最小ストレス”で仕上げましょう！
コメント