0人中、0人の方がこのレビューが役に立ったと投票しています。
投稿者：qima - この投稿者のレビュー一覧を見る
するわけではないですが、とりあえず読んでみたいと思って手に取りました。自分の知らない世界の話ですが、いろいろ参考になりました。
投稿元：
レビューを見る
2023/01/09 1回目読了。印象に残ってるのは細かいテクニックよりも、腹を括って最後まで諦めんと粘り強く仕事に取り組む姿勢がまずは大事ってこと。そこは全面同意できる。
内容自体は、今の自分の立場よりもっと上の立場でのPJ参加(PM)の観点が多かった印象。なんですぐに本書の技法を色々試すとかはないと思うかな。
投稿元：
レビューを見る
・やばい状態で管理すべきは、作業管理・進捗管理・課題管理の３点
・１タスクは５営業日（週次定例で完了未完了がチェックできる）
・タスクが遅延した場合は、理由・対策・リカバリ予定日の３点を報告させる
・規律やプロセスの順守は徹底させる。守らなかった場合は必ず指摘して放置しない
・期限を守らせる３つのテクニック
１．期限の数日前に状況報告させる
２．遅れることが分かった時は、わかった時点で報告する
３．遅れた場合は、なぜ遅れたのか毎回問いただす
・メンバーが手におえなくても、リーダーが受け取るかどうか考える。取りたくなるのはわかるが、リーダーがボトルネックになってはいけない
・マイクロマネジメントは時限的に。宣言してから
・嫌がられてもきっちりメンバーに割り振って対応させること。恐れない
・メンバーに好かれようとしてはチームは弱くなる。メンバー全員から好かれることはない。それはメンバーにとって楽なだけ
・常に厳しいわけではない
投稿元：
レビューを見る
2022年5月25日読了。「炎上プロジェクト」のマネジメントに役立つTipsを集めた解説本。PMBOKに基づく理論的なプロジェクトマネジメント解説本は数あれど、「理論としてはいいけど現場では役に立たないよ、経験を積んでなんぼ」みたいなことは当たり前のように言われる（自分も言ったことある）が、「炎上プロジェクトあるある」を集めたような本書は読んでいて面白いし新米PMにも役立つないようなのではないか。Excelの神ショートカットとかを学ぶより遥かに有用と思う。「炎上プロジェクトに際しては、まず『腹をくくる』」と来るのは「おいおい精神論かよ」という気もするが、実際マイナスからプロジェクト管理をスタートするのだから、腹をくくってやれることは何でもやる、というスタンスで取り組まないとそりゃあうまくいかんよな…と同意する。細かい技法は数あれど、プロジェクトは人が実行するものだから、結局は人をうまく管理することに尽きるのだが。
投稿元：
レビューを見る
トラブルの火消しについて書かれているが、その内容は普段の業務にも使える心構えやテクニックが多く、参考になります。
投稿元：
レビューを見る
プロジェクト管理のための実践的なノウハウ・テクニックが詰まっている。
教科書的な話というか理想論的な話ではなく、筆者の経験を元にした対処法という仕立てなので、参考にできる術は多いと感じる。
投稿元：
レビューを見る
パラパラっと通読。
テクニカルなところと情感的なところと良い塩梅ですね。大切なのは徹底的な分析と現状把握からの必ずトラブル解決したるという確固たる信念。そう受け止めました。後はメンバーの意見を総合して最終的な判断は自分、厳しい態度も仕事という割り切る力。そういったところでしょうか。
投稿元：
レビューを見る
炎上プロジェクトは避けて通りたいが、避けきれなかった場合はこの本を読み直そうと思う
判断ではなく決断というのはリーダーとして常に心掛けておきたいポイントだった
プロジェクトの把握
プロジェクト計画書
体制図
人数、チーム数
メンバースキルの可視化
設計
プログラミング
業務スキル
マネジメント
リーダーシップ
リーダー、キーマン
懐刀になる人
トラブルメーカー
対応時は影響力を無視しない
指揮命令系統
課題管理表
スケジュール、担当者
課題収集プロセス
優先度判断
重要度、緊急度、難易度、効果、コスト、時間
進捗報告資料
質問項目
PMBOKの知識体系ベース
QCDベース
仮説を立てる
トラブルの原因は？
問題、原因、対策
あるべき姿と現実のギャップ
マトリクスで検討
QCD、機能、開発フェーズなど
タテヨコ
具体と抽象、類似
事実の確認
なぜそう思うのか
原因は何だと思うか
推測の場合は判断基準は
どの資料を見れば確認できるか
わかっていること、わかっていないこと
軸毎に洗い出し
システム調査なら機能毎、など
できない理由の精査
どうすればできるようになるのか
制約を外す方法は
やらないことを決める
リソースの集中
スケジュールはゴールから逆算
10％ほどのバッファー(見積もりの-10%で計画)
バッファーはタスク毎に乗せない
メンバーからの見積もりは詳しく精査
スケジュール全体でバッファーを持つ
1タスクは5営業日以内
担当者は必須
複数人での担当になる場合はタスクを分ける
会議
頻度、議題、参加者が適切か
議事録、アクションリスト
議論の活性化
各自に意見を求める
準備不足の場合はリスケ
スケジュールは決める
プロジェクトの意義を共有
チームのルールは守らせる
都度なぜ守らないか聞いたりして守る雰囲気を作る
最低限の管理
作業管理、進捗管理、課題管理
作業遅延
原因、対策、リカバリ予定日を確認する
課題
内容は明確に分かりやすく
担当者を決める
連名にしない
期限を決める
最低限の日数で
起票者は担当にしない
朝会
前日の状況確認
問題、課題の状況確認
共有事項確認
当日の予定確認
課題表確認
属人性排除
手順、プロセス定義
テンプレート用意
ツールでの自動化
マイクロマネジメント
期���限定で行う
確認頻度を上げる
朝会、夕会
確認内容を細かく
数字での進捗確認からタスク内容の確認へ
PDCA
PDとCAのマトリクスで考える
計画、実行内容がどうだったか
改善点をもとにしたアクションプラン
ガス抜きヒアリングでは約束はしない
課題を理解したので検討する旨を伝える
共感はするが解決の約束はしない
リーダーシップ
9割ポジティブ
諦め癖の言葉に注意
メンバーと話し合う
支えになる言葉を持つ
転ぶときも前のめり
責任を持つところと持たないところの線引きをしておく
チームに良い緊張感をもたせる
メンバーの成果、仕事ぶりに厳しく
プロジェクト成功のための妥協をしない
投稿元：
レビューを見る
トラブルに対する火消し術が、筆者の体験交えて書かれているので気持ちが入りやすくスラスラ読めた、
本書にも書かれている通り、トラブル中でなくても普段の業務で実践していきたい内容も多々あった。
体育会系っぽく受け取る人もいるとは思うが、絶対にやり切ると腹をくくること、そういうマインドを形成することは、確かにステークホルダーに影響を与えるし、少なからずチームのパフォーマンスにも影響を与えると、自分も思う。
投稿元：
レビューを見る
プロジェクトの理想的な進め方を記した本は世の中に数多くあれど、いざ炎上した時の対応方法が書かれた本は意外と少ない。しかし、ほぼ全てのプロジェクトで予想外のトラブルは必ず起きる。そして大半の現場では残業なり納期調整なり、もしかしたらテスト工程を省くなりで何となく凌いでいるのではないかと思う。もちろんこの本を読んだだけで明日からすぐ火消しが出来るようになるわけではなく、その局面に立って実践経験を積む必要はあるわけだが、それでも理論と実践的・具体的な術があるのと無いのとでは全然違うと思う。自分はプロジェクトマネジメントで一度失敗してしまい、先月から文字通り出直し的にPMの仕事に再挑戦している。本書を片手に火種の段階で消しながら進んでいきたい。
投稿元：
レビューを見る
・成否は「最初に腹をくくれるかどうか」で9割決まる。
〇：腹をくくり覚悟を決めている
×：いざという時の逃げ道を作っている。(「自分は被害者だ」と思ったらそこで負け、他責にならない)
・「トラブルの原因は何だと思う？3つ教えて」、仮説を考えていないと答えられない。
・犯人探しが無意味な理由
(1)犯人を間違ってしまう可能性が大きいから(色々な人の主観は正しいとは限らない)
(2)たとえ犯人がわかっても、その人にだってプロジェクトで活躍してもらわないといけない
・ビジネスパーソンが仕事の期限を守る動機は２つだけです。
(1)プロとして期限には必ず仕上げる、と言うモチベーション
(2)期限を過ぎると怒られるから、遅れないようにやろうという気持ち(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を記録してあとで振り返られるようにする。
投稿元：
レビューを見る
プロジェクトには、
想定できない色々なことが起こります。
通常業務と違い、継続性、反復性というものではなく、
プロジェクトは、有期性、独自性という面があります。
なので、小さな火種を放置せず、
慌てることなく、逃げずに腹をくくり、
取り組むことが、大切であると学びました。
メンタル面、テクニック面について、記載があり、
一度に多く取り入れることはできないですが、
一つひとつ試してみようと思いました。
投稿元：
レビューを見る
PMPとか他のプロジェクト管理の本とか読んだが、この本が最も実践的な内容である。
私の中だけなのかもしれないが、プロジェクト管理の名著と言ってよい。
投稿元：
レビューを見る
プロジェクトに対するマインド、管理すべき内容、リーダーシップについて、プロジェクトを成功させるための幅広いTipsがまとめられた本。
プロジェクトに関連するフレームワークの説明ではなくそれをどう使うかが述べられていて実践的であった。
