ITエンジニアの暗中模索

システム開発やプロジェクトマネジメントに関する雑記

読書「プロジェクトのトラブル解決大全」

ITプロジェクトでは、大小はあるものの炎上と呼ばれるプロジェクトに遭遇することがある。

  • バグだらけのシステム改修
  • 要件が曖昧でユーザとの認識に不一致が後工程で出てくる(ウォーターフォール

今回取り上げる書籍は、著者が過去に直面した炎上プロジェクトに対する火消し術である。

本書はプロジェクトリーダーを想定読者として記載されている。例えばプロジェクトメンバーのモチベーションを上げる方法や、対応期限が逼迫する中でいかに優先順位をつけて決断していくのか。いずれもリーダーとしての目線を大事にしている。

本書が一貫して伝えてくるメッセージ

炎上プロジェクトにおいて奇跡はなく、地道な課題解決を突き詰めていくことが大事と著者は伝える。この突き詰めていくというのは言葉にすると簡単ではあるが、実際には難しいのだ。この過程にはリーダーの決断も必要である。決断するには勇気がいる。同書の中では「腹をくくる」という言葉が出てくる。腹をくくらないと勇気を持てない。

 

気持ちの問題にもフォーカスしつつ、課題管理とWBSと体制図と進捗報告資料の現物確認で何を見るべきなのか、プロジェクトにおいて特定の兆候が見られたらどうするのかなど、すぐに活用できるメソッドも多く伝えてくれる。

特に刺さったポイント

  1. 担当者がアサインされていない課題管理表はリーダーの気の弱さが表されている。難局打破のためにはメンバーに遠慮しすぎてはいけない。それで嫌われてしまうかもしれないが、それでもプロジェクトの完遂のためには無理なお願いも申し入れする機会も出てくる。課題管理表はリーダーを表すのではないだろうか。他にもダメなかだり管理表には次の傾向があるとのこと。同じような体験をした諸兄もいるのではないだろうか。① 課題内容がわからない ② 担当者がブランク、もしくは複数名書かれている ③ 期限が設定されていない ④ 課題提起した人を担当者にしてしまう  
  2. 仮説検証は一人で考え抜く。プロジェクトが陥っている状態の深掘りと解決策の模索。これらを余計なバイアスを入れず現状をありのまま捉えて解決策を出していく。何が問題であるかなどメンバーにヒアリングしながら民主的な解決策を出していくことが最適解と思っていただけに、なるほどなと思った。
  3. 直接工数と間接工数。いわゆる報告会議などの間接工数を下げていき、直接工数たる作業に注力していく。一見当たり前であるがこの間接工数を下げていくためにリーダーが会議を30秒で終了判断(もちろんダメな点を伝えて次の機会を作った上でである)をするなどはポイントである。
  4. メンバーとの飲み会は立食形式。メンバーとの交流をやりやすい形にするためにゲームなども用意する。このご時勢では飲み会を開くのも一苦労かもしれないが結局はプロジェクトは人である。コミュニケーション大事

まとめ

本書は炎上プロジェクトにリーダーとしてアサインされた際の心構え、具体的な対応方法を伝えてくれる。私も過去に炎上プロジェクトを体験してきたが、大きく頷く点も新しい発見もあった。運悪く炎上プロジェクトの中にいる人はもちろん、このような炎上プロジェクトにならないようにするための予防として本書の記載内容は示唆に富む。