今のシステム開発の業界における価格は、実はその提供している価値に対して、コストが高すぎるのではないか、と以前から考えていました。IT投資に対するパフォーマンスの比率が著しく悪い、摩擦係数が異常に高い気がします。それが何故なのかを考えてみました。（今回は問題提起だけなので悲観的なようですが、別途私の提案編を書く予定です）
色々なお客様とお話しさせて頂くと、かなりの予算投資をしてシステムを構築した後に、実際に使い始めると修正したい箇所が出てくるもので、その改修をベンダに依頼すると想像以上の金額の見積りが返ってきて驚いた、という話をよく聞きます。
実際に、画面の一部のキャプションを少し直すだけでも、数万円とかの見積が出てきた、というのも大袈裟な話ではないのでしょう。そんな経験をしてしまうと、より一層に構築時に確実に作って、改修しなくて済むように、と考えてしまっても仕方ありません。
また、システムを分割して少しずつ発注をしていくと、どうも割高になってしまうということもあります。大雑把に見積りを依頼した方が安くなるというのであれば、やはり最初に色々と決めきって、一度に大きく発注した方が良いと考えてしまうことでしょう。
この方向性の果てにあるのが、今のシステム開発の慣習である大掛かりな要件定義と一括請負にいきつく訳です。しかし、このビジネスの形こそが実は、システムの価格を異常に高くしている原因になっているのです。その原因は以下の３つだと考えています。
- ベンダの見積りにおける過重なバッファ
- 開発と運用で別の業者を利用している
- 最大時を想定したハードウェアの購入
摩擦係数の最大の原因は「見積り時の過重なバッファ」にあります。SIerのマネージャを経験するとわかりますが、自分がマネジメントするプロジェクトにおいて、自分が課せられた売上と利益を上げるためにコントロールできる要素は限られています。
ソフトウェアのような何が正解かわからない、目に見えないものの完成責任を負わされた時、リスクに対処するためにバッファを積んでしまうものですし、そのこと自体はプロジェクトマネジメントの世界では当たり前の処置の一つです。
そこまでは良いとして、マネージャはチーム毎に組織を作れば、それぞれのチームの長に見積りを依頼するのです。チームの長は自分の責任を守る為にバッファを積みますし、さらにプログラマに見積を依頼すると、彼らも当然バッファを積みます。
もうお分かりかと思いますが、それぞれの段階ごとにバッファを積んでいくので、本来価値よりもバッファの方が大きくなってしまうのです。まだ１社でやる場合はマシですが、外注という形にすると顕著に現れます。
一次受けしたマネージャ自身が見積りが出来れば、バッファもそこだけで済むのですが、実際に開発をする技術者まで聞かないと見積りが出来ないことに問題があります。しかし現実問題として、マネージャでは見積りは出来ません。
結果として、システム開発は本来価値よりも高い見積りになってしまうし、小規模に分割して見積りをした方が割高になる理由もわかると思います。これは、完成リスクも丸投げしようとするユーザ企業にも問題があるかもしれません。
次に「開発と運用で別の業者を利用している」という点です。システムの発注をアウトソーシングした後で、納品されたシステムは自社で運用する、もしくは安価な業者を利用して運用してもらうということが普通に行われています。
これは一度、システムは完成した後、改修は殆ど行われないという想定だからですが、そうしたい原因には、前述の高すぎる見積りがあります。つまり、開発そのものが見積りバッファによって高価になりすぎるので、せめて運用は安く、ということです。
しかし、運用だけを請け負うのだとしたら、他人の作ったものをメンテナンスするとなると、そのためにはしっかりした設計資料が必要になります。そうなると、最初の開発時にしっかりしたドキュメントを要求するのもわかります。嫌な流れです。
また、開発だけを請け負う業者としては、当然プロフェッショナルとしてメンテナンスしやすい設計や実装を心がけるとは思いますが、もしもプロジェクトが赤字になりかけたとしたら、まずは納品することを最優先してしまうかもしれません。
発注側の企業が、プログラムコードなどの保守性といったテストで見れない内的品質を検収時にチェックすることが出来れば、作り直しを要求することも出来るかもしれませんが、だいたいの企業ではテストを通すことを重視しています。
メンテナンスしにくいソフトウェアが出来上がってしまい、かつ、自分たちで開発したものでなければ、少しの改修をするにしてもどれだけの影響範囲があるか見えないので、キャプション一つ直すのにも、高い金額が発生してしまうのです。
そして、最後の「最大時を想定したハードウェアの購入」ですが、これまでのシステム開発だとインフラ設計や非機能要件というのが大事で、ハードウェアの見積りをしっかりする訳ですが、そこにも高価になる原因がありました。
どれくらいの人数が利用するのか、どれくらいのアクセス頻度なのか、停止して良い時間はどれくらいなのか、そういった利用する機能とは直交する要件を非機能要件と呼び、それに応じて、ハードウェアの見積りをする訳です。
そして、だいたいのケースにおいては、最大の利用シーンを想定した上でハードウェアを購入します。何故なら、ハードウェアを買ってしまうと、途中での変更は費用的にも容易ではないからです。なるべく効率を考えて、一番良いのを買おうとします。
しかし、本当にそこまでの利用想定までいくかというと不明だったりしますし、BtoC向けだと捕らぬ狸の皮算用になりかねません。何よりコンピュータの世界では有名な「ムーアの法則」というのがあります。時間とともにハードは安くなるのです。
一括で大きなシステムを一度に作ろうとしてしまう流れにのってしまうと、ハードウェアも高価で大きなものを一度に購入した方が安いかもしれない、という気持ちになってしまうのかもしれません。そして、長い期間をかけて償却するしかなくなります。
長くなったので、もう一度「システム開発が高くなる３つの理由」を列挙します。
- ベンダの見積りにおける過重なバッファ
- 開発と運用で別の業者を利用している
- 最大時を想定したハードウェアの購入
これらは、ベンダだけが悪い訳でも発注側のユーザ企業がだけが悪い訳でもなく、今の業界の構造が抱える問題と言えます。ソフトウェアも未来も目に見えないものであり不確実なものであるのに対し、事前に固めようというベクトルがもたらした結果です。
私も、以前に大手のSIerでマネージャをやっていた頃は、当時の金額が当たり前だと思っていたんですが、今考えると、やっぱりちょっと感覚がおかしかったかな、と思います。自分たちの価値をおとしめる訳でなく、本来価値にあった金額にすべきと考えます。
今回は問題提起だけを行いました。私は、この昔ながらの習慣そのものを疑問視し、新しいビジネスモデルがないものか模索してきました。そして今は「納品しない」という提供スタイルによって、低価格でも高品質なものを提供できるのではないか、という仮説をもっています。その紹介はまた別の機会に。
あわせて読みたい：ディフェンシブな開発 ～ SIビジネスの致命的欠陥
