要件定義は "工程" ではなく "対話" である
要件定義は、ヒアリングして文書を渡せば終わる工程ではなく、要求の解釈と完成条件を関係者で更新し続ける対話です。
最初にすべての詳細を確定する必要はありません。次の実装単位を進めるために必要な要求・制約・受入条件を明確にし、実装や検証で分かったことを上流へ戻します。
「要件定義とは何か」を先に整理したい場合は要件定義 完全ガイドを参照してください。
全体フロー：5フェーズの俯瞰
開発前には大きく5つの整理を行い、その後の実装・検証で得た事実を上流へ戻します。
- ステークホルダーと業務ゴールを明確にする
- 現状（As-Is）と目標状態（To-Be）を理解する
- 課題・要求を集め、未決事項を質問として残す
- 機能仕様をStoryへ分解し、非機能要件・制約を明確にする
- 受入可能な振る舞いを定義し、実装へ渡せる状態にする
要求 → 機能仕様 → 非機能要件・制約 → 受入仕様 → 設計 → 実装 → テスト → PR / CI → 顧客フィードバック → 不具合・変更 → 次の仕様・Regression
この5フェーズは「文書を完成させるまでのゲート」ではなく、次の実装単位を許容できるリスクで開始するための整理です。
フェーズ1：ステークホルダー特定とゴール定義
このフェーズで決めること
- 誰がこのシステムを使うのか（業務担当者・管理者・エンドユーザー）
- 誰が要件を承認するのか（プロジェクトオーナー・経営層）
- このシステムで達成すべき 数値目標 は何か
よくある失敗
「経理部長は途中から呼べばいい」と判断して、終盤で「経理処理の要件が抜けている」と発覚し、再見積もりが発生する。最初に呼ぶ人を誤ると、後工程で手戻りが起きやすくなります。
アウトプット例
役割 | 氏名 | 関与レベル | 期待アウトカム |
|---|---|---|---|
プロジェクトオーナー | 田中 | 承認権限 | 売上20%増、業務時間30%削減 |
業務担当 | 佐藤 | 日次運用 | 二重入力の解消 |
経理部長 | 鈴木 | 月次レビュー | 月次決算の早期化 |
情報システム | 高橋 | 技術検証 | 既存システムとの連携可否 |
このマトリクスができれば、フェーズ2以降の インタビュー対象と承認フロー が確定します。
フェーズ2：業務フローの可視化（As-Is / To-Be）
このフェーズで決めること
- 現状の業務フロー（As-Is）を、誰が・何を・いつ・どのツールで実施しているか
- 新システム導入後の業務フロー（To-Be）はどう変わるか
- As-Is と To-Be の 差分 が、システムが提供すべき機能の輪郭になる
よくある失敗
As-Is を書かずにいきなり To-Be を議論すると、「現場で本当に困っていること」が抜け落ちて、机上の空論で要件が決まる。現場ヒアリング → As-Is 図 → To-Be 議論 の順を守るのが重要です。
アウトプット例（抜粋）
[As-Is] 受注から請求までのフロー
営業 → 受注メール受領 → Excelに転記（手作業）
↓
営業 → 請求書テンプレート（Word）に手入力
↓
経理 → 請求書PDF確認 → 会計ソフトに転記（手作業）
↓
経理 → 入金確認 → Excelの売掛金台帳を更新
As-Is の問題点
- Excel と会計ソフトに同じデータを2回入力（二重作業）
- 営業のExcelと経理のExcelで金額がずれることが月3〜5件発生
- 請求書の発行までに平均5営業日かかる
[To-Be] CRM導入後のフロー
営業 → 受注情報をCRM入力 → 請求書自動生成
↓
経理 → CRMで承認ボタン → 会計ソフトへAPI連携
↓
経理 → 入金消込もCRM側で完結
To-Be の期待効果
- 二重入力を完全排除
- 請求書発行を1営業日以内に短縮
- 売掛金の整合性を100%保証
フェーズ3：要求収集とユーザーストーリー化
顧客や事業側の「何を実現したいか」を、いきなり詳細仕様へ変換しません。まず要求を正本として残し、その要求からユーザーや業務主体が何をできるようになるかをUser Storyとして分解します。性能・セキュリティ・法令・技術上の制約は、機能仕様へ混ぜず別のRequirementとして管理します。
このフェーズで決めること
- 各ステークホルダーが「やりたいこと（要望）」を吸い上げる
- 要望を ユーザーストーリー の形式に変換する
- ユーザーストーリーごとに 受入条件（Acceptance Criteria） を定義する
ユーザーストーリーのフォーマット
〇〇として（誰が）、
△△したい（何を）。
なぜなら××だから（なぜ）。
例：
営業担当として、受注メールから自動で請求書を作成したい。
なぜなら、転記作業に毎日30分使っているから。
よくある失敗
受入条件（Acceptance Criteria）を書かずに次フェーズに進む。受入条件はテストケースの元になるため、これが曖昧だと後工程で「どう動けば正解か」を決めるたびに発注側に再確認が走り、開発が止まります。受入条件は EARS記法 で書くと曖昧さが減ります（→ EARS記法ガイド）。
要件定義でのAI活用の可否は要件定義にAIは使えるかで整理しています。
作るものを一緒に整理する 要望メモ、既存資料、口頭のアイデアだけでも構いません。何を最初に作るべきか、開発会社へどう伝えるかを整理します。フェーズ4：要件の整理と優先順位付け（FM）
このフェーズで決めること
- 各要件を 3軸（ビジネス価値 × 現場で使えるか × 技術コスト） で評価する
- 第1リリースで 作る／後回し／作らない を確定する
- 「やらないこと」を明示してスコープを締める
FM の3軸
要件の優先順位付けは、書籍『システムを作らせる技術』(白川克) の FM（ファンクショナリティ・マトリクス） をベースに、Beekle では以下の3軸で評価します。1軸（重要度だけ）で判定すると「重要だけど現場が使わない」「重要だけど技術的に難しすぎる」要件をそのまま着手してしまい、投資が無駄になりやすいためです。
軸 | 意味 | 評価 |
|---|---|---|
ビジネス価値 | 経営インパクト・売上／コスト効果 | ★1〜3（多いほど良い） |
現場で使えるか | 現場が実際に使う準備（運用・教育・受け入れ）が整うか | ★1〜3（多いほど良い） |
技術コスト | 実装・運用・既存システム連携の難易度 | 低／中／高（低いほど良い） |
判定ロジック
状態 | 判定 |
|---|---|
どれか1軸でも ★1（または技術コスト=高） | 作らない（使われない／作れない／投資回収できない） |
★3 が2つ以上 | 作る |
それ以外（中間） | 後回し（次リリース候補） |
アウトプット例
要件 | ビジネス価値 | 現場で使えるか | 技術コスト | 判定 |
|---|---|---|---|---|
受注登録 | ★★★ | ★★★ | 低 | 作る |
請求書自動生成 | ★★★ | ★★ | 中 | 作る |
売上ダッシュボード | ★★ | ★ | 中 | 作らない（現場が使う準備不足） |
多通貨対応 | ★ | ★ | 高 | 作らない |
顧客別の請求パターン | ★★ | ★★ | 中 | 後回し |
よくある失敗
全要件を「作る」として記録してしまう。これでは優先順位が無いのと同じです。FM を使うときは 「現場で使えるか」を必ず別軸で評価する こと。ビジネス価値だけで判断すると、「経営層は欲しがるが現場は使わない機能」を作って失敗します。
フェーズ5：要件定義書の作成とレビュー
このフェーズの目的は、一冊の要件定義書を「完成品」にすることではありません。要求・機能仕様・非機能要件・制約・受入条件・未決事項を、誰が見ても関係を追える状態にし、次の実装単位を開始できるかレビューします。
正常系だけでは完成判定にならないことがあります。異常系、境界条件、権限、外部連携失敗時など、重要な例外を受入条件へ含めます。
このフェーズで決めること
- フェーズ1〜4の成果物を統合した 要件定義書（10章構成） を作成
- ステークホルダー全員でレビュー → 合意形成
- スコープ確定書（"今回作らないもの" の明示）に署名
要件定義書の章立て
要件定義書テンプレート で詳しく解説しているテンプレートを使うと、章立ての抜け漏れを防げます。Word／Excel／Markdown の3形式を無料配布しています。
実装・テスト・顧客フィードバックを上流へ戻す
要件整理の後は、仕様をTaskへコピーして別の正本を作るのではなく、Taskを元のStoryやScenarioへ接続します。実装後も、受入条件に対するTestResult、PR、CIの結果までつなげます。
顧客から曖昧な点への回答をもらった場合は、顧客回答 → 変更案 → 人間による確認 → 正本へ反映の順に扱います。AIが回答を直接仕様へ上書きすると、文脈の取り違えを正本へ固定する危険があるためです。
上流情報が変わったら「どのStory、Scenario、Task、設計、テストへ影響するか」を確認します。重要なBugもRoot Causeを確認し、仕様不足ならScenario / Regression Testへ戻して次回のQuality Gateへ反映します。
要件定義で失敗しないチェックリスト
- 解決したい業務課題と要求の正本が残っている
- 機能仕様と非機能要件・制約を区別できている
- 未決事項が質問として残り、判断者が分かる
- 主要なStoryに検証可能な受入条件がある
- 正常系だけでなく、重要な異常系・境界条件がある
- Taskが仕様のコピーではなく、元の仕様へ接続されている
- 実装後にTestResult / PR / CIで受入条件を確認できる
- 上流変更の影響先を追跡できる
- 不具合をRegression Testへ戻すルールがある
テンプレート項目は要件定義テンプレートを参照してください。
要件定義の予算・スケジュールとシステム開発全体の工程
要件定義に必要な期間や費用は、プロジェクト金額だけでは決まりません。未知の業務が多い、関係者が多い、既存システム連携が複雑、法規制がある、品質属性が厳しい、といった不確実性とリスクによって必要な深さが変わります。
重要なのは「何週間やれば十分」という固定値より、次の実装単位を始めても過大な手戻りが起きないだけの共有理解があるかです。
スケジュールを短縮したい場合も、要件定義を省くのではなく、スコープを小さくして「要求を整理する → 実装する → 検証する」の単位を小さくする方が安全です。
まとめ：要件定義は "対話の設計" である
要件定義プロセスは、ヒアリング後に要件定義書を渡して終わる直線ではありません。要求を集め、課題と要求を整理し、未決事項を質問にし、Story・非機能要件・制約・受入条件へ分け、実装・テスト・フィードバックを上流へ戻す循環です。
AI開発では、この循環を短く回せる一方、曖昧な仕様を高速に実装するリスクも上がります。だからこそ、文書の量ではなく、要求から検証までの接続と変更追跡が重要になります。
関連ガイド：要件定義 完全ガイド ／ 要件定義テンプレート ／ EARS記法 ／ Gherkin / BDD ／ RFPの書き方