「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
計画プロセス全体の主要な役割 †
- 初めにテーラリングを行い、
プロジェクト・マネジメント・プロセスを選択・定義する。
- 比例して、時間と労力も多くなる。
- 計画だけで、実行、監視・制御のプロセス群と同じぐらいの時間をかける。
プロセス、インプット・アウトプット（ITTO） †
計画の流れ †
全容 †
↓ ↓ ↓
↓ ↓ ↓
プロジェクト計画書 †
↓ ↓ ↓
↓ ↓ ↓
↓ ↓ ↓
↓ ↓ ↓
↓ ↓ ↓
プロジェクト文書 †
プロジェクト・マネジメント計画書作成 †
プロジェクトをマネジメントするための全体的なアプローチを作成する。
- 各知識エリアの補助計画書を定義 / 準備 / 調整する方法を定義し、
各ベースラインをプロジェクト・マネジメント計画書に統合する方法を定義する。
- プロジェクト・マネジメント・プロセス（実施、監視・制御の方法）を選択・定義して文書化する。
補助計画書 †
- 最初に実行されるプロセスであるが、下記 補助計画書が含まれるため、
- 実際は、他の幾つかのプロセスの後に、プロジェクト・マネジメント計画書を作成する。
- また、補助計画書が更新された場合、プロジェクト・マネジメント計画書も更新する。
- 変更マネジメント計画書
ステークホルダーから何かしらの変更が提案された時、
どうやってその変更を受け入れ、処理するかといったルールを定めたもの。
- コンフィグレーション・マネジメント計画書
コンフィグレーション・コントロール配下に置く成果物を定義する。
また、変更前と変更後でどう変わったかを記録するルールを定める。
- パフォーマンス測定ベースライン（PMB）
頻繁に変更されることのない、マネジメント上のコントロール。
- その他
- プロジェクト・ライフサイクルの記述
- 開発アプローチ
プロジェクト文書 †
ちと古いかも（第4版のもの）。
- ステークホルダー特定
- ステークホルダー・マネジメント戦略
- ステークホルダー登録簿
- 要求事項収集
- 要求事項文書
- 要求事項トレーサビリティ・マトリックス
- アクティビティ定義
- アクティビティ属性
- アクティビティ・リスト
- マイルストーン・リスト
- アクティビティ資源見積り
- 資源ブレークダウン・ストラクチャー
- アクティビティ資源に対する要求事項
プロセスを選択・定義に影響を与える要素。
プロセスを選択・定義に影響を与える要素。
プロセス（ツールと技法） †
アウトプット †
プロジェクト・マネジメント計画書 †
- プロジェクト特性によって、概要レベルになることも、詳細レベルになることもある。
- 以下が記載される。
- プロジェクト進行に伴い、プロジェクトを実行、監視・制御する方法
- 及び、プロジェクト完了時に、プロジェクトを終結する方法
- プロセス（テーラリング作業の一部）
- 使用するプロセス
- プロセスの実現レベル（？）
- プロセスで使用するツール・技法
- プロセス（補助計画書）間の相互作用と依存関係
- ライフサイクルの定義
- プロジェクト全体のプロジェクト・ライフサイクル（フェーズ）
- 各フェーズのライフサイクル（必要に応じて）
- ステークホルダー
- コミュニケーション・ニーズ
- ニーズを満たすための技法
- 実行
目標を達成するための、プロジェクト作業を実行する方法。
- 実行、監視・制御
- パフォーマンス測定ベースライン（計画からの逸脱の測定に使用される）。
- 相互作用と依存関係から、変更の監視・制御の方法を定義
※ PMIでは、「必要に応じて承認を受ける。」としている。
コミュニケーション・マネジメント計画 †
- ステークホルダーとのコミュニケーション・ニーズを明らかにし、
PMとステークホルダーは「誰が」・「どの情報を」・「いつ得るか」を知る。
プロセス（ツールと技法） †
コミュニケーション要求事項分析 †
移動しました。
コミュニケーション・モデル †
移動しました。
コミュニケーション技術 †
移動しました。
コミュニケーション方法 †
移動しました。
コミュニケーションの障壁 †
移動しました。
アウトプット †
プロジェクト伝達事項 †
プロジェクト・マネジメント文書更新版 †
必要に応じて更新する。
- コミュニケーション・マネジメント計画書
- ステークホルダーのコミュニケーション・ニーズ
- ステークホルダーの持つ情報ニーズの種類
- 情報を配布するタイミング
- 情報を配布する手段（技法）
- コミュニケーションのタイミング、頻度、方法など。
（プロジェクトの規模や複雑さ、組織の方針によって変更する）
- 要素
- コミュニケーション要求事項
- コミュニケーション目的
- 配布の期間と頻度
- 情報伝達責任者
- フォーマットと技法
- フローチャート、共通用語集
- エスカレーション・プロセス
- 計画書の変更プロセス
プロジェクト文書更新版 †
必要に応じて更新する。
ステークホルダー・エンゲージメント計画 †
- 目的
- ステークホルダーと効果的に対話するための実践的な計画をする。
- 以下に基づき、ステークホルダーの関与を促す。
- ステークホルダーの
- 実行方法
- プロジェクト全体を通して定期的に実行される。
- ステークホルダーが特定された後、ライフサイクルの早い段階で策定
- フェーズの開始（時に新しいステークホルダーが特定されることがあるので、そ）の度に実行。
- プロジェクト・コミュニティの変更に伴い計画書は定期的にレビュー・更新される。
- 活動内容
- 更新のトリガ
プロジェクト・コミュニティの変更
- 新しいフェーズの開始時
- 組織構造や業界の変更時
- ステークホルダー追加・離脱時
- ステークホルダーの重要性の変更時
- ステークホルダー・エンゲージメント計画の戦略見直し
（変更マネジメント、リスク・マネジメント）
プロセス（ツールと技法） †
ステークホルダー関与度評価マトリックス †
SEAM (Stakeholder Engagement Assessment Matrix)
- 関与度の分類
| # | 分類 | 関与度の説明 |
| 1 | 不認識 | プロジェクトも影響も認識していない。 |
| 2 | 抵抗 | プロジェクトと影響を認識し、生じるTO-BEに抵抗（不支持）する。 |
| 3 | 中立 | プロジェクトと影響を認識し、生じるTO-BEに中立（支持も不支持もしない）。 |
| 4 | 支持 | プロジェクトと影響を認識し、生じるTO-BEを支持する。 |
| 5 | 指導 | プロジェクトと影響を認識し、プロジェクトに積極的にコントリビュート（貢献）する。 |
- 例
| # | ステークホルダー | 不認識 | 抵抗 | 中立 | 支持 | 指導 |
| 1 | A氏 | 現状 | ----------> | 目的 | |
| 2 | B氏 | | | 現状 -----> 目的 | |
| 3 | C氏 | | | | 現状 > 目的 | |
アウトプット †
プロジェクト・マネジメント文書更新版 †
必要に応じて更新する。
- ステークホルダーの参加を促すために使用する戦略を文書化する。
- ステークホルダーのニーズ、利害、影響度を文書化する。
- プロジェクトの意思決定に関するプロセスを文書化する。
- プロセスの相互作用と依存関係から、変更の監視・制御の方法を記述する。
- 要素
- 計画書の変更プロセス
- ステークホルダー間の関係
- コミュニケーション要求事項
- 情報配布の理由
予想される反応、関与レベルの変化、上記の両方
プロジェクト文書更新版 †
必要に応じて更新する。
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
