 |
[2005 年 4 月号] |
|
[2005 年 4 月号] |
［ＯＯエンジニアの輪！］
今回のゲストは、アクセンチュアの 小野沢 博文 さんです。ご専門である分散オブジェクト技術や Web サービスの話題を中心に、EA や MDA の標準化についてもお話を伺いました。
|
|
||||||||
-- 現在のお仕事について、教えていただけますか？
アクセンチュアには、去年の 6 月に入りました。先端技術グループという部署に所属していて、そこの仕事をやりながら、プロジェクトにも携わっています。先端技術グループでは、EA（エンタープライズ・アーキテクチャ） のリードをやっています。アクセンチュアの、EA の技術面での方針決めですとか、どういうプロモーションをやっていくのか、といったところを担当しています。
実際のプロジェクトでも、EA と無関係なところではなくて、現在は、官公庁さんの EA のプロジェクトに入って、そこのアーキテクチャを見ています。
アクセンチュアに入社する前は、かなり畑違いで、ミドルウェアのベンダーに長い間おりました。前職では、分散オブジェクトですとか、Web サービスなど、特定の技術分野の技術コンサルタントを、5 〜 6 年やってきました。
アクセンチュアに入ってからは、特定の技術分野の担当ではなくて、「何でも屋」ですね。具体的には、コンサルティングのマネージャーとして、実際のプロジェクトに入って、そのプロジェクトのアーキテクト的な仕事をしています。
-- EA と言うと、いくつかのレイヤーがあると思うんですが、やはりテクノロジー・アーキテクチャの部分を、ご担当されているのですか？
特にどのレイヤーということはないです。どちらかというとテクニカルな部分なんですけれども、実際にプロジェクトが始まると、何でもやります。（笑）
ビジネスレイヤーもタッチしますし、アプリケーション・アーキテクチャ、それからもちろんテクノロジー・アーキテクチャも、すべてやっています。
-- 小野沢さんが分散オブジェクトを始められたきっかけを教えていただけますか？
きっかけは、かれこれ 13 年位前、1992 〜 93 年のころになりますね。その当時私は、DEC*2 におりまして、研究開発センターに所属していました。そこで、TP（Transaction Process）の標準化ですとか、DCE（Distributed Computing Environment）の国際化ですとか、ローカリゼーションをやっていました。
そこで、Object Broker という製品のローカリゼーションに関わったことが、分散オブジェクトを始めたきっかけです。
それ以前は、あまりオブジェクト指向というのはやったことがなかったんですね、実は。ですから、オブジェクト指向を通り越して、いきなり分散オブジェクトに入ったという感じですね。
-- Web などで経歴を拝見させていただいたんですが、Object Broker 以降も、ずっと分散オブジェクトに関わっていらっしゃいますよね。やはり分散オブジェクトにご興味があったんですか？
ええ、そうですね。DEC でたまたま Object Broker をやったことがきっかけで、それ以降は分散オブジェクトにどっぷりとつかっています。
DEC を退社したあとも、分散オブジェクトの仕事をずっとやっていました。TCSI という比較的小さな会社で、TCSI 独自の分散オブジェクト技術を使って、テレコム向けのアプリケーションを開発していました。CORBA とほぼ同じようなことを、独自のフレームワークとミドルウェアで構築していたんです。別の会社に買収されてしまって、今はもうないんですが。
*2 Digital Equipment Corporation: 独自のアーキテクチャに基づくワークステーションやサーバ製品を展開していたコンピュータメーカーで、1998 年に Compaq Computer に吸収合併された。Compaq Computer は、2002 年に HP（Hewlett-Packard） に吸収合併されている。
-- 小野沢さんがオブジェクト指向に触れたきっかけは、分散オブジェクト技術を使ったフレームワークやミドルウェア製品を通じて、ということなんですね？
ええ。最初にオブジェクト指向に触れたのは、OO の開発方法論や学術的なところよりは、どちらかというと、ミドルウェアの実装から入っている、という部分が強いです。
-- 分散オブジェクトとオブジェクト指向は、非常に近い関係があると思うんですが、オブジェクト指向に対して、小野沢さんご自身はどうお考えですか？
私がオブジェクト指向に入ったのは、かなり最近になってからなんですけれども、自分としては、かなり自然に入っていけたと思います。
例えば、対象のものを、オブジェクトあるいはクラスとして認識して、何か操作を加える場合には、そのオブジェクトに対してメッセージを送って、あーしなさいこーしなさいと指図してやっていくわけですね。何か特別なものというよりは、非オブジェクト指向のプログラミングと比べて、むしろ自然な感じがしています。
-- やはり、CORBA に深く関わっていたことが、OO を自然に理解できたということと結びついているのでしょうか？
そうだと思います。
-- 分散オブジェクトや CORBA を、ずっと仕事として志向されてきた理由を教えていただけますか？
もともと通信のミドルウェアにすごく興味があったんですよ。DCE をやったのもその一つです。
その流れがやはり強かったと思います。ですので、オブジェクト指向の難しい方法論のようなものは、あとからだんだんと勉強してきたという感じですね。
実際にものが動くところ、例えば、あるコンピュータ上で動いているアプリケーションが、別のコンピュータ上のアプリケーションと実際に会話をして、処理を進めていくという、そういうところにすごく惹かれました。
-- やはり CORBA 製品は、通信の分野で強みを発揮しているんでしょうか？
ええ。その面で考えると、最初の CORBA の仕様は、私から見ると違和感がありました。CORBA1.1 の仕様のころは、通信プロトコルが何も決められていなくて、API も、どうとでも解釈できるような API の記述しかありませんでした。
CORBA のバージョン 2.0 になって、だんだんと、通信プロトコルもきちんと決まって、各言語のバインディング、というか、API もきちんと決まってきたという感じですね。
-- ちなみに私も、あるテレコムさんのプロジェクトをやった際に、小野沢さんの本で勉強させていただいたことがあります。やはりテレコム業界では、いまだに CORBA がかなり使われていますね。
ええ、いまだに CORBA は使われてますね。
-- Web サービスに携わられたのは、分散オブジェクトからの流れからということでしょうか？
Web サービスを始めたのはやはり、CORBA からの流れです。分散オブジェクトの流れで、どちらかというと必然的に、Web サービスに行き着いたというところがあります。
私は前職が、IONA テクノロジーという会社だったんです。そこは、CORBA をベースにした、Orbixという非常に面白い製品を持っていました。設計と実装がユニークなんですね。
外から見ると CORBA なんですけれど、中身の実装は、ミドルウェアのカーネルの部分と、プロトコルの部分、それから API の部分が、完全に分離しているんです。つまり、カーネルが真ん中にあって、その上に API があり、下にはプロトコルがあります。それで、API とプロトコルはプラグインとして、自由に付け替えられるようになっています。
API として CORBA の API を使って、プロトコルとして IIOP を使えば CORBA になりますし、別のものにも簡単に付け替えることができるんですよ。Web サービスがなかったころから、そういう設計思想で作られている製品なんですね。
SOAP が出てきたころに、Microsoft と SOAP のプラグインを追加して、接続の実験を最初にやったのが IONA です。
今の IONA の製品は、Artixという製品なんですが、ベースは Orbix と同じものを使っていて、カーネル部分はまったく同じです。プロトコルの部分には、 IIOP 以外に、Web サービスの SOAP や、非常にユニークなんですが、MQですとか、Tuxedoですとか、Rendezvousですとか、何でもありなんです。
プラグインを交換するだけで、まったく別のものと通信できるようになっていますし、 API の部分も同じような感じになっています。
-- マイクロソフトさんは、SOA は一つのパラダイムだという位置づけで捉えていますが、いわゆる CORBA による分散オブジェクトと、SOA とは、何が違うのでしょうか？それとも同じものなのでしょうか？
オブジェクトやサービスの粒度、といったところで当然違いはありますし、それらを使って設計をする場合には、きちんと違いに気をつけて作る必要があります。しかし、まったく別のものではないと私は思っています。
SOA は、Web サービスによって生まれたまったく新しいパラダイム、というものではなくて、これまで 10 年以上の分散オブジェクトの技術の歴史の中で、だんだんと積み重ねられてきたものが、ようやく開花したものだと、私は理解しています。
実際、 90 年代の中ごろ、Web サービスが登場するかなり前に、CORBA のような分散オブジェクトの技術を使って、今の SOA とまったく同じような目的を持って、開発されたシステムはたくさんあります。例えば、スイスのクレディ・スイス、あるいはアメリカのアメリカンエアラインズなどです。
-- クレディ・スイスさんといえば、最近は SOA を事例として結構紹介されていますよね。
それとまったく同じことを、10 年近く前に、CORBA で実際にやって成功されているお客様なんですね。
-- SOA 自体は、実装を問わないコンセプトなので、CORBA を使ってそれを実現しても、当然良いわけですよね？
そうですね。最近の雑誌を見ると、「もう CORBA は古くなった」と受け取れるような記事が結構あるんですが、実際そうではないんですね。CORBA の時代から、CORBA を使って SOA 的なことをやっているお客さんは、たくさんいらっしゃいます。
-- 分散オブジェクトと SOA は、同じものなのか違うものなのか、少しわかりづらい気がします。
レイヤーがぜんぜん違うんですよね。SOA はアプリケーションを設計するレイヤーで、その下に、例えば Web サービスがあって、CORBA がある、という考え方をすれば良いと思います。
-- あくまでも SOA というのはコンセプチュアルなもの、考え方というか、設計方針で、それを支えるアーキテクチャとして、設計や実装の部分で、CORBA なり Web サービスがあるということでしょうか。
そうですね。私はそう思っています。
-- CORBA は現在も、通信系などで主に使われていると思いますが、今後は Web サービスや SOAP がどんどん使われて、発展していくとお考えですか？
ええ。そうだと思います。実際、かなり多くの部分で、すでに Web サービスが使われてますよね。.NET のいろいろなアプリケーションが、もうすでに Web サービスを使っていますし、ビジネス系のアプリケーションでも、特に EA との関係で、SOA が指向されていることが多いです。
-- 異機種接続のためのプロトコルとして、SOAP や Web サービスがあると思うんですけれど、SOA と言えるほどのレベルでそれらを使っている例は、あまりないのではないでしょうか？
確かにおっしゃるとおりですね。単にアプリケーションの通信レイヤーとして、Web サービスを使っているだけというケースと、SOA をきちんと適用しているケースは、分けて考えるべきだと思います。
従来の CORBA ベースで、その上に SOA で構築したという例はたくさんあると思いますが、本格的な SOA ベースのものは、やはりこれからでしょう。
-- EA の中でも、いわゆるテクノロジー・アーキテクチャについては、SOA を指向すべきだと、一般的に言われています。それは、やはり真理なのでしょうか？
ええ。それは、真理だと思います。多くの官庁さんや企業さんのシステムを実際に見てきましたが、何が問題かというと、その場しのぎの接続を繰り返してきたというケースがすごく多いんですね。例えば、あるときは FTP でファイル転送して、あるときは MQ を使って、あるときは Rendezvous を使って、というように。
その時々は、それが最適な選択だったかもしれませんが、結果として一つの企業の中に、いろいろなプロトコル、いろいろな手法が混在してしまうわけです。
-- EA はもともと官公庁から、さらに元をたどれば米国から入ってきたコンセプトですが、今後は民間でも取り組むところは増えていくでしょうか？
ええ。そう思っています。
-- オブジェクト指向の、いわゆるモデル化の考え方は、EA にも適用できるとお考えですか？
オブジェクト指向を全面的に適用しなくても、EA 的なことはできるんですけれども、双方の考え方は、非常に近いと思っています。
従来のオブジェクト指向はどちらかというと、一つの個別システムをいかに最適化して、設計・開発していくのかというところに力を注いでいたと思うんです。その同じ考え方を、企業全体のレベルに適用したのが、EA だと思っています。
-- MDA には賛否両論あると思うんですが、小野沢さんはどうお考えですか？
基本的な考え方としては、MDA がすぐに実用化されるとは思っていません。現時点では、標準化のレベルもまだまだですし、ツールも、実際のシステムに適用して効果を発揮するということろまではいっていないと思います。ただし、流れとしては、MDA が目指す方向は正しいと思っています。
システム開発の歴史を見ると、昔はアセンブラ言語で書いていたわけですよね。特定のプラットフォーム向けに、アセンブラでごりごり書いていました。それが高級言語になって、特定のプラットフォームを意識しなくても、プログラムが書けるようになってきたわけです。
その後、CASE ツールと呼ばれるツールが出てきました。最初のころは、特定のベンダーに依存したものだったんですけれど、それが、UML や、あるいは今の MDA の考え方の登場で、特定のベンダーに依存しない形でモデルを記述して、そこからコードを生成するという流れができてきました。
その流れ自体は、今後もますます強くなっていくと思います。それで、あと 4 〜 5 年すれば、今の MDA が目指すものが実現できるのではないかと思っています。
現在、アクセンチュアも MDA の取り組みをやっていまして、例えば、Accenture MDA Asset for Rational XDE というアセットを開発して、お客さんのプロジェクトに適用するということをやっています。
実際、ヨーロッパやアジアのいくつかのお客さんで成功を収めているんですけれど、やはり現状ですと、MDA が目指すものを、全面的にお客さんのプロジェクトで享受するというところまでには至っていません。
どこまでできているかというと、UML 等を使って、プラットフォーム依存ではないモデル（PIM）を作って、それをプラットフォーム依存の、コードなりモデルなりに落とす、というところまでですね。
何ができてないかというと、実際のアクションの記述です。静的な部分には対応できているんですが、動的なアクションの部分は、Java や .NET で書いているのが現状ですね。
まだ OMG がそこの部分を完全に標準化していないので、そこをやろうと思うと、どうしてもツールに依存することになってしまうんですね。そのツールも、Java で書くのと大して変わらないような抽象化レベルでしか記述できません。
そうであれば、最初から Java で書いたほうがいいんじゃないかと、今は判断しています。
-- 特にアクションランゲージ、というか、アクションセマンティックスの部分については、ベンダー間でも記述方式がばらばらですね。もし、ベンダー共通のアクションランゲージができたら、高級言語に代えて、それを使う価値はあるのでしょうか？
ええ。そこが標準化できて、すべてのベンダーの製品、ツールがそれをサポートするようになれば、使う価値は十分あると思います。現状の Java や C# よりも、さらに抽象化レベルの高いものになれば、もっと良いですね。
-- MDA のテクノロジーは、EA 的な考え方に何らかの貢献をするでしょうか？
EA の考え方と MDA の考え方は、非常にうまくミックスすると思います。そもそも EA の一つの考え方というのは、それぞれのレイヤーを、独立にメンテナンスできるようにしましょう、というものなんですね。テクノロジーのレイヤー、アプリケーションのレイヤー、あるいはデータのレイヤーを、きちんと分けて管理できるようにするわけです。
ですので、MDA のような考え方が適用できれば、テクノロジーに依存せずに、上のレベルでモデルをきちんと決めて、それからテクノロジーに落としていく、ということが可能になるはずです。
-- 新しいパラダイムや技術のトレンドは、なかなか見えにくいと思うんですが、小野沢さんからご覧になって、次はこれだ ! というものはありますか？
私も、先のこと予想するのはすごく大変なんですけれど、MDA も含めて、最近の技術の動向を考えると、それぞれの技術のレイヤーが独立して、他のレイヤーから見たら仮想的に扱えるようになってくるのではないか、と思っています。
一つの流れが、ユーティリティコンピューティングですね。
例えば、サーバですとか、ストレージを仮想化して、使う側はどこにストレージがあってどこにサーバがあるのか、その物理的な場所や実体を意識しなくても使えるような仕組みです。それが別のものに置き換わっても何ら影響を受けない。
あるいは、アプリケーションのレイヤーだったら、ASP（アプリケーションサービスプロバイダ）のように、アプリケーションそのものを仮想化して、自分が使いたいときに、使いたい分だけ使って、必要であれば課金されるという仕組みです。
そういう流れが、これから強くなってくるんじゃないかな、と思います。
-- 役割分担して、それぞれを抽象化して仮想化するという考え方の元祖が、分散オブジェクト的な発想、ということになるのでしょうか？
そうですね。
-- この業界の方に今まで何人もインタビューしてきて、仕事が趣味だ ! と言い切る方が非常に多かったんですが、小野沢さんは、どのように休みの日を過ごされていますか？
家族とのんびり過ごしたり、あるいは公園を散歩したり、というのが理想ですね。理想なんですけど、今の仕事に就いてからは、ほとんど休みがなくて、一応家にはいるんですけど、家で仕事をしていることが多いです。
なので、夢としては、休みの日はきちんと休んで、家族とリラックスすることですね。
-- 今は中途半端にモバイル環境が整って、どこでも仕事ができちゃいますからね。
ええ。良くないですよね。
-- 最後に、若手エンジニアへのアドバイスをお願いいたします。
本当に最近の若い人は、決して傍から見てるというわけではないんですけど（笑）、すごく大変だと思います。僕が若かったころは、自分がフォーカスすべきものが、すごくクリアだったんですよ。私はもともとメインフレーム系の技術者だったので、そのメインフレームの技術、OSですとか、あるいはプログラム言語、アセンブラですとか、FORTRANとか、フォーカスするものがすごくはっきりしていました。
でも今は、いろいろなバズワードが並んでいて、自分が何をすればいいのか、すごくわかりにくいですよね。
そういう中で、若手エンジニアにはどうしてほしいかというと、物事の本質をしっかりと勉強してほしい、と思います。
当然、流行語はある程度理解していないと話についていけません。でも、それだけで終わってしまうと、中身がなくなってしまいます。
よく若い人と話していて、本当に基本的なことを知らないな、と思うことがあります。
例えば、コネクションをオープンにして、パケットをやり取りするという、TCP の基本的な仕組みです。あるアプリケーションが別のアプリケーションと通信することを考えた場合、僕の頭の中ではこれがクリアなんですが、その辺の仕組みを理解していなくても、システム開発ができてしまう。そういう現状があります。
通信の仕組みにしてもそうですし、プログラミング言語の仕組み、あるいは、コンパイラがどうやって動いているか、そういう基本的なところをしっかりと、勉強していってほしいと思います。
| ©2005 OGIS-RI Co., Ltd. |
|
