「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
計画プロセス全体の主要な役割 †
- 初めにテーラリングを行い、
プロジェクト・マネジメント・プロセス
を選択・定義する。
- 比例して、時間と労力も多くなる。
- 計画だけで、実行、監視・制御のプロセス群と同じぐらいの時間をかける。
プロセス、インプット・アウトプット †
プロジェクト・マネジメント計画書作成 †
プロジェクトをマネジメントするための全体的なアプローチを作成する。
- 各知識エリアの補助計画書を定義 / 準備 / 調整する方法を定義し、
各ベースラインをプロジェクト・マネジメント計画書に統合する方法を定義する。
- プロジェクト・マネジメント・プロセス（実施、監視・制御の方法）を選択・定義して文書化する。
他のプロセスのアウトプット †
- 最初に実行されるプロセスであるが、下記 補助計画書が含まれるため、
- 実際は、他の幾つかのプロセスの後に、プロジェクト・マネジメント計画書を作成する。
- また、補助計画書が更新された場合、プロジェクト・マネジメント計画書も更新する。
- 変更マネジメント計画書
ステークホルダーから何かしらの変更が提案された時、
どうやってその変更を受け入れ、処理するかといったルールを定めたもの。
- コンフィグレーション・マネジメント計画書
変更前と変更後でどう変わったかを記録するルールを定めたもの。
- パフォーマンス測定ベースライン（PMB）
頻繁に変更されることのない、マネジメント上のコントロール。
- その他
- プロジェクト・ライフサイクルの記述
- 開発アプローチ
プロセスを選択・定義に影響を与える要素。
プロセスを選択・定義に影響を与える要素。
プロセス（ツールと技法） †
アウトプット †
プロジェクト・マネジメント計画書 †
- プロジェクト特性によって、概要レベルになることも、詳細レベルになることもある。
- 以下が記載される。
- プロジェクト進行に伴い、プロジェクトを実行、監視・制御する方法
- 及び、プロジェクト完了時に、プロジェクトを終結する方法
- プロセス（テーラリング作業の一部）
- 使用するプロセス
- プロセスの実現レベル（？）
- プロセスで使用するツール・技法
- プロセス（補助計画書）間の相互作用と依存関係
- ライフサイクルの定義
- プロジェクト全体のプロジェクト・ライフサイクル（フェーズ）
- 各フェーズのライフサイクル（必要に応じて）
- ステークホルダー
- コミュニケーション・ニーズ
- ニーズを満たすための技法
- 実行
目標を達成するための、プロジェクト作業を実行する方法。
- 実行、監視・制御
- パフォーマンス測定ベースライン（計画からの逸脱の測定に使用される）。
- 相互作用と依存関係から、変更の監視・制御の方法を定義
※ PMIでは、「必要に応じて承認を受ける。」としている。
コミュニケーション・マネジメント計画 †
- ステークホルダーとのコミュニケーション・ニーズを明らかにし、
PMとステークホルダーは「誰が」・「どの情報を」・「いつ得るか」を知る。
プロセス（ツールと技法） †
コミュニケーション要求事項分析 †
- 情報源
- 組織図
- ステークホルダーの責任関係
- 関連する機能部門と事業部門
- アクティビティと（人的）資源の数と場所
- ニーズ
- 内部ニーズ（内部とのコミュニケーションが必要）
- 外部ニーズ（外部とのコミュニケーションが必要）
- ステークホルダー情報（ステークホルダー登録簿に記載）
※ 参加者の数 = 3で計算すると解り易い。
コミュニケーション・モデル †
コミュニケーション・モデルの構成要素
- 基本要素（一方向コミュニケーション・モデル）
- コード化
- 送信者が理解可能な言語に変換する。
- このアウトプットがメッセージになる。
- メッセージの送信
- 送信者がコミュニケーション技術を使用してメッセージを送信する。
- 受信者のメッセージの理解を妨げる障壁をノイズ（先入観等）と呼ぶ。
- メッセージの解釈
受信者が受信したメッセージを解釈する。
- 双方向コミュニケーション・モデルの追加ステップ
- メッセージの受信確認
受信者がメッセージを受信したことを送信者に知らせる。
- フィードバッグ・応答
受信者のメッセージの理解度の確認
- 送信者の責任
- メッセージの送信
- 明確で完全な情報の送信
- 正しく解釈されているか判断
- 受信者の責任
- メッセージの受信
- 受信した情報を正しく解釈
- 適切な受信確認・応答
- 異文化コミュニケーションのコミュニケーション・モデル
異文化コミュニケーションでは、正しく解釈されているか判断するのが困難になる。
- 因子：働き方、専門領域、国籍、民族性、人種、年齢、性別
- 送信者：メッセージ内容と送信方法
- 媒体：異なる言語、プロセス、プロトコル
- 受信者：心の状態、知識/背景/人格/文化/偏見
コミュニケーション技術 †
コミュニケーション技術の選択。
- システム
- 電子メール
- オンライン・データベース
- オンライン・スケジューラ
- システム（手段）
- 既存のものが使えるか？新たに調達が必要か？
- そのシステムを使用した経験があるか？
- 全期間機能するか、アップグレードが必要になるか？
- チームの機能
- 同じ場所で働いているか？
- 複数の場所に分散しているか？
コミュニケーション方法 †
- プル型コミュニケーション
- Webサイト
- e-learningサイト
- リポジトリ（ナレッジ・ベース）
- ネットワーク・ドライブ
- その他のコミュニケーション方法
- 対人コミュニケーション（１対１）
- 少グループ・コミュニケーション（３ - ６人）
- 大衆コミュニケーション（１ 対 集団）
- マス・コミュニケーション（大規模、匿名グループ）
- SNSによるコミュニケーション（多対多）
アウトプット †
コミュニケーション・マネジメント計画書 †
- ステークホルダーのコミュニケーション・ニーズ
- ステークホルダーの持つ情報ニーズの種類
- 情報を配布するタイミング
- 情報を配布する手段（技法）
- コミュニケーションのタイミング、頻度、方法など。
（プロジェクトの規模や複雑さ、組織の方針によって変更する）
- 要素
- コミュニケーション要求事項
- コミュニケーション目的
- 配布の期間と頻度
- 情報伝達責任者
- フォーマットと技法
- フローチャート、共通用語集
- エスカレーション・プロセス
- 計画書の変更プロセス
プロジェクト・マネジメント文書更新版 †
必要に応じて更新する。
プロジェクト文書更新版 †
必要に応じて更新する。
ステークホルダー・エンゲージメント計画 †
プロセス（ツールと技法） †
ステークホルダー関与度評価マトリックス †
- 関与度の分類
| # | 分類 | 関与度の説明 |
| 1 | 不認識 | プロジェクトも影響も認識していない。 |
| 2 | 抵抗 | プロジェクトと影響を認識し、生じるTO-BEに抵抗（不支持）する。 |
| 3 | 中立 | プロジェクトと影響を認識し、生じるTO-BEに中立（支持も不支持もしない）。 |
| 4 | 支持 | プロジェクトと影響を認識し、生じるTO-BEを支持する。 |
| 5 | 指導 | プロジェクトと影響を認識し、プロジェクトに積極的にコントリビュート（貢献）する。 |
- 例
| # | ステークホルダー | 不認識 | 抵抗 | 中立 | 支持 | 指導 |
| 1 | A氏 | 現状 | ----------> | 目的 | |
| 2 | B氏 | | | 現状 -----> 目的 | |
| 3 | C氏 | | | | 現状 > 目的 | |
アウトプット †
ステークホルダー・エンゲージメント計画書 †
- ステークホルダーの参加を促すために使用する戦略を文書化する。
- ステークホルダーのニーズ、利害、影響度を文書化する。
- プロジェクトの意思決定に関するプロセスを文書化する。
- プロセスの相互作用と依存関係から、変更の監視・制御の方法を記述する。
プロジェクト文書更新版 †
必要に応じて更新する。
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
