読書ログ：プロジェクトマネジメントの基本が面白いほど身につく本
ran第1章 プロジェクトマネジメントの基本をおさえよう
そもそもプロジェクトとは
「独自の目標」と「期限」という２つの要素が設定されている「一連の活動」
「独自の目標」- 過去に経験したことのない要素が含まれている未来の目標
「期限」 - 目標を達成すべき未来の日付
プロジェクトには必ず「始まり」と「終わり」がある
プロジェクトの特徴
プロジェクトには以下の特徴があり、特徴を攻略しながら、上手にやりくり（＝プロジェクトマネジメント）することで目標達成を目指す。
①複数の制約が存在する
「コスト」「スケジュール」「品質」「人材要件」「仕様」...etc
②不確実性（＝リスク）が存在する
「事件・事故」「市場の変化」「経営状態の悪化」...etc
過去に経験したことのない要素が含まれている未来の目標だから
③独自のメンバー
「リーダーシップ」「育成」「モチベーション「コミュニケーション」...etc
測定ができないものは管理できない
プロジェクトマネジメントの知識と技術はあらゆるモノやコトを言語化し可視化するもの。言語化し可視化することで測定が可能になる。
工程表（WBSなど）にして測定可能にするとプロジェクトの管理がしやすくなる。
MORSの法則
- Measured 計測 数値化できる
- Observable 観察 誰が見てもどんな行動をしているかわかる
- Reliable 信頼 客観性があり誰が見ても同じ行動だと認識できる
- Specify 明確化 何をどうするかが明確になっている
SMARTの法則
- Specific 明確
- Measurable 測定可能
- Assignable 割り当て可能 誰が行うかが明確で役割や権限が割り当てられているか
- Realistic 現実的
- Time-bound 期限設定
ran第２章 未来の目標を明確にしよう
「できない理由を考える」のではなく「どうしたらできるか」を志向する
ゴールから考える。最初に目標を設定する。
＝目標達成時と現在のギャップ（差）を埋めるべく「どうしたらできるか」を考える
目標を明確に設定できる6W2H
- what このプロジェクトでなにをするのか
- why なぜこのプロジェクトを行うのか
- when このプロジェクトはいつからいつまでなのか
- who 誰がこのプロジェクトを行うのか
- whom 誰に対してこのプロジェクトを行うのか
- where どこでこのプロジェクトを行うのか
- how どのようにこのプロジェクトを行うのか（開発アプローチなど）
- how much このプロジェクトの予算はいくらか
6W2Hの情報源はステークホルダーのヒアリングで「情報をダイレクトに得る」ことが最も良い。
「誰が」「何を」要求しているかを要求事項にまとめ、やり直しを防ぐ。
利害衝突した要求は優先順位をつける
要求事項管理表に優先度の項目を設け、どれを優先的に対応すべきかを明確化する。
優先度は「Must」「should」「won't」などステークホルダーがわかりやすいもので表示する
6W2Hと要求事項をプロジェクト憲章にまとめる
プロジェクト憲章はプロジェクトの計画と実行をする前の企画書の位置づけ。
この中で6W2Hをさらに詳細化する。プロジェクト検証は作って終わりではなく、後から変更が入る可能性もある。
プロジェクト憲章の承認は決裁者に必ず承認を貰い署名又は捺印してもらう。
変更された場合も決裁者に必ず承認を貰い署名又は捺印してもらう。
→約束した・していない問題を回避する
長期や大きなプロジェクトになればなるほど決裁者も意思決定しづらい。
→フェーズで細切れにして決済を得るのも一つの手（＝スモールスタート）
ran第3章プロジェクトを計画しよう
目標は1日で達成できない 実行しやすいサイズに目標を細分化する
なにを なぜ いつ だれが だれに どこで どのように いくら(6W2H)で明確化して細分化
どのパーツが揃えば目標達成できるのか
どのパーツが揃えば目標達成できるのか 細分化することを要素分解という
タスクのヌケモレ遅延を防ぐ
WBS
要素分解するためのツールがWBS
一層目 目標やプロジェクト名
二層目 成果物 目標を達成するために必要なパーツ
三層目 要素成果物 成果物を完成させるために必要なパーツ
四層目 活動タスク 要素成果物を完成させるために必要な作業
WBS≠ガントチャート
WBSで抽出したタスクに開始日、終了日、優先順位を追加してガントチャートで工程管理する
マイルストーンをまず決め、それぞれのマイルストーンに間に合うようにタスクを調整する(=やりくりする)
スケジュール内で収まらない時
期日を変更する or 要求事項のレベルを下げる
いずれの方法で対処する場合もプロジェクト憲章を修正して再度決裁者の承認をもらうこと
スケジュールが遅延する二大要素
チームの生産性を考慮しない
開始当初は低く、徐々に向上する
プロジェクトの開始時は同じタスクボリュームでも時間がかかることを想定してスケジュールをつくる
決裁者の意思決定時間を考慮しない
会議のスケジュールや追加の資料作成にかかる時間
意思決定の時間を決め、意思決定自体もタスク化する
バッファ
タスクごとにバッファを設けるとダメ 怠けて使い切る
プロジェクト期間終了前やマイルストーン前にまとめてバッファを設ける
予算オーバーの対処法
ECRS
- Eliminate 排除
- Combine 結合
- Rearrange 入替、代替
- Simplify 簡素化
プロジェクト憲章の予算を変更する
決裁者の承認を忘れずに
リスク(不確実性)にはポジティブとネガティブがある
ただし大体はネガティブリスクを指す
リスクの抽出
- WBSやガントチャートなどあらゆる計画書を見て具体的なリスクを洗い出す
- 洗い出したリスクを影響度と発生頻度の3x3→定性リスク分析
- 対応するリスクの優先順位をつける→定量リスク分析
コンティンジェンシー計画
受容したリスクや残存リスクはコンティンジェンシー計画で対策する
コンティンジェンシー計画とはリスク発生時の対応計画
具体的には体制や手順、意思決定手段を文書で明確にしておく
ヒトモノカネジョウホウジカンの予備を準備しておくことも含まれる
変更要求への対応を決める
一般的にはプロジェクト憲章に記載する
どこまで、どの程度、会議の出席者、承認の意思決定方法など
具体的な場所や開催頻度、会議名などはコミュニケーションマネジメント計画書に記載
ran第4章プロジェクト計画を実行しよう
キックオフ会議
プロジェクトの実行フェーズを開始するための会議
キックオフの良し悪しでプロジェクト開始時点のチームの生産性が大きく変わる
細かい話はせずプロジェクトの社会的意義や会社としての意義を伝える→モチベーションを高めることを意識
メンバー同士の交流を促進させる→メンバー同士が理解し合える時間であることを意識
プロジェクト全体の進捗率
50％ー50％ルールを適用→割り当てた各タスクの進捗率の平均値をプロジェクト全体の進捗率とする
マニューバリング
プロジェクトが計画どおり進むようにやりくりすること
→それでも解決しない場合の最後の手段として決裁者との協議
是正措置
異変は発見したら早期に対処することが大切
→早期発見のための情報収集
→情報収集のためのコミュニケーション
進捗管理と情報分析も併せて行う
予防措置
想定できる問題や障害を事前に取り除く
→特定のチームの問題がほかのチームでも発生する可能性があれば情報共有する
→是正措置を予防措置につなげる
変更要求と変更会議
基本的にはマニューバリング(変更せずやりくりする)
それでも変更が必要になる場合がある
変更要求を管理表にまとめて変更会議にかける
変更によって他の要素に影響はないか
影響があるから他の要素をどう変化させればいいか
進捗レポートのポイント
現在、過去、未来
- 現状どうなったのか
- なぜそうなったのか
- これからどうするのか
プロジェクト終了書
失敗しても成功しても作成しプロジェクト終了会で決済者の承認を得る
プロジェクト終了書に教訓(成功要因、失敗要因)を残し、その教訓を活かすサイクルを回す
プロジェクト教訓の蓄積されることで未来のプロジェクトマネジャーはより高度なやりくりができる
ran第5章戦略的思考を身につけよう
バックキャスティング思考
現状から考えると現状が制約となりできない思考になる。目標から逆算することでどうしたらできるかという思考に変わる。
- 目標達成した地点＝ゴールから現状を見る
- 目標と現状のギャップを把握
- ギャップを埋めるために何が必要かどうしたらできるかを考える
エンジニアリングアプローチ
あらゆるモノやコトを可視化させてマネジメントしやすくすること。
見えないものを 言語化 可視化 構造化 する習慣を身につける。
ボトルネック
一連の作業プロセスの中で最も生産性が低く全プロセスの生産性に影響を与えている部分。
プロセス全体のアウトプットはボトルネックの生産性で決定づけられる。