ベンダーのPM交代が招いた、プロジェクトの「静かなる沈没」

信頼していたプロジェクトマネージャー（PM）が交代する。そんなによくある話、大した影響はないと思っていた。しかし、それは巨大なタイタニック号が氷山に触れた瞬間だった。

「エースPM」が去った日

ある大規模なシステムリプレースプロジェクト。ベンダー側のPMは、こちらの業務を深く理解し、無理な要望にも「それはこういう理由で難しいですが、代わりにこうしましょう」と対案を出してくれる、まさにエース級の人物でした。

しかし、プロジェクトの山場を越えたあたりで、ベンダーから一通のメールが届きました。「PMのAが、一身上の都合により交代いたします。後任はベテランのBが務めますので、ご安心ください」

発注側である製造業のシステム課長は、「まあ、仕組みはもう決まっているし、あとは作るだけだろう」と軽く考えていました。しかし、この「人入れ替え」が、全ての狂いの始まりでした。

蓄積された「文脈」という名のブラックボックス

後任のPMは、確かにベテランでしたが、これまでの数ヶ月にわたる「議論のプロセス（文脈）」を全く持っていませんでした。

「なぜ、この複雑な計算ロジックを採用することになったのか」
「なぜ、あの機能をあえて削ったのか」
「現場のキーマンが、どの画面で一番こだわっていたのか」

これらは仕様書には書ききれない、会議室での熱い議論や、ホワイトボードの端書きの中にあった「暗黙知」です。後任のPMは、手元の仕様書だけを頼りに指示を出し始めました。すると、一度解決したはずの疑問が現場から再燃し、決定事項が覆り、プロジェクトは目に見えて失速していきました。

誰にも止められない「要件の先祖返り」

「前のPMの方は、ここはこうすると言ってましたよ！」現場の不満に対し、新しいPMは「仕様書にはそう書いてありません」と機械的に答える。

このコミュニケーションの断絶により、現場の士気は下がり、開発チームも混乱。修正に次ぐ修正で、スケジュールは半年遅延し、追加費用は雪だるま式に膨らんでいきました。ベンダー側の会社としての技術力は変わらないはずなのに、PMという 「情報のハブ」 が変わるだけで、プロジェクトはこれほどまでにもろく崩れ去るのか——。発注者は、その現実に愕然としました。

教訓：プロジェクトは「人」ではなく「記録」に預ける

ベンダーのPM交代を、発注側で止めることはできません。組織である以上、退職や異動は避けられないからです。

だからこそ、発注者として自衛すべきは、 「特定の人間にしかわからない情報」をゼロにすること です。

重要な決定事項は、なぜその結論に至ったかの「理由」とともに議事録に残す。
画面の動きについては、仕様書だけでなくプロトタイプ（動く証拠）を残し、誰が見ても一目でわかる状態にしておく。
PM交代の打診があった際は、単なる挨拶で終わらせず、最低1ヶ月の「並走期間」を設け、情報の引き継ぎが完了したことを発注側が承認する権利を行使する。

「あの人がいれば大丈夫」という安心感は、ITプロジェクトにおいては最大の脆弱性です。システムを作る前に、まず情報の引き継ぎができる仕組みを作っておくこと。それが、不測の事態でもプロジェクトを沈没させないための、唯一の航海術です。