前回、従来のようなやり方ではビジネス要求を受け取れないという指摘をした。その時に提示した従来のやり方というのは、全部Howのことを言っている。システム開発の方法をどうするかという議論になってしまっている。スクラッチでコードを書くのか、それとも出来合いのものを持ってくのか、あるいはクラウド上にあるものを利用するのかといったHowである。

限界の打ち破りかたとして、他の画期的なHowを考えればいいじゃないかというアプローチもありそうだが、おそらく成功はおぼつかいないと思う。"悪いWhat"をいくら"良いHow"で作っても意味がないということである。実はWhatはHowに優先するといくら言ってもなかなか理解されない。

データを登録して、計算・編集して、そうして格納されたデータを検索して、帳票を出す仕組みがWhatだと思い込んでいる。その仕組みをいかに早く作るか、いかに少ないコードで書くのか、いかに少ない人数で作るのかがHowなのだが、これとて今の人月ビジネスからいくと良いHowを考えるインセンティブは弱いというヒドイ話になっている。

Howばかり追い込んでも限界なのだから、ここらで、Whatを考え直す時期にきているのではないだろうか。プロセス参照モデルを使って業務をプロセス展開していきますが、その結果としてかなり構造化されたプロセスに落とし込まれます。前にも言いましたが分解されたプロセスの多くは非定型業務です。もし定型業務が多かったらその会社はつぶれてしまいます。それでなくとも中国人がすぐに替わりを務めてくれます。

プロセス分解はあるところでできなくなります。プロセスはアクティビティの連なりですから、そのアクティビティの粒度に限界が来るということです。すなわち粒度を細かくすると定型になってしまいます。例えば、データ入力なんていうレベルまで持っていってしまうと定型化してしまうというパラドックスが生じてしまいます。従来のシステムはここの定型的なアクションを単発で行うための仕組みだったのです。

ですから、定型的にならない程度の粒度で止めて、そのレベルでシステム化することを考えるというのが非定型業務のIT化のミソです。せっかく、ビジネス要求を抽出してそれを実現すべくプロセス分析・設計を繰り返してきて、さてシステム化の段になって、ビジネス要求が埋め込まれていない定型的なアクションレベルの粒度のIT化しかできなかったら何も意味もなくなります。

繰り返しますが、"WhatはHowに優先する"ということが非常に大事です。ビジネス要求を受けるWhatとは何か、効率的なオペレーションかできるWhatとは何かという見方が必要なのです。もうそろそろ30年間変わらない構造・機能の業務システムから脱却しようではありませんか。
 

No TrackBacks

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

Leave a comment

About this Entry

This page contains a single entry by Masanori Wada published on February 28, 2012 9:34 AM.

T再考-組み合わせで効果を出す was the previous entry in this blog.

IT再考-もうひとつの組み合わせ is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Pages

Powered by Movable Type 4.34-en