ITプロジェクト失敗例から見る、プロジェクトマネージャに必要なもの

昨今、ITシステム開発プロジェクトの成功率は3割以下だといわれています。

ITシステム開発が行われるようになって、かれこれ50年ほど経つにもかかわらず、未だに70%以上のプロジェクトが、当初の想定を大幅に下回るQCD（クオリティー・コスト・デリバリー）で納品されるか、そのまま納品されずに開発中止という結果に終わっています。

なぜ、システム開発プロジェクトがこれほどまでに成功率が低いのかを、私が経験したプロジェクトの失敗から考察してみます。

失敗例

以前、途中参加したとあるプロジェクトでは、ウォーターフォール型開発が採用されていました。

そのときのプロジェクトマネージャーは、できないエンジニアではありませんでしたが、かといって特に優秀なエンジニアとも言えない、ごく一般的なエンジニアでした。

発注元はこのプロジェクトマネージャーに、要件を口頭で伝えるだけでほぼ丸投げし、出てきた要件定義書や外部設計書にはいちいち文句を言い、なかなか全ての要件に決定を出さない状態でした。仕方なく、要件定義や設計が終わらないまま実装がスタートしました。

そして、数ヶ月後には、結局納期を守れず炎上、客先の信頼を大きく失墜させる結果に終わりました。

まあ、よくある話です。

原因1. プロジェクトマネージャの技術的実力不足

まず第一に、失敗したプロジェクトでよく言われるのが、「プロジェクトマネージャの技術的実力不足」です。

システムを設計する上で、とても重要になってくる一つの要素に、「アーキテクチャ」というものがあります。「コンピュータシステムの論理的構造」という意味ですが、その構造指針、いわば設計思想のことも指します。このアーキテクチャに基づいて、全てのシステム開発作業は行われます。よって、「アーキテクチャ」がシステム開発成功のカギであると言っても過言ではありません。

アーキテクチャが良くない（一貫性がない）システムは、総じて拡張性・合理性に欠けるシステムになってしまい、開発効率が一貫して悪くなったりバグを含みやすくなったりする傾向にあります。すなわち、要求された要件に最適なアーキテクチャを選択できないということは、プロジェクトマネージャにとって重要な要素が欠落していることになります。

また、最適なアーキテクチャを選択できていたとしても、その思想を開発チームのエンジニアが的確に共有するようにマネジメントできていない、ということもあります。

最適なアーキテクチャを選択・共有して初めて、開発のスタートラインに立てるのです。

今回の例では、この部分がうまくマネジメントできていなかったように感じました。

原因2. プロジェクトマネージャの発注元交渉力不足

アーキテクチャを策定したら、今度はそのアーキテクチャで開発することを発注元に認めさせる交渉力が必要になります。半ば強引でも構いません。

発注元というのは、往々にしてシステムに関しては素人です。どれだけ拡張性の重要度を伝えたとしても、「で？機能は良くなるの？」と、結局使う側のメリットしか考えません。システムの保守のことなどこれっぽっちも考えていないのです。

そんな人のいいなりになって、言われたことを全て鵜呑みにして無理な機能追加を繰り返しながらシステムを開発していたら、そりゃあバグだらけのシステムが出来上がります。なぜなら、発注元はバグを作りこまないのは開発側の当然の責任と思っているからであり、その原因が自分たちが無理な発注をしているからだとは思いもしないからです。

また、発注元が外部設計（特に機能設計）などに口出しをするのはもってのほかです。それではいつまでも開発に入れず、無駄なやり取りだけで時間を浪費します。発注元が口を出せる場所は、通常であれば要件定義の部分や細かな画面設計だけのはずです。明確にどこまで顧客の要望に応えるのか、というのは予め決めておき、文書で取り交わしておきましょう。

今回の例では、顧客の無理な要望も全て一旦受け入れ、吟味し、極力取り入れるという手段をとりました。その結果、最終的には納期には到底間に合わなくなってしまいました。顧客にとって重要なことを見失わないようにするのが大事だと感じます。

原因3. ウォーターフォール型開発

そして最後に、「ウォーターフォール型開発」の困難さが、プロジェクト失敗の一端を担っていたと思います。

結論から言うと、ウォーターフォール型開発は、プロジェクトマネージャーがかなり優秀であり、なおかつシステムに関する知識・決定権や責任を持っていないと、最終的に破綻してしまう仕組みです。また、発注元の積極的な協力も必要不可欠です。今回の場合でいうと、どの要素も含まれていなかったのです。

ウォーターフォール型開発でプロジェクトを進めていく上で最も重要なのが、「最適な決定を確実に下していく」ということです。この「確実に下す」というのが非常に重要で、「曖昧に」「とりあえず」「今のところ」というような形で進めていくのは絶対にダメです。

ウォーターフォール型開発とアジャイル型開発

一般的なシステム開発であれば、以下のような順序で工程が進んでいくはずです。

要件定義
外部設計
内部設計
実装
単体テスト
結合テスト
システムテスト

ウォーターフォール型開発であれば、これが1回で納品。アジャイル型開発であれば、これを複数回継続的に回し続けていくことになります。

なぜアジャイル型開発が近年注目され、採用例が増えてきているのかというと、市場投入やカットオーバーが早いということがあります。なぜ市場投入やカットオーバーが早くなるのか。それは、「確実な決定」が早いからに他なりません。

先ほど「曖昧に」「とりあえず」「今のところ」で進めていくのはダメだと申し上げました。上記の7つの工程でいうところの、例えば「1. 要件定義」→「2. 外部設計」にプロジェクトが進むとき、要件定義での決定は"絶対"でなくてはなりません。「曖昧に」「とりあえず」「今のところ」ではダメなのです。

つまり、外部設計をしているとき、要件定義は100%決定していないとダメであり、実装をしているのに内部設計に変更があるなど言語道断です。前の工程が100%終了していないと、次の工程には進めないのが、前提となっています。

失敗するプロジェクトでは、この辺りの「決定」がかなり曖昧になされています。人間必ず漏れがあるため100%とは言わずとも本来は90%以上の内容を網羅できていなければならない要件定義が、まだ50%しか出ていない段階で外部設計に突入してしまうのです。

10%程度なら後で設計者が頑張れば、アーキテクチャに影響を与えることなく後から設計に盛り込むこともできるでしょう。しかし、50%の要件・機能の追加となれば話は別です。それは即ち、外部設計のやり直しをしないことにはアーキテクチャが破綻することを意味します。

ウォーターフォール型開発のデメリットはここにあります。全ての工程を完璧に進めていく必要があり、後から前工程の不備の修正や改善をするのが非常に難しいです。変化を受け入れられないのです。

その点、アジャイル型開発は、「1→2→3→4→5→6→7→1→2→...」と、工程をサイクルさせるわけですから、1つの工程が巨大化せず設計/実装がシンプルになりますし、1での不備は次の1で修正し挽回できる可能性もあります。「細かい100%の決定」を何度も繰り返すということです。

以上のことから、ただでさえ有能なシステムエンジニアにしかできないプロジェクトマネージャーという責務を、ウォーターフォール型開発はより困難なものにすることは明白です。

今回の例では、プロジェクトマネージャーの資質や技量そのものがウォーターフォール型開発に向かないものであったと考えるより他ありません。アジャイル型開発でも優れた技術力は必要ですが、こうはならなかったかもしれません。少なくとも、ミニマムなシステムは導入できた可能性があります。

まとめ

ITシステム開発のプロジェクトマネージャは映画監督のようなものです。映画（システム）に一貫した世界観（アーキテクチャ）を持たせ、観客（発注元）を満足させる必要がある。いちいち全ての観客（発注元）の要望を聞いていたら、世界観（アーキテクチャ）は崩壊してしまい、結果として観客（発注元）の満足できない映画（システム）が出来上がってしまう。

ある意味で、一人の有能な、かつ独裁的な、マネジメントが必要になるのかもしれません。