「JavaとWebサービスは夢で終わる」 (2003年5月19日)

 2003年4月、「鉄腕アトム」は誕生しなかった。ソニーやホンダの二足歩行ロボットは大きな進歩だが、人の心を持ったロボットは実現していない。同様に、制御系など機械に近い分野では比較的容易にシステム構築できるが、人の営みに近いビジネス系分野は、システム設計ミスが発生し易く、完璧なシステムを構築することは「絶対に無理」なことを前提とすべきである。

■Javaが目指すもの

 Javaは、1995年5月に発表されたWebシステム用のオブジェクト指向言語である。
 Javaのメリットとしては、当初、以下の3つがあると言われていた。
 一つは、オブジェクト指向を活かしてのコンポーネントウェアによる「ソフトウェア部品の再利用」、二つ目は、JavaVM(仮想マシン)を間にはさむことによって実現する「クロスプラットフォーム性」、そして、三つ目が、クライアントサーバー型の問題点であったプログラムの入換えを容易にし、Javaアプレットの最大のメリットでもあり、サーブレットでも違う形で実現できた「プログラムの再配布」である。
 二つ目の「クロスプラットフォーム性」の確保は、今でも大きなメリットと考えている。基本ソフトとアプリケーションの間のソフトウェアがそれぞれの違いを吸収して、大型コンピュータからパソコンや家電製品に組込まれたコンピュータまで、同じソースコードで書かれたプログラムが稼働することなのである。ただ、現在はその基本ソフトごとの違いに十分な対応はできていない。
 そして、三つ目の「プログラムの再配布」についても、大規模なシステムになればなるほど、システムの更新の際に、一々利用者のコンピュータのハードディスクの中に入っているソフトウェアを、全て一気に載せ換えるのは大変な作業となる。したがって、Webコンピューティングがブラウザという一つのソフトウェアをベースとして、利用ソフトウェアの更新を吸収してくれる仕組みは素晴らしいし、Javaだけのメリットではない。この当時の中心的な仕組みであったクライアントサーバー型が、利用するシステムをクライアント側に置いており、この更新作業に大変な労力を割いていたことに対する優位性の強調だったはずである。
 今でも、大企業ではたくさんのWindowsクライアントを均一化していくには、大変な労力とタイミングを見計らう必要があり、その運用費用の増大を回避するために、Webシステムへ移行しようとしている。

■ソフトウェア部品の再利用は永遠の課題

 問題となるのは、一つ目の「ソフトウェア部品の再利用」であり、最近のJavaの傾向が、EJBやコンポーネントウェアなど、このことばかりに集中している様に見えるからである。
 ソフトウェアの部品化については、1960年代後半、故ダイクストラ(昨年8月に亡くなられたとのこと)の「構造化プログラミング」から始まり、筆者の世代にはモジュール化の動きが活発化して、一つの入口と一つの出口、一つの機能をモジュールとして部品化することが重要となった。その進化の結果が「オブジェクト指向言語」である。
 オープンソース・ソフトウェアの中心であるC言語についても、登場した時のキャッチフレーズは、モジュール化言語「C」であった。
 C言語によるソフトウェア部品化は、ハードウェアに近いレイアにおいては、大きな成果をもたらし成功していると思う。
 しかし、ビジネス系のシステムでは成功していない。
 我々がC言語を用いて業務処理システムの構築をした時も、このモジュール化を進め、再利用を心掛けたが、ビジネス系の処理は、実に複雑である。世の中の様々な状況をソフトウェア部品として、開発プロジェクト全員に徹底させなければならない。再利用しようとするビジネス向けソフトウェア部品は、次のシステムでは更に修正修正を繰り返し、意味を持たなくなっていった。
 この問題は、現在のJavaでも解決されていない。
 いつの時代も、「そんなことはない、ソフトウェア部品化による再利用は実現できる」という人がいる。よく話を聞いてみると、制御系やエンジニアリング系であったりすることが多い。
 もともと「構造化プログラミング」の概念は、プログラムを「シンプル」にして維持管理をし易くすることが「目的」であり、部品化することはその「手段」だと考えている。
 現在のJavaは、複雑になり過ぎている。
 このあたりで原点に戻り、「シンプル」さの追求などに立ち返ってはどうだろう。他の優れたメリットもあるのだから。

■XMLでの誇張が致命的

 Webサービスが、Javaのソフトウェア部品化に拍車をかけることになる。
 XMLは、データに普遍的なタグを付け意味を持たせることの試みであり、JavaをWebサービスの世界へと導いた。
 Webサービスは、もともとマイクロソフトの「.NET」での提案であったが、IBMやサンマイクロシステムズも反応し、Javaも同様の方向へ動くこととなった。
 筆者のJavaに対する興味が失せていったのは、ほぼこの時期であった。アプレットとしてVisualBasicに匹敵するクライアント品質を維持していたのに、問題であったパフォーマンスの向上を図る道も、よりクロスプラットフォーム性を追求し様々な基本ソフトの上での稼働を保証していく道も、どこかへ行ってしまったからである。
 XMLが出現したころ、データの普遍的な意味づけを実現するナレッジマネジメントが注目を浴びた。
 この普遍化に大きな誤りがある。前述のソフトウェア部品化も同様であるが、人が行う処理やデータを、普遍的に意味づけることや適切な名前づけをすることはできないのである。
 ここに一つの書類があるとする。これをどの分野として整理するか?
 一人一人まったく違う分野に区分してしまうはずである。だから他人が作ったプログラムを理解するのに時間が掛かるし、自分では考えもつかないことに感動したりもする。
 また、同じ人間であっても、時とともに変化する。去年の自分と今年の自分では、この書類の区分は多分違ってくるだろう。自分の環境も変化しているし、何よりも自分も進化しているからだ。
 何年か前に、野口悠紀男著『「超」整理法』という本が大ヒットしたのを覚えている読者も多いと思う。この本でのポイントは、時間軸だけを基準に一つのファイルに整理することだった。様々な分野に分けてファイルを作ると、自分自身ですら探すことができなくなるからだ。
 このように、XMLやJava部品を他人(同一社内であっても)とシェアしながら、しかもビジネス系システムで実現することなどできる訳がないのだ。

 Webサービスは、Webにおけるシステム基盤の考え方の整理としては、それなりに意味はあるかも知れない。しかし、一つのキーワードをネットワークに伝えることで、インターネットの様々な処理システムの中から適切な処理同士を結びつけて、回答を導き出していくようなことは、レイアの高い「人の営み」に近いビジネスの世界では実現しない。

 Javaでのシステム開発に、そしてシステムの維持運営に苦慮しているユーザー企業が増加してきていることは事実である。
 もっと「シンプル」な仕組みが、必要となっていることは間違いない。

「オープンソース・ビジネスは第2世代へ」 (2003年5月6日)

 オープンソース・ビジネス第2世代の方向性は、ブラックボックスの排除とオープンソース・ソフトウェアによる簡易なシステム構築手法の提供、強固なシステム運営体制の準備となる。

■ 業務処理システムまで突き進む

 これからのオープンソース・ビジネスは、Linuxだけではなく業務処理システム全体を如何に構築し運用するかに注目すべきである。
 未だに、RedHatLinuxかUnitedLinuxかなどの議論をしたがる人や技術的問題を口にする人が多いが、既に米国を中心に、現実としてUNIXやメインフレームのリプレースが急速に進展し、情報化投資は削減されているのである。今なすべきことは、Linuxを如何に大規模システムで使える様に改造調査を実施するかではなく、実際に使ってみて運用の仕組みを明確化することである。

 もう一つのブラックボックスによる情報漏洩リスクについては、米国オレゴン州やカリフォルニア州の様に、オープンソースでないブラックボックスのソフトウェアを一切州の情報システムから締め出す方向に進むことは間違いない。国や自治体だけでなく、一般企業においても同様に情報漏洩への対応は必須であることから、ブラックボックスの排除とオープンソースの採用はますます勢いを増すことになる。

 そこで、見落とされがちなのが、業務処理システムをどう構築するかと言う基本的な問題である。 Webによる業務処理システム構築の基盤技術については、欧米では「LAMP(ランプ)」というキーワードがある。すべてのレイアにオープンソース技術を用いるもののことで、Linux(OS)、Apache(Web)、MySQL(DB)、PHP(Script)の頭文字を並べたものである。Linuxだけではシステム構築はできない。社内Webシステムとしてのイントラネット構築の基盤は、この「LAMP」技術の習得や充実を図っていくことで実現できる。
 日本の場合は、データベースにPostgreSQLが使用されることが多く、「LAPP(ラップップ)」となり、既に、これらの技術をベースとしたWeb業務処理システムの構築事例が出始めている。

■ 経済不況こそがビジネスチャンス

 これまでも情報システムにおける革命的変化は、経済環境が良くない時に起きている。前述した様に、パソコンとLANによる情報システム革命を引き起こしたEUCとダウンサイジングも然りである。
 1990年ころのバブル崩壊では、NetWareによるパソコンLAN旋風が吹き荒れた。NetWareはネットワークOSとしての位置付けだが、当初、NetWareを販売するノベル社がハードウェア・ベンダーであったことは、あまり知られていない。しかも、インテルのCPUではなくモトローラの68000系のCPUに、NetWareOSを搭載してNetWareサーバーとして販売していた。このころのNetWareの主たる機能は、ファイル共有やプリンタ共有であり、ローカルなハードディスクからファイルを読み込むよりも、NetWareのファイルサーバーから読み込んだ方が早いなどを、売り物にしていたのを覚えている。
 我々が初めてこのNetWareを使って業務処理システムを構築したのは、1987年、当時新金融商品として話題を集めていた変額保険のシステム化を、某外資系生命保険会社向けに開発したものである。しかし、この時は、時期が早過ぎたこともあり、特にパソコンLAN用のデータベースの安定性が十分ではなかったため、大きく納期を遅らせることになってしまった。業務処理システムをパソコンLANで構築する環境が不十分だったと言える。
 その後、Btrieveというデータベース(Btree型)の出現は、パソコンLANによる業務システム構築においては、非常に大きな進歩となった。更に、dbMagicなどの4GL(第4世代言語と言われたシステム構築簡易言語)の定着化で、様々なユーザー・アプリケーション分野向けの技術が業務処理システムの発展に寄与していった。米国においては、今でもNetWareのシェアがある程度残っているのは、この業務処理アプリケーション形態の膨大な普及の結果に他ならない。

 今はまさにバブル後最悪の経済環境であり、何かによる革命的変化が起こり易い状況なのである。
 オープンソース・ビジネス第2世代においては、当初のLinux技術中心ではなく、たくさんの情報システムで利用されていくために、オープンソースのデータベースなどを含む「LAMP/LAPP」で、Webシステム構築を簡易に行える技術追求の時代となっていくのである。
 これを、コンポーネントウェア化で目茶苦茶になったJavaやブラックボックスを引きずる.NETで行うというのか?
 この辺りの議論は、次回に展開したい。

■ そして産業構造が変わる

 最近の大手SI企業では、政府のオープンソース採用検討に合わせて、明らかに国家予算狙いと思える様なLinux参入表明をするところ(殆どが表面的にではあるが)が増えてきている。冷静に考えると判ることだが、これまでメインフレームやUNIXでシステムを納入していたSI企業が、本気でLinuxによるリプレースに動くであろうか? 一つの案件の受注金額を半分にしたら、昨年と同じ売上を確保するには、2倍の案件をこなさなければならない。したがって、表面的にはLinuxやオープンソースを提案すると発表したもののどうしても腰が引けてしまうのが現実である。
 米国での同様の事例は、サンマイクロシステムズのSolarisの失速とLinuxへのやむを得ない参入に見ることができる。

 既得権益を持つ大手情報処理業界の企業にとっては、オープンソースによる情報化投資削減が進行することは大変な問題である。したがって、ユーザー企業がオープンソースを導入したいと言っても、当面は信頼性が低いとの理由で、今の仕組みの維持に動くことになる。米国ではエンタープライズLinuxとLAMPによりオープンソース活用は一般化しているにもかかわらず。
 ユーザー企業にしてみれば、これまでの大きな情報化投資を少しでも削減したいところなのに、従来のシステム業者では十分な対応ができず、新たなパートナーを探すことになり、この様なチャレンジの結果の成功事例がトリガーとなって、一気にオープンソース・ビジネスの時代に突入していくであろう。
 オープンソースによる業務処理システムの「構築」と「運用」の準備が整った時、情報処理産業の仕組みが変わる。金融業界や建設業界が肥大化して行き詰まった様に、情報処理業界も明らかにバブルである。今までの安閑とした既得権益者たちは事業崩壊を招くことになるだろう。
 ただし、オープンソースの最大の特徴はソースコードの公開が、誰にも平等にあることなのである。現在の既得権益を持つ大企業も、地方の小さなソフトハウスも、コンピュータ普及初期に大活躍した企業も、新規に事業参入する企業も、まったく同じスタートラインに立つことが保証されている。そこから、新しい情報処理産業の再構築が始まる。
 これがオープンソース・ビジネス第2世代の到達すべき姿なのである。

Pin It on Pinterest