プロジェクトのトラブル解決大全 小さな問題から大炎上まで使える「プロの火消し術86」 [Kindle]
- KADOKAWA (2022年2月18日発売)
- Amazon.co.jp ・電子書籍 (358ページ)
感想・レビュー・書評
-
職種に関わらない部分は流し読み。
本来であれば時間をかけて読まなければならない内容でした。
自身の記憶として記録。
チームとの関わり方のコラムを印象深く読ませていただきました。
立場が変わった時に改めて読ませていただきます。詳細をみるコメント0件をすべて表示 -
・・・以下メモ・・・★は自分が思ったこと
プロジェクトマネジメントというのは、「初めてやる」プロジェクトを「問題ないよう」にマネジメントする、という究極の難しさをはらんでいるのです。
■腹を括る
過去のことも含めて、自分のせいじゃ無いと思ってもいいけど表に出しちゃダメ
■体制図
プロジェクトが炎上してしまった要因は、1人ひとりのメンバーというよりも、リーダーや主要メンバーにあることがほとんどです。だから、リーダーと主要メンバーは要チェック
■質問を100考える
スケジュール、コスト、品質
■仮説を自分で立てる
スポーツや囲碁、将棋と同じで、「相手がどう出てくるか」を予測(仮説構築)したうえで、実際の相手の出方を見て修正をかけます。何も考えない、出たとこ勝負の人は勝ち上がれないのです。
→★初速が違う
「トラブルの原因は何だと思う? 3つ教えて」
→この先輩の問いに答えられなかったのが強烈な反省だという。
→目の前のことだけで、考えてなかった
■懐刀を手に入れる
一人で局面を変えることは不可能
→自分には持っていないものを持っている人
自分の下につける
■それはなぜですか?を聞く
■ 「わかっていること/いないことフレームワーク」をつかう
→機能やチームなど切り口を決めて
■安易に人を増やさない
コミュニケーションチャネルが増える
■
そもそもできるかできないかは結果論です。始まる前に決めることではありません。炎上トラブルではこのようなマインドが必要です。
■想定外はあたりまえ
プロジェクトでは「想定外のことが起きる」ということを「想定しておく」ことが重要です。
→バッファをつんでおく
→メンバにはバッファの存在をバレないようにしておく
■バッファの置き方
バッファーをかき集めて最後に置く" -
情報システムの開発に携わっている人には刺さる本。トラブル発生時の対処法を豊富な経験を持つ優秀なプロジェクトマネジャ(PM)が火消しの現場での心得を解説する。腹をくくって課題管理をきっちりとやるとかコミュニケーションの重要性など、当たり前のことを当たり前にやるだけなのだが、その実行が難しかったからプロジェクトが炎上するのだ。炎上したときに、また炎上する前の火種で消火するための優先度をシンプルに解説している。文章だけで読むと理想論だよなあと思うけれど、システム開発以外にも応用できそうだ。
-
炎上してるわけではないけど、期間の短いプロジェクトに関わることになったので読んでみた。
内容が、炎上しているプロジェクトに途中から火消し役として入った人のための本なので、自分の状況とは全然異なる。しかも、著者はプロマネで、技術者ではないそうなので、開発技法とかについて書いてあるわけではない。それでも、いくつかは参考にできそうとは思った。
まあ、中には「腹をくくるだけ」とか、解決策といえるのか微妙なものもあったけど。
一つ一つにバッファーを置くより、最後にまとめてバッファーを置いた方がいいというのは、言われてみればそうかもなと思う。自分もついつい、一つ一つでバッファーを置いたりするけど、今後はそうしたいと思う。
飲み会は立食スタイルがいいと書いてあって、確かにこれはいいなと思った。ただ、調べてみても立食形式は貸切パーティーか立ち飲み屋ぐらいしかないっぽい。立食形式の居酒屋とかないのだろうか。
課題内容は誰が読んでも分かるようにというのは、本当、そうしてほしいと思う。一回上司が、「○○の動きが変です」というような内容を書いてきて、やめてくれと思った。触ったらおかしいのは分かったのだけど、実際にそのことを言ってるのか分からない。
朝会については、炎上してたら毎日やる必要あるけど、炎上してなければ週一回でもいいとのこと。そういうもんなのか。来週から毎日朝会やろうと思ってたけどそうしよう…。
PDCAについて、サークルではなく、マトリクスの形式で書いてあるのは、「なるほど」と思った。PlanとDoの両方にたいして、CheckとActionをしようとのこと。確かに、Checkして問題があると分かった場合、Planが悪い場合とDoが悪い場合があるだろうしね。この発想はなかった。
後、ガス抜きでメンバーの愚痴を聞くというのも大事だとのこと。それぐらいなら実践できそうかな。同調するのと、解決を約束しないというのが重要らしいので覚えておきたい。
他に、リーダーはポジティブである必要があるとのこと。自分はどっちかというとネガティブ思考だしなぁ。今関わってるプロジェクトも「間に合わないだろう」なんて言ってしまってるけど、もうちょっとポジティブに考えていきたい(実際、工数を細かく書いて行ったら間に合わないような気がしたけど、いくつかのまとまりで分けたら、もうちょっと少なくすむような気はしてきてる)。
英語には「しょうがない」という言葉がないと書いてあって、「そうなのか!」と思って調べたら、いろいろでてきた(https://nativecamp.net/blog/20211003english)。微妙にニュアンスが違うのだろうか。
途中書いてあった、10年も続いた炎上プロジェクトに驚きた。そんな長いことやるプロジェクトってあるのか。自分の場合、だいたい半年程度、長くても1年のプロジェクトしか関わったことないなぁ。
これって10年間炎上してたということなんだろうか…。 -
炎上プロジェクトでのトラブル対処法の本ではあるが、平時から実践することで炎上を未然に防ぐことに役立つものもある。筆者の経験に基づいたもので具体性がありやってみようと思うものがいくつかあって参考になった。
-
本当は炎上しないに越したことはないが、ITプロジェクトが最後まで炎上せず着地する確率は極めて低い。
どうしたらプロジェクトが成功するかという本はいくらでもあるので、本書はユニークだしプロジェクト担当なら読む価値はあると思う。
ただし既に炎上しているプロジェクトばかりに放り込まれるのは相当きついので、ここまで極めた著者のようにはなれないかな… -
Kindle Unlimitedにあったので。
ノウハウ本かな〜と思って軽い気持ちで読んだら、やたら具体の濃い内容で笑った(褒めてる)。
テクニックもあるが、メンタリティ/スタンスの話も多い。あくまで著者のマイルールだが、ITコンサルで成功してる人のタイプとしては非常にメジャーな話が多い気がしたし、過去に自分が仕事で経験した優秀な人にも似てて、説得力高かった。書いてることは平易なので、内容そのものよりがんばろうとやる気をもらえる本。 -
炎上案件への取り組みやマインドセットが記載されている。
火消しの心得を身に着けよう。 -
勉強になった。
マネジメントする側として持っておくべき心持など学べて、常日頃からこういった考えを持っておいた方がいいなど参考になることが多かった。