勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

大規模プロジェクトは失敗しやすいのか?

大規模開発では4割が予算超過、5割が工期遅延」という記事を読んで考えたこと。

http://www.flickr.com/photos/56594044@N06/7052562051
photo by Official U.S. Navy Imagery

そもそも定義はあっているか問題

前述の記事では、『大規模プロジェクト』は『43.9%が予算超過』『48.9%で工期が「予定より遅延」』と言っているのだけれども、細かい定義は記載されていないのでなんだか怪しい。

  • 大規模開発の定義は「500人月超」
  • 予算の定義はよくわからない(どこからどこまでの工程なのか、外注費のみなのか総費用なのか)
  • 工期の定義もよくわからない(どこからどこまでの工程なのか、ベンダーが請け負った範囲なのか)

細かいデータは(有償なので)見ていないけれども、実態は次のようなものではないかと考えている。

  • JUASの調査ということで、あくまで「ユーザ起業の目線と印象論」である。
  • 500人月超が基準ということで、全般的には「新規開発」または「システム更改」ばかりばピックアップされていると予想。一般論であるがこれらのプロジェクトは(「保守開発」などに比べて)難易度が高く、工期や工数のブレが大きいのは仕方が無いという気がする。

この手の調査はどこまで信頼できるかという問題があって、例えば有名な1994年のChaos Reportというもの(ソフトウェアプロジェクトの期限超過率は平均189%で、予算と工期が予定内だったのは16%と論じている)についても、事後の研究で信頼性が欠けると評されてもいる(Making Software ―エビデンスが変えるソフトウェア開発の 3章 システマチックレビューから学べるもの P44あたり参照)。

大規模と一括りに言うけれど

そもそも巨大でコントロールしにくいものは、分割して取り扱いやすくするものだ。「大規模ソフトウェア開発プロジェクト」といっても、具体的な設計や開発のフェーズに入れば中規模以下のサブプロジェクトの集合体になっている。サブプロジェクトの分け方によって、特定のサブプロジェクトが失敗・遅延した場合に全体が失敗となってしまう直列の関係となるのか、影響が限定的となり部分的な失敗で済むのかが決まる。とすれば、いかにサブプロジェクトを分割するのか、というのが大きな論点となってくる。

  • アーキテクチャをどのように構想するかという問題とも言える
  • うまく切り分けることができればしめたもの。逆に切り方を失敗すると後で大きく後悔することになる。やりなおしは難しい。
  • アプリケーションのドメインが狭ければ、一般的なアプリケーションフレームワークを取り込んでしまえばなんとかなるという感覚あり(むしろ、独自構想は危険)。
  • アプリケーションのドメインが広い場合は要注意。王道は無く、身悶えながら検討する。

開発プロセスの問題はあるのか

ところで、「大規模」と言うとウォーターフォール型の開発プロセスをイメージである。では、アジャイル開発プロセスだったら成功しやすいかというと、それはまた別の話だと考える。

  • 小刻みにタイムボックスで管理するので、形式的には「大規模」ではない
  • しかし、小刻みに拡大していって最後に爆発するという話も無くはない
  • 斬新的にアプリケーションが進化し、利害関係者の暗黙知も共有されていくのだから失敗しにくいとは思うが、アーキテクチャ切りをミスするとやっぱり死んでしまうと思う。