プロジェクトリカバリで気をつけたい5つのこと

システム開発などプロジェクトにトラブルが発生してリカバリが必要になることがあります。

特にリカバリの陣頭指揮を取る立場となる場合に、過去の自らの教訓踏まえて、気をつけたいことをまとめました。

１．「そもそも」は目の前の火を消してから

一般的にトラブル状態のプロジェクトは、対応すべき問題が複数重なり、その本質が見えにくくなっている事が多い。最初から無理に本質をつこうとせず、解決すべき問題の数を一旦絞り、絡んだ糸を解くように１つづつ解決していくことを心がける。

２．プロジェクトを救うにはまずは人を救う

「既存体制の中で引き続き一緒に戦えるメンバーは誰か？」を見極める。心身ともに戦える状態にない者や、不満を周りに吐露し悪害となる面子、この後に及んで自己防衛的に事実を歪曲して報告する面子は、最速のタイミングでリリースする。なお既存メンバーに対する周囲からの評判は鵜呑みにしないよう注意し、一人一人しっかりと話しを聞く。（べきだった論の押し付けはNG）

一方でリカバリに入るメンバーは必要最小限にすること。単純な納期＝人月/人数で計算したくなる誘惑に負けない。また新メンバーの既存メンバーへの態度には細心の配慮を払う。全員にとって明日は我が身であり、炎上案件に回されたという被害者意識を表に出させない。もちろんその分の労いと感謝は十分に伝える。

当然困っているのは自分たちだけではなく、お客様の担当者も社内で厳しい状況に立たされていることを十分に理解し、コミュニケーションする。

雰囲気は意図的に明るくする。成果の質は関係の質に依存する。

３．完了までにやるべきことの分母を100にする

「ごめんなさい」と頭を下げ、顧客やプロジェクトオーナーに計画の引き直しを認めてもらえるのも一度きりであり、その貴重なカードを無駄に使わない。

リカバリ計画（リスケジュール案）を作るにあたり、やるべき仕事の全量を明らかにせずに計画を立て始めることは厳禁。トラブル事案ではプロジェクトの完了の条件が顧客と合意できていないことがほとんどなので、まずここを固める。 雨漏りしている中で床の水を吸い取っても、掃除は終わらない。

また何が出来ていて何が出来ていないかを判断する際、メンバーからのコメントを100%鵜呑みにしない。必ず実際の成果物を自ら目を通し判断する。また各成果物が顧客に合意を得たのかどうかも、メンバーの意見だけではなく顧客にも確認する。

４．チームのコミットメントの拠り所を作る

トラブル中のプロジェクトは、日常のルールが曖昧だったり、正しく守られていないことが多い。例えば日報提出をルールとしながら出さない人を放置したり、朝会などの定例会が無意味にスキップされたり、課題管理表が放置されているなどがそれにあたる。

まず全員が当たり前にできることをやり続け、チーム全体に変わったことを意識付けさせる。当たり前の規律なくして、チームでの成果は期待できない。

５．自分を信じすぎない/ヒーローになろうとしない

ほとんどの場合、現有体制＋αでリカバリを進めることが多く、内容と経緯を理解すればするほど、意図せず自分も問題の一部になってしまうことがある。ミイラ取りはミイラになってしまうものだと思っておいた方が良い。

そのため、リカバリ中も自分の考えを客観視できる機会を敢えて自分で作る。例えば自分が信用する人に自分の現状認識や今後のプランを聞いてもらい、見た目はかっこいいが実現性が低いプランになっていないか、第三者の意見を必ず仰ぐようにする。