要件定義の進め方｜実プロジェクト例で学ぶ5フェーズ完全ロードマップ

要件定義は "工程" ではなく "対話" である

要件定義の進め方を、教科書的に「ヒアリング → 整理 → ドキュメント化」と覚えても、実プロジェクトでは通用しません。実際は、ステークホルダー間の 対話と合意形成 を5つのフェーズに分けて進める作業です。

このコラムでは、Beekle が中規模プロジェクト（開発費1,000〜3,000万円程度）で実際に使っている要件定義プロセスを、具体的な会話例とアウトプットの抜粋を交えて解説します。

「要件定義 とは何か」を先に理解したい方は、要件定義の完全ガイド を先にお読みください。

全体フロー：5フェーズの俯瞰

[フェーズ1] ステークホルダー特定とゴール定義
       ↓
[フェーズ2] 業務フロー可視化（As-Is / To-Be）
       ↓
[フェーズ3] 要求収集とユーザーストーリー化
       ↓
[フェーズ4] 要件の整理と優先順位付け（MoSCoW + FM）
       ↓
[フェーズ5] 要件定義書の作成とレビュー

各フェーズは独立しているわけではなく、後のフェーズで前フェーズの内容を更新することもあります。1ヶ月のプロジェクトであれば、フェーズ1〜2に2週間、フェーズ3に1週間、フェーズ4〜5に1週間が目安です。

フェーズ1：ステークホルダー特定とゴール定義

このフェーズで決めること

• 誰がこのシステムを使うのか（業務担当者・管理者・エンドユーザー）
• 誰が要件を承認するのか（プロジェクトオーナー・経営層）
• このシステムで達成すべき 数値目標 は何か

よくある失敗

「経理部長は途中から呼べばいい」と判断して、終盤で「経理処理の要件が抜けている」と発覚し、再見積もりが発生する。最初に呼ぶ人を誤ると、後で必ず手戻りします。

アウトプット例

このマトリクスができれば、フェーズ2以降の インタビュー対象と承認フロー が確定します。

フェーズ2：業務フローの可視化（As-Is / To-Be）

このフェーズで決めること

• 現状の業務フロー（As-Is）を、誰が・何を・いつ・どのツールで実施しているか
• 新システム導入後の業務フロー（To-Be）はどう変わるか
• As-Is と To-Be の 差分 が、システムが提供すべき機能の輪郭になる

よくある失敗

As-Is を書かずにいきなり To-Be を議論すると、「現場で本当に困っていること」が抜け落ちて、机上の空論で要件が決まる。現場ヒアリング → As-Is 図 → To-Be 議論 の順を守るのが重要です。

実践ツール

Beekle の /tools/flow-mapper を使うと、As-Is と To-Be を並べて可視化できます。スイムレーン形式（業務担当者ごとのレーン）で書くと、属人化や二重作業がひと目で見えます。

アウトプット例（抜粋）

[As-Is] 受注から請求までのフロー
営業 → 受注メール受領 → Excelに転記（手作業）
       ↓
営業 → 請求書テンプレート（Word）に手入力
       ↓
経理 → 請求書PDF確認 → 会計ソフトに転記（手作業）
       ↓
経理 → 入金確認 → Excelの売掛金台帳を更新

問題点:

Excel と会計ソフトに同じデータを2回入力（二重作業）
営業のExcelと経理のExcelで金額がずれることが月3〜5件発生
請求書の発行までに平均5営業日かかる

[To-Be] CRM導入後のフロー
営業 → 受注情報をCRM入力 → 請求書自動生成
     ↓

経理 → CRMで承認ボタン → 会計ソフトへAPI連携
       ↓
経理 → 入金消込もCRM側で完結
期待効果:

二重入力を完全排除
請求書発行を1営業日以内に短縮
売掛金の整合性を100%保証

フェーズ3：要求収集とユーザーストーリー化

このフェーズで決めること

• 各ステークホルダーが「やりたいこと（要望）」を吸い上げる
• 要望を ユーザーストーリー の形式に変換する
• ユーザーストーリーごとに 受入条件（Acceptance Criteria） を定義する

ユーザーストーリーのフォーマット

〇〇として（誰が）、
△△したい（何を）。
なぜなら××だから（なぜ）。

例：

営業担当として、受注メールから自動で請求書を作成したい。
なぜなら、転記作業に毎日30分使っているから。

実践ツール

Beekle の /tools/story-builder では、要望をフォームに入力すると上記形式に半自動変換できます。詳しい書き方は ユーザーストーリーテンプレートと実例 を参照してください。

よくある失敗

受入条件（Acceptance Criteria）を書かずに次フェーズに進む。これがあると無いとでは、後工程のテストケース作成効率が10倍違います。受入条件は EARS記法 で書くと曖昧さがなくなります（→ EARS記法ガイド）。

フェーズ4：要件の整理と優先順位付け（MoSCoW + FM）

このフェーズで決めること

• ユーザーストーリーを MoSCoW で4分類（Must / Should / Could / Won't）
• 機能ごとの ビジネス価値 × 技術コスト をFM（ファンクショナリティマトリクス）で評価
• 第1リリースに含めるスコープを確定

MoSCoW の使い方

詳しい使い方は MoSCoWとFMで要件を絞り込む方法 を参照してください。

実践ツール

Beekle の /tools/scope-manager では、要件をMoSCoW + FM で一元管理し、 作る／後回し／作らない の判定を自動化できます。

よくある失敗

全要件を「Must Have」として記録してしまう。これでは優先順位が無いのと同じです。Must Have は全要件の30〜40%以内 に収めるのが現実的なライン。50%を超えると、開発計画が破綻します。

フェーズ5：要件定義書の作成とレビュー

このフェーズで決めること

• フェーズ1〜4の成果物を統合した 要件定義書（10章構成） を作成
• ステークホルダー全員でレビュー → 合意形成
• スコープ確定書（"今回作らないもの" の明示）に署名

要件定義書の章立て

要件定義書テンプレート で詳しく解説しているテンプレートを使うと、章立ての抜け漏れを防げます。Word／Excel／Markdown の3形式を無料配布しています。

レビュー会のコツ

3回に分けてレビューする のが鉄則です。

1. 概要レビュー（30分）— プロジェクト概要・スコープ・前提条件のみ。経営層も参加
2. 機能要件レビュー（2時間）— 業務担当者と詳細を確認
3. 非機能要件レビュー（1時間）— 情報システム部門と性能・セキュリティを確認

1回で全部やろうとすると、必ずレビューが浅くなります。

よくある失敗

要件定義書ができた直後にいきなり開発契約に進む。最低1週間、ステークホルダーが持ち帰って読む時間を確保 してください。週末を挟まないと、現場担当者は読む時間が取れません。

要件定義で失敗しないチェックリスト

各フェーズの完了時に、以下を確認します。

フェーズ1完了時

• ステークホルダーマトリクスが作成済み
• プロジェクトの数値ゴールが定義済み

フェーズ2完了時

• As-Is フロー図が完成
• To-Be フロー図が完成
• As-Is と To-Be の差分（=システム機能の輪郭）が言語化されている

フェーズ3完了時

• ユーザーストーリーが30〜100本作成されている
• 各ストーリーに受入条件が付いている

フェーズ4完了時

• MoSCoW分類が完了
• FMマトリクスで「作る／後回し／作らない」が決定
• Must Have が全要件の30〜40%以内に収まっている

フェーズ5完了時

• 要件定義書（10章）が完成
• レビュー会が3回（概要／機能／非機能）実施済み
• スコープ確定書にステークホルダー全員が署名

これらが揃っていない状態で設計工程に進むと、必ず手戻りが発生します（DX失敗の典型パターン も参照）。

まとめ：要件定義は "対話の設計" である

要件定義は単なるドキュメント作成工程ではなく、 誰と・何を・どの順番で・どう議論するか を設計する活動です。フェーズごとの目的とアウトプットを明確にし、ツールで省力化することで、要件定義の品質と速度は両立できます。

Beekle では、要件定義の各フェーズを支援するサービスとツールを提供しています。

• /tools/flow-mapper — As-Is/To-Be 業務フロー可視化（フェーズ2）
• /tools/story-builder — ユーザーストーリー作成（フェーズ3）
• /tools/scope-manager — MoSCoW + FM 管理（フェーズ4）

「自社で要件定義を進めているが、フェーズの順序が分からない」「外注したが、要件定義のレビュー会が形骸化している」といったご相談は、無料相談フォーム からお気軽にお問い合わせください。