２００３年４月、「鉄腕アトム」は誕生しなかった。ソニーやホンダの二足歩行ロボットは大きな進歩だが、人の心を持ったロボットは実現していない。同様に、制御系など機械に近い分野では比較的容易にシステム構築できるが、人の営みに近いビジネス系分野は、システム設計ミスが発生し易く、完璧なシステムを構築することは「絶対に無理」なことを前提とすべきである。
■Ｊａｖａが目指すもの
Ｊａｖａは、１９９５年５月に発表されたＷｅｂシステム用のオブジェクト指向言語である。
Ｊａｖａのメリットとしては、当初、以下の３つがあると言われていた。
一つは、オブジェクト指向を活かしてのコンポーネントウェアによる「ソフトウェア部品の再利用」、二つ目は、ＪａｖａＶＭ（仮想マシン）を間にはさむことによって実現する「クロスプラットフォーム性」、そして、三つ目が、クライアントサーバー型の問題点であったプログラムの入換えを容易にし、Ｊａｖａアプレットの最大のメリットでもあり、サーブレットでも違う形で実現できた「プログラムの再配布」である。
二つ目の「クロスプラットフォーム性」の確保は、今でも大きなメリットと考えている。基本ソフトとアプリケーションの間のソフトウェアがそれぞれの違いを吸収して、大型コンピュータからパソコンや家電製品に組込まれたコンピュータまで、同じソースコードで書かれたプログラムが稼働することなのである。ただ、現在はその基本ソフトごとの違いに十分な対応はできていない。
そして、三つ目の「プログラムの再配布」についても、大規模なシステムになればなるほど、システムの更新の際に、一々利用者のコンピュータのハードディスクの中に入っているソフトウェアを、全て一気に載せ換えるのは大変な作業となる。したがって、Ｗｅｂコンピューティングがブラウザという一つのソフトウェアをベースとして、利用ソフトウェアの更新を吸収してくれる仕組みは素晴らしいし、Ｊａｖａだけのメリットではない。この当時の中心的な仕組みであったクライアントサーバー型が、利用するシステムをクライアント側に置いており、この更新作業に大変な労力を割いていたことに対する優位性の強調だったはずである。
今でも、大企業ではたくさんのWindowsクライアントを均一化していくには、大変な労力とタイミングを見計らう必要があり、その運用費用の増大を回避するために、Ｗｅｂシステムへ移行しようとしている。
■ソフトウェア部品の再利用は永遠の課題
問題となるのは、一つ目の「ソフトウェア部品の再利用」であり、最近のＪａｖａの傾向が、ＥＪＢやコンポーネントウェアなど、このことばかりに集中している様に見えるからである。
ソフトウェアの部品化については、1960年代後半、故ダイクストラ（昨年８月に亡くなられたとのこと）の「構造化プログラミング」から始まり、筆者の世代にはモジュール化の動きが活発化して、一つの入口と一つの出口、一つの機能をモジュールとして部品化することが重要となった。その進化の結果が「オブジェクト指向言語」である。
オープンソース・ソフトウェアの中心であるＣ言語についても、登場した時のキャッチフレーズは、モジュール化言語「Ｃ」であった。
Ｃ言語によるソフトウェア部品化は、ハードウェアに近いレイアにおいては、大きな成果をもたらし成功していると思う。
しかし、ビジネス系のシステムでは成功していない。
我々がＣ言語を用いて業務処理システムの構築をした時も、このモジュール化を進め、再利用を心掛けたが、ビジネス系の処理は、実に複雑である。世の中の様々な状況をソフトウェア部品として、開発プロジェクト全員に徹底させなければならない。再利用しようとするビジネス向けソフトウェア部品は、次のシステムでは更に修正修正を繰り返し、意味を持たなくなっていった。
この問題は、現在のＪａｖａでも解決されていない。
いつの時代も、「そんなことはない、ソフトウェア部品化による再利用は実現できる」という人がいる。よく話を聞いてみると、制御系やエンジニアリング系であったりすることが多い。
もともと「構造化プログラミング」の概念は、プログラムを「シンプル」にして維持管理をし易くすることが「目的」であり、部品化することはその「手段」だと考えている。
現在のＪａｖａは、複雑になり過ぎている。
このあたりで原点に戻り、「シンプル」さの追求などに立ち返ってはどうだろう。他の優れたメリットもあるのだから。
■ＸＭＬでの誇張が致命的
Ｗｅｂサービスが、Ｊａｖａのソフトウェア部品化に拍車をかけることになる。
ＸＭＬは、データに普遍的なタグを付け意味を持たせることの試みであり、ＪａｖａをＷｅｂサービスの世界へと導いた。
Ｗｅｂサービスは、もともとマイクロソフトの「．ＮＥＴ」での提案であったが、ＩＢＭやサンマイクロシステムズも反応し、Ｊａｖａも同様の方向へ動くこととなった。
筆者のＪａｖａに対する興味が失せていったのは、ほぼこの時期であった。アプレットとしてＶｉｓｕａｌＢａｓｉｃに匹敵するクライアント品質を維持していたのに、問題であったパフォーマンスの向上を図る道も、よりクロスプラットフォーム性を追求し様々な基本ソフトの上での稼働を保証していく道も、どこかへ行ってしまったからである。
ＸＭＬが出現したころ、データの普遍的な意味づけを実現するナレッジマネジメントが注目を浴びた。
この普遍化に大きな誤りがある。前述のソフトウェア部品化も同様であるが、人が行う処理やデータを、普遍的に意味づけることや適切な名前づけをすることはできないのである。
ここに一つの書類があるとする。これをどの分野として整理するか？
一人一人まったく違う分野に区分してしまうはずである。だから他人が作ったプログラムを理解するのに時間が掛かるし、自分では考えもつかないことに感動したりもする。
また、同じ人間であっても、時とともに変化する。去年の自分と今年の自分では、この書類の区分は多分違ってくるだろう。自分の環境も変化しているし、何よりも自分も進化しているからだ。
何年か前に、野口悠紀男著『「超」整理法』という本が大ヒットしたのを覚えている読者も多いと思う。この本でのポイントは、時間軸だけを基準に一つのファイルに整理することだった。様々な分野に分けてファイルを作ると、自分自身ですら探すことができなくなるからだ。
このように、ＸＭＬやＪａｖａ部品を他人（同一社内であっても）とシェアしながら、しかもビジネス系システムで実現することなどできる訳がないのだ。
Ｗｅｂサービスは、Ｗｅｂにおけるシステム基盤の考え方の整理としては、それなりに意味はあるかも知れない。しかし、一つのキーワードをネットワークに伝えることで、インターネットの様々な処理システムの中から適切な処理同士を結びつけて、回答を導き出していくようなことは、レイアの高い「人の営み」に近いビジネスの世界では実現しない。
Ｊａｖａでのシステム開発に、そしてシステムの維持運営に苦慮しているユーザー企業が増加してきていることは事実である。
もっと「シンプル」な仕組みが、必要となっていることは間違いない。