プロジェクト炎上の立て直し方｜最初の2週間でやること、増員が効かない理由

まず、増員とリスケの相談を上から受けていませんか。

どちらもまだ答えられません。炎上したプロジェクトで最初にやるのは、遅れの取り戻し方を決めることではなく、判断が止まっている場所を数えることです。そこを飛ばして人を足すと、燃えている面積が広がるだけです。

いま起きているのが、手が打てている遅れなのか、炎上なのかで、打つ手が変わります。3か月という数字だけでは、まだどちらとも言えません。

遅れの大きさでは決まりません。見るのは、遅れの理由を関係者が同じように説明できるかどうかです。

遅れているだけの現場では、誰に聞いても同じ答えが返ってきます。「移行データの不備で2か月止まった」。原因が特定されていて、対策も打たれている。これは管理できている状態です。

炎上している現場では、聞く相手ごとに答えが変わります。情シスは「ベンダーの要員が弱い」と言い、ベンダーは「要件が固まらない」と言い、業務部門は「そもそも聞かれていない」と言う。全員が正直に答えていて、それでも話が合わない。

では炎上です。説明が食い違うのは、誰かが嘘をついているからではなく、判断が止まった場所を全員が別々に見ているからです。

数字の上でも、大きなプロジェクトほど遅れます。JUASの調査では、500人月以上のシステム開発で工期が予定どおり完了したのは11.0%、予定より遅延したものが43.7%（2024年度調査）。100人月未満だと予定どおりが31.0%なので、規模が上がるほど落ちる。遅れること自体は珍しくありません。

楽になった直後に厳しいことを言いますが、珍しくないのは遅れであって、説明が割れている状態は別です。放っておくと、遅れの理由がそのまま社内政治の材料になります。そうなってからの立て直しは、倍の時間がかかります。

そこに2週間かけて、集め終わった頃には数字が古くなっている。炎上の現場でよく見る失敗です。

炎上している時点で、進捗の数字はほぼ壊れています。壊れた数字を丁寧に集め直しても、精度は上がりません。

代わりに数えるのは、決まっていないことです。誰が、いつまでに、何を決めれば次に進むのか。これを一覧にすると、たいてい10件から20件で収まります。数百件ある課題一覧より、こちらのほうが先に効きます。

その300件を眺めても、止まっている理由は出てきません。課題一覧に載るのは、担当者が「これは課題だ」と認識できたものだけです。止まっているプロジェクトの本当の原因は、誰も自分の担当だと思っていない未決事項として、一覧の外にあります。

よく見る形で言うと、旧システムに残っている取引先データを、どこまで移すか。情シスは業務部門が決めることだと思っていて、業務部門は情シスが技術的に判断することだと思っている。3か月誰も決めず、その間、移行チームは全件移行の前提で作り続けていました。あとで半分捨てることになって、作業も2か月ぶんが消えます。

課題一覧には一行も載っていませんでした。担当者が決まっていない論点は、課題として登録されないからです。

「困っていることはありますか」と聞くと、相手の悪口が返ってきます。聞き方を変えます。「あなたがいま止めている判断は何ですか」ではなく、「次の2週間で、誰かに決めてもらわないと進めない作業はどれですか」と聞く。これなら人ではなく作業の話になるので、正直な答えが出ます。

立て直しに入った最初の2週間でやることは、この4つに絞れます。全部やらないと、どれも効きません。

ここが一番効きます。炎上している現場では、悪い情報を報告した人が責められるので、報告のたびに情報が薄まっていきます。悪意ではなく、報告の場が評価の場を兼ねているせいです。

経営報告の場で「遅れています」と言えば、その場で担当者が詰められる。次からは「一部で調整中です」に変わります。3回繰り返すと、報告書からは何も読み取れなくなります。

だから場を分けます。リスクだけを扱う30分の会議を作って、そこでは対策も犯人探しもしない。事実を出す場と、判断する場と、評価する場を混ぜないことです。分けたその週から、出てくる情報の質が変わります。

全員に「ここを見てください」と宣言して、報告用の資料を作るのをやめさせるだけです。難しいのは技術ではなく、報告資料をやめる決定を誰がするかのほうです。

集めて整える作業自体は、いまはAIでかなり肩代わりできます。議事録から決定事項と宿題を抜き出す、複数のチームの進捗を1枚にまとめる、報告のたたき台を作る。人が手で表を作り続けている現場は、判断に使える時間をそこで削っています。

効く条件は限られます。まず、増やした人に仕事を説明するのは、いま一番忙しい人です。説明に取られる時間のぶん、短期的には全体が遅くなります。ソフトウェア開発では50年前から知られている話で、『人月の神話』が「遅れているプロジェクトへの要員追加は、さらに遅らせる」と書いています。

増員は、社内に対して「手を打っている」と示せる、いちばん分かりやすい打ち手だからです。判断を整理しましたと報告しても、経営会議では動いたように見えない。5人増やしましたなら見える。

正直に言うと、発注側の担当者が板挟みを抜けるために増員を選ぶ場面を、何度も見ています。効かないと分かっていても、何もしていないと言われるよりましだと。

増員が効くのは、教えなくてもできる独立した作業が残っているときだけです。テストの実施、移行データの突合、マニュアルの作成。この種の作業が実際に積み上がっているなら、人を入れれば減ります。

逆に、仕様を理解していないと手が出ない作業しか残っていない場合、増員は費用だけが増えます。判断すべきなのは人数ではなく、いま残っている作業が説明なしで着手できるかどうかです。

納期を動かさないなら、動くのは範囲か品質のどちらかです。両方動かさないと決めた場合、実際に動くのは品質で、それは半年後に障害として出てきます。決めていないだけで、選んではいます。

順番があります。初回リリースで使わない機能、当面は手作業で回せる業務、同時に移行しなくていい範囲。この3つを、業務部門と一緒に線引きします。

できません。範囲を切るのは事業側の判断で、PMがやるのは判断に必要な材料を揃えて、決める場に持っていくところまでです。

だから未決事項の一覧が先に要ります。「削ってください」ではなく、「この機能を後ろに送れば2か月縮みます。送らない場合、初回の稼働は6月になります」という形にする。選択肢と期限を出せば、経営は決められます。決められないのは、聞かれ方が悪いときです。

犯人を特定した形で報告しないことです。ベンダーの能力不足という説明にすると、その場では通りますが、次にベンダーが情報を出さなくなります。立て直しの期間中に必要なのは、正確な情報が早く上がってくることのほうです。

事実だけを出します。何がいつ決まらなかったか、その結果どの作業が止まったか。この形なら、ベンダーも反論する必要がありません。

立て直しで外の人を入れる場合、見るところが平時とは違います。技術の深さより、悪い情報を持って役員のところに行ける人かどうかです。

社内の人間は、その報告をすると自分の評価が下がる立場にいます。外から来た人には失うものがないので、そこだけは代われます。逆に、社内の人が言えることを丁寧に整理し直すだけの人なら、入れても現状は変わりません。

「入ってから最初の2週間で何をしますか」と聞いてください。「まず現状を把握します」で止まる人は、立て直しの経験がありません。経験がある人は、把握の中身を具体的に答えます。誰に何を聞くか、どの数字は信用しないか、いつまでに何を判断の場に出すか。

火消しで入るPMの単価は、平時より上がる傾向があります。相場そのものはPM代行の費用相場に整理しているので、見積を比べるときはそちらを見てください。金額を比べる前に、その人に何を決めさせるかを契約前に文書にしておくことです。

権限を渡さずに人だけ入れると、外部PMも「言われたことを整理する人」になります。PMOを含めた依頼の設計はPMO外注の選び方に書きました。

同じ体制のまま次のプロジェクトを始めると、同じ理由で燃えます。原因は個人の能力ではなく、決まっていないことが見えない進め方のほうにあるので、そこを直さない限り繰り返します。

余裕はありません。ただ、立て直しでやる4つのことは、そのまま平時の進め方になります。未決事項を数える、現状を見る場所を1か所にする、悪い情報の場を分ける、終了条件を先に決める。火が消えたあとにこれを外すから、また燃えるんです。