目的と用語例
統合の対象群が含むプロセスの主要なインプット及びアウトプットを理解する。
用語例
プロジェクト作業規定書，契約，ビジネスケース，プロジェクト憲章，プロジェクト全体計画（プロジェクト計画及びプロジェクトマネジメント計画），変更要求，承認された変更，変更登録簿，是正処置，プロジェクト完了報告書，プロジェクト又はフェーズの終結報告書，得た教訓文書
1. 概要
プロジェクトの統合管理において、主要なインプット及びアウトプットを理解することは、プロジェクト全体を効果的に運営する上で非常に重要です。これらは、プロジェクトの開始から終了まで、一貫した管理を行うための基礎となります。
2. 詳細説明
2.1. プロジェクト立ち上げ段階のインプット・アウトプット
インプットには、プロジェクト作業規定書、契約、ビジネスケースなどが含まれます。これらの文書を基に分析と評価を行い、主要なアウトプットとしてプロジェクト憲章が作成されます。
プロジェクト憲章には以下の項目が含まれます：
- プロジェクト名と概要
- 主要な目標と成功基準
- 制約条件と仮定条件
- 主要な利害関係者とその役割
表1：プロジェクト憲章の構成例
| 項目 | 内容 |
|---|---|
| プロジェクト名・概要 | プロジェクトの正式名称 プロジェクトの目的と概要説明 背景情報 |
| 目標・成功基準 | 具体的な達成目標 測定可能な成功基準 期待される成果物 |
| 制約条件・仮定 | 予算の制約 スケジュールの制約 リソースの制約 前提条件と仮定 |
| 主要利害関係者 | プロジェクトスポンサー プロジェクトマネージャー 主要なステークホルダー 各関係者の役割と責任 |
| 承認者情報 | 承認者の役職・氏名 承認日付 承認者の署名欄 |
2.2. 計画段階のインプット・アウトプット
プロジェクト憲章をインプットとして、プロジェクト全体計画（プロジェクト計画及びプロジェクトマネジメント計画）が作成されます。この計画書は、プロジェクトの実行段階における基準となります。
全体計画の例として、スコープ管理計画、タイムライン、予算計画などが含まれます。
図1: プロジェクト全体計画の概要
2.3. 実行・監視・コントロール段階のインプット・アウトプット
主要なインプットには、変更要求や作業実績データが含まれます。これらは評価され、承認された変更として変更登録簿に記録されます。また、必要に応じて是正処置が実施されます。
変更登録簿の具体例として、変更要求の概要、承認状況、実施結果などが記録されます。
表2：変更登録簿の記載例
| 変更ID | 変更内容 | 提出日 | 承認状況 | 影響度 |
|---|---|---|---|---|
| CH001 | データベース設計の変更 理由：性能要件の変更 | 2024/04/01 | 承認済 | 高 |
| CH002 | 開発環境のバージョンアップ 理由：セキュリティ対応 | 2024/04/15 | 審査中 | 中 |
| CH003 | 画面レイアウトの修正 理由：ユーザーフィードバック | 2024/04/20 | 却下 | 低 |
凡例
承認済
変更が承認され、実施が決定
審査中
変更要求を審査中
却下
変更要求が却下
2.4. 終結段階のインプット・アウトプット
プロジェクトの完了時には、プロジェクト完了報告書、プロジェクト又はフェーズの終結報告書が作成されます。また、プロジェクトを通じて得た教訓文書も重要なアウトプットとして作成されます。
教訓文書には、成功要因や課題、今後の改善策が含まれます。
表3：教訓文書の構成例
| カテゴリー | 内容例 | 記載のポイント |
|---|---|---|
| 成功要因 | 週次での進捗報告会の実施 メンバー間の積極的な情報共有 早期のリスク特定と対応 |
具体的な成功事例と、その要因となった施策や行動を記載。
再現可能な形で記録することが重要。
| | 課題・問題点 |
- 要件定義の遅延
- テスト工程の時間不足
- 外部ベンダーとの連携不足
|
問題の内容、影響、原因を明確に記載。
blame（非難）を避け、事実に基づいた記述を心がける。
| | 改善提案 |
- 要件定義フェーズの期間延長
- テスト計画の早期策定
- ベンダー合同会議の定例化
|
具体的な改善案と、その実施方法を提案。
実現可能性を考慮した提案を心がける。
| | 次回への提言 |
- プロジェクト計画時の余裕確保
- コミュニケーション計画の策定
- リスク管理体制の強化
|
次回のプロジェクトで活用できる具体的な推奨事項を記載。
優先順位を付けて記載することが望ましい。
|
記載上の注意点
- 客観的な事実に基づいて記載する
- 具体的な数値や事例を含める
- 再現性・実現可能性を考慮する
- 個人の責任追及を避ける
3. 応用例
3.1. システム開発プロジェクトでの適用例
大規模なシステム開発では、ビジネスケースから始まり、プロジェクト憲章の作成、変更管理、最終的な完了報告書の作成まで、体系的な文書管理が行われています。
3.2. アジャイル開発での活用
アジャイル開発においても、プロジェクト全体の方向性を示すプロジェクト憲章や、反復開発での変更管理において、これらのドキュメントが活用されています。
具体例として、スプリント計画書やバックログ管理の一環として教訓文書を利用することが挙げられます。
4. 例題
例題1
以下のうち、プロジェクト立ち上げ段階での主要なアウトプットとして最も適切なものはどれか。
- 変更登録簿
- プロジェクト憲章
- 完了報告書
- 是正処置
回答：2)
解説：プロジェクト憲章は、プロジェクトの立ち上げ段階における最も重要なアウトプットです。
例題2
プロジェクト実行中の変更管理において、承認された変更を記録する文書として最も適切なものはどれか。
- プロジェクト憲章
- ビジネスケース
- 変更登録簿
- 得た教訓文書
回答：3)
解説：変更登録簿は、プロジェクト実行中の変更要求とその承認状況を記録する文書です。
5. まとめ
プロジェクトの統合における主要なインプット及びアウトプットは、プロジェクトのライフサイクル全体を通じて重要な役割を果たします。プロジェクト作業規定書やビジネスケースからプロジェクトが開始され、プロジェクト憲章や全体計画を経て、変更管理や是正処置が行われ、最終的にプロジェクト完了報告書や得た教訓文書として締めくくられます。これらの文書の適切な管理と活用が、プロジェクトの成功につながります。