プロジェクトを進めていくと日々の業務の中で、さまざまな問題が出てきて、解決することが求められる。できることならば避けて通りたいと思うのが人情だ。

　ましてやそれが一筋縄では解決できない難題であればなおさらだ。時にはプロジェクトの運命を左右するような難題が降りかかってくる。難題をどうやって乗り切るかはすべてPM（プロジェクトマネジャー）の双肩にかかっている。

　ここでたとえ難題がPMの専門外だったり、PMが経緯を十分つかんでいなかったりしたとしても、担当のPL（プロジェクトリーダー）やメンバーに解決を丸投げしてはいけない。

DB設計の不整合の解決を丸投げしたHさんの失敗

　大手小売り企業のA社は業務体系の見直しに併せて、既存のホストシステムをオープンシステムに刷新しようとしていた。このオープン化の中には、既存データベースの構造を根本から見直すといった技術的に難易度の高い要件も盛り込まれていた。

　このA社のシステム再構築プロジェクトに抜擢されたのは、システムインテグレータ所属のHさんだった。Hさんはプログラマとしての実績は申し分なかったが、PMとしての実績は2、3の小規模システム開発の経験だけにとどまっていた。今回のような大規模システム開発の経験は全くない。

　そこでHさんの上司は、彼の経験不足を埋めるために、長年付き合いのある協力企業からベテランSEをPLとして配置した。また既存データベースの構造を見直すため、データベース設計に精通したA社の情報システム部門のKさんと、その部下のLさんに参画してもらうことにした。

　ベテランSEをPLにしたこともあって、プロジェクトは順調に進んでいった。特にKさんの働きはめざましく、基本設計フェーズの中盤には、既に新しいデータベース構造が大方でき上がっていたのだった。その成果を受けてA社はKさんを引き上げ、それ以降の作業をLさんが進めることを決定。Lさんによるデータベースの詳細設計フェーズも順調に進んだ。

　Hさんはデータベース設計の専門家ではないことから、基本設計と詳細設計フェーズともに、データベース構造については、KさんとLさんに一任。レビューはしていたものの、内容についてほとんど口出しはしていなかった。

　結合テストフェーズに入ったとき、問題が起こった。一部でデータの整合性が取れないという問題が発生した。原因は、Lさんが行った内部設計にあった。設計を見直すことが必要で、それはプロジェクトにとってもインパクトが大きく、大きな手戻りになることも明らかになった。

　データベースの構造や設計に関して、それまでほとんど関与していなかったHさんは、「有効な打ち手が全く分からない。ここはこれまで担当してきて詳細に設計内容をつかんでいるLさんに解決をお願いするしかない」と判断。Lさんに解決を依頼した。Lさんも強く責任を感じていたこともあり快諾してくれた。

　Hさんはその返事に安心し、いつもの進捗管理だけを続けることにした。つまり、Lさんに解決を丸投げしてしまったのだ。日々の進捗報告会でもHさんはLさんに「内部設計の見直しは、いつごろまでかかるでしょうか？」と聞くだけで、それ以上突っ込んだ話はしなかった。

　そうこうするうちにLさんに頼んでいた問題は解決しないまま、１カ月がたってしまった。焦ったHさんはベテランSEをLさんの手伝いに回した。すると今度はそのベテランSEが担当していた作業が遅延。プロジェクトは完全に負のスパイラルに入ってしまった。

　この状況に業を煮やしたA社は急きょ、別システムのデータベース設計に携わっていたKさんを呼び戻して火消し役として投入。何とか危機的な状況を打開できたものの、最終的には大幅な納期遅延とコスト超過になってしまったのである。