- はじめに
- プロジェクト炎上の原因は品質問題から始まる
- 最初に必要なのは腹を括ること
- 仮説を持って現場を見る
- カラーバス効果を活用する
- 課題管理表を見るとプロジェクトレベルが分かる
- 課題が放置される理由
- 「それはなぜか？」を繰り返す
- 見積もりの−10％で計画を立てる
- プロジェクトは必ず予定通りには進まない
- ターゲットとしても現実的
- バッファーは個別に持たせない
- 人は余裕があると使い切る
- プロジェクトマネジメントで重要な考え方
- プロジェクトを進めるためには決断が必要
- 決断とは腹を括ること
- 完璧な情報は揃わない
- 静かなプロジェクトは怪しい
- 「順調です」が続くプロジェクト
- 悪い情報が出てこない方が危険
- 悪い報告はむしろ歓迎すべき
- 会議のための会議は無駄
- 情報共有だけの会議
- 私自身のプロジェクトでも同じ
- 会議をなくせないなら省力化する
- 遅延報告で必ず確認すべきこと
- 必要なのは3つの情報
- この3点がなければ追求する
- プロジェクト進捗は可視化する
- 見えないプロジェクトは危険
- 可視化には心理的効果もある
- 炎上プロジェクトの会議は議論の場である
- 会議は報告会ではない
- 一方通行の会議は価値がない
- 議論があるから会議の価値が生まれる
- 悪い報告が上がらない方が損をする
- 小さな火種のうちに見つける
- 小さな問題を放置すると炎上する
- 報連相は自分を守るためにも使う
- 定期報告を仕組み化する
- 聞かれなくても情報が届く状態を作る
- 上司対応もプロジェクトマネジメント
- 未来を想像する力
- 未来を具体的にイメージする
- 未来を想像できる人が強い
- スケジュールは未来を考えるために存在する
- PMBOKとの共通点
- プロジェクトの炎上を資産にする
- リフレクション（振り返り）の重要性
- 終わりから最初を見る
- 最初から終わりを見る
- 「もう一度やるならどうするか」を考える
- 過去を責めるためではない
- 自分の武器になる
- 問題対応を個人の経験で終わらせない
- 報告書に残すべき内容
- 組織へのフィードバックは必須
- 個人だけが学んでも意味がない
- 再発防止のための資産化
- PMBOKとの共通点
- PMPやPMBOKを学ぶ人にもおすすめ
- 建設プロジェクトとの共通点
- 私が学んだこと
- 完璧なプロジェクトは存在しない
- 良いPMとは何か
- まとめ
はじめに
『プロジェクトのトラブル解決大全』を読みました。
私は建設プロジェクトに携わる機会がありますが、本書はPM（プロジェクトマネージャー）やプロジェクトリーダーだけでなく、プロジェクトメンバーとして働く人にも非常に参考になる内容でした。
特に、
- プロジェクトマネジメント
- プロマネ
- PMBOK
を勉強している人にはおすすめしたい一冊です。
本書のテーマはシンプルです。
「炎上プロジェクトをどう立て直すか」
しかし内容は単なるトラブルシューティングではありません。
プロジェクトマネジメントの本質である、
- 問題発見
- 原因分析
- 意思決定
- 再発防止
まで踏み込んで解説されています。
私自身のプロジェクト経験とも重なる部分が多く、非常に学びの多い一冊でした。
プロジェクト炎上の原因は品質問題から始まる
本書で最初に印象的だったのは、
プロジェクトの炎上はQCDのうち品質問題から始まる
という考え方です。
QCDとは、
- Quality（品質）
- Cost（コスト）
- Delivery（納期）
です。
多くの人は、
工期遅延
や
予算超過
が炎上の原因だと考えます。
しかし本書では、
まず品質問題が発生する。
その対応で時間を使う。
コストが増加する。
納期が遅れる。
という流れで炎上が進行すると説明されています。
確かに私自身の建設プロジェクトでも、
図面品質
設計品質
仕様の不整合
などが発端となり、
最終的に工期やコストへ影響するケースを何度も見てきました。
PMBOKでも品質マネジメントは重要な知識エリアですが、本書を読んで改めて品質の重要性を認識しました。
最初に必要なのは腹を括ること
本書で何度も登場するキーワードが、
「腹を括る」
です。
炎上プロジェクトに入ると、
- 前任者が悪い
- 他部署が悪い
- 発注者が悪い
と言いたくなります。
しかし本書では、
「自分のせいではないと思ったら負け」
と表現されています。
これは非常に厳しい言葉ですが、本質を突いていると思いました。
実際には自分が原因ではなくても、
プロジェクトを立て直す責任を負った以上、
最終的には自分がやり切るしかありません。
プロジェクトマネジメントにおいて重要なのは、
責任の所在を議論することではなく、
プロジェクトを成功に導くこと
なのだと感じました。
仮説を持って現場を見る
本書では、
炎上プロジェクトへアサインされた直後にやるべきこと
として、
仮説を立てる
ことが挙げられています。
まず、
QCD
組織
コミュニケーション
進捗管理
などの観点から質問リストを作る。
そして、
なぜ問題が起きているのか
を考える。
その後で現場を確認する。
この順番が重要だと説明されています。
カラーバス効果を活用する
この考え方は非常に納得感がありました。
本書では、
カラーバス効果
という言葉が紹介されています。
人は一度意識した情報を見つけやすくなるという心理効果です。
例えば、
「品質管理に問題があるのではないか」
という仮説を持って現場を見ると、
品質に関する異常や違和感に気付きやすくなります。
逆に何も考えずに現場を見ると、
問題が目の前にあっても気付けません。
プロジェクトマネジメントにおいて、
まず仮説を持つことの重要性を学びました。
課題管理表を見るとプロジェクトレベルが分かる
本書の中で非常に共感したのが、
課題管理表を見ればプロジェクト状況が分かる
という話です。
私自身も建設プロジェクトを経験してきましたが、
会議で指摘された課題が放置される
ということは本当に多いです。
課題が放置される理由
本書では、
課題管理が機能しない理由として、
- 課題の吸い上げルールがない
- 担当者が決まっていない
- 期限が設定されていない
- 期限切れ後も放置される
ことが挙げられています。
これは非常によく分かります。
会議で問題提起されても、
「誰がやるのか」
が決まっていないため進まない。
結果として次回会議でも同じ話題になる。
この繰り返しです。
プロジェクトマネジメントでは、
課題管理表の品質そのものがプロジェクト品質を表している
と言えるかもしれません。
「それはなぜか？」を繰り返す
本書では、
問題報告を簡単に信じてはいけない
とも説明されています。
例えば、
「工期が遅れています」
という報告があった場合、
そこで終わりではありません。
なぜ遅れたのか。
なぜその状態になったのか。
なぜ事前に気付けなかったのか。
と掘り下げていく必要があります。
いわゆる
「なぜを5回繰り返す」
考え方です。
私自身も業務で実践してみたいと思いました。
問題の表面だけを見るのではなく、
本質原因へたどり着く訓練が必要だと感じます。
見積もりの−10％で計画を立てる
本書で興味深かった考え方の一つが、
「見積もりの−10％で計画を立てる」
という考え方です。
通常の感覚では、
見積もり通りに計画を立てれば良い
と思ってしまいます。
しかし本書では、
プロジェクトは想定外が起きることを前提に考えるべき
だと説明されています。
プロジェクトは必ず予定通りには進まない
建設プロジェクトでも同じですが、
実際には、
- 設計変更
- 手戻り
- 調達遅延
- 人員不足
- 顧客要望変更
などが発生します。
つまり、
工期もコストも増加する方向に働きやすい
のです。
そのため、
見積もりをそのまま使うのではなく、
一定の余裕を残した計画を立てる
ことが重要になります。
ターゲットとしても現実的
この考え方は、
単なる楽観的な計画ではなく、
チームにとって実行可能な目標設定
という意味でも有効だと感じました。
あまりにも厳しい目標を設定すると、
最初から達成できない空気が生まれます。
逆に余裕がありすぎると、
人は先延ばしを始めます。
適度な緊張感を持たせながら、
最終的な余裕も確保する。
プロジェクトマネジメントにおける計画策定の難しさを感じる部分でした。
バッファーは個別に持たせない
本書でもう一つ印象的だったのが、
バッファー管理
です。
一般的には、
各担当者がそれぞれ余裕を持つ
ことがあります。
しかし本書では、
バッファーは一括管理するべき
と説明されています。
人は余裕があると使い切る
これは非常に納得できる内容でした。
例えば、
本来3日で終わる仕事に対して、
5日ある
となると、
多くの場合は5日使ってしまいます。
学生時代の夏休みの宿題と同じです。
締切直前まで手を付けないことがあります。
プロジェクトマネジメントで重要な考え方
そのため、
各工程に余裕を持たせるのではなく、
プロジェクト全体でバッファーを管理する
方が効率的です。
これはPMBOKのスケジュールマネジメントを考える上でも非常に参考になる考え方でした。
プロジェクトを進めるためには決断が必要
本書では、
決断
についても多く語られています。
プロジェクトが停滞する原因の一つは、
決断しないこと
です。
決断とは腹を括ること
本書では、
決断とは腹を括ること
と表現されています。
プロジェクトでは、
どの案にもリスクがあります。
100％正しい選択肢は存在しません。
そのため、
どれかを選ぶしかない
場面が必ず出てきます。
完璧な情報は揃わない
プロジェクトマネジメントでは、
情報が揃うまで待つ
という姿勢は危険です。
待っている間にも、
工期は進みます。
コストは発生します。
問題は拡大します。
そのため、
現時点で最善と思われる判断を行う
ことが重要になります。
これはPMやプロマネに求められる重要な能力だと感じました。
静かなプロジェクトは怪しい
本書の中で非常に共感したのが、
静かなプロジェクトは危険
という話です。
「順調です」が続くプロジェクト
会議で、
- 問題ありません
- 順調です
- 計画通りです
という報告ばかりが続くことがあります。
一見すると良い状況に見えます。
しかし本書では、
むしろ危険信号
だと説明されています。
悪い情報が出てこない方が危険
私自身の経験でも、
工期遅延の兆候があるにもかかわらず、
担当者が報告していない
ケースを見たことがあります。
理由は様々です。
- 怒られたくない
- 自分で解決できると思っている
- 面倒だから
しかし結果として、
小さな問題が大きな問題になります。
悪い報告はむしろ歓迎すべき
本書では、
悪い報告が上がってくる組織の方が健全
と説明されています。
小さな火種の段階で問題が共有されれば、
早期に対処できます。
炎上プロジェクトの多くは、
問題が存在しなかったのではなく、
見えなかっただけ
なのかもしれません。
会議のための会議は無駄
本書で特に共感したのが、
会議のあり方
についてです。
情報共有だけの会議
多くのプロジェクトでは、
担当者が順番に報告するだけ
という会議があります。
例えば、
A担当
「予定通りです」
B担当
「問題ありません」
C担当
「順調です」
これで1時間終わる。
本書では、
このような会議に価値はない
と説明されています。
私自身のプロジェクトでも同じ
私自身のプロジェクトでも、
まさに同じ状況があります。
毎週会議を開催しているものの、
議論がほとんど発生しない。
結果として、
時間だけが消費されます。
本書を読んで、
本当に必要な会議なのか
を考えるきっかけになりました。
会議をなくせないなら省力化する
ただし、
会議を完全になくす
ことは現実的ではありません。
関係者も多く、
反対も出るでしょう。
そのため、
- 開催頻度を下げる
- 資料共有だけにする
- ドキュメントレビューにする
など、
できる限り省力化することが重要だと感じました。
遅延報告で必ず確認すべきこと
本書では、
遅延報告を受けた際のポイント
も紹介されています。
単に、
「遅れています」
という報告では意味がありません。
必要なのは3つの情報
報告時には、
理由
なぜ遅れたのか
対策
何を実施するのか
リカバリー
どのように挽回するのか
この3つが必要です。
この3点がなければ追求する
本書では、
理由・対策・リカバリーが示されない場合は追求する
と書かれていました。
これは非常に納得できます。
遅延報告そのものに価値はありません。
重要なのは、
どう解決するのか
です。
プロジェクト進捗は可視化する
本書で繰り返し語られていたのが、
「見える化」
の重要性です。
プロジェクトマネジメントでは、
進捗を管理する
ことが重要だとよく言われます。
しかし実際には、
担当者しか状況を知らない
というケースも少なくありません。
見えないプロジェクトは危険
プロジェクトの進捗が見えない状態では、
問題が発生していても気付けません。
また、
「誰かがやっているだろう」
という思い込みも発生します。
本書では、
進捗を可視化し、全員で共有すること
の重要性が説明されています。
可視化には心理的効果もある
進捗管理は単なる管理手法ではありません。
可視化することで、
- 自分の現在地が分かる
- ゴールまでの距離が分かる
- 遅れが明確になる
という効果があります。
これは心理的にも大きな意味があります。
例えばマラソンでも、
あと何kmか分からない状態
より、
残り3km
と分かった方が走りやすいものです。
プロジェクトも同じです。
進捗の見える化は、チーム全体の行動を変える力があります。
炎上プロジェクトの会議は議論の場である
本書で非常に共感したのが、
会議の目的
についてです。
会議は報告会ではない
炎上プロジェクトでは、
問題が発生しています。
つまり、
考えなければならないこと
決めなければならないこと
が存在します。
そのため会議の目的は、
議論
であるべきです。
一方通行の会議は価値がない
本書では、
- 一方的な報告
- 指示だけの会議
- 情報共有だけの会議
は健全ではないと説明されています。
確かに、
会議で報告だけして終わるのであれば、
メールや資料共有でも成立します。
わざわざ人を集める意味がありません。
議論があるから会議の価値が生まれる
会議の価値は、
異なる視点がぶつかること
にあります。
例えば、
工期遅延
という問題に対しても、
設計担当
施工担当
調達担当
品質担当
それぞれ見えている景色が違います。
その情報を持ち寄り、
どう解決するかを議論する。
これが本来の会議だと感じました。
悪い報告が上がらない方が損をする
本書で印象に残った考え方が、
悪い報告は損ではなく得
ということです。
小さな火種のうちに見つける
プロジェクトでは、
最初は小さな問題から始まります。
例えば、
図面確認が少し遅れている
部材調達に懸念がある
担当者が不足している
などです。
小さな問題を放置すると炎上する
しかし、
報告しない
共有しない
という状態になると、
問題は大きくなります。
その結果、
工期遅延
予算超過
品質問題
につながります。
本書を読んで、
悪い報告を歓迎する文化
がプロジェクトマネジメントには必要だと感じました。
報連相は自分を守るためにも使う
本書では報連相についても興味深い考え方が紹介されています。
一般的には、
報連相は上司のため
と思われがちです。
しかし本書では、
自分の仕事を邪魔させないため
という視点が紹介されています。
定期報告を仕組み化する
例えば、
月2回
毎週金曜日
など、
定期的な報告を行います。
すると、
上司は状況を把握できます。
聞かれなくても情報が届く状態を作る
すると、
「今どうなっている？」
という問い合わせが減ります。
結果として、
自分の仕事を中断される回数が減ります。
これは非常に面白い考え方でした。
報連相は管理のためだけではなく、
仕事の効率化にも使えるということです。
上司対応もプロジェクトマネジメント
本書を読んで改めて感じたのは、
プロジェクトは現場だけでは動かない
ということです。
上司
経営層
顧客
協力会社
など、
多くのステークホルダーが存在します。
そのため、
上司マネジメント
も重要になります。
未来を想像する力
本書で非常に参考になったのが、
カレンダーとマスタースケジュールを並べて見る
という考え方です。
未来を具体的にイメージする
プロジェクトでは、
今日の仕事
ばかりに目が向きがちです。
しかし重要なのは、
未来に起こる問題を予測すること
です。
未来を想像できる人が強い
例えば、
3か月後に大型機器が搬入される
とします。
すると、
- 搬入経路は確保できているか
- 基礎工事は終わっているか
- 電源は準備できているか
- 設計は完了しているか
などを考える必要があります。
これがプロジェクトマネジメントです。
スケジュールは未来を考えるために存在する
多くの人は、
スケジュールを報告資料
として扱っています。
しかし本来は、
未来を予測するためのツール
です。
カレンダーとマスタースケジュールを見ながら、
未来の行動を具体的に想像する。
この考え方は非常に参考になりました。
PMBOKとの共通点
PMBOKでも、
リスクマネジメント
スケジュールマネジメント
が重要視されています。
本書の内容は、
理論だけでなく、
現場でどう考えるか
に落とし込まれている点が特徴です。
PMBOKを学んでいる人にとっても理解を深める助けになると思います。
プロジェクトの炎上を資産にする
本書を読んで最も印象に残った考え方が、
「炎上プロジェクトを資産にする」
という考え方です。
炎上プロジェクトは誰も経験したくありません。
工期は遅れる。
品質問題が発生する。
顧客から厳しい指摘を受ける。
社内からもプレッシャーがかかる。
できれば避けたいものです。
しかし本書では、
炎上したこと自体を失敗として終わらせるのではなく、
次のプロジェクトで活かせる資産に変えること
が重要だと説明されています。
これはプロジェクトマネジメントにおいて非常に重要な考え方だと思いました。
リフレクション（振り返り）の重要性
本書では、
リフレクション
の重要性が繰り返し説明されています。
単なる反省会ではありません。
終わりから最初を見る
まず、
プロジェクト完了時点から振り返る
方法があります。
例えば、
- なぜ工期が遅れたのか
- なぜ品質問題が発生したのか
- なぜ予算超過したのか
を整理します。
最初から終わりを見る
もう一つは、
プロジェクト開始時点から振り返る
方法です。
例えば、
- 初期段階で気付けた兆候はなかったか
- 課題管理は適切だったか
- リスク管理は十分だったか
を確認します。
本書では、
この両方向から振り返ること
が重要だと説明されています。
「もう一度やるならどうするか」を考える
特に印象的だったのは、
「もう一度同じプロジェクトをやるならどうするか」
という問いです。
過去を責めるためではない
振り返りは、
誰が悪かったか
を決めるためではありません。
重要なのは、
次に同じ状況になったらどう対応するか
を考えることです。
自分の武器になる
例えば、
- この段階でリスクレビューを実施する
- この会議体は廃止する
- この課題は即エスカレーションする
など、
具体的な改善策が見えてきます。
そして、
「以前似たような問題があった」
という経験は、
次のプロジェクトでの武器になります。
これこそが炎上を資産にするという考え方だと思いました。
問題対応を個人の経験で終わらせない
本書では、
プロジェクト終了後の報告
についても説明されています。
報告書に残すべき内容
例えば、
- プロジェクトの背景
- 発生したトラブル
- 根本原因
- 解決に向けたアプローチ
- 成功した施策
- 失敗した施策
などです。
多くの組織では、
問題を解決した時点で終わってしまいます。
しかし、
記録として残さなければ再発防止にはつながりません。
組織へのフィードバックは必須
本書で非常に共感したのが、
組織へのフィードバックは必須
という考え方です。
個人だけが学んでも意味がない
例えば、
担当者が炎上経験から学んだとしても、
異動や退職をすれば知識は失われます。
そのため、
組織として知見を蓄積する
ことが重要になります。
再発防止のための資産化
本書では、
プロジェクトチームとしての課題
組織としての課題
を整理することが推奨されています。
例えば、
チーム課題
- 課題管理が機能していなかった
- 会議が形骸化していた
- 情報共有が不足していた
組織課題
- 人員不足
- 教育不足
- 意思決定プロセスの問題
などです。
ここまで整理して初めて、
再発防止のための資産
になります。
PMBOKとの共通点
本書を読みながら感じたのは、
PMBOKの考え方と非常に近い
ということです。
PMBOKでは、
- 品質マネジメント
- リスクマネジメント
- スケジュールマネジメント
- ステークホルダーマネジメント
などが体系的に整理されています。
本書は、
その理論を現場でどう使うか
に焦点を当てています。
PMPやPMBOKを学ぶ人にもおすすめ
私は現在、
PMBOKやPMPについて学習しています。
その中で感じるのは、
理論だけでは現場は動かない
ということです。
例えば、
リスク管理が重要
と理解していても、
実際にどう問題を見つけるのか
どう関係者を動かすのか
は別問題です。
本書はそのギャップを埋めてくれる内容だと思いました。
建設プロジェクトとの共通点
私自身も建設プロジェクトに携わっていますが、
本書で紹介されている内容は非常に共感できるものが多くありました。
例えば、
課題管理が放置される
担当者が悪い情報を上げない
会議が報告会になっている
工期遅延を楽観視する
などです。
業界は違っても、
プロジェクトの本質的な問題は共通しているのだと感じました。
私が学んだこと
本書を読んで最も学んだのは、
プロジェクトマネジメントとは、
問題をなくすことではなく、
問題を早く見つけて対処すること
だという点です。
完璧なプロジェクトは存在しない
プロジェクトでは必ず問題が発生します。
重要なのは、
問題が起きないこと
ではありません。
問題が小さいうちに発見されること
です。
良いPMとは何か
本書を読んで感じた良いPM像は、
- 腹を括る
- 仮説を持つ
- 悪い情報を歓迎する
- 決断する
- 学びを残す
人です。
派手なリーダーシップではありません。
地道に問題へ向き合い続ける姿勢が重要なのだと思いました。
まとめ
『プロジェクトのトラブル解決大全』は、
単なるトラブルシューティング本ではありません。
プロジェクトマネジメントの本質を、
非常に実践的な形で学べる一冊でした。
特に印象に残ったのは、
- 炎上は品質問題から始まる
- 腹を括ることが重要
- 仮説を持って現場を見る
- 悪い報告を歓迎する
- 会議は議論の場である
- バッファーは一括管理する
- 炎上を資産に変える
という考え方です。
プロジェクトマネジメントやPMBOKを学んでいる方、
これからPMやプロマネを目指す方、
現在炎上プロジェクトで苦労している方にとって、多くの学びが得られる一冊だと思います。
私自身も、本書で学んだ内容を今後のプロジェクト運営やPMBOKの学習に活かしていきたいと思います。
コメント