要件定義の進め方｜実プロジェクト例で学ぶ5フェーズ実践ガイド

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

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

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

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

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

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

各フェーズは独立しているわけではなく、後のフェーズで前フェーズの内容を更新することもあります。プロジェクト規模によって配分は変わりますが、フェーズ1〜2（合意形成と現状把握）に最も時間を割く のがプロジェクトを破綻させないコツです。

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

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

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

よくある失敗

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

アウトプット例

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

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

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

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

よくある失敗

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

実践ツール

Beekle の 業務フロー可視化ツール を使うと、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 の ユーザーストーリー作成ツール では、要望をフォームに入力すると上記形式に半自動変換できます。詳しい書き方は ユーザーストーリーテンプレートと実例 を参照してください。

よくある失敗

受入条件（Acceptance Criteria）を書かずに次フェーズに進む。受入条件はテストケースの元になるため、これが曖昧だと後工程で「どう動けば正解か」を決めるたびに発注側に再確認が走り、開発が止まります。受入条件は EARS記法 で書くと曖昧さが減ります（→ EARS記法ガイド）。

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

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

• 各要件を 3軸（ビジネス価値 × 現場で使えるか × 技術コスト） で評価する
• 第1リリースで 作る／後回し／作らない を確定する
• 「やらないこと」を明示してスコープを締める

FM の3軸

要件の優先順位付けは、書籍『システムを作らせる技術』(白川克) の FM（ファンクショナリティ・マトリクス） をベースに、Beekle では以下の3軸で評価します。1軸（重要度だけ）で判定すると「重要だけど現場が使わない」「重要だけど技術的に難しすぎる」要件をそのまま着手してしまい、投資が無駄になりやすいためです。

判定ロジック

アウトプット例

実践ツール

Beekle の スコープ管理ツール では、要件を FM の3軸で評価し、 作る／後回し／作らない の判定を自動化できます。

よくある失敗

全要件を「作る」として記録してしまう。これでは優先順位が無いのと同じです。FM を使うときは 「現場で使えるか」を必ず別軸で評価する こと。ビジネス価値だけで判断すると、「経営層は欲しがるが現場は使わない機能」を作って失敗します。

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

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

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

要件定義書の章立て

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

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

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

フェーズ1完了時

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

フェーズ2完了時

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

フェーズ3完了時

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

フェーズ4完了時

• 全要件が FM の3軸（ビジネス価値 × 現場で使えるか × 技術コスト）で評価されている
• 「作る／後回し／作らない」が要件ごとに決定している
• 「作らない」要件がスコープ確定書に明示されている

フェーズ5完了時

• 要件定義書（10章）が完成
• ステークホルダー全員でレビューが実施済み
• スコープ確定書にステークホルダー全員が署名

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

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

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

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

• 業務フロー可視化ツール — As-Is/To-Be 業務フロー可視化（フェーズ2）
• ユーザーストーリー作成ツール — ユーザーストーリー作成（フェーズ3）
• スコープ管理ツール — FM（3軸評価）でスコープ管理（フェーズ4）

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