5つのプロセスグループ
立ち上げ → 計画 ⇔ 実行
↓↑ ↓↑
監視・コントロール → 終結
10個の知識エリア
1.統合 ⭐️⭐️
2.スコープ
3.スケジュール ⭐️
4.コスト
5.品質 ⭐️⭐️
6.資源
7.コミュニケーション
8.リスク ⭐️⭐️⭐️
9.調達
10.ステークホルダー ⭐️⭐️⭐️
1.統合 ⭐️⭐️
| エリア | プロセス | input | output |
|---|---|---|---|
| 立ち上げ | プロジェクト憲章の作成 | プロジェクト憲章、前提条件ログ | |
| 計画 | プロマネ計画書の作成 | プロジェクトマネジメント計画書 | |
| 実行 | プロジェクト作業の指揮・マネジメント | 成果物、作業パフォーマンスデータ、課題ログ | |
| 実行 | プロジェクト知識のマネジメント | 教訓登録簿 | |
| 監視・コントロール | プロジェクト知識作業の監視・コントロール | 作業パフォーマンス報告書、変更要求 | |
| 監視・コントロール | 統合変更管理 | 承認済変更要求、プロジェクト文書更新版(変更ログ) | |
| 終結 | プロジェクトやフェーズの終結 | 最終プロダクト・サービス・所産の移管、最終報告書、プロジェクト文書更新版 |
プロジェクトやフェーズの終結
全ての情報が含まれている→PMIS システム
効率指数
- スケジュール効率指数(SPI)
1→予定通り 1未満→遅延 ＞1→予定より早い - コスト効率指数(CPI)
1→予算通り 1未満→コストオーバー >1→予算より少ないコスト
意思決定マトリックスの利用手順
- 実行可能な選択肢を特定する
- 選択肢の評価基準を特定する
- 評価基準に相対的重みづけ(HML等）をする
- 各選択肢を各基準（最高を10として相対的に）で採点する
- 各点数に重みをかけて合計した値を各選択肢の総得点とする
- 総得点を参考に望ましい選択肢を決定する
3.スケジュール ⭐️
クラッシングとファストトラッキング
クラッシング: プロジェクトを早く完了するためにタスクにリソースを追加すること、ファストトラッキング:最初は順番にやることになっていたタスクを同時に開始すること
5.品質管理 ⭐️⭐️
| エリア | プロセス | input | tool | output |
|---|---|---|---|---|
| 計画 | 品質マネジメントの計画 | 品質マネジメント計画書、品質尺度 | ||
| 実行 | 品質のマネジメント | プロマネ計画書,プロジェクト文書,プロセス資産 | データ収集、分析、監査.. | テスト評価文書、変更要求 |
| 監視・コントロール | 品質のコントロール | プロマネ計画書,プロジェクト文書,承認済変更要求,成果物、作業用パフォーマンスデータ、組織環境要因EEF,プロセス資産 | データ収集、分析、検査、データ表現、会議.. | 品質コントロール測定結果、検証済成果物 |
監査＆検査
監査：プロセス、アクティビティを対象に、改善点や品質基準を満たされているかを確認
検査：プロジェクトの結果(成果物)を対象に、要求に満たされているかどうか
DoD
Doneの定義（DoD）とは、成果物の完成基準のことです。DoDを確認して品質問題を特定し、是正計画を立てます。
データ表現
特性要因図(ishikawa図、fishbone図)：原因、要因を特定
ランチャート、管理図(control chart): 時系列標準線があるやつ(管理の方は上下範囲があるやつ)
散布図: 2つの変数間の関係 点が点在しているやつ
ヒストグラム:成果物の欠陥数を表示 品質の配置
フローチャート：プロセス
プロトタイプ
プロジェクト等において、後の改良を見込んで大筋として作る最初の実態・実物のこと
(初期段階の試作)
7.コミュニケーション
DiSC行動モデル
- 主導型 D:単刀直入、成果重視、意志堅固
- 感化型 i:社交的、情熱的、楽観的
- 安定型 S:協調的、寛容、謙虚、如才ない
- 慎重型 C:分析的、控え目、正確
8.リスク
| エリア | プロセス | ツール | output |
|---|---|---|---|
| 計画 | リスクマネジメントの計画 | リスクマネジメント計画書 | |
| 計画 | リスクの特定 | リスクの定性的分析 | |
| 計画 | リスクの特定 | リスクの定量的分析 | |
| 計画 | リスク対応の計画 | 変更要求 | |
| 実行 | リスク対応策の実行 | 変更要求 | |
| 監視・コントロール | リスクの監視 | リスク監視・テータ分析 | 作業パフォーマンス情報,変更要求,プロジェクト文書更新版,リスク登録簿 |
リスクの特定のメイン成果物
・リスクレジスター：特定されたリスク、リスクonwer,リスク対応
・リスクレポート:特定されたリスクとチャンスの数、分類されたリスク分布、指標と傾向への洞察
(リスク登録簿は特定されたすべてのリスクと関連する詳細のマスタードキュメントですが、リスクレポートはプロジェクト全体のリスクの概要ドキュメントです。)
.プロジェクト文書の更新：仮定ログ、問題ログ、教訓
リスクへの対応策
リスクの軽減：発生確率・影響度を減らす(冗長化)
リスクの転移：結果を第三者に移す(保険・外注)
リスクの受け入れ：発生しても受け入れる
リスクの回避：発生しないように計画を変更
エスカレーション：PJのスコープ外・PMの権限を超えている場合
リスクの報告：
リスク態度
リスク回避、リスク中立、リスク許容、リスクシーキング(リスク大歓迎)
対リスク費用
管理準備金：予期しない作業のためのお金
予備費：既知のリスクに対しての資金
9.調達
| エリア | プロセス | input | tool | output |
|---|---|---|---|---|
| 計画 | 資源管理計画 | 資源管理計画書、憲章 | ||
| 計画 | アクティビティ資源見積もり | 資源要求事項、資源ブレークダウンストラクチャ | ||
| 実行 | 資源の獲得 | 先行割り当て、コロケーション、バーチャルチーム | 物的震源の割り当て、資源カレンダー | |
| 実行 | チームの育成 | チームのパフォーマンス評価 | ||
| 実行 | チームの管理 | 変更要求 | ||
| 監視・コントロール | 資源のコントロール | 作業パフォーマンス情報 |
ダックマンモデル
チーム形成の発展段階モデル
成立期→動乱→安定→遂行期→解散期
10.ステークホルダー ⭐️⭐️⭐️
| エリア | プロセス | input | tool | output |
|---|---|---|---|---|
| 立ち上げ | ステークホルダーの特定 | ステークホルダー登録簿 | ||
| 計画 | ステークホルダーエンゲージメントの計画 | ステークホルダーエンゲージメント計画書 | ||
| 実行 | ステークホルダーエンゲージメントのマネジメント | プロジェクト文書更新版、課題ログ | ||
| 監視・コントロール | ステークホルダーエンゲージメントの監視 | 作業パフォーマンス情報、変更要求 |
ステークホルダー登録簿
- 識別情報（氏名、役職、PJ内部での役割 等）
- 評価情報（期待や要求、影響 等）
- ステークホルダー分類
通常プロジェクトマネージャー自らのために利用し、他者に公表・配布するものではない
ステークホルダー分類
- ステークホルダー関与度評価マトリクス
- 権力と関心度のグリッド:
- 権利高&関心度高：注意深くマネジメント MGMT
- 権利高&関心度低：満足な状態を保つ
- 権利低&関心度高：常に情報を伝える
- 権利低&関心度低：監視のみ
ステークホルダーエンゲージメントを高める方法
1.ステークホルダー・マップを作成しプロジェクトの状況に応じて更新する
2.主要ステークホルダーを優先順位付けし、コミットメントと関与度を頻繁に見直す
3.主要なステークホルダーとの関係を深め、変革に対するコミットメントを高める。
アジャイル(スクラム)
## 構成役割
-
アジャイルチーム
- product owner:productの責任者、user story・product backlogを管理、開発チームに相談できるが、干渉できない
- 開発チーム:product onwerが順位付けしたproduct backlogの項目を順番に開発.3~9名ぐらい
- アジャイルコーチ:開発チームの進捗を妨害するのもを排除するが、管理はしない
-
ステークホルダー
プロダクトオーナーが調整、交渉、ヒアリング
puroduct backlog (要件定義みたいなもの)
- 実現したいことを全て書いた一覧
- プロダクトバックログ項目を書く形式の一つ[user story]
循環
product ownerが作ったuser storyを小さい循環単位(イテレーション)を分け
各循環単位(イテレーション/スプリント)内では、「設計(スプリントプランニング)」「開発(daily スクラム)」「テスト(スプリントレビュー)」「改善(スプリントレトロスペクティブ)」 が構成され
-
ベロシティ
一回の循環で完了する仕事の量 -
ストーリーポイント
user storyの作業量見積もりするために、開発チームと会話して、1つのストーリー実装に必要な作業量(story point)で表現
多いほど作業量が大きい -
planning poker
全員参加型で相対見積もりを行うための手法 -
スパイク
経験がない場合など見積もりができないストーリーに対し、時間を区切って、見積もりのための調査（調査だけで、実装まで必要ない） -
バックログ・リファインメント
バックログの優先順位をつけること -
バーンダウンチャート
縦軸：残り作業総量、横軸：インテレーション
傾き：チームのベロシティ
どれだけ完了したか、どれだけ残っているか、チームのベロシティ、いつ完了見込みがわかる図 -
スプリントプランニング
循環(スプリント)のゴールを決める
product owner は目的を明示し、完成するproduct backlogを選択
開発リーム はproduct backlogを実現する方法などを計画し、スプリントバックログを作成 -
daily scrum
毎日開催の進捗確認会議 -
スプリントレビュー
product ownerが開催し、ステークホルダーに参加してもらい、成果物の関係者demoを実施する -
スプリントレトロスペクティブ
チーム内次回のスプリントに向けての改善や品質を高める方法を計画する振り返り -
プロジェクト・イテレーション・ボード
-
MVP(実用最小限製品)
1循環内の実用最小限の製品→最低限に満足しないといけない仕様
3つの要因
A.明確なプロダクト・ビジョン
B.概要レベルのプロダクト・ロードマップ
C.優先順位付けされた概要レベルのプロダクト・バックログ
コンフリクトマネジメント
コンフリクト解消法：
撤退や回避
問題を回避または延期、対立から手を引いたり、対立を完全に避け
ステークホルダーの影響力が小さく コンフリクトが重大ではない場合
鎮静や適応
ステークホルダーの影響力が大きくコンフリクトが重大である場合(チームの調和や関係を維持することが最大の目標である場合)
どちらか一方が相手の要求を受け入れる
対立や意見の不一致を生じさせることなく行われる意思決定
妥協や和解
ステークホルダーの影響力が大きくコンフリクトが重大である場合
対立する二者が合意に達するために互いに何かを諦める(少なくとも一時的にまたは部分的に対立を解決する)
強制や指示
ステークホルダーの影響力が小さくコンフリクトが重大である場合
(緊急事態を解決するために権力のある立場から強制され)
どちらか一方が権力や権限を利用して、自らの要求を相手に飲ませる
一方の当事者が他方を犠牲にして自分の視点を押し付け、勝敗の解決策