プロジェクト・マネージャ（PM）がシステムの出来栄えを左右することに異論はないだろう。開発者や営業の担当者など，プロジェクト・メンバーはPMの指揮を確認しながら作業する。

　PMとメンバーの間に隙間があり，メンバーが勝手なことを始めたら，プロジェクトは危うい。「要件が拾えない」「コーディングにミスがある」「テストが漏れる」――システム障害の原因は，この隙間から生まれる。これを埋めなければ障害は繰り返されるだろう。PMと隙間をはさむ相手は，開発者だけでなく，ユーザー企業の担当者，自社の営業担当者など様々だ。しかも隙間は，PMがほんの少し油断しただけで見る見る大きくなっていく。

　月曜日に稼働させた新システムは平日を無事に乗り切った。プロジェクト・メンバーが一息つこうとした矢先，週末のバッチ処理が異常終了した。客先に呼び出されたSIベンダーのエンジニア 赤嶺聡氏（仮名）は，原因を突き止めて対処するまでの2日間，ほぼ休みなく端末に向かった。トイレに行く以外は椅子から立ち上がるのがはばかれる雰囲気だった。

　障害に見舞われたのは，ある金融機関の勘定系システム。機能強化を図るこのプロジェクトは，大手のSIベンダーA社が元請けとなり，別のSIベンダーのB社とC社がその下で開発した。赤嶺氏が所属するB社は，データベース・チームとしてDBへのインタフェース・プログラムの開発を担当。アプリケーションを開発したのはC社である。

　要件定義や基本設計は，A社のPMが中心となり行った。両チームの開発は順調に進み，稼働開始4カ月前ぐらいから，C社のリーダーがプログラムを納品し始めた。それを横目で見ていた赤嶺氏は不安を覚えていた。「機能は満たしているようだが，単体テストがやっと通る程度の代物」と映ったからだ。なぜなら，そのテストはコーディングした本人が行っていた。

　赤嶺氏の不安をよそに，A社のPMは「これでOKです」と次々にプログラムを検収していった。このPMは1人で顧客側と開発側に対応していた。忙しさのあまり，2～3カ月も客先に近いホテルを借りて臨戦態勢にあった。もちろん，PMはC社が行ったテスト内容をチェックしていたが，どんなテストをしたかよりも，テスト件数に重きを置いていた。

　C社のリーダーは，「一刻も早く検収してほしい」と急いでいた。100人を超えるメンバーは，後半になり頭数が減っていった。最終的にはB社だけを残し，C社はプログラムをＢ社へ引き継いで離れる計画だった。C社のリーダーは，投入工数が従来の半分に減っており，「早く新しい客先に行きたい」という気持ちがありありと見えた。

　C社からB社への引き継ぎは形ばかりのものだった。C社の開発ドキュメントは，要求仕様がアップデートされずにころがっている有様。赤嶺氏の上司に当たるB社のリーダーは「こういったドキュメントがほしい」と要求したが，C社のリーダーに「まあ，大丈夫ですよ」といなされるだけ。

　B社のリーダーはA社のPMに対して，「引き継ぎがうまくいっていない」と訴えた。しかし，多忙を極めるPMの耳には届かない。B社のリーダーはPMに対してあまり強いことも言えず，出来る限りのことをやろうと，ソースコードを追いかけた。

　C社のリーダーは「無事にカットオーバーできた」と意気揚々と引き上げていった。その週末，計算ロジックの誤りが異常終了を引き起こした…。

　このプロジェクトは，とにかくC社のリーダーに振り回された。テストがいい加減，引き継ぎも不十分となれば，バグが残っていても不思議はない。ただし，A社のPMの管理責任も問われるところだ。テストや引き継ぎの手抜きを見過ごしたからである。

　このPMが多忙なことは分かる。しかし，だからといって品質が悪いプログラムを見過ごすわけにはいかない。自分ひとりでこなせないなら，プログラムの検収を行うサブのPMを連れてくることも考えられたはずだ。結果的に，このPMはC社のリーダーとの隙間を埋める努力を怠った。PMが自分の方に近づいてこないと見たC社のリーダーは，「品質の悪いプログラムでも大丈夫」と高をくくったに違いない。

　もう一つ，PMはB社のリーダーとの隙間を広げるというミスも犯している。プロジェクトの途中で，C社のプログラムをB社が引き継ぐことが決まった。品質が悪いプログラムが検収されている実態は，同じ現場にいれば誰でも分かる。「粗悪なプログラムを押し付けられる」となれば，PMへの信頼が薄れても仕方がない。理不尽な引き継ぎにしても，PMのバックアップが得られねば，両者の隙間は広がるばかりだろう。もしPMが無理に1人で仕事を抱え込まず，助けを頼んでいれば，プログラムの検収や引き継ぎはもう少し違った結果になっていたはずだ。