KAI_REPORT

導入（２）

２番目の内在する問題、「ユーザーの無知の問題」について。

アプリケーションプログラムで実現される機能は、現場の担当者の頭の中にあって、今後想定される「ルール」の範囲の中にあります。当然の話しですが、想定されない「ルール」が実現されることはありません。

例えば、今まで卸しか行ってこなかった企業が、インターネットによる通信販売に進出することがあります。卸販売におけるさまざまな「ルール」を、そのまま通信販売に適用できないのは、誰が考えても明かです。そこで卸販売用のシステムに加えて、通信販売用のシステムが必要となって、ここで、通信販売の業務担当者は様々なトラブルに遭遇することになります。

一から開発するか、通販用のパッケージソフトをカスタマイズするか、あるいは卸販売用システムを改修して通販機能を追加するか、いずれの方法にせよ、商品の在庫管理は卸、通販共通で行う必要があります。

そうなると、パッケージでは対応できないと言うことが分かります。なぜなら、在庫のデータベースを共有化できませんから、結果的に、在庫情報のバッチ交換しか実現できず、全社の商品の在庫状況をリアルタイムに把握できなくなります。今時リアルタイムを実現できないシステムは使い物になりません。

残る方法、一から開発するか、既存システムの改造かになります。まず一から開発する場合、卸機能を含んで、通販機能を開発する必要があり、これでは通販業務開始に間に合うわけがありません。後は、既存システムの改造ですが、今更レガシーシステムに新機能を追加するわけにも行かないので、オープンプラットフォームへマイグレーションの上、別コンポーネントとして通販機能を実現すると言うのが現実解となります。

しかしこれも、本番稼働に最低10ヶ月は必要となって、通販開始にとても間に合いません。しばらくの間は、暫定システム、ツールを使用した二度入力、三度入力の修羅場を味わうことになります。

しかしながら、これがベストの選択だったのでしょうか。もっと方法はなかったのでしょうか。

ここで、卸販売用システムの開発当時に時代を戻します。

経営者は当然がごとく言います。

「当社は卸専業であり、小売は一切行わない。」

この時点で、システム担当者の頭から、小売に関わる「ルール」が一切消えてなくなるのは当然と言えば当然です。が、果たしてそれでよかったのでしょうか。

「当社は卸専業であり、小売は一切行わない。」と言う言葉の妥当性はさておき、これから開発するシステムで実現する「ルール」から小売に関する「ルール」を排除、あるいは、検討しないと言うのは正しい選択だったのでしょうか。

つまり、もしこの時点で、卸業務の「ルール」にとらわれず、小売を含む販売業務全般の「ルール」をシステムとして実現していたら、上記のような塗炭の苦しみを味わうこともなかったはずではないかと考えるのです。

これに対して「それは無理です」との反論が予想されます。「小売機能まで入れ込んで開発すれば、開発費がとても予算内に収まりません」と。もっともな意見です。

ところがこれは大きな誤解であり、これこそが「ユーザーの無知の問題」であるのです。

ユーザーの無知とは

卸業務に例えば50の業務機能があるとします。小売業務にも50の業務機能があるとすれば、この二つを足すと、

■＜業務機能＞50＋＜業務機能＞50＝＜業務機能＞100

一見このような式が成り立つように思えます。

しかし実際は、

■＜業務機能＞50＋＜業務機能＞50＝＜業務機能＞65

となるのです。考えれば当たり前ですが、冒頭の例でも述べた通り、在庫管理など共通の業務機能が大半であって、二つの業務の「ルール」の詳細である業務機能を足し合わせても、増えるのは一部の業務機能にすぎません。上記システム開発当時、50が65になる程度であることが最初から理解できていれば、まったく違ったシステムの開発を目指すことになったかも知れません。

なぜこう言った勘違い、誤解が生じるのかと言うと、ユーザーの卸業務担当者が、小売業務の「ルール」の知識を持ち合わせていないからです。知識がないから、卸業務と同じ程度の50と見積もるしかありません。これがユーザーの、自分たちが所属する業界以外の業務への無知です。

更に、同じ業界でも、知っているつもりの他社の業務「ルール」に対する無知もあります。同じ業界の競争相手でもある他社には、競争優位となる「ルール」ほど公開しないものです。ユーザーは、現場でやっている自分たちが、一番業務のことが分かっていると思いがちです。実際は限られた範囲の「ルール」しか理解できていないと考えているユーザーはまれです。

それでは、この「無知の壁」は、どうやれば乗り越えられるのでしょうか。以下次回です。　KAI