ソフトウエアの生産性を上げるための取り組みの流れをもう一度考え直してみよう。標準化にしても、構造化にしても、オブジェクト指向にしても、すべてプログラムの再利用もしくはもう一歩進めて汎用的な部品化を行うための考え方だと言える。このためには、似て非なる処理に共通した部分と違う部分を徹底的に洗い出し、分離することや、必要に応じて、プログラムの構造を、それに適した形に変えてやることが必要になる。
ビジネスロジックの部分でも、それは同じだ。後者がＢＰＲならば、前者はビジネスロジックの汎用化である。幹と枝葉をきちんと分離できれば、多くのビジネスロジックは共通化できる。これまでパッケージではこの作業が行われてきた。それにより、ユーザのカスタマイズ要求に対して、変更が必要な部分を局所化して、カスタマイズ作業の負荷を減らすことを目指してきたわけだ。ただ、パッケージという、ある意味で閉鎖的な環境の中では、この共通化という作業はそれ以上の意味をもたない。だから、案外、この仕分け作業は中途半端に終わってしまい、時にはユーザの要望に応じるために、本来共通化されているはずのロジックにも手をつけざるを得なくなってしまう。だから、こうした作業そのものが無意味だという極論を言う人もいるわけだが、むしろ、パッケージという閉じた世界では、無意味というよりもそれを徹底的にやるだけのメリットが、ベンダにはないのだろう。カスタマイズの余地が多いほど、そのパッケージを使ってカスタマイズする仕事が増えるからだ。つまりは、パッケージを担いでくれるＳＩ会社の仕事を増やすことにつながり、そのパッケージが好んで提案される理由となる。ユーザにとって使い勝手をよくするカスタマイズが柔軟に可能である・・・という理由が表向きの話だが。
これはベンダ目線にほかならない。ユーザ側から見れば、工期や工数を削減する目的でパッケージを選んでいるはずなのに、実際は、カスタマイズに大きな費用がかかり、工期もどんどん長くなる。ユーザから見れば、こんな馬鹿げた話はない。おまけにビジネス環境はめまぐるしく変わるのだから、それになかなか追い付いていけないＩＴは常に経営陣の悩みの種になってしまう。ユーザから見れば、最初の段階でシステムのそれぞれに機能に選択肢があり、それを組み合わせると必要なシステムが出来上がるような、いわば、システムのＢＴＯ（Build To Order）モデルがあるといいわけだ。パソコンのＢＴＯは、ＣＰＵ，メモリ容量、ＨＤＤの容量、周辺機器など、様々な仕様をユーザが指定したとおりに組み立てるものだが、必要なパーツは規格化、標準化されていて、メーカーはそれを組み合わせて組み立てるだけである。（厳密にいえば、これはＣＴＯ（Configure To Order）とも言えるが、CTOは標準製品の一部だけを別仕様に変える、もしくは選択する・・という意味のほうが強いのではないかと思うので、パッケージのカスタマイズに近い） 要するに、システムのＢＴO化が望まれるわけだが、残念ながら、情報システムのパーツは業界レベルでは標準化されておらず、ユーザにとって自由に選択できる状況には程遠い。たとえば、各パッケージベンダが自社のパッケージの一部分を標準化したいと思っても、意外と敷居が高い。記述されている言語も違えば、使っているデータベースも違う。たとえば、ユーザがＡ社の営業系パッケージとＢ社のＥＲＰパッケージの会計部分を組み合わせてシステムを作りたいと思っても、単純にそれを張り合わせることは不可能だ。こうした違いを乗り越える、新しいアーキテクチャが必要だ。
違う言語やデータベースを使って作られた「機能」をうまく連携させて使うにはどうしたらいいのか。こうした違いを超えて、互いにその機能を「呼び出せる」ようにできればいいのだが。たとえば、ネットワーク上のサービスとしてその機能が定義されていて、その呼び出しのインターフェイスも通信手順として標準化されていたなら・・・。
私の目線から見たＳＯＡ（Service Oriented Architecture）とは、このようなものだ。
（続く）
コメントする