Essence is Real

11月6日（月）の日経産業新聞に、”「悪役」P2P-動画で見直し”という記事がありました。”ナップスター”や”Winny”のために著作権問題やウィルスの温床としての評判の悪さが知られていましたが、P2Pは、従来から注目されているように新しいビジネスモデルとしても、技術上の選択肢としても非常に重要な視点であると言えます。

日経産業の記事では、従来、サーバから一律コンテンツを送信しているのに比べてP2Pを利用すると通信量が減ることになり、100万人向けに配信するのに、4億5千万円の通信費用がかかるのに、P2Pでは5分の1から10分の1にコストを軽減でき、アクセスの集中による動画が見られないということも解消されるということです。

このブログはミドルウェアについて徒然に公開しているので、P2Pそのものの議論ではないのですが…EAIの流れを汲む、ESBは、インハウスのインテグレーションの問題に対応するものであると暗黙に認識されていますが、Webサービスは、インターネット上でIPの上位に搭載されるミドルウェアの層のプラットフォームと考えることができます。Web2.0でもプラットフォームという言葉が出てくるようにインターネット上に高度に抽象化されたプラットフォームが出現するはずです。

Webサービスについては、様々な仕様がOASISで議論されていますが、製品としてはESBによって体系化されます。つまり、OSASISの仕様が決まっていようが、未定であろうが、ESBはプラットフォームとして機能を提供しなければなりません。つまり、インターネット上に新しいプラットフォームはESBが担わなければならないことになると考えられます。

しかし、一般のインターネット上には、インハウスでのアーキテクチャをそのままインプリすることはできません。つまり、インターネット上に全体最適を目指すようなハブ＆スポークのアーキテクチャを実現することはナンセンスです。あるいは、インターネット中にメッセージングのためのブローカを配置することもとても得策とはいえません。つまり、インターネット上には、P2Pのアーキテクチャを配置することが、合理的だということです。

P2PによるESBはエンドポイントにESBの機能を集約している必要があります。また、PCをはじめとするインターネットに接続するすべてのデバイスがエンドポイントとして扱える必要があります。これによって、インターネット上のESBが実現できると考えます。このときには、ESBは、バスではなくネットワークでなければならないわけですからISN（Internet Service Network）という名前がいいかもしれません。Artixは、その可能性を持っていると思います。

江川

日経コンピュータが創刊25周年となったそうです。私の業界年齢も27歳（これからこの歳を言うことにしましょうか）なので、日経コンピュータとともにあったかもしれません。実際には、最初の5年くらいは読み続けていました。この日経コンピュータの25周年記念のセミナーが「ITがもたらすビジネス・イノベーション」と称して行われました。基調講演は、大前研一さんで、お話しのポイントのひとつは右脳でした。大前さんのお話しの背景は、最近、翻訳されたダニエル・ピンクの「ハイコンセプト」という本で、実際は、この本の宣伝もかねていたようです。

MBA取得するようなロジカルな人は左脳を酷使してきましたが、ロジカルな思考は、部分的とは言え、コンピュータに置き換えることができます。あるいは、ロジカルな思考をベースにしたサービスで、定型的であったり、複雑ではない場合は、世界のフラット化によってBRICsにとって代わられるというのが、先進国の懸念です。そこで、「ハイコンセプト」で言われているのが、直感、デザインのセンス、従来と違う発想などの右脳によるアプトプットの新しい価値が普遍的なものとして築かれてきているということです。

確かに、最近は、優秀なロジックを持ってしても、すぐ先のビジネスの結果を予想することが難しくなっています。「予想できない世の中」とか言われますが、このようなときには、直感による判断が不可欠であす。実際に、なんらかの決断をする際にも熟慮の末に直感で決めることも多いかと思います。また、同様に、難しいことを理解する上でも、直感が必要であると言っています。「ハイコンセプト」では、”物語”によって物事を理解したり、覚えていたりすることが有効であると指摘しています。実際に、イソップ物語やギリシャ神話、日本昔話でも、物語にすることで物事の本質を理解することが行われてきました。

やっと、SOAに結びつきますが、「ハイコンセプト」にしたがって、SOAやESBを理解する上で物語も有効なのではないかと考えて、物語”風”にシチュエーションを作ってみました。これで、なにを理解していただけるかは、自信はないですが、今後、もっと、直感的に理解できる物語を考えていきたいと思います。

物語　-　いつもの風景

上司：BPRもできたし、BPMツールも導入したから私たちでもビジネス・プロセスを設計できるようになるんだよね。
部下：ええ。でも、そんなに今まで違わないように思うのですが？

上司：なんだ、すべてのタスクに人が介在しなければならないのか？これでは効率化にならないではないか！
部下：タスクが自動的に既存のアプリケーションと連携してプロセスを進めないといけないんです。

上司：何で連携の仕方がバラバラなんだ。それに、まだ、コストのかかるEAIなんかを使っているのだ？
部下：部門毎にシステムの設計が違うのです。
上司：違うのはいいとしても、安く早く確実に連携できるのか？
部下：だぶん、ベンダに聞いてみないとわからないのではないでしょうか。

上司：いちいちシステム毎に検討会議が必要のか？いつになったらできるんだ？
部下：まだ、見積もりが出ていないですから予算内にできるかどうかもわかりません。
上司：なんだ、この見積もりは、既存のアプリケーションを呼び出すだけで1億もかかるのか？
部下：いままでと変わりませんが…

部下：SOAを導入しましょう。
上司：えっ！まだ、検討中じゃないか？全体最適化はまだできないぞ。
部下：製品によっては安くスモールスタートができるんです。しかも、そのまま全体へ拡張できます。
上司：確かにビジネス・プロセスを自動するためには部門を超えた共通の連携の仕組みがないとBPMなんぞはやってられないな！
部下：その前にアプリケーションを抽出してラッピングしてサービス化する必要があります。
上司：そうだな。SOA導入に向けて統一した検討と運用の体制を作ろう。
部下：それと、まだ、人が判断しなければならない問題が多くあるのですが、ルール化を考えたいのですが？
上司：サービス化にルール化か!？

上司：SOAの小さいのができたじゃないか。
部下：しかも、既存のミドルウェアの資産を活かして新しい技術で連携できるので、余計なミドルウェアを導入しなくて済むんです。
上司：BPMにビジネス・ルールの判断のできる仕組みを埋め込んだのか？
部下：いままで人が判断していた商品の提案をBRMSで自動的に決定できます。ルールはサービスとしても作れますのでBPM以外からも利用できます。
上司：そうか。ということはSOAを考える上では、ビジネス・ルールのシステム化も同時に進められるのだな。

ちょっと、やらせっぽいので、今後は改善します。

江川

今年の9月に「ユーザはITプロフェッショナルであるべきか」というベンダーのブログでは、書いてはいけないようなことを書きました。実際はヨーロッパのある企業のIT部門の構成を理解していただきたかったのですが、当然、ユーザがITのプロとはどういうことかと、違う見方もあると思います。

ITproの経営とIT新潮流2006というサイトの真髄を語るというコーナーの中でJTBのシステムを見られてきた佐藤正史 氏が「経営者がITを理解できない本当の理由」という文章を寄稿されています。氏のご経験が素直に表現されているいい文章です。

ITのROIがはっきりとした形で見えないために経営者が、ITに懐疑的になることは、経営者がITを理解していないということと違うというお話しから始まっています。その中で、ITベンダーのプロフェショナリズムに言及されています。ユーザが要件をきちんと定義できないのは、ユーザの問題ではあるけれども、プロジェクトマネージャやSEの中には、そんなユーザの要件をうまく引き出してくれる優秀な人がいる。実際に、そのような優秀な人がいる以上、ITベンダーの人間もユーザの問題として逃げずに、きちんと責任をとれることが必要であるということです。さらに、プロであるのに、十分なスキルを身に着けていないことも明らかであると厳しいお言葉でした。

確かにユーザはITベンダーの仕事にお金を払うし、ITベンダーは、ユーザからお金をいただける仕事をしなければなりません。優秀な人間が、そうそういるわけではないという言い訳も確かですが、プロである以上は、気持ちよくお金を払っていただけるようにすることは、基本的なことだと言えます。ベンダーが、こんなことを書くとベンダー側で問題になる可能性もなきにしもあらずですが、これは避けられないことです。

しかし、ユーザがITのプロでなくてもいいということではないと思います。たとえば、あるOSのバグでシステムが停止して、ビジネス上の損害が出たとするとユーザ側が、OSのバグの内容なんかは理解できないと避けてしまっては、問題は解決しないし、いつまで経っても同じことを繰り返すことになります。ユーザが理解できるようにベンダーが誘導することは絶対に必要ですが、ユーザが最初から諦めてしまったらそんな努力も意味はないのです。

ITシステムは、1ビット間違っただけで障害となります。そのことをユーザは理解しなければなりません。システムが、ハードウェア、OS、ミドルウェア、パッケージなどのあるアーキテクチャを基に構成されていることと、そのようなアーキテクチャの必要性は理解していただかないとシステムのライフサイクルを正しく回すことはできません。ミドルウェアはお金がかかるばかりで本当に必要かどうかわからないということではなく、必要性を理解していただきたいのです。

一般に自分でできることにお金は払いません。ユーザではできないこと、不可能なことにお金を払うのです。ベンダーが不可能なことを実現できなければユーザはお金を払いたいとは思わないのです。ユーザがITのプロとなればベンダーはそれ以上のスキルと経験によって、さらに高い価値を生み出さなければならないことになり、より厳しくなっていきます。常に学習しながら向上させていくためにもベンダーのプロフェッショナリズムは重要です。

江川

2年くらい前の米国のeWeekのサイトに「Move Over, EAI」という記事が、記載されています。Webサービスが広まることで、従来のEAIアダプタによってインテグレーションを行っていたのが、大きく変わるという内容です。記事の中で、主要なEAIベンダーのマネージャもWebサービスが台頭することを肯定していますが、2年経った、今現在、EAIのアダプタがすべてWebサービスに置き換わるという勢いとはいえないと思いますが…

パッケージベンダーはWebサービス化を進めているのは、もちろんですが、ユーザ側でも次のプロジェクトではWebサービスを使うと普通に考えられるようになっているので、EAIアダプタの適用にも変化が出て繰るのではないかと思います。アダプタと言っても、いくつか種類があります。テクノロジー・アダプタと呼ばれるトランスポートの違いをサポートするもの、アプリケーション・アダプタと呼ばれる、たとえば、ERPと連携するための特別なアダプタ、あるいは、データベースと連携するためのDBアダプタなどです。

このうちのテクノロジー・アダプタは確実にWebサービスに替わっていくものだと思いますが、そのときはESBということになっているかもしれません。アプリケーション・アダプタは、機能として、アプリケーションやデータベースのスキーマを意識したものとなるので、個別の追加機能として提供されるようになるのではないでしょうか。つまり、Webサービス（あるいは、ESB）を基盤として、その上にアプリケーション毎の連携機能が搭載されるというイメージです。

いままでアダプタを介して、異なる言葉が通訳されていたとするとWebサービス（あるいはESB)は、直接、ユーザ同士が直接コミュニケーションする共通言語のようなものとなるのではないでしょうか。ちょうど、英語のようなものです。豊かなコミュニケーションが、通訳を介するか、あるいは、直接話しをすることのどちらで得られるか？私は後者であるべきだと思います。

時として、通訳が必要となることはあるでしょうが、通訳の方はアプリケーションの本質は理解できなし、時間単位でコストがかかります。これは、特別な場合であると思うべきではないでしょうか。多少、勉強しなければならなくても、Webサービスというツールがある以上、カスタマイズを加えて、直接、連携することを考えてもいいのではないでしょうか？

江川

しばらくサボっていました。その後、プロジェクトに引き込まれてしまったので、未だに更新ができていません。CORBAの文化を引き継いだESBであるArtixがCeltixはエンドポイントにすべてを集約する考え方でエンドポイントを組み合わせることでESBを構成します。メディエーション（仲介機能）などのためにスマートブローカと称する軽量で柔軟な構成の組めるブローカも作ることができますが、Java EEなどを前提とせずにエンドポイントにESBの機能を集約していることは構成を組む上で非常に有利となります。エンドポイントESBのロゴを作ろうかと思ってスライドの中から取ってきたものです。

江川

ドラッガーの言葉です。BEA Japan Forum 2006の午前中のパネルで三菱東京UFJ銀行のCIOの根本氏が、お話の中で引用されていました。実は2004年にお話を伺っているのですが、そのときに比べてSOAの導入に対して、他に選択の余地はないというくらい積極的にお話になっておられ、かつ、背景や技術、想定できる結果までも実にクリアにお話になっておられたことが非常に印象的でした。

タイトルの言葉の意味は、文字通りですが、その基礎は、すべてが変化することは必然であるということです。しかも、変化が起きて、周知のことになってからでは遅すぎるということも含んでいます。自らが変化を作り出していくことで変化への対応を実現するという逆説的な意味もあるかもしれません。

ビジネスの変化ということはよく言われますが、テクノロジーの変化やアーキテクチャの変化についてはあまり真剣に話をされていることを聞いたことがありません。ビジネスの変化に対するSOAのソリューションを支えるテクノロジーも変化すると考えるべきです。これまでも新たなテクノロジーやソリューションが出現すると古いテクノロジーは捨てられて、システムの再構築となっていました。

しかし、新しいテクノロジーに乗り換えるために、たとえば、5年に1回、ガラガラ、ポンでアプリケーションからシステム基盤を入れ替えていたなら大変な浪費といえます。つまり、テクノロジーの変化に対しては、特定のテクノロジーに依存しない”テクノロジーに中立”なフレームワークが必要となります。

一方、アーキテクチャの変化については、アーキテクチャが変化してしまっては、その上に乗るアプリケーションは対応できないのではないかという懸念があります。つまり、あるアプリケーションはあるアーキテクチャに依存しているということになりますが、すべてが変化することからアーキテクチャも変化することを前提とすべきです。

エンドポイントにESBの機能を集約し、分散アーキテクチャで仮想のバスを構成するArtixは、エンドポイントを組み合わせることでアーキテクチャを柔軟に変化させることができます。エンドポイントでESBの機能が完結することで自由にエンドポイントの構成と新しいアーキテクチャへの移行をサポートすことができます。つまり、分散アーキテクチャは、アーキテクチャを変化させることができる唯一のアーキテクチャであると思います。

江川