■    失敗しないシステム開発

業務システム開発の世界ではプロジェクトの失敗例がよく出てきます。お金がかかり過ぎて途中でやめてしまったとか、作ったはいいが使い物にならなかったとか、当初の予算が倍になってしまったとかいった事例を見聞きします。こうしたことはなぜ起きるのでしょうか。やってみないとうまくいくかどうかわからないプロジェクトなのでしょうか。

そんなギャンブルのようなプロジェクトも考えてみればおかしな話ですよね。その原因は、簡単に言えば何を作るのかが明確になっていないからではないでしょうか。それにも二つあって、仕様そのものが明確になっていない場合と、作る人と使う人の理解に相違があってそこで齟齬が生じるというケースです。作ったものが使う人が考えていたものと違ったなんていうことです。

ですから、そうした問題が起きないようにするには使う側から作るものを決めるようにすればよいのです。業務を回す、仕事を行うために必要なビジネスサービスをイメージしてそのとおりに作れば、少なくとも作ったはいいが使わないということはなくなります。さらにそれを自分たちの好きなように作れたなおさらいいですよね。

つまり、使うものだけ、役に立つものだけを作れば失敗はしません。それができなかったら作るのをやめればいいのです。そのとき、作るときに大きな費用がかかるとなると問題なのです。途中でやめるのはいいが、それまで結構な投資をしてしまうと、それをサンクコストとして見てしまい、無理やり続けて傷口を広げてしまうということも起こります。ですから、大事なのは安価な投資でできるやり方でなければなりません。

ERPなどのように統合化された大がかりシステムはその可能性があるのですが、それに対する防御策は、固有性を排除して標準的なものにしておくことでしょう。固有的あるいは差別的な機能は外出しにしておくのです。それによって、仕様も標準のものであればでき上がりのイメージもつかめるので、できたはいいが使い物にならないということはないでしょう。そして、外出しにしたものは、個別に安価な開発費用でアダプティブに作ってつなげればよいのです。

ケースに応じて失敗しないようなやり方を採用していけば当然のように失敗しません。これから議論していくやり方は、そんな志向のものです。サービスという言い方をしているのは、ビジネスの役に立つ、使いこなせる、仕事がうまくいくためのサービスを選んで使うだけといったニュアンスだからです。

ちょっと、話はそれるかもしれませんが、サービスですから取り扱い説明書があればいいわけで、それも最初だけ必要でちょっと慣れればそれもいらなくなります。従来のようにドキュメントを作ってそれをメンテしてといった煩わしさは排除すべきです。サービス化とはそういうものでもあります。

結局、心構えとしてこれまでと違ってもっと気楽に使う人が、あるいは作る人が使う人と一緒になって、業務がやりやすい仕組みと仕掛けを組み上げるということではないでしょうか。そうすれば、失敗することもなく作ったらすぐに使えるようになるのです。

No TrackBacks

TrackBack URL: http://blog.wadit.jp/mt/mt-tb.cgi/71

Leave a comment