要件定義とは何か：目的と位置付け
要件定義とは、システム開発において「何を作るのか」を発注側と開発側が合意するための設計工程です。要望（Wants）を整理し、業務上の問題を解決する具体的な機能・性能・制約条件として言語化することで、後工程の設計・実装・テストすべての基準となるドキュメント（要件定義書）を作成します。
要件定義はシステム開発工程の「最上流」に位置し、ここで決めた内容が下流すべての工数・品質・コストに影響します。経済産業省の「DXレポート2.2」や独立行政法人IPA（情報処理推進機構）の調査でも、システム開発失敗の最大の原因として 「要件定義の不足・曖昧さ」 が一貫して挙げられています。
要件定義と要求定義の違い
混同されがちですが、両者は明確に異なる工程です。
項目 | 要求定義 | 要件定義 |
|---|---|---|
主語 | 顧客（ユーザー） | システム |
内容 | やりたいこと・解決したい課題 | 実装すべき機能・条件 |
抽象度 | 高い（What） | 低い（What & How to ensure） |
検証可能性 | 曖昧（"使いやすく"） | 測定可能（"3秒以内に表示"） |
要求定義の成果物（要求リスト）を入力として、要件定義工程で 検証可能な要件文 へ変換するのが標準的な流れです。詳しくは 要求定義と要件定義の違い で解説しています。
なぜ要件定義で失敗するのか
要件定義の失敗は、開発工程の後半で「これは作る予定じゃなかった」「思っていたのと違う」という形で表面化します。原因を分解すると、以下の5パターンが繰り返し発生しています。
- ステークホルダーの抜け漏れ — 経営層や現場部門のキーマンが要件定義に参加せず、後工程で「聞いていない」が発生する
- 要望と要件の混同 — 「使いやすく」「速く」のような曖昧表現がそのまま要件として記録され、検証不能なドキュメントが完成する
- 優先順位の不在 — すべての要件が「Must Have」として扱われ、開発が破綻する
- 業務フローの未整理 — 現状（As-Is）が文書化されないまま、新システム（To-Be）の話を始めてしまう
- 検収条件の未定義 — 「完成」の定義が曖昧なまま開発が始まり、終盤で発注側と受注側が衝突する
DX案件における失敗パターンは DX失敗の典型パターン でも詳しく扱っていますが、いずれも要件定義の精度が直接の引き金になります。
要件定義の5つのフェーズ
実プロジェクトでの要件定義は、以下の5フェーズで進めます。詳細は 要件定義の進め方 で各フェーズの実例とテンプレートを掲載していますが、ここでは全体像を整理します。
フェーズ1：ステークホルダー特定とゴール定義
「誰が、何のために、このシステムを必要としているか」を明らかにします。プロジェクトオーナー、業務担当者、システム管理者、エンドユーザーを洗い出し、それぞれの 成功基準（Goal） を定義します。
フェーズ2：業務フローの可視化（As-Is / To-Be）
現状の業務フローを図示し、新システム導入後にどう変わるべきかを描きます。Beekle では /tools/flow-mapper で As-Is / To-Be を並べて可視化することを推奨しています。
フェーズ3：要求の収集とユーザーストーリー化
ステークホルダーから要望を吸い上げ、 ユーザーストーリー の形式（"〇〇として、△△したい。なぜなら××だから"）に整理します。詳しくは ユーザーストーリーテンプレートと実例 を参照してください。Beekle のツール /tools/story-builder で半自動的に作成できます。
フェーズ4：要件の整理と優先順位付け
ユーザーストーリーを 機能要件 と 非機能要件 に分類し、MoSCoW（Must/Should/Could/Won't）法または FM（ファンクショナリティマトリクス）で優先度を確定させます。詳細は MoSCoWとFMで要件を絞り込む方法 を参照してください。
フェーズ5：要件定義書の作成とレビュー
整理した要件を 要件定義書テンプレート に流し込み、ステークホルダー全員でレビュー → 合意形成を行います。
要件定義書に書くべき項目
要件定義書の章立ては、業界・規模により多少異なりますが、Beekle が標準的に使うのは以下の10章構成です。テンプレート（Word／Excel／Markdown）は 要件定義書テンプレート で無料配布しています。
- プロジェクト概要（目的・背景・スコープ）
- ステークホルダーと役割
- 業務フロー（As-Is / To-Be）
- 機能要件
- 非機能要件（性能・可用性・セキュリティ等）
- 画面要件・画面遷移図
- データ要件（ER図・データ移行）
- 外部連携要件
- 制約条件・前提条件
- 検収条件と完了の定義
要件の書き方ルール：EARS記法
機能要件を曖昧さなく記述するには、EARS（Easy Approach to Requirements Syntax）記法 が役立ちます。EARS は5つのパターン（Ubiquitous / Event-Driven / State-Driven / Optional / Unwanted Behavior）で要件文を構造化する記法で、 検証可能な要件文 を高速に量産できます。
（例：Event-Driven）
ユーザーが商品をカートに追加した場合、
システムは在庫数を1減らさなければならない。
詳しい構文は EARS記法ガイド を参照してください。EARS で書いた要件文は、そのまま Gherkin（BDD）形式のテストシナリオ に変換できるため、テスト工程との連動性も高まります。
要件定義のスコープ管理
要件が多すぎると開発が破綻します。優先順位付け後、FM（ファンクショナリティマトリクス） でスコープを「ビジネス価値 × 技術コスト」のマトリクスで可視化し、何を作るか・何を捨てるかを決めます。詳細は スコープ管理FM法 で解説しています。
Beekle のツール /tools/scope-manager では、要件をMoSCoW＋FMで一元管理できます。
要件定義の成果物チェックリスト
要件定義工程の完了時に、以下が揃っていることを確認してください。
- 要件定義書（10章すべて記入済）
- ユーザーストーリー一覧（優先度・受入条件付き）
- 業務フロー図（As-Is / To-Be）
- 画面遷移図 ＋ 主要画面のワイヤーフレーム
- 非機能要件の数値目標（応答時間、同時接続数、稼働率 等）
- 検収条件（テストケースの抜粋でも可）
- スコープ確定書（"今回作らないもの" の明示）
これらが揃っていない状態で設計工程に進むと、後で必ず手戻りが発生します。
よくある質問（FAQ）
Q1. 要件定義の期間はどれくらいですか？
プロジェクト規模によりますが、小規模（数百万円規模）なら2〜4週間、中規模（1000万〜5000万円）なら1〜3ヶ月、大規模（5000万円以上）なら3〜6ヶ月が目安です。
Q2. 要件定義の費用相場は？
開発費全体の10〜20%が目安です。1000万円のシステム開発なら、要件定義に100〜200万円を見込みます。安すぎる要件定義は後工程の手戻りで結局高くつくため、上流投資を惜しまないのが鉄則です。
Q3. 要件定義の担当者は誰がやるべきですか？
発注側はプロジェクトオーナー＋業務責任者、受注側は要件定義経験のあるシニアエンジニアまたはコンサルタント、というペア体制が標準です。発注側だけ／受注側だけで進めると、必ず認識ズレが起きます。
Q4. 要件定義書は何ページくらいになりますか？
中規模プロジェクトで30〜80ページが標準。極端に短いと検証不能、極端に長いとレビューが回らないため、章立てに沿って必要十分な分量を心がけます。
Q5. アジャイル開発でも要件定義書は必要ですか？
必要です。アジャイルでも「全体スコープ」「非機能要件」「制約条件」は最初に固定しないと、スプリントが回りません。詳細機能は後回しにできますが、基盤要件は要件定義書として明示すべきです。
Q6. 要件定義に Excel と Word、どっちが向いていますか？
Word（または Markdown）= 説明文中心の章、Excel = 一覧・対応表（要件一覧、画面一覧、データ項目一覧）の使い分けが現実的です。Beekle のテンプレートも両方を組み合わせています。
まとめ：要件定義は "投資"
要件定義に時間をかけることは、開発全体のコストとリスクを削減する 最も投資効果の高い活動 です。曖昧な要件のまま実装に入ると、テスト工程・運用開始後に必ず大きな手戻りが発生します。
Beekle では、要件定義支援サービスで貴社のプロジェクトを上流から伴走します。「自社で要件定義を進めているが、これで合っているか不安」「外注先と要件レビューが噛み合わない」といったご相談は、無料相談フォーム からお気軽にお問い合わせください。
また、すぐに使えるテンプレートと、要件定義を半自動化するツールを以下で公開しています。
- 要件定義書テンプレート（Word/Excel/Markdown 無料DL）
/tools/story-builder— ユーザーストーリー作成ツール/tools/scope-manager— MoSCoW＋FMによるスコープ管理ツール/tools/flow-mapper— As-Is/To-Be 業務フロー可視化ツール