Home
要件定義を計画する
実践ガイド
文書情報
プロジェクト概要
🚧 レビュー・承認(※追記予定）
業務要件
機能要件
非機能要件
🚧 インプット(※追記予定)
🚧トレーサビリティ(※追記予定)
🚧 SoR 向け(※追記予定）
🚧 SoE 向け(※追記予定）
ステークホルダー一覧
プロジェクトに関与する全てのステークホルダーを特定し、役割・責任範囲・関係性を明確化することで、円滑なコミュニケーションと意思決定を実現します。
🎯 概要
- 目的: プロジェクトに関与する全てのステークホルダーを特定し、役割・責任範囲・関係性を明確にすることで、円滑なコミュニケーションと意思決定を実現する
- スコープ: 発注者側・受注者側・利用者側のステークホルダー、各ステークホルダーの役割・責任範囲・権限、ステークホルダー間の関係性・報告ラインをカバーする
- 推奨する実施タイミング: 要件定義の初期段階（プロジェクトキックオフ前後）で実施し、プロジェクト全体で参照する
- 関連するステークホルダー: プロジェクトマネージャー、プロジェクトオーナー、業務責任者、システム責任者
📥 重要な前提知識・インプット
- 前提知識: プロジェクト体制の基本概念、RACI図（責任分担マトリクス）の理解、ステークホルダーマネジメントの基礎
- インプット: プロジェクト計画書、契約書（役割分担の記載）、組織図、既存プロジェクトの体制情報
📄 成果物の定義
- ドキュメントテンプレート: 📄
[テンプレ]ステークホルダー一覧 - 必須要素: ステークホルダー一覧表（区分・組織・役職・氏名・役割・責任範囲）、ステークホルダー関連図（組織間の関係性と報告ライン）
✅ 品質基準・レビュー観点
✅ 品質チェックリスト:
| チェック項目 | チェック内容 |
|---|---|
| 網羅性 | プロジェクトに関与する全てのステークホルダーが洗い出されているか |
| 役割の明確性 | 各ステークホルダーの役割と責任範囲が明確に定義されているか |
| 意思決定権限の明確化 | 誰が何を承認・決定する権限を持つかが明確か |
| 連絡先情報 | 各ステークホルダーの連絡先（メール・電話等）が記載されているか |
| 関係性の可視化 | ステークホルダー間の関係性・報告ラインが図で表現されているか |
👁️🗨️ レビュー観点:
- プロジェクト体制との整合性: プロジェクト計画書や契約書に記載された体制と一致しているか
- 意思決定プロセスの明確性: 要件承認、仕様変更、課題エスカレーションの意思決定ルートが明確か
- コミュニケーションパスの適切性: 日常的なコミュニケーション経路と正式な承認ルートが整理されているか
- 実効性: 記載された連絡先で実際にステークホルダーと連絡が取れるか
🧪成果物のサンプル
## ステークホルダー
### ステークホルダー一覧
プロジェクトに関与するステークホルダーを記載する。
**記述例:**
| 区分 | 組織・役職 | 氏名 | 役割 | 責任範囲 |
|------|------------|------|------|----------|
| 発注者 | 営業部長 | 山田太郎 | プロジェクトオーナー | 最終意思決定 |
| 発注者 | 業務課長 | 佐藤花子 | 業務責任者 | 業務要件の承認 |
| 発注者 | 情報システム部長 | 鈴木一郎 | システム責任者 | 技術要件の承認 |
| 受注者 | プロジェクトマネージャー | 田中次郎 | PM | プロジェクト全体管理 |
| 利用者 | 営業担当 | - | エンドユーザー | システム利用・フィードバック |
### ステークホルダー関連図
```mermaid
graph TB
subgraph "経営層"
A[経営会議]
end
subgraph "発注者側"
B[プロジェクトオーナー<br/>営業部長]
C[業務責任者<br/>業務課長]
D[システム責任者<br/>情報システム部長]
E[エンドユーザー<br/>営業担当]
end
subgraph "受注者側"
F[PM]
G[システム設計チーム]
H[開発チーム]
end
A --> B
B --> C
B --> D
C --> E
B --> F
F --> G
F --> H
D --> F
```
---🔄 設計の進め方・プロセス
🏗️ プロセス1: ステークホルダーの洗い出し
設計対象:
プロジェクトに関与する全てのステークホルダーを特定する。
具体例:
- 発注者側: 経営層、プロジェクトオーナー、業務責任者、システム責任者、情報システム部門
- 受注者側: プロジェクトマネージャー、システムアーキテクト、開発リーダー、品質保証担当
- 利用者側: エンドユーザー、システム管理者、運用担当者
- 外部関係者: 外部ベンダー、パートナー企業、監査機関（必要に応じて）
設計原則:
- 網羅性の確保: プロジェクト計画書、契約書、組織図を参照し、関与者の漏れがないように確認する
- 利用者の代表性: エンドユーザーは代表者を特定し、全体を代表する立場として定義する
- 意思決定者の明確化: 最終承認権限を持つキーパーソンを明確に特定する
文書化の推奨表現:
- ステークホルダー一覧表: 区分・組織・役職・氏名・役割を一覧表で整理する
- 連絡先情報: メールアドレス、電話番号、Teams/Slackアカウント等を記載する
🏗️ プロセス2: 役割と責任範囲の定義
設計対象:
各ステークホルダーの役割と責任範囲を明確に定義する。
具体例:
- プロジェクトオーナー: プロジェクト全体の最終意思決定、予算承認
- 業務責任者: 業務要件の定義・承認、業務プロセスの最終決定
- システム責任者: 技術要件の承認、非機能要件の決定、セキュリティポリシーの承認
- プロジェクトマネージャー: プロジェクト全体の計画・管理・調整、ステークホルダー間の調整
- エンドユーザー: 業務要件のインプット、UIレビュー、受入テストへの参加
設計原則:
- RACI図の活用: Responsible（実行責任者）、Accountable（説明責任者）、Consulted（相談先）、Informed（報告先）を明確にする
- 意思決定権限の明確化: 誰が何を承認する権限を持つかを明確にする
- 曖昧さの排除: 「関与する」「協力する」といった曖昧な表現を避け、具体的な責任範囲を定義する
文書化の推奨表現:
- 役割定義表: 各ステークホルダーの具体的な役割と責任範囲を記載する
- 承認マトリクス: 成果物ごとの承認者を一覧化する
🏗️ プロセス3: ステークホルダー関連図の作成
設計対象:
ステークホルダー間の関係性と報告ラインを視覚化する。
具体例:
- 組織階層: 経営層 → プロジェクトオーナー → 業務責任者/システム責任者
- プロジェクト体制: 発注者側 ↔ 受注者側（PMを中心とした連携）
- 利用者との関係: 業務責任者 → エンドユーザー代表
- エスカレーションルート: 現場 → PM → プロジェクトオーナー → 経営層
設計原則:
- 視覚的明瞭性: 複雑な関係性を分かりやすく図示する
- 報告ラインの明確化: 通常時の報告ルートとエスカレーション時のルートを区別する
- コミュニケーションパスの可視化: 日常的なコミュニケーション経路を明示する
文書化の推奨表現:
- Mermaid図: 階層構造と関係性を表現したステークホルダー関連図を作成する
- コミュニケーションマトリクス: ステークホルダー間のコミュニケーション頻度・方法を一覧化する
🏗️ プロセス4: ステークホルダーとの合意形成
設計対象:
作成したステークホルダー一覧と関連図を関係者と合意する。
具体例:
- キックオフミーティングでステークホルダー一覧を共有し、認識を揃える
- 役割・責任範囲について各ステークホルダーと個別に確認する
- 意思決定プロセスとエスカレーションルートを明確化する
- 定期的にステークホルダー情報を更新し、関係者に共有する
設計原則:
- 早期の合意形成: プロジェクト初期段階で明確化し、認識齟齬を防ぐ
- 定期的な見直し: プロジェクト進行に伴う組織変更・人事異動を反映する
- ドキュメントの共有: 全ステークホルダーがアクセスできる場所に情報を配置する
文書化の推奨表現:
- 合意記録: キックオフ議事録等にステークホルダー一覧の合意を記録する
- 更新履歴: 変更があった場合の更新日時と変更内容を記録する
🚨 よくある失敗と予防策
🚧 実例収集後、追記予定
📚 参考資料・関連リンク
- 参考文献: 『プロジェクトマネジメント知識体系ガイド（PMBOK）』、『ステークホルダーマネジメント実践ガイド』
- 関連する他のガイド: プロジェクト計画書作成ガイド、コミュニケーション計画ガイド、変更管理プロセスガイド
- ツール・テンプレート: Mermaid（関連図作成）、RACI図テンプレート、ステークホルダー分析マトリクス
テンプレートサイト: 📄テンプレート集