Home
要件定義を計画する
実践ガイド
文書情報
プロジェクト概要
🚧 レビュー・承認(※追記予定）
業務要件
機能要件
非機能要件
🚧 インプット(※追記予定)
🚧トレーサビリティ(※追記予定)
🚧 SoR 向け(※追記予定）
🚧 SoE 向け(※追記予定）
要件定義書 プロジェクト概要
プロジェクトの目的・背景、ステークホルダー、前提・制約条件、スコープを明確に定義し、プロジェクト関係者間で共通認識を形成します。
🎯 概要
- 目的: プロジェクトの目的・背景、ステークホルダー、前提条件・制約条件、スコープ（対象範囲と対象外範囲）を明確に定義し、プロジェクト関係者間で共通認識を形成する
- スコープ: プロジェクトの目的、背景・課題、期待効果、ステークホルダー、前提条件、制約条件、スコープ内・スコープ外の定義をカバーする。個別の機能要件や技術仕様は対象外
- 推奨する実施タイミング: 要件定義の初期段階。ビジネス要件のヒアリングが完了し、プロジェクトの全体像が見えてきた段階で実施する
- 関連するステークホルダー: プロジェクトマネージャー、プロジェクトスポンサー（発注者）、業務部門責任者、システムアーキテクト、開発リーダー
📥 重要な前提知識・インプット
- 前提知識: プロジェクト管理の基礎知識、ステークホルダー分析の手法、スコープマネジメントの基本、要件定義プロセスの全体像
- インプット: プロジェクト発足資料（提案書、企画書）、経営戦略・事業計画、ビジネス課題のヒアリング結果、現行システム資料、予算・スケジュール情報、既存の業務フロー資料
📄 成果物の定義
- ドキュメントテンプレート: 📄
[テンプレ]要件定義書 プロジェクト概要 - 必須要素: プロジェクト目的・背景、業務課題一覧、期待効果（定量・定性）、ステークホルダー一覧、前提条件一覧、制約条件一覧、スコープ内定義、スコープ外定義
✅ 品質基準・レビュー観点
✅ 品質チェックリスト:
| チェック項目 | チェック内容 |
|---|---|
| 目的の明確性 | プロジェクト目的が具体的かつ測定可能に記述されているか |
| 課題の具体性 | 現状の業務課題が具体的に特定され、影響度・発生頻度が明記されているか |
| スコープの明確性 | スコープ内・スコープ外が明確に区別され、曖昧な領域がないか |
| ステークホルダーの網羅性 | 関係するすべてのステークホルダーが漏れなく特定されているか |
| 前提・制約の明示 | 前提条件・制約条件が具体的に記述され、変更時の影響が考慮されているか |
👁️🗨️ レビュー観点:
- ビジネス価値との整合性: プロジェクト目的が経営戦略・事業計画と整合しているか
- 実現可能性: 予算・スケジュール・リソース制約の中で達成可能な目的・スコープか
- 合意形成: ステークホルダー間で目的・スコープについて合意が形成されているか
- トレーサビリティ: 後続の機能要件・非機能要件に繋がる情報が十分に記載されているか
🧪成果物のサンプル
# プロジェクト概要
## プロジェクト目的・背景
### システム化の目的
本プロジェクトで達成すべき目的を記載する。
**記述例:**
本プロジェクトは、現行の販売管理システムを刷新し、以下の目的を達成することを目指す。
- 業務効率の向上: 受注処理時間を50%削減
- データ精度の向上: 在庫データの正確性を99%以上に向上
- 顧客満足度の向上: 納期回答時間を即時化
### 背景・課題認識
システム化に至った背景と、現状の課題を記載する。
**記述例:**
#### 現状の問題点
- 現行システムは15年前に構築され、保守性が低下
- 複数のシステムが分散し、データの二重入力が発生
- リアルタイムな在庫確認ができず、機会損失が発生
#### 業務課題一覧
| 課題ID | 課題内容 | 影響度 | 発生頻度 | 関連業務 |
|--------|----------|--------|----------|----------|
| I001 | 受注データの手入力によるミス | 高 | 日次 | 受注管理 |
| I002 | 在庫データの更新遅延 | 高 | 日次 | 在庫管理 |
| I003 | システム間のデータ不整合 | 中 | 週次 | 全業務 |
### 期待される効果（任意）
システム化により期待される効果を定量的・定性的に記載する。
**記述例:**
#### 定量的効果
- 受注処理時間: 30分/件 → 15分/件（50%削減）
- 在庫確認時間: 10分 → 即時（100%削減）
- データ入力ミス: 月20件 → 月5件（75%削減）
#### 定性的効果
- 従業員の業務負荷軽減
- 顧客対応品質の向上
- 経営判断のスピードアップ
---
## ステークホルダー
プロジェクトに関与するステークホルダーを別紙に記載する。
[ステークホルダー一覧](stakeholder-list.md)
---
## 3. 前提条件
要件定義の前提となる条件を別紙に記載する。
[前提条件一覧](assumption-list.md)
---
## 4. 制約条件
システム要件上の制約事項を別紙に記載する。
[制約条件一覧](constraint-list.md)
---
## スコープ管理
### スコープ内定義
本プロジェクトで実施する範囲を明確に記載する。
**記述例:**
#### 対象業務
- 受注管理業務
- 在庫管理業務
- 出荷管理業務
#### 対象機能
- Web画面による受注入力
- リアルタイム在庫照会
- 出荷指示書の自動生成
- 基本的な帳票出力
#### 対象拠点
- 東京本社
- 大阪支社
- 名古屋支社
#### 対象ユーザー
- 営業担当者（約50名）
- 倉庫担当者（約20名）
- 管理者（約5名）
### 5.2 スコープ外定義
本プロジェクトで実施しない範囲を明確に記載する。
**記述例:**
#### 対象外業務
- 経理業務（請求・入金管理）→ Phase2で検討
- 人事業務 → 対象外
- 生産管理業務 → Phase3で検討
#### 対象外機能
- AI による需要予測機能 → Phase2で検討
- 多言語対応 → Phase3で検討
- モバイルアプリ → Phase2で検討
#### 対象外拠点
- 海外拠点 → Phase2で検討
- 物流センター → 既存システムを継続利用
#### 対象外システム
- 会計システムとの連携 → Phase2で検討
- 外部ECサイトとの連携 → Phase3で検討
## その他プロジェクト情報
前提条件変更時の承認フローなど、その他のプロジェクト管理情報は、プロジェクト計画書を参照する。
---🔄 合意の進め方・プロセス
🏗️ プロセス1: プロジェクト目的・背景の合意形成
合意対象:
プロジェクトの目的、システム化に至った背景、現状の業務課題、期待される効果について、ステークホルダー間で共通認識を形成する。
合意形成のステップ:
- ステップ1: 情報収集: 経営層・業務部門へのヒアリングを通じて、システム化の目的、背景・課題、期待効果を収集する
- ステップ2: 文書化: 収集した情報を構造化し、目的・背景・課題・効果を文書としてまとめる
- ステップ3: レビューと調整: 主要ステークホルダー（プロジェクトスポンサー、業務部門責任者など）にドラフトを共有し、フィードバックを収集する
- ステップ4: 合意確認: 修正版を再度提示し、プロジェクト目的・背景について正式な合意を得る
合意形成のポイント:
- 定量化による測定可能性: 目的や効果は可能な限り数値化し、達成度を測定できるようにする
- 認識ズレの早期発見: 複数のステークホルダーから独立にヒアリングし、認識の相違を早期に発見・調整する
- 優先順位の明確化: すべての課題を同列に扱わず、影響度・発生頻度に基づいて優先順位を合意する
- トレーサビリティの確保: 課題に一意のIDを付与し、後工程で機能要件との紐付けができるようにする
合意文書の推奨構成:
- 目的: プロジェクト目的を箇条書きで3〜5項目程度に整理する
- 背景・課題: 「現状の問題点」→「業務課題一覧（表形式）」の順で構造的に記述する
- 期待効果: 定量効果は「現状値 → 目標値（改善率）」の形式で記述する
- 根拠: 目的や効果の根拠となる経営戦略、事業計画、ヒアリング結果を参照資料として記載する
🏗️ プロセス2: ステークホルダー・前提条件・制約条件の合意形成
合意対象:
プロジェクトに関与するステークホルダー、プロジェクト遂行上の前提条件、システム要件上の制約条件について合意する。
合意形成のステップ:
- ステップ1: ステークホルダー特定: プロジェクトに直接・間接的に関与する組織・役割を洗い出す
- ステップ2: 役割・責任の定義: 各ステークホルダーの役割（意思決定者、承認者、利用者、協力者など）と責任範囲を明確にする
- ステップ3: 前提条件・制約条件の収集: プロジェクト遂行の前提や制約となる条件を各ステークホルダーからヒアリングする
- ステップ4: 文書化とレビュー: ステークホルダー一覧、前提条件一覧、制約条件一覧を文書化し、関係者に共有する
- ステップ5: 合意確認: 各ステークホルダーから承認を得て、前提・制約を正式に確定する
合意形成のポイント:
- 網羅性の確保: プロジェクトに影響を与える可能性のあるステークホルダーを漏れなく特定する
- 役割の明確化: 意思決定権限、承認権限、情報提供者などの役割を明示し、責任の所在を明らかにする
- 前提の明示と影響分析: 前提条件を明示し、前提が崩れた場合の影響とエスカレーション手順を事前に合意する
- 制約の受け入れ: 制約条件は変更できない前提として受け入れ、その範囲内で最適な要件を定義することを合意する
合意文書の推奨構成:
- ステークホルダー一覧: 組織・役割、責任範囲、連絡先、関与フェーズを表形式で整理する
- 前提条件: 「前提ID」「前提内容」「根拠」「変更時の影響」を記載する
- 制約条件: 「制約ID」「制約内容」「理由」「対応方針」を記載する
- 別紙化: 項目数が多い場合は、ステークホルダー一覧、前提条件一覧、制約条件一覧を別紙として分離する
🏗️ プロセス3: スコープ管理（スコープ内・スコープ外の合意形成）
合意対象:
プロジェクトで実現する機能・対象範囲（スコープ内）と、実現しない機能・対象外範囲（スコープ外）を明確に定義し、期待値調整とスコープクリープの防止を図る。
合意形成のステップ:
- ステップ1: スコープ内の定義: プロジェクト目的を達成するために必要な機能・業務範囲・対象システムを洗い出す
- ステップ2: スコープ外の明示: 検討されたが対象外とする項目、将来フェーズで対応する項目、他プロジェクトで対応する項目を明示する
- ステップ3: 境界の明確化: スコープ内・外の境界が曖昧な項目について、判断基準と具体例を用いて明確化する
- ステップ4: レビューと調整: スコープ定義をステークホルダーに共有し、期待値とのギャップを確認・調整する
- ステップ5: 合意確認: スコープ内・外の定義について正式な承認を得て、変更管理プロセスを確立する
合意形成のポイント:
- スコープ外の明示による期待値調整: 「やらないこと」を明示することで、ステークホルダーの過度な期待を早期に調整する
- 判断基準の明確化: スコープ内・外の判断基準（優先度、投資対効果、技術的実現性など）を文書化し、追加要望の評価に活用する
- 段階的実現の計画: スコープ外でも重要な項目は「将来対応」として記録し、次期フェーズでの実現可能性を残す
- 変更管理プロセスの確立: スコープ変更が発生した場合の承認フロー、影響評価方法を事前に合意する
合意文書の推奨構成:
- スコープ内: 対象業務範囲、対象システム範囲、実現機能カテゴリを階層構造で整理する
- スコープ外: 「対象外項目」「理由」「将来対応の有無」を表形式で明示する
- 境界の定義: スコープの境界が曖昧になりやすい領域について、具体例を用いて明確化する
- 変更管理: スコープ変更時の承認プロセス、影響評価の方法、エスカレーション基準を記載する
🚨 よくある失敗と予防策
🚧 実例収集後、追記予定
📚 参考資料・関連リンク
- 参考文献: PMBOK（プロジェクトマネジメント知識体系ガイド）、『要求開発の基礎知識』、IPA「要件定義ガイド」、『システム要求分析実践ガイド』
- 関連する他のガイド: 要件定義のプロセス、ステークホルダー分析、機能要件定義、非機能要件定義、要件定義書の完成条件
- ツール・テンプレート: ステークホルダー一覧テンプレート、前提条件・制約条件一覧テンプレート、スコープ定義書テンプレート
テンプレートサイト: 📄テンプレート集