前回、いまの業務システムがビジネスの変化に追随できていないということを指摘した。そこでもう少し具体的に問題点を探ってみましょう。大きくつぎのような分類をしてみました。

１） 構造上の問題
２） 技術上の問題
３） 制度・慣習上の問題

まずは、構造的な問題について考えてみます。いろいろな領域でその構造の問題点が浮かび上がってきます。

（１）システムのつくりの問題（システム構造）
（２）ユーザとベンダー間の問題（業界構造）
（３）組織と個人の問題（人材構造）

システムそのものの構造については、前にも触れたように変化対応力に乏しい硬直的な構造になっています。それは、手組み開発であれ、パッケージ開発であれ、プログラムに機能が埋め込まれた構造になっていて、手組みだとそこにプログラムを継ぎ足し、スパゲッティ状態を作りだしています。

パッケージの場合はそうではなくモジュール単位になっているじゃないかと言われますが、結局、カスタマイズやアドオンという形でロックインされてしまいます。ですから、基本的にみな密結合で形成されているといえます。これが、柔軟性、すなわち変化対応力がない原因ではないでしょうか。

つぎに、ユーザとベンダーとの関係をみていきましょう。ユーザといっても直接現業部門ということもあり、IS部門が窓口という場合もあるでしょう。また、ベンダーといっても、SIerであったり、パッケージやソフトウエアベンダーであったり、単なる開発ソフトハウスだったりします。そのなかで一番悩ましい問題を抱えているのは、ユーザ企業のIS部門とSIerとの間の問題ではないでしょうか。

そして最大の問題は、「情報の非対称性によるインセンティブの歪み」から生じる利害の不一致です。どういうことかというと、ITに関する情報はたいていの場合SIerが多く持っています。ユーザはSIerがどんなことをしているの容易にはわからないし、自分たちの要求がどう実現されるかはできてみないとわからないという意味で情報不足の立場にあります。

この非対称性によってどうなるかは、コストや品質などについての合意形成の難しさとして表出してきます。しばしば、ここの争いでプロジェクトが紛糾することになります。

組織と個人の問題という点では、簡単に言うと、IS部門であれ、SIerであれ、自分のキャリアパスをどう描くが焦点になるでしょう。３K職場と揶揄されるように、ITSSのようなものがあったとしても、必ずしも実際の現場レベルにはきちんとした人材育成ロードマップやロールモデルがあるとは言えないのではないでしょうか。

ついで技術問題をみていきます。これは何回も言っていますが、簡単にいうとつぎの開発のジレンマのことになります。

（１）アプリケーション仕様のほとんどが、結局、ユーザの恣意でしか決まらないこと　　
仕様を決定付ける科学的、工学的なモデルが存在しないということ
（２）実業務の様々な例外をコンピュータ上に乗せるか否か
情報システムと人間の境界が、元来不安定であること
　　
こうしたジレンマを抱えながら技術者は日々苦闘しているのではないでしょうか。このジレンマから解いてあげることを真剣に考えないといけません。

最後の制度や慣習みたいなものもあるがここではそれほど重要ではないということで取り上げないことにします。