『プロジェクトのトラブル解決大全』⇒「まずは腹をくくれ。とか書いてあるけど、かなり泥臭くリアルに「取るべき行動を具体的」に書いてくれてるので、良い感じ。読み終わったら、ペライチにして時々見返そうと思ってます」

ざき@IoTエンジニア @zaki134rp

プロジェクトのトラブル解決大全 本日の新幹線のお供 まずは腹をくくれ。とか書いてあるけど、かなり泥臭くリアルに「取るべき行動を具体的」に書いてくれてるので、良い感じ。 読み終わったら、ペライチにして時々見返そうと思ってます。 pic.twitter.com/66OAuWSumn

拡大

拡大

もとやま📚著書『投資としての読書』 @ysk_motoyama

プロジェクトの火消し術において比類ない本『プロジェクトのトラブル解決大全』 実に86もの火消し術が紹介されていますが、特に実践するなかで効果を痛感した学びが3つあります。 学び1：思考停止せず、とにかく書く 学び2：消火の仕組みを作る 学び3：嫌われる覚悟で関係者と接する 学び1：思考停止せず、とにかく書く ━━━━━━━━━━━━━━━━━━ 本書では86個ものテクニックが紹介されていますが、その中の3分の1は「可視化」です。 炎上プロジェクトに参加することになったら、まず ・体制図を書き出して、規模/リーダー/キーマン/指揮命令系統を把握する ・問題を把握するために100の質問を書き出す ・100の質問について、原因と対策の仮説を書き出す プロジェクトに参加した後も ・メンバーのスキルを評価表にまとめる ・事象・原因・対策のフレームワークを整理する …など、多数のテクニックが紹介されています。 そのテクニックの数々から浮かびあがってくるのは「可視化へのこだわり」です。 確かに「可視化は大事です」くらいの認識であれば、誰もが持っているでしょう。 一方で難しいのは、「可視化したいけど、何を書けばいいかわからない問題」です。 特に炎上プロジェクトともなってくると、起きていることが複雑すぎて、何をどう可視化すればいいかさっぱりわかりません。 しかし本書を読んでいくと、筆者は「いつどのフレームワークやフローを使うのか」を予め決めているんだろうなと気づかされます。 「状況把握のためには、このフレームワークを書く」「問題を解決するためには、このフローに沿って整理する」といった具合に。 だから、初動で迷うことなく、テキパキと火消しに向けて思考を進めることができるのでしょう。 「いつどのフレームワークを使うのか、予め決めておく」 これは、私自身も強く効果を実感しています。 私もシステム管理に携わる機会が多く、よく突発的なシステムトラブルに直面します。 システムトラブルが発生した際は、落ち着いて以下を書き出すようにしています。 ①何が起きているのか ②①の原因は何か 　-わかっていることは何か 　-わかっていないことは何か ③暫定対応をどうするか ④誰にどんな報告をするか パニックになっているときも、とりあえず上記にフレームに沿って書き出してみると、「あ、意外とわかっていること多いな」「どうにかなりそうだ」と、まず自分を安心させることができるんですよね。 トラブル対応時に大切なのは「まず自分が冷静になること」でもあります。 そういう意味でも、事前に使うフレームワークを決めておいて書き出す効果は大きいでしょう。 少し話がそれましたが、炎上プロジェクトにおいても迷わず落ち着いて対処するためには、シーン別のフレームワークを多数知っておくとよさそうです。 プロジェクトに関わる人は、一家に一冊置いておくことをオススメします。 学び2：消火の仕組みを作る ━━━━━━━━━━━━━━━━━━ 本書が好きな理由の1つが「きれいごと0」なところ。 それを象徴するのが、筆者が語っている数々の仕組みです。 1つひとつの仕組みを読んでみて感じたのは、筆者はよくも悪くも「人に期待しすぎていない」ということです。 例えば、次のような仕組みが書かれています。 ・想定外を防ぐ「1タスク5営業日以内」で書かせる ・メンバーに期日を守らせるために、以下の3つのルールを作っておく ①期限の数日前に状況報告させる ②タスクが遅れる場合はそれが「わかった時点」で報告させる ③タスクが遅れたときは、なぜ遅れたのか、と毎回問い質す いずれも、メンバー能力によってではなく、仕組みによって、プロジェクトの火種を潰そうとしています。 先述の「可視化のフレームワークへのこだわり」しかり、今回の「仕組みへのこだわり」しかり、筆者が再現性高くプロジェクトを消火できている理由がよくわかります。 学び3：嫌われる覚悟で関係者と接する ━━━━━━━━━━━━━━━━━━ 「あの人には話しかけたくないな」 「期限が遅れているメンバーを叱りたくないな」 プロジェクトにおいて避けては通れないのが、こういった悩みでしょう。 注意やフィードバックをすれば、相手に嫌な思いをさせる…そうわかっているときに、どう動くのか。 その動き1つひとつの積み重ねが、プロジェクトの行方を左右します。 筆者はこの点を人一倍、私の100倍くらい熟知しているのでしょう。 だからこそ、1つひとつのケースを例外なく徹底して対処できるよう、細かくテクニックを教えてくれます。 例えば、以下のテクニックが紹介されていました。 ・誰もが嫌がる課題対応であっても、必ず担当者を決めきる ・定例会議を欠席する人や遅れる人には、「なぜ出れないのか？」「なぜ間に合わなかったのか？」をチクチク確認する ・プロジェクトが本当に不味い状況のときは、マイクロマネジメントに切り替える …などなど。いずれも、メンバーに嫌われても仕方のない行動ばかりです。 でも、こういった行動を躊躇していると、プロジェクト炎上コースまっしぐらです。 一次的にメンバーに嫌われたとしても、プロジェクトを炎上させて疲弊させるよりはマシ。 そんな筆者の優しさも垣間見える本でした。

拡大

藤井ハルカ / エンジニア採用や営業窓口担当 @TB_Fujii

プロジェクトのトラブル解決大全って本がまーーーーーじで刺さる。。。 pic.twitter.com/kMWYDSU92O

拡大

拡大

@haji28290

数々の炎上PJで火消しレスキューを行った火消しのプロ、デロイトの木部さんが書かれた「プロジェクトのトラブル解決大全」が面白い。中途半端な仕事術とかではなく、幾つもの修羅場をくぐり抜けてきた方の言葉は重い。トラブル時ではなくても参考になる。 pic.twitter.com/sKBYhKQp4y

拡大

もりみき@出版社のバックオフィサー @mikio_76

『プロジェクトのトラブル解決大全』を読んだ。仕事のすべては言ってしまえば何らかのプロジェクトだし、仕事でトラブルがない日はない。タイトルだけ見るとプロジェクトマネジメントの本っぽいけど、チーム内の調整の仕方やトラブった時の「火消し」の仕方がわかって、日常的な示唆がすごく多かった。 pic.twitter.com/ynImyT5yja

拡大

もりもり @hikidasinoneko

今関わってるプロジェクト大変だから「プロジェクトのトラブル解決大全」をヒント探しの旅で読む… pic.twitter.com/WPMjaSxSCe

拡大

mayu @noopy_mayu

プロジェクトのトラブル解決大全という本を読んでいるけど、「一番大切なことは『腹を括ること』」って書いてあって笑った。(その通りなので良い本。)