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