旧知のソフトウエア開発会社のA社長が緊急で相談に乗ってほしいことがあると駆け込んできた。だいたいこういうときはあまり良い話ではない。案の定、話を聞いてみると、請け負った開発プロジェクトが遅延に遅延を重ね、泥沼状態だという。「このままでは会社が倒産してしまう」とA社長は顔面蒼白であった。
A社長は元同僚であったB氏と一緒に会社を立ち上げた。A社長は営業パーソンとして非常に優秀で、B氏はITエンジニア、特に開発のプロジェクト管理が得意であり、2人がコンビを組むことで会社は順調な立ち上がりを見せた。会社は小規模ながらも大手の下請けではなく、直接ユーザー企業から開発案件を受託していた。「中抜き」が無いので開発コストはリーズナブルであり、顧客からは納期順守や品質に関しても高い評価を得ていた。
ところが会社設立から数年たち、経営方針を巡って2人の意見が頻繁にぶつかるようになった。やがてB氏は会社を去り、プロジェクト管理を任せられる人がいなくなってしまった。そこでA社長は、プロジェクトマネジャーを外注することにしたのである。
A社長は営業出身ということもあり、顧客志向が非常に強く、外注したプロジェクトマネジャーに対して「顧客の言うことにしっかりと耳を傾け、要求をきちんと取り入れるように」と強く指示していた。この指示自体は決して間違いではなく、ベンダーとしては正しい姿勢であろう。しかしA社長は、プロジェクト管理に関しては素人であった。プロマネから「顧客からさみだれ式に追加要求が出てきているのですが…」と報告があると「なるべく要望を取り入れろ」と指示を繰り返した。
やがてプロマネも、どうせA社長に相談しても同じ答えだろうと自分の判断でどんどん追加要求を受けてしまうようになった。また、このプロマネはプロジェクトの受注額や採算ラインなどの情報はA社長から詳しく知らされておらず、コストへの責任意識が最初から希薄であったことも災いとなった。
こうして、ある意味A社長の指示に忠実に従って顧客の追加要求を受け入れていったために、当初の納期では全く間に合わない状況になった。さすがにA社長も焦って顧客と交渉するが、顧客は「追加要求が出るのは要件定義が甘かったからでプロマネの責任だ」という。システム開発の正論からいえば要件定義は顧客側に大きな責任があるのだが、プロジェクト管理の基本すら知らないA社長はこの顧客の言葉をうのみにして「費用は当社の持ち出しでやります」と答えてしまう。A社長には、ここで損をしても、次のフェーズを受注して挽回しようという思惑もあった。
ところが当初は2カ月の遅延で収まるはずが、予想外のバグが発生したり、あるいはその遅延期間中にも新たな追加要求が出されたりと、遅延が3カ月になり、4カ月になりとエンドレスの様相を呈してきた。2カ月ならなんとか資金負担できると計算していたA社長も、さらにプロジェクト期間が延び、先が見えない状況となりお手上げとなってしまったのである。
このプロジェクトは、発注者である顧客の側にも大いに問題があった。まずシステム開発の調達に当たってRFP（提案依頼書）を作成せず、他ベンダーとの比較検討もきちんとやらなかったそうだ。さらに要件定義もベンダー任せであり、当事者意識が低かった。プロジェクトの進捗遅延により泥沼化してからも、「ベンダー側でなんとかして」という姿勢は変わらなかった。プロジェクトの問題は発注者と受注者双方が問題意識を共有して、協力して当たらないと解決は難しい。
プロ野球元監督の野村克也氏が好んで使っていた言葉に「勝ちに不思議の勝ちあり、負けに不思議の負けなし」がある。まさにこのケースは「プロジェクトの失敗に不思議の失敗なし」の典型といえるだろう。
