Development Style Round Table Talking
第1回 オブジェクト指向の弱点
浅海智晴×平鍋健児×原田洋子×村田真

構成 谷古宇浩司（編集局）
2003/11/22

---

　XMLで定義したデータ構造をそのままJavaで扱えるクラスとして生成するスキーマ・コンパイラ「Relaxer」。このツールを核に、日本発の新たなソフトウェア開発プロセスを生み出そうとする4人の“革命家”がいる。Relaxer開発者の浅海智晴を中心とし、開発プロセスの枠組みを構築する平鍋健児、J2EE開発のノウハウを注入する原田洋子、XMLの日本における泰斗、村田真。「Relaxerサービス・フレームワーク・プロジェクト」と名付けられたこのプロジェクトは、経済産業省とIPA（情報処理振興事業協会）が展開する「未踏ソフトウェア創造事業」の1つでもある。エンジニアにとって真に役に立つソフトウェア開発プロセス、ツールとは何かを模索し、具体的な成果として世に問おうとしているこの4人が、現在のソフトウェア開発現場の矛盾を暴き出し、その解決策を提示する。（敬称略）

---

◆スキーマ・コンパイラがソフトウェア開発に及ぼす影響

浅海　僕は、オブジェクト指向による実装技術の弱点は分散やコンポーネントといった疎結合の実行環境上で「データを共有化したり、持ち回る」ということだと思っているんです。で、この弱点を補完する技術として何が最適かというとXMLなんですね。XMLを使ってデータを表現することで、いろいろな可能性が広がっていくわけです。

浅海「XMLとオブジェクト指向を組み合わせると、ものすごく効率的なシステム開発が実現するのですが」

　XMLとオブジェクト指向を組み合わせると、ものすごく効率的なシステム開発が実現するのですが、1つ問題があって、オブジェクト指向とXMLが基にしている、「ドキュメントモデル」と僕はいっているんですけど、つまり、セマンティクスが根本的に異なっているので、簡単にすり合わせができないんですよ。なので、この2つの世界をどうやってすり合わせていくのかという問題はソフトウェアを開発するうえで、とても重要な問題なんです。

　現時点では、個々のエンジニア独自のノウハウですり合わせを行うしかないのですが、かなりの上級者でないと作業を行うことができないんですね。でも、現場にいるのは上級者だけではないですから。そこで必要になってくるのが、だれでも使える標準的な技術です。例えば、ソースコードを自動生成することによって、2つの世界のギャップを埋めていくという作業ですね。2つの世界のギャップを埋めるコードを自動生成することで、データ表現のXMLとシステム構築の基本的な方法論であるオブジェクト指向をうまくつなげてやれば、システム構築の効率が非常に上がるんじゃないか、と思うわけです。この2つの世界のギャップを埋めるコードを自動生成する技術がスキーマ・コンパイラです。スキーマ・コンパイラの導入によってシステム構築の生産性が劇的に向上するとすると、そのことにより、スキーマ・コンパイラという技術がシステム開発のいろいろなフェイズに、いろいろなインパクトを与えて、その副次作用でシステム開発の方法論全体まで変えていくようなポテンシャルのある技術ではないか、というふうに思っています。

　2つの世界のギャップを埋めるには、XMLとオブジェクトのそれぞれのモデルを記述する仕組みが必要です。そのXMLの部分をモデル定義として活用するにはRELAX（REgular LAnguage description for XML) というスキーマ言語が僕は一番いいと思っています。オブジェクト指向に関しては、モデリング言語としてUMLがあり、すでにモデリングの方法も決まっているので、これを活用すればいいだけです。2つモデル体系をつなぐための技術として、スキーマ・コンパイラがある、とこういうわけです。

◎参考： 悪の秘密結社RELAX
　
　で、スキーマ・コンパイラとして、Relaxerを作りました。後は、このRelaxerを具体的に実際のシステム開発に適用するため、さらに磨き上げていかなければいけない。この辺の作業がこれから必要になってくると思っています。

◎参考： Relaxer：XMLがJava開発を変える （XML & Web Services ）
◎参考： RelaxerStudioプロジェクト （Development Style）

村田　これまで、ソフトウェア開発業界は常に「硬いデータ」を扱ってきたわけです。一番初めは「テーブル」で、最近は「オブジェクト」という具合に。少しずつ「柔らかく」はなっているのですが、それでもまだ硬そうなんですね。

村田「現時点では、XMLデータをプログラムから扱おうとするとき、最も使える技術がスキーマコンパイラだというのは確かだと思いますね」

　XMLはもっと柔らかい、もう少しルーズというか自由度があるというか、あらかじめ最初に型定義をしなくても作れる構造になっているんです。そういうもの（XML）とプログラミングの世界をどうつなぐか、という問題を考えるときに、いろいろな考え方が出てきましたね。

　例えば、UMLで全部統一して、XMLは単にUMLのダンプ・フォーマットにしてしまおうという考え方。僕にはあまり面白くない考え方ですが、1つの考え方ではあります。つまり、硬いモノの受け皿としてしかXMLを使わないという使い方ですね。それなりに有効だと思います。あるいは、XMLをオブジェクトのダンプ・フォーマットにするという考え方。これも僕にはあまり面白くありません。もっとXML中心的な発想はないのか、というと、2つあるんです。
　
　1つは、スキーマ・コンパイラを採用するという方針です。これはスキーマをオブジェクトの言葉でとらえ直そうという、簡単にいうとそんな感じですね。ただし、この考え方には弱点もいっぱいあります。そもそもXMLとオブジェクトの世界は違うので、Relaxerなどのツールがどんなに頑張っても問題は残ります。しかし、スキーマ・コンパイラは、現時点では最も実用性が高い技術だと思いますよ。

　この考え方をさらに冒険的に発展させると、プログラミング言語の型としてXMLを入れるという発想です。スキーマをデータ・タイプとして入れ込んでしまう。プログラミング言語そのものを変えてしまうというドラスティックな発想です。Javaだ、C#だという限定された世界ではなくなります。これが実現すると、getter／setterメソッドが使えないかもしれない。変数名で値にアクセスできるという信仰を捨てなければいけないかもしれない。
　
　現時点では、XMLデータをプログラムから扱おうとするとき、最も使える技術がスキーマコンパイラだというのは確かだと思いますね。

原田「スキーマが決っていないと、まるで “霧の中でもがいてなんとかした” ような状態になってしまい、目的に合うように書けないんですね」

原田　私は最近、XMLとJavaを組合せて使うようになりましたが、エンドユーザとして使っているだけで、エキスパートではありません。自分が决めたルールに従ってXMLを書いて使っているだけならスキーマが決っていなくてもいいのですが、XML文書やXMLを扱うプログラムを誰かに使ってもらうとか、誰かが决めたルールに適合するようにXML文書を作ろうとした時に問題があることに気が付きました。スキーマが決っていないと、まるで “霧の中でもがいてなんとかした” ような状態になってしまい、目的に合うように書けないんですね。

　なので、標識がはっきり見えるという点では、スキーマは絶対にあった方がいい。その次の段階として、スキーマ・コンパイラの登場があると思います。サーバサイドJavaだと、ドキュメントとしてXMLを書くというよりは、XMLをコンフィグレーションとして、または命令、あるいは一種のプログラミング言語的に使うのが普通です。Javaのオブジェクトと組み合わせて使うので、どこかの段階でオブジェクトになってくれないと困るのですが、スキーマ・コンパイラはその点をうまく解消してくれる存在だと思っています。

◆オブジェクト指向の弱点をXMLで埋める

平鍋　僕はオブジェクト指向分析／設計／実装を含めた包括的なシステム開発のプロセスを見るという立場から、スキーマ・コンパイラの存在を意識しています。まず、オブジェクト指向分析／設計をざっと説明しましょう。

平鍋「僕はオブジェクト指向分析／設計／実装を含めた包括的なシステム開発のプロセスを見るという立場から、スキーマ・コンパイラの存在を意識しています」

　ある問題領域を分割し、型を見つけ、型同士の関係を抽出し、静的な分析をするというのが第1段階です。そして、型同士がどういうインタラクションをするのか、という動的な分析をするのが第2段階です。
　
　今回のように、スキーマ・コンパイラを核とした開発のアプローチは、クラスをたくさん抽出していく中で、真剣に分析／設計の作業を行わなくても、ほぼストレート・フォワードに実装に落とせてしまうとか、メタデータを活用することで、分析の段階から実装まですんなりこなせてしまうという部分があると思います。型を見つけ、関係を定義していく段階で、ある部分の範囲の型に関しては、半自動的に分析から設計、実装まで持っていける部分が存在するということですね。少し整理しましょう。浅海さんが考えるソフトウェア開発のアプローチは、分析から設計、実装までをツールを活用することで、自動的かつシームレスに展開するというところにキモがあると思います。
　
　僕の立場からいうと、浅海さんのアプローチというのは、オブジェクト指向分析／設計という1つのアクティビティのとらえ方に対するまったく新しいアプローチだと思います。確かに、開発プロセスの各フェイズとツールをうまく組み合わせることで、新しいプロセスを定義するという動きがいま、特に求められていることなのではないか、と思います。XMLとオブジェクト、Webアプリケーションという3つの熱い動きが交差した2003年というタイミングと、RELAXを含めたXML技術の成熟度が、浅海さんのいわれる新しい開発プロセスの提案にぴったり一致するのではないかという感じを受けています。

村田　SGMLのころからの延長である、文書としてのXMLには、いま、平鍋さんがいったような見方が欠落しているんですよ。

　モデル設計というのは、何を部品として取り上げるかを決めていきます。例えば、「タイトル」「著者名」「段落」などの部品を洗い出していくんですね。そのとき、部品を何に使うかは当然意識します。例えば、著者名検索に使いたいとかね。しかし、それについてのきちんとした方法論は、SGML(Standard Generalized Markup Language) の世界では結局できませんでした。伝統的なSGMLあるいは文書処理技術の弱点はまさに、プロセスをきちんと考えてこなかったという点にあるといえますね。

浅海　オブジェクト指向とXML（の融合）を考えるときに重要だと思うのは、キャッチーないい方をすると「バリューの復権」という言葉に集約されるのではないでしょうか。バリュー（値）はもともとモデルにとって重要な要素だったのですが、オブジェクト指向は、バリューはほとんど無視して、オブジェクトのみを重視する考え方なんですね。

　技術的にいうと識別子（identifier）を持つエンティティがオブジェクト、識別子を持たないエンティティがバリューです。現在のオブジェクト指向というのは「識別子がないバリュー」を軽くみています。名前を保持するくらいだろう、と。しかし、僕は「構造化されたバリュー」がとても重要なのではないかと思っているんです。というのも、構造化されたバリューを、オブジェクトの世界に再導入することで、モデリングの幅がすごく広がるはずだから。

　例えば、分散処理システムを考えてみましょうか。分散処理システムは、構造化されたデータをリモート間で持ち回るのがすごく難しいんです。RPC（Remote Procedure Call）は全部失敗しているでしょう。同様に、CORBA（Common Object Request Broker Architecture）も結局は失敗しているのではないかと思います。XMLの導入によって、構造化されたデータの持ち回りという課題がクリアできるのではないか。最初に考えたのはこういう発想です。

◎参考： XML-RPC

　もう1つ重要なのが、コンポーネント技術という新しい開発方法論（開発の枠組み）の登場です。コンポーネントにもやはり、バリューがすごく大事なはずなんです。なぜかというと、データに関して、従来のオブジェクト指向の考え方では、グローバル・データをみんなでオブジェクトとして共有するというモデルしかないんです。カプセル化したコンポーネント間で、実装非依存のデータをどうやって持ち回るのか、という大きな問題があるのですが、オブジェクト指向はそれを解決していないんですね。コンポーネントの場合、構造化されたバリューを持ち回る手段はいまのところ、オブジェクト指向の技術の中にはないのですが、XMLを導入することでコンポーネントの問題は解決できるのではないか、と考えました。

　XMLをオブジェクトにエンコーディングし、そのエンコーディングされたオブジェクトをコンポーネント間で持ち回ることが、Relaxerを活用することで可能になります。つまり、XMLのメタモデルで定義されたモデルを持ち回る、という考えです。これによってコンポーネント間の独立性が非常に高まります。XML技術とオブジェクト指向のすり合わせ、つまり、オブジェクト指向の弱点をXMLがぴったりと補完できるわけです。現段階のオブジェクト指向開発プロセスは、オブジェクトのみありき、という考え方が主流ですが、オブジェクトとバリューを2つの柱だとする前提で、オブジェクト指向開発プロセスを考え直す時期が来ているのではないか、その結果、いまよりも便利なそして実用的なプロセスが出来上がるのではないか。平鍋さんや原田さん、村田さんと連携することで、そういう考えを現実のものにしていければと思っています。

◆ツリー構造の重要性

平鍋　僕がさっきいった、開発プロセスのある部分（フェイズ）はスパーッと機械的にいけるんじゃないか、というのが、つまり浅海さんの目指していることですよね。クラスに切っていくのはいいけれど、ある部分をメタデータ的に扱えれば、実装までしなくてもいい部分ができ（写真1）、そこを構造化することによって、実装にかかる労力をすぱっと取り払ってしまおうという。

写真1

　浅海さんは「構造化されたバリュー」といっていましたが、浅海さんの考えに3層構造という概念を持ち込むと、ある程度、オブジェクト指向とマッチングを保ちながら、数学的にも扱えるのではないか、と考えています。そういう意味で、XMLは構造を表現するのに最も適している。僕の視点から浅海さんの提案を眺めると、こんな感じに見えます。

浅海　数学的に記述できる範囲で一番複雑な構造はツリー構造（木構造）だと思います。グラフ構造の中には、まだ数学的に扱える技術はなくて、まあ、もしかしたらあるんでしょうけれど、少なくとも僕らみたいなプログラマの目からみて、わかりやすく使える技術はないんじゃないかと思う。

村田　グラフ構造（というか半構造データベース）のスキーマ言語というものはありますけれど、XMLの場合と違って一般に使われるようになったわけではありません。

浅海　システム構築をターゲットとしたプログラマから見て、最も複雑で、しかし数学的にきちんと扱える限界がツリー構造ではないでしょうか。

平鍋　きちっとしたメタモデルが存在するという意味ではそうでしょうね。

浅海　だから、ツリーを基準に構造化したバリューを定義するのは非常に理にかなっているのでは。

村田　浅海さんがさっき、「バリューの復権」といったでしょう。バリューにとって、基本的にグラフというのは、オブジェクト・アイデンティティがない以上、やっぱり無理でしょうね。

浅海　確かにそうなんです。逆に、ツリー構造であるXMLの文章はIDがないけれども、構造を1次元にエンコーディングすることができます。だから、IDを持たないバリューを表現するためにXML文書がとても適しているんです。

村田　ツリーではない一般のグラフを扱おうとすると、オブジェクト・アイデンティティがないバリューでは、問題が出ませんか？

浅海　オブジェクトのグラフ構造は1つの大きなモデルなんですが、隣のコンポーネントに渡すときには、ここからツリー構造を切り取り、バリューとして出すことはできるのではないかと思っています。つまり、ツリー構造に写像するわけです。非常に複雑なモデルでも、あるユースケースやある特定の目的に関していえば、ツリー構造にマッピングすることは可能です。だから、ユースケースといった単位でコンテクストを絞り込めば、ツリー構造にマップして、隣のコンポーネントに渡すことが可能なのです。こんな感じでうまく開発プロセス化できるのではないだろうかと考えているわけです。

原田　イメージとしては、分散環境でWebサービスを活用し、構造化されたデータをXMLで受け渡ししているような形ですか。

浅海　サービス指向という考え方がありますね。データとサービスを分離して、コンポーネント化しようという考えはWebサービスの基本概念ですし、とても似ていると思うんですよ。ただ、Relaxerが採用しているアプローチは、今すぐ、SEが使えて、しかも役に立つというのがポイントなんです。Webサービスはこれからの未来を志向する技術なので、「まあ、頑張ってください」としかいえませんが。ところで、データと言えばプログラムを書いていて、リレーショナルとツリーとオブジェクトの3つを合体させたいと思うことがありませんか。何かいい方法はないか、と。

村田　その辺、僕としてはすごく悩むところです。下手をすると、XMLがオブジェクトのダンプ・フォーマットに成り下がるんじゃないかという危ぐがあるんです。そもそも「統一理論」といわれるものは、統一する側が、自分たちに興味のない部分を切り捨てることで成立するものですから。

浅海　主導する人の好き嫌いで……。

平鍋　結局、エンタープライズ・システムというのは、最後はRDBに落ちるというのがパターンじゃないですか。ただし、プログラミング言語としてはJavaに代表されるオブジェクト系の言語を使用することが多いんですね。その結果、現在多くのプログラマが日夜、徹夜しながら頑張っているのは、どうやってO-R（Object-Relation）マッピングするか、ということです。もしかして、浅海さんのアプローチがうまくいったら、O-T-R（Object-Tree-Relation）マッピングみたいな、3レベルマッピングが可能になるのではないか、と思っています。

浅海　バリューをツリー構造に収斂（しゅうれん）させるというのは、いい考えだと思うんですよ。つまり、オブジェクトをリレーショナルにやろうとするとIDの扱いでおかしくなるんですが、ツリー構造からリレーショナルはそんなに難しくないと思うんです。

村田　でも、いままで歴史的にずうっと大失敗の繰り返しですよ。

浅海　あ、そうですか。まあ、論理的に全部自動でやるというのは難しいと思うんですけど。SEが一手間かけたらうまくいくぐらいのところまでは持っていけそうな気がするんですが。オブジェクトは一手間でもなかなかうまくいかないですよね。

平鍋　O-T-Rマッピングみたいにしてしまうか、あるいはバリューを「通貨」として、持ち回りするものとして割り切ってしまって、永続しないというふうにしてしまうとか。

浅海　それもあるんですよね。（ツリー構造による）バリューは、コンポーネントとコンポーネントをつなぐものと割り切って、オブジェクトとRDBの間は頑張って今までのように力業で作業してください、と。

村田　その方がお互いけんかをしなくていいかもしれない。すみ分けができて。

（第2回に続く）

---

ラウンド・テーブル参加者 プロフィール

◆ 浅海智晴（あさみ ともはる） 　1985年立命館大学電気工学科卒業。同年富士通(株)入社。UNIXワークステーション/サーバのOS、分散基盤、Web基盤の開発に従事。2001年11月より浅海智晴事務所代表。現在はオブジェクト指向、Java、XMLを中心に活動を行っている。著書に「Java Super Tips オブジェクト指向設計編」、「XML/DOM Programming」（秀和システム）、「やさしいUML入門」、「Relaxer - Java/XMLによるWeb開発」、 「XML SmartDoc公式リファレンスマニュアル」（ピアソンエデュケーション）がある。代表作はJava&XMLベースのオープンソース・ソフトウェアであるXML SmartDoc(XML文書処理システム)<http://www.XMLSmartDoc.org>、Relaxer(XML/Javaスキーマコンパイラ)<http://www.relaxer.org>。 ◆ 平鍋健児（ひらなべけんじ） 　1989年東京大学工学部卒業後、3次元CAD、リアルタイムソフト、UMLエディタなどの開発を経て、現在、株式会社永和システムマネジメントでコンサルタントとしてオブジェクト指向開発を研究・実践。XPに関するメーリングリストXP-jpを運営、オブジェクトクラブを主宰。酒と映画と福井を愛する。翻訳書に「XPエクスストリーム・プログラミング 導入編」（ピアソン･エデュケーション）、「マルチパラダイムデザイン」（ピアソン･エデュケーション）がある。 ◆ 原田洋子（はらだようこ） 　1994年9月にWeb サーバ／Proxy サーバを自ドメインに立ち上げて以来、特にWeb サーバやインターネットの世界に興味をもつ。サーバサイドJavaとして後に名を馳せるようになったJava Servlet に巡り合い、Java に目覚める。現在はServlet&JSPを中心とするJavaプログラミングが本業である。著書に『Javaサーバサイドプログラミング』(技術評論社)がある。 ◆ 村田真（むらたまこと） 　1960年生まれ。1982年京都大学理学部卒業。W3C XML WGのメンバとして、XML 1.0の制定に携わる。編著書に「XML入門」（日本経済新聞社）。インターネットコンファレンス 98論文賞。国際会議WWW'99、PODDP 98、EP 98などのプログラム委員。国際ジャーナルMarkup Languagesの編集ボードメンバー。

IT Architect 連載記事一覧