あらすじ
数々の炎上プロジェクトを解決、ゴールに導いてきた著者が、プロジェクトのトラブルを解決（防止）する方法を事細かに伝授する。
著者自身がこの本に書いた手法でIBM史上最大級のトラブルプロジェクトを解決したこともある「実践の書」だ。
準備→状況把握→原因特定とリカバリプラン策定→リスタートを切る→リカバリ遂行→クロージング という流れに沿って、プロジェクト上で起きるあらゆる落とし穴をカバーする。
加えて、メンバーモチベーションの管理および、リーダー自身のためになるリーダーシップとメンタリティについても解説。
「ずっと使える100の質問」の作り方、１人決断タイム、犯人活用法、正しいバッファーの置き方、チームのルール作り、オフィス改善のコツなど、超具体的な手法が満載！
プロジェクトマネジャー初心者、何かとトラブルが起きがちなチームリーダー、既に何度も炎上プロジェクトを任されたことのある人まで、学びのある１冊。
感情タグBEST3
Posted by ブクログ
身につまされすぎる…
自分が駄目なリーダーそのものだ…
だめな例に当てはまり過ぎる…
本当に、火消しはスキルなのか？
覚悟を持ってやれということか…
Posted by ブクログ
基幹システムの導入プロジェクトで初めてのチームリードを任されたものの、メンバー管理で頭を悩ませていた時に手を取った本。
筆者が現場で試行錯誤したアイディアが惜しげもなく披露されています。
Posted by ブクログ
著者の経験からのトラブル解決法がまとめられたもの。ライトに読めて読みやすい仕上がりにもなっているが、なんというか血の匂いというか血に足ついた実践的な具体な内容でとても良書でした。
こういう本はPMBOKとかのフレームワークからブレイクダウンした内容になりがちですが、戦場帰還兵のリアルなボトムアップアプローチからなる戦術本だと思いました。
Posted by ブクログ
非常に良い。
１章の01に、"トラブル対応のファーストステップは「腹をくくる」こと。「自分は被害者だ」と思ったらそこで負け"と書いてあるのが素晴らしい。
内容の７割はトラブル時に限らず、通常のプロジェクト管理でも実施するべきことなので、炎上案件に関係なく参考になる内容。
Posted by ブクログ
プロジェクト管理のための実践的なノウハウ・テクニックが詰まっている。
教科書的な話というか理想論的な話ではなく、筆者の経験を元にした対処法という仕立てなので、参考にできる術は多いと感じる。
Posted by ブクログ
・成否は「最初に腹をくくれるかどうか」で9割決まる。
〇：腹をくくり覚悟を決めている
×：いざという時の逃げ道を作っている。(「自分は被害者だ」と思ったらそこで負け、他責にならない)
・「トラブルの原因は何だと思う？3つ教えて」、仮説を考えていないと答えられない。
・犯人探しが無意味な理由
(1)犯人を間違ってしまう可能性が大きいから(色々な人の主観は正しいとは限らない)
(2)たとえ犯人がわかっても、その人にだってプロジェクトで活躍してもらわないといけない
・ビジネスパーソンが仕事の期限を守る動機は２つだけです。
(1)プロとして期限には必ず仕上げる、と言うモチベーション
(2)期限を過ぎると怒られるから、遅れないようにやろうという気持ち(9割の人がこちら、それを考えると、期限を超えたときには指摘をしないといけない、ということが分かると思います。)
・長年の炎上経験から、「すみません」「申し訳ありません」という言葉を安易に発しなくなった。理由はシステム開発の契約形態にあり、自分たちの品質などに落ち度を認めてしまうと、それはどんなに時間とコストがなかったとしてもやらざるをえない状況においこまれてしまう可能性が高くなる。
・ただし本当に実害を伴う問題が起きたときには、すぐに謝る。原因は推測しない。原因がわからないうちに原因の可能性にまで言及してしまうと、余計なアクションを課せられることがあるから。この時真面目な人ほど「いつまでには報告します」と言い添えなくては、思うものですが先走って期限を切ると自分たちの首を絞めることになる。期限を求められなければ期限を宣言せずに「追って報告します」といって済ませますし、「報告します」と言わない事もあります。やらなくてもい仕事は増やさない事。
・できるリーダーはみんな姿勢がいい
Posted by ブクログ
プロジェクトに対するマインド、管理すべき内容、リーダーシップについて、プロジェクトを成功させるための幅広いTipsがまとめられた本。
プロジェクトに関連するフレームワークの説明ではなくそれをどう使うかが述べられていて実践的であった。
Posted by ブクログ
PMPとか他のプロジェクト管理の本とか読んだが、この本が最も実践的な内容である。
私の中だけなのかもしれないが、プロジェクト管理の名著と言ってよい。
Posted by ブクログ
プロジェクトの理想的な進め方を記した本は世の中に数多くあれど、いざ炎上した時の対応方法が書かれた本は意外と少ない。しかし、ほぼ全てのプロジェクトで予想外のトラブルは必ず起きる。そして大半の現場では残業なり納期調整なり、もしかしたらテスト工程を省くなりで何となく凌いでいるのではないかと思う。もちろんこの本を読んだだけで明日からすぐ火消しが出来るようになるわけではなく、その局面に立って実践経験を積む必要はあるわけだが、それでも理論と実践的・具体的な術があるのと無いのとでは全然違うと思う。自分はプロジェクトマネジメントで一度失敗してしまい、先月から文字通り出直し的にPMの仕事に再挑戦している。本書を片手に火種の段階で消しながら進んでいきたい。
Posted by ブクログ
トラブルに対する火消し術が、筆者の体験交えて書かれているので気持ちが入りやすくスラスラ読めた、
本書にも書かれている通り、トラブル中でなくても普段の業務で実践していきたい内容も多々あった。
体育会系っぽく受け取る人もいるとは思うが、絶対にやり切ると腹をくくること、そういうマインドを形成することは、確かにステークホルダーに影響を与えるし、少なからずチームのパフォーマンスにも影響を与えると、自分も思う。
Posted by ブクログ
・計画書、体制図、課題表、進捗報告資料が重要
・課題表は誰が観てもわかる記載に
・質問は深掘りと新たな視点
・先を見ること、リスクや成り行きを想像する時間を必ず持つこと
・バッファは一番最後に
・課題表は期日の数日前に必ず報告する
・悪い報告は歓迎する
Posted by ブクログ
炎上プロジェクトは避けて通りたいが、避けきれなかった場合はこの本を読み直そうと思う
判断ではなく決断というのはリーダーとして常に心掛けておきたいポイントだった
プロジェクトの把握
プロジェクト計画書
体制図
人数、チーム数
メンバースキルの可視化
設計
プログラミング
業務スキル
マネジメント
リーダーシップ
リーダー、キーマン
懐刀になる人
トラブルメーカー
対応時は影響力を無視しない
指揮命令系統
課題管理表
スケジュール、担当者
課題収集プロセス
優先度判断
重要度、緊急度、難易度、効果、コスト、時間
進捗報告資料
質問項目
PMBOKの知識体系ベース
QCDベース
仮説を立てる
トラブルの原因は？
問題、原因、対策
あるべき姿と現実のギャップ
マトリクスで検討
QCD、機能、開発フェーズなど
タテヨコ
具体と抽象、類似
事実の確認
なぜそう思うのか
原因は何だと思うか
推測の場合は判断基準は
どの資料を見れば確認できるか
わかっていること、わかっていないこと
軸毎に洗い出し
システム調査なら機能毎、など
できない理由の精査
どうすればできるようになるのか
制約を外す方法は
やらないことを決める
リソースの集中
スケジュールはゴールから逆算
10％ほどのバッファー(見積もりの-10%で計画)
バッファーはタスク毎に乗せない
メンバーからの見積もりは詳しく精査
スケジュール全体でバッファーを持つ
1タスクは5営業日以内
担当者は必須
複数人での担当になる場合はタスクを分ける
会議
頻度、議題、参加者が適切か
議事録、アクションリスト
議論の活性化
各自に意見を求める
準備不足の場合はリスケ
スケジュールは決める
プロジェクトの意義を共有
チームのルールは守らせる
都度なぜ守らないか聞いたりして守る雰囲気を作る
最低限の管理
作業管理、進捗管理、課題管理
作業遅延
原因、対策、リカバリ予定日を確認する
課題
内容は明確に分かりやすく
担当者を決める
連名にしない
期限を決める
最低限の日数で
起票者は担当にしない
朝会
前日の状況確認
問題、課題の状況確認
共有事項確認
当日の予定確認
課題表確認
属人性排除
手順、プロセス定義
テンプレート用意
ツールでの自動化
マイクロマネジメント
期間限定で行う
確認頻度を上げる
朝会、夕会
確認内容を細かく
数字での進捗確認からタスク内容の確認へ
PDCA
PDとCAのマトリクスで考える
計画、実行内容がどうだったか
改善点をもとにしたアクションプラン
ガス抜きヒアリングでは約束はしない
課題を理解したので検討する旨を伝える
共感はするが解決の約束はしない
リーダーシップ
9割ポジティブ
諦め癖の言葉に注意
メンバーと話し合う
支えになる言葉を持つ
転ぶときも前のめり
責任を持つところと持たないところの線引きをしておく
チームに良い緊張感をもたせる
メンバーの成果、仕事ぶりに厳しく
プロジェクト成功のための妥協をしない
Posted by ブクログ
プロジェクトには、
想定できない色々なことが起こります。
通常業務と違い、継続性、反復性というものではなく、
プロジェクトは、有期性、独自性という面があります。
なので、小さな火種を放置せず、
慌てることなく、逃げずに腹をくくり、
取り組むことが、大切であると学びました。
メンタル面、テクニック面について、記載があり、
一度に多く取り入れることはできないですが、
一つひとつ試してみようと思いました。
Posted by ブクログ
・感想
数々の炎上プロジェクトをうまく乗り越えてきた木部さんがどういう心持ちや取り組みを大事に解決してきてたかをまとめた書籍。
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を記録してあとで振り返られるようにする。
Posted by ブクログ
パラパラっと通読。
テクニカルなところと情感的なところと良い塩梅ですね。大切なのは徹底的な分析と現状把握からの必ずトラブル解決したるという確固たる信念。そう受け止めました。後はメンバーの意見を総合して最終的な判断は自分、厳しい態度も仕事という割り切る力。そういったところでしょうか。
Posted by ブクログ
プロジェクトマネジメントのトラブルを解決の火消し術を86項目に分けて解説している。よくある状況把握、原因特定、リカバリプラン策定と遂行だけではなく、リーダーシップやリーダーのメンタリティ、メンバーのモチベーション管理、火消し後にその経験をいかに知見として残すのかについての触れられている。トラブル解決に関連したリーダーの振る舞いについて知りたい方にもおすすめです。
