なぜ、システムの仕様は膨らむのか？

システム開発の技術者にとって最も難しい仕事の一つが「プロジェクト工数のマネジメント」であろう。

企業がシステムをつかうようになった当時から、この手の問題は常に課題の中心となった。

国立競技場の建築プロジェクトや、鉄道におけるトンネル掘削など、建設業においても同様の問題があるが、システムは成果物の全体像が抽象的で把握しにくいという特性上、どうしても予算をオーバーランしやすい。感覚的には、企画・構想時から要件定義時に、だいたい2倍の仕様になるイメージだ。

したがって、システム開発のプロジェクトマネジャーは、「どのようにして仕様の増加と修正を抑止するか」ということに、気を遣う必要がある。

だが、顧客に対して「これは今回のプロジェクトの範囲に含めない方が良いと思います」と堂々と述べるプロジェクトマネジャーは極めて少ない。仕様は現実的には際限なく膨らむ。

なぜ、これほどまでに工数が増加してしまうのだろうか。理由は３つある。

1.顧客システム開発部の発言権

顧客先において、システム開発部の地位が低いと、社内での利害調整ができず、結果としてすべての部門から出てきた要望をそのまま全て作りこむ、という結果になることが多い。

実際には作られた機能は殆ど使われないのだが、工数は際限なく膨らむ。システム開発において「みんなの言うことを聞く」のは愚の骨頂なのだが、陥りがちな罠である。

2.システム開発会社の都合

工数ベースでの契約の場合、工期が伸びればシステム開発は儲かる。したがって、システム開発会社は「そのシステムがどう業務に役立つか」よりも、「どれだけ工数が稼げるか」に関心があることも少なくない。

顧客側での仕様増加にとくに反対しなければ、どんどん工数は増加するのだから、開発側としては「やりたければどうぞ」と言えばいいのだ。

工数の増加を抑止する人がいなければ、とうぜん仕様は膨らむ。

3.顧客先で業務の標準化が成されていないこと

業務は柔軟に変更できたほうが良いが、システムはそれほど柔軟ではない。現状の業務システムは、「手続きに従ったこと」しかできないからだ。

したがって、しすてむは柔軟に対応できればできるほど、エクセルに近いものとなる。「じゃあエクセルでいいじゃない」という方もおおいが、そのとおりなのである。

したがって、現場とシステムが喧嘩しないようにするためには、「余り変わらない業務」だけをシステム化して効率よくし、「やり方を模索中である」といった柔軟性を保ちたい領域はシステムではなくエクセルなどで管理するほうが良い。

柔軟性を保ちたい領域をシステム化しようとするから、仕様が膨らんだり、コロコロ変更されたりするのである。