金融PMの炎上プロジェクト立て直し｜初動と実務手順ガイド

「このプロジェクト、もう無理じゃないですか」と、ある基幹系刷新の現場でPMOの若手に真顔で聞かれたことがあります。

結論から言うと、僕はそのとき「無理じゃない、順番を変えれば戻せる」と答えました。金融PMの現場で炎上プロジェクトに遭遇するのは、決して珍しいことではないと個人的には感じています。むしろ勘定系刷新やBaaS連携のような大型案件では、どこかのフェーズで一度は火の手が上がるものだと思っておいた方が現実的です。この記事では、炎上プロジェクトの典型パターンを整理し、PMとして立て直しに入るときにまず何をすべきか、初動から体制の再構築、そして今日から動ける実務アクションまでを段階的に見ていきます。

0. まず結論として（体感値の全体像）

僕の体感値で言うと、金融システムの大型プロジェクトのうち、進行中に一度でも「これは危ないぞ」という局面を通過する案件は、全体の半数近くにのぼるのではないかと感じています。これはあくまで独自ガイドの目安値であり、公的な統計に基づくものではありません。ただし「炎上している」と「完全に破綻している」はまったく違う状態だと考えています。多くの現場は、火が小さいうちに気づいて手当てすれば、通常のプロジェクト運営に戻せます。逆に、火が大きくなってから気づくと、スコープの削減や体制の入れ替えといった痛みを伴う判断が必要になります。

大きな船の進路を変える作業に近いと僕は思っています。舵を切ってすぐに船首が動くわけではなく、まず速度を落とし、乗員に状況を伝え、それから少しずつ方向を変えていく。炎上プロジェクトの立て直しも同じで、いきなりスケジュールを巻き戻そうとしても現場は動きません。この記事で扱う「立て直し」は、すでに遅延やコスト超過が可視化されてしまった、比較的深い段階を想定しています。軽微な遅れの段階で対処できるのが理想ですが、現実にはPMが交代で投入されるタイミングというのは、たいてい問題が誰の目にも明らかになったあとです。

1. 炎上プロジェクトの典型パターン3つ

僕がこれまで見聞きしてきた範囲では、金融系の炎上プロジェクトは大きく3つのパターンに分けられると考えています。厳密な分類学ではなく、あくまで実務上の整理として捉えていただければと思います。

実務ではこの3つが単独で起きるより、遅延型が進行してスコープ肥大が重なり、最終的に体制崩壊に至るという複合形が多いと感じています。特にスコープ肥大型は要注意です。業務部門の要望はどれも「業務上必要」に見えるため、担当者一人ひとりの判断では断れず、結果として気づいたときには当初計画の1.5倍近い工数になっているというケースも珍しくないという印象を持っています。

2. 立て直しの初動48〜72時間でPMが最初にやること

炎上案件に投入されたとき、僕がまず優先するのは「現状の見える化」と「関係者の個別ヒアリング」の2つです。全体会議を開いて状況を確認しようとする方も多いのですが、個人的にはこれはあまり得策ではないと考えています。関係者が同じ場に集まると、責任の押し付け合いになりやすく、正直な情報が出てこないことが多いからです。

そのため最初の2〜3日は、あえて大きな会議を開かず、キーパーソンに一人ずつ個別で話を聞くようにしています。「今どこが一番つらいですか」という一問だけでも、立場によってまったく違う答えが返ってくることが分かります。開発チームは「要件が固まらない」と言い、業務部門は「開発が遅い」と言い、ベンダーは「発注元の意思決定が遅い」と言う。この三者の言い分をすべて聞いた上で、どこに事実としてのボトルネックがあるのかをPM自身の目で確認する作業が、初動で最も重要だと僕は考えています。

この段階でスプレッドシート1枚に「タスク・担当・当初予定・現状・遅延理由」を並べるだけでも、驚くほど状況が整理されます。派手なツールを導入する必要はなく、まずは手元で全体像を掴むことを優先すべきだと思っています。

3. ステークホルダー別の調整順序

状況が見えてきたら、次は誰にどの順番で話をつけるかという調整に入ります。僕の経験上、この順番を間違えると立て直しがかえって遅くなることがあるため、慎重に考えるべき部分だと感じています。

1. 経営層・スポンサー：まず全体の方向性について、率直な現状と選択肢を共有します。ここで「まだ間に合う」という空気だけを演出すると、後から信頼を失うため、僕は良い面と悪い面を両方伝えるようにしています。
2. 業務部門：次にスコープの優先順位について合意を取ります。経営層の意向を踏まえた上で「全部は無理だが、この機能は必ず入れる」という線引きを一緒に作る作業です。
3. ベンダー：業務部門との優先順位が固まった段階で、実現可能なスケジュールと体制について協議します。ここを先にやってしまうと、業務部門の合意なしに技術側だけで話が進み、後でひっくり返るリスクがあると考えています。
4. 開発チーム：最後に現場のエンジニアやメンバーに、新しい優先順位と体制を共有します。現場が最も疲弊している場面が多いため、変更の理由を丁寧に説明することを心がけています。

この順序は絶対的な正解ではなく、案件の性質によって前後することもあります。ただ、経営層への説明を後回しにして現場対応だけを進めると、途中で方針が覆されて二度手間になる場面を何度か見てきたため、個人的には経営層を最初に置くことを基本形にしています。

4. スケジュール・スコープ・体制の見直し方

立て直しの中核は、いわゆるスコープ・スケジュール・リソースの三角形を、どこかを妥協しながら再設計する作業だと考えています。すべてを当初計画どおりに戻すのは、炎上している段階ではほぼ不可能です。

僕がよく使う考え方は、機能を「今回必須」「次回以降でも業務は止まらない」「そもそも要否が曖昧」の3段階に振り分けることです。金融システムの場合、法令対応やセキュリティ要件は削れないことが多いため、削減の余地があるのはむしろ利便性向上系の機能に集中していると感じています。この振り分けを業務部門と一緒に行うことで、削るという決定を業務部門自身の合意として持ってもらうことができ、後々の「PMが勝手に決めた」というトラブルを避けやすくなります。

体制面では、役割が重複している、あるいは誰も持っていないタスクを洗い出すことが有効だと思っています。RACI表を作り直すだけで、実は同じ調整を3人が別々にやっていた、あるいは誰もオーナーを持っていなかった、という発見があることは珍しくありません。スケジュールについては、いきなり全体を再計画するのではなく、直近4〜6週間だけを高精度で組み直し、その先は粗い見通しにとどめるという段階的なアプローチを僕は好んでいます。全体を一度に精緻化しようとすると時間がかかりすぎ、状況がさらに動いてしまうためです。

5. 今日からやれる実務アクション

ここまでの内容を踏まえて、炎上案件に入ったPMが今日から動ける実務アクションを整理します。大がかりな準備は不要で、多くは今日中に着手できる範囲だと考えています。

1. タスク・担当・当初予定・現状・遅延理由を1枚のシートに書き出し、全体像を自分の目で確認する。
2. キーパーソン3〜5人に個別ヒアリングの時間をもらい、それぞれの立場から見た「一番つらい点」を聞く。
3. 機能一覧を「今回必須」「次回以降」「要否要検討」の3段階に仮で振り分けてみる。
4. 現行の体制図・RACIを見直し、オーナーが不在のタスクや役割の重複を洗い出す。
5. 直近4〜6週間分だけ、より詳細なスケジュールに組み直し、その先は粗い見通しにとどめる。

これらは特別なスキルを必要とするものではなく、地道な確認作業の積み重ねです。ただ、炎上している現場ほど、こうした基本的な整理を誰もやっていないというケースが多いと僕は感じています。派手な対策より、まず事実を並べることが立て直しの第一歩になると考えています。

6. よくある失敗とその対処

立て直しの現場で僕が見てきた失敗のパターンをいくつか挙げます。ひとつは、着任してすぐに「全部やり直しましょう」と宣言してしまうケースです。現場のモチベーションを大きく下げるだけでなく、それまでの積み上げを無駄にしてしまうことがあり、個人的にはあまり推奨していません。既存の成果物を活かせる部分は活かし、変える部分だけを明確にする方が、現場の協力を得やすいと思っています。

もうひとつは、業務部門への説明を後回しにして、技術的な立て直しだけを先行させてしまうケースです。開発側の視点だけでスコープを削ると、後になって「その機能がないと業務が回らない」という反発を受け、せっかく組んだスケジュールが崩れることがあります。対処としては、削減候補を出す段階から業務部門を巻き込み、代替手段があるかどうかを一緒に検討する進め方が有効だと考えています。

最後に、ベンダーとの関係を一方的な発注元・受注先の構図で押し切ろうとする失敗もよく見られます。炎上している状況では、ベンダー側にも遅延の背景や事情があることが多く、そこを聞かずに一方的にスケジュールを詰めても、表面上の約束だけが残って実態は変わらないということが起きます。事情を聞いた上で、無理な部分は無理だと認め、代わりに何を優先するかを一緒に決める方が、結果として立て直しが早く進むという印象を僕は持っています。

7.（結論）

金融PMにとって炎上プロジェクトの立て直しは、避けたい場面である一方、実務者としての力が試される場面でもあると個人的には考えています。パターンを見極め、初動で事実を見える化し、経営層から業務部門、ベンダー、開発チームという順序で調整を進める。この一連の流れは、勘定系刷新でもBaaS連携でも、金融DXの現場に共通する基本形だと思っています。

皆さんいかがでしたでしょうか。今まさに難しい案件を抱えている方も、これから金融PMとしての実績を作りたい方も、まずは事実を1枚のシートに書き出すところから始めてみてください。では今日もがんばりましょう。