プロジェクトのトラブル解決大全 小さな問題から大炎上まで使える「プロの火消し術86」

木部智之

数々の炎上プロジェクトを解決、ゴールに導いてきた著者が、プロジェクトのトラブルを解決（防止）する方法を事細かに伝授する。
著者自身がこの本に書いた手法でIBM史上最大級のトラブルプロジェクトを解決したこともある「実践の書」だ。
準備→状況把握→原因特定とリカバリプラン策定→リスタートを切る→リカバリ遂行→クロージング という流れに沿って、プロジェクト上で起きるあらゆる落とし穴をカバーする。
加えて、メンバーモチベーションの管理および、リーダー自身のためになるリーダーシップとメンタリティについても解説。
「ずっと使える100の質問」の作り方、１人決断タイム、犯人活用法、正しいバッファーの置き方、チームのルール作り、オフィス改善のコツなど、超具体的な手法が満載！
プロジェクトマネジャー初心者、何かとトラブルが起きがちなチームリーダー、既に何度も炎上プロジェクトを任されたことのある人まで、学びのある１冊。

• カテゴリ: ビジネス・実用
• ジャンル: ビジネス・経済 / 経済
• 出版社: KADOKAWA
• 電子版発売日: 2022年02月18日
• コンテンツ形式: EPUB
• サイズ(目安): 10MB

[ブクログ · ★★★★★]

非常に良い。
１章の01に、"トラブル対応のファーストステップは「腹をくくる」こと。「自分は被害者だ」と思ったらそこで負け"と書いてあるのが素晴らしい。
内容の７割はトラブル時に限らず、通常のプロジェクト管理でも実施するべきことなので、炎上案件に関係なく参考になる内容。

[ブクログ · ★★★★★]

プロジェクト管理のための実践的なノウハウ・テクニックが詰まっている。
教科書的な話というか理想論的な話ではなく、筆者の経験を元にした対処法という仕立てなので、参考にできる術は多いと感じる。

[ブクログ · ★★★★★]

・成否は「最初に腹をくくれるかどうか」で9割決まる。
　〇：腹をくくり覚悟を決めている
　×：いざという時の逃げ道を作っている。(「自分は被害者だ」と思ったらそこで負け、他責にならない)

・「トラブルの原因は何だと思う？3つ教えて」、仮説を考えていないと答えられない。

・犯人探しが無意味な理由
　(1)犯人を間違ってしまう可能性が大きいから(色々な人の主観は正しいとは限らない)
　(2)たとえ犯人がわかっても、その人にだってプロジェクトで活躍してもらわないといけない

・ビジネスパーソンが仕事の期限を守る動機は２つだけです。
　(1)プロとして期限には必ず仕上げる、と言うモチベーション
　(2)期限を過ぎると怒られるから、遅れないようにやろうという気持ち(9割の人がこちら、それを考えると、期限を超えたときには指摘をしないといけない、ということが分かると思います。)

・長年の炎上経験から、「すみません」「申し訳ありません」という言葉を安易に発しなくなった。理由はシステム開発の契約形態にあり、自分たちの品質などに落ち度を認めてしまうと、それはどんなに時間とコストがなかったとしてもやらざるをえない状況においこまれてしまう可能性が高くなる。

・ただし本当に実害を伴う問題が起きたときには、すぐに謝る。原因は推測しない。原因がわからないうちに原因の可能性にまで言及してしまうと、余計なアクションを課せられることがあるから。この時真面目な人ほど「いつまでには報告します」と言い添えなくては、思うものですが先走って期限を切ると自分たちの首を絞めることになる。期限を求められなければ期限を宣言せずに「追って報告します」といって済ませますし、「報告します」と言わない事もあります。やらなくてもい仕事は増やさない事。

・できるリーダーはみんな姿勢がいい

[ブクログ · ★★★★★]

プロジェクトに対するマインド、管理すべき内容、リーダーシップについて、プロジェクトを成功させるための幅広いTipsがまとめられた本。
プロジェクトに関連するフレームワークの説明ではなくそれをどう使うかが述べられていて実践的であった。

[ブクログ · ★★★★★]

PMPとか他のプロジェクト管理の本とか読んだが、この本が最も実践的な内容である。
私の中だけなのかもしれないが、プロジェクト管理の名著と言ってよい。

[ブクログ · ★★★★★]

プロジェクトの理想的な進め方を記した本は世の中に数多くあれど、いざ炎上した時の対応方法が書かれた本は意外と少ない。しかし、ほぼ全てのプロジェクトで予想外のトラブルは必ず起きる。そして大半の現場では残業なり納期調整なり、もしかしたらテスト工程を省くなりで何となく凌いでいるのではないかと思う。もちろんこの本を読んだだけで明日からすぐ火消しが出来るようになるわけではなく、その局面に立って実践経験を積む必要はあるわけだが、それでも理論と実践的・具体的な術があるのと無いのとでは全然違うと思う。自分はプロジェクトマネジメントで一度失敗してしまい、先月から文字通り出直し的にPMの仕事に再挑戦している。本書を片手に火種の段階で消しながら進んでいきたい。

[ブクログ · ★★★★★]

トラブルに対する火消し術が、筆者の体験交えて書かれているので気持ちが入りやすくスラスラ読めた、
本書にも書かれている通り、トラブル中でなくても普段の業務で実践していきたい内容も多々あった。

体育会系っぽく受け取る人もいるとは思うが、絶対にやり切ると腹をくくること、そういうマインドを形成することは、確かにステークホルダーに影響を与えるし、少なからずチームのパフォーマンスにも影響を与えると、自分も思う。

[ブクログ · ★★★★☆]

炎上プロジェクトは避けて通りたいが、避けきれなかった場合はこの本を読み直そうと思う
判断ではなく決断というのはリーダーとして常に心掛けておきたいポイントだった

プロジェクトの把握
　プロジェクト計画書
　体制図
　　人数、チーム数
　　　メンバースキルの可視化
　　　　設計
　　　　プログラミング
　　　　業務スキル
　　　　マネジメント
　　　　リーダーシップ
　　リーダー、キーマン
　　　懐刀になる人
　　　トラブルメーカー
　　　　対応時は影響力を無視しない
　　指揮命令系統
　課題管理表
　　スケジュール、担当者
　　課題収集プロセス
　　優先度判断
　　　重要度、緊急度、難易度、効果、コスト、時間
　進捗報告資料
　
　質問項目
　　PMBOKの知識体系ベース
　　QCDベース
　　仮説を立てる
　　　トラブルの原因は？
　　　　問題、原因、対策
　　　　　あるべき姿と現実のギャップ
　　　　　マトリクスで検討
　　　　　　QCD、機能、開発フェーズなど
　　タテヨコ
　　　具体と抽象、類似
　　事実の確認
　　　なぜそう思うのか
　　　　原因は何だと思うか
　　　推測の場合は判断基準は
　　　　どの資料を見れば確認できるか
　　わかっていること、わかっていないこと
　　　軸毎に洗い出し
　　　　システム調査なら機能毎、など
　　できない理由の精査
　　　どうすればできるようになるのか
　　　　制約を外す方法は
やらないことを決める
　リソースの集中
スケジュールはゴールから逆算
　10％ほどのバッファー(見積もりの-10%で計画)
　バッファーはタスク毎に乗せない
　　メンバーからの見積もりは詳しく精査
　　スケジュール全体でバッファーを持つ
　1タスクは5営業日以内
　　担当者は必須
　　複数人での担当になる場合はタスクを分ける
会議
　頻度、議題、参加者が適切か
　　議事録、アクションリスト
　議論の活性化
　　各自に意見を求める
　準備不足の場合はリスケ
　　スケジュールは決める
プロジェクトの意義を共有
チームのルールは守らせる
　都度なぜ守らないか聞いたりして守る雰囲気を作る
最低限の管理
　作業管理、進捗管理、課題管理
　　作業遅延
　　　原因、対策、リカバリ予定日を確認する
　　課題
　　　内容は明確に分かりやすく
　　　担当者を決める
　　　　連名にしない
　　　期限を決める
　　　　最低限の日数で
　　　起票者は担当にしない
朝会
　前日の状況確認
　　問題、課題の状況確認
　　共有事項確認
　当日の予定確認
　課題表確認
属人性排除
　手順、プロセス定義
　テンプレート用意
　ツールでの自動化
マイクロマネジメント
　期間限定で行う
　確認頻度を上げる
　　朝会、夕会
　確認内容を細かく
　　数字での進捗確認からタスク内容の確認へ
PDCA
　PDとCAのマトリクスで考える
　　計画、実行内容がどうだったか
　　改善点をもとにしたアクションプラン
ガス抜きヒアリングでは約束はしない
　課題を理解したので検討する旨を伝える
　　共感はするが解決の約束はしない
リーダーシップ
　9割ポジティブ
　　諦め癖の言葉に注意
　　メンバーと話し合う
　支えになる言葉を持つ
　　転ぶときも前のめり
　責任を持つところと持たないところの線引きをしておく
　チームに良い緊張感をもたせる
　　メンバーの成果、仕事ぶりに厳しく
　　プロジェクト成功のための妥協をしない

[ブクログ · ★★★★☆]

プロジェクトには、
想定できない色々なことが起こります。

通常業務と違い、継続性、反復性というものではなく、
プロジェクトは、有期性、独自性という面があります。

なので、小さな火種を放置せず、
慌てることなく、逃げずに腹をくくり、
取り組むことが、大切であると学びました。

メンタル面、テクニック面について、記載があり、
一度に多く取り入れることはできないですが、
一つひとつ試してみようと思いました。

[ブクログ · ★★★★☆]

・感想
数々の炎上プロジェクトをうまく乗り越えてきた木部さんがどういう心持ちや取り組みを大事に解決してきてたかをまとめた書籍。
86テーマで記載がありますが、どれも大事なこと。
木部さん書籍を別で読んだので似たセリフもいくつかありましたが総じて良い本でした。

・Todo
課題1つ1つを放置することで炎上につながっていく。
炎上PJ は腹を括る
最初に大枠を掴む。
炎上PJは必ず人が問題で起こる。
必要質問は事前に100個洗い出す。
・PJに関するカテゴリを10個洗い出す
　10個ないなら5個でもとにかく網羅的に洗い出す
　参考はPMBOKの10の知識エリアを参考に
重要資料を一通り読んで、100の質問も見直したら自分で仮説を立ててアクションする。
トラブルでも仮説を立ててみる。
PJのメンテナンス用にホワイトボードに目を通す。

聞いたことを事実と感想に分けること
フレームワーク有効活用
犯人にも役立ってもらう。
問題、原因、対策をフローチャート図に起こす。
対策は制約ゼロベース思考で検討。
重要課題をマトリクスで整理する。

やらないものを選ぶ
体制の見直しや中心メンバーの業務負荷軽減については深く考え、場合によってはそのメンバーが炎上案件に集中できるようにする。
炎上PJは無理矢理にでもスケジュールを引く必要があり、その際には必ずロット分けをしてゴールから逆算する。
炎上PJは無理矢理にでもスケジュールを引く必要があり、その際には必ずロット分けをしてゴールから逆算する。
恫喝にはとにかく同調、専門家には専門家を。
#BookNotion
とにかく腹を括ること。
PJのやる意義とこんなトラブル大したことないとモチベーションを上げる発言をする。
PJの再スタートでは対面で問題点とスケジュール、具体策を直接説明する。
PJはこの3つの管理をうまくやることが出来れば大丈夫。
ただし、それが出来なくなったPJから炎上が始まる。
よくある。誰もが受けたがらず名前が空白になっているタスクね。これは本当にどうなのかといつも思ってしまう。
今でも思い出すことがある。
昔、なんでもかんでも営業さんが〜って丸投げしてくるPMが居たなぁ。お客さんも最後は味方になってくれて嬉しかったけど体制として不完全だったのは本当に情けない。
報告や共有資料は誰が見てもその場でわかる報告を意識すること。
無理矢理にでも割り振ること。
神経をすり減らしながらでも無理矢理にでも割り振ること。
誰かに極端に割り振られるタスクは無くすこと。
朝会を必ずセットし、対応する。
久しぶりに本読んでさーっとなりました。
めっちゃ多い。ちくちく言う。定例の日時を変える。
徹底しよう。
#BookNotion
会議というのは議論をする場である。
30秒で無駄な会議は終了させる。
期限を設けて中間報告と、遅れたタイミングでの報告と理由の説明を徹底させる。
バッドニュースファーストかつ評価できる仕組みを作る。
コミュニケーションが遅い人とは期限を切る。
口頭のコミュニケーションはなくして、図で書く。
ちょくちょくのホウレンソウで上司を安心させる。
仕事として愚痴を聞く。
腹を割って話を聞く場を作る。
メンタル不調のメンバーは言動より行動を重視して休ませる。
嫌われれる勇気を持つこと。
明けない夜はない。
炎上PJは出世のチャンスと考えて前向きに取り組む。
メモをとっていなくてもこれはある。。。
その人のキャリアを潰さない。。。
炎上PJを記録してあとで振り返られるようにする。