UBLにみる明快なビジョンと情熱

前回のエントリには多くの反響をいただきました。やはりBlogコミュニティだけにセマンティックWebというテーマに関心が高いのだということがわかって、ある意味では狙い通り、加えて少しピンとくるものがあったので、今回はUBLを取り上げてみることにしました。

私の書くBlogは、時間の制約と性格の制約によりロジカルな緻密さよりもインスピレーションと「思考の揺さ振り」を重視しているので、内容の荒削りな部分は救い難いものがあると思います。一方で、それを補う仕組みとしてトラックバックがうまく機能してくれたおかげで、全体として読み手に対してバランスのとれた思考を提供することに成功しているのではないかとも思います。トラックバックをいただいた皆さんに感謝します。

横道に逸れますが、インスピレーションを重視しているというのは「思考の揺さ振り」はそれ自体が価値だと信じているところによります。リスクとリターンが必ず一対になるように、意図的に逆張りの思考ベクトルを提供するということは、その正しさを競うという以上にエントロピーを一旦高め、内部エネルギーを増幅し、無用なハイプを相殺し、結果としてより早い段階での軌道修正を促し、進展スピードを高めるという効果をもたらします。もしあなたがマネー脳の持ち主なら、「市場の流動性はそれ自体が価値である」と言い換えればピンとくるかも知れません。

前回の確信犯的な煽り口調のエントリで気分を害された方にはお詫びを申し上げたいと思いますが、せっかくご縁あって訪問いただいたのですから、今後もこのBlogにしばらくお付き合いいただいて、私が普段何をどう考えている人間なのかをご理解いただくことで、得るものだけを得て、いらないものはバッサリと切って、間違いを糾すべきはトラックバックなりコメントをいただければ嬉しいなと思います。（デヴィッド・リンチ監督の「他人から与えられる答えなんてない。『自分がどう感じたか』が唯一の答えだ」という言葉が私の思考回路をよく表しています）

左脳系セマンティクスの標準化を目指すUBL

さて。今回はちょっと濃い話をしよう。先日のセマンティックWebのエントリに関心（賛否問わず）を持った人やWeb Servicesのテッキーな分野の住人は、今回の左脳系のビジネス世界で起きているコンバージェンス（融合）の方向性を少し感じ取ってもらえれば、より深みのある理解が得られるのではないかと思う。何よりも、「ギークとスーツ（梅田さんの10月8日のエントリを参照）の協調」という観点で最も進んでいると考えられるebXMLに、多くの人が関心を持つきっかけになってくれればと思う。

先週の東アジア電子商取引協会のセミナー、そしてOASIS Open Standards Days Tokyo 2003でUBL (Universal Business Language)のLibrary Content SubcommitteeのチェアパーソンであるTim McGrathが講演をした。

OASIS UBL TC

ちょうど今週の24日にUBL v1.0ベータのドラフトがアップされたので、関心のある人はレビューしてみて、できればコメントなどポストしてみて欲しい。

UBL TCとは、もともとebXMLのコア・コンポーネント技術仕様（実装独立のセマンティック・メタモデル、略称CCTS）を現実の実装で扱えるXMLのシンタックスまできちんと落とし込まなくては意味がないというSun MicrosystemsのJon Bosak（ご存知、W3CでXML Working Groupのリーダーを務めた人物）の強い意志により起案され設けられた技術委員会である。UBLについての最もわかりやすいチュートリアル（といってもこの分野に馴染みのない人にはチンプンカンプンかも知れないが）を一度ざっと目を通してもらえれば、なんとなくその意図するところが読めてくるだろう。

さらに遡ってebXMLというのは、1999年から18ヶ月という期限で完遂されたOASISとUN/CEFACTのジョイントプロジェクトおよびその成果物たる仕様群を指すものだが、中でもコア・コンポーネント技術仕様は悩みのタネだった。メッセージング仕様、プロトコル合意仕様、レジストリ＆リポジトリ仕様、ビジネスプロセス仕様などの仕様書が次々と承認されていく中で、唯一、仕様書として承認されることがなかったのが最上層のビジネス・セマンティクスを取り扱うコア・コンポーネント仕様であった。（テクニカルレポートという位置付けとなった）

当時のebXMLプロジェクトの最中でも多くのプロフェッショナルたちが陥っていた誤解だが、CCTS（コア・コンポーネント）とBPSS（ビジネスプロセス）のレイヤー関係としてCCTSがBPSSの下位に位置づけられているチャートが多く使用されていた。しかし実際にはCCTSそのものはレイヤースタックに組み込めず、その具象としてのUBLが提供するようなビジネスメッセージが最上位に位置する。ビジネスドキュメント（古い言い回しでイベントファイルとかトランザクションファイルと呼んだ方が判りやすい人もいるかも知れない）やその要素のセマンティクスは本来プロセスとコンテキストが定まらないと設計できないのだから、BPSSのようなものが下層に位置することはアプリケーションエンジニアにとっては素直な理解なのだが、そのようなことはもっともっと下層のレイヤーに属するテッキーなエンジニアの関心の外にあったというか、多くの人々がダイナミックなプロセスとスタティックな情報の相互作用、セマンティクスの本質を理解しきれていなかったということをある意味で暗示している。（このことがOASISとUN/CEFACTの間の溝を深めたのではないかという邪推は、ここでは脇に置いておこう）

CCTSはISO11179（ISO/IEC JTC1 SC32 WG2のMetadata Standardsというサイトが詳しい）に準拠しており、オブジェクト指向と親和性の高い手法でモデルを「抽象的に」定義している。言い換えれば、例えばコードリストの表現にRDFオントロジを使うかXML Schemaの列挙型を使うかといった実装上の選択とは独立であることを重視している。まぁビジネス寄りの文化人が考えそうなことではある。

一方でUBLの考え方は、コア・コンポーネント仕様に対する実装へのバインディングをエイヤで決め、兎にも角にも「具体化」を重視している。こちらはいかにも技術屋が考えそうなことだが、現段階に至ってはこちらのアプローチの方が必要とされるステップに来ていると思う。「机上の議論はもういいから、そろそろコードを書こう」ということだ。なかでもビジネストランザクションで最も使用頻度の高い受発注プロセスに注目し、PurchaseOrder（注文書）ドキュメントなどを構成したサンプルを提供している。

なお、UBLはxCBL V3.0を起源としており（ということはCNET社長の御手洗さんあたりから突っ込みが入るかも知れないが）、即ち間接材（オフィス文具だとか消費財、いわゆる購買部で購入するような非生産材）の取引に使われることを想定して作られたメッセージ群がベースにある。もともとB2Bの取引はこの分野（MROという）の立ち上がりが最も早かったということもあり、ここで既に叩かれた仕様を採用するのは妥当なアプローチだろう。また、MROはエンドユーザ取引が主体であり、比較的シンプルなプロセスとコンテキストを前提にできたということも、業界中立の標準として用いる雛形としてはもってこいだという読みもあったに違いない。

単純明快なビジョンが支える情熱

しかし、そうは言っても業界ごとの商習慣や地域ごとの商習慣から独立した受発注プロセスなどというものは現実には存在せず、UBLが提供するような注文書ドキュメントが実際に適用可能な領域などないことは明らかである。さらに悪いことに、こういった新しいことに積極的な業界ほど、すでにRosettaNetのような取り組みを何年も前から行って成果を上げつつあり、UBLの入り込む余地は当面ない。つまり、コードを書いてもすぐに捨てることになるのだ。しかし、そのことに気付きながらも情熱的に作業に取り組み、あちこちに頭をぶつけながら標準化を進めていくメンバーたち。

こういった暗中模索での作業は、常に「計画、実行、レビュー」の短いスパイラルな工程を経ることになる。当初思ってもいなかったような課題に直面し、たびたび方向転換を迫られる（余談だが、そういった困難と格闘する経験は何物にも代えがたい貴重なものである）。そして、ゴールに至る経路といつごろ到着できそうかの予測が全く立たないような状況の中にあって、超一流のプロフェッショナルたちの情熱を維持させているものは、単純明快な「国際・業際で相互運用可能な取引標準仕様を作る」というビジョンの存在である。

この気の遠くなるようなゴールは、傍から見ればセマンティックWebと同様の「バベルの塔」に思えるだろう。しかし、目を閉じて20年後の未来を想像して欲しい。30年前に登場し現在の総トランザクションの80％を占めるビジネスツールとなっているFAXは、20年後にも同等のシェアを維持しているだろうか。ここ数十年の歴史の中で郵便・電話・テレックス・FAXとコミュニケーションツールが進化してきている中で、インターネットというインフラが現在のWebとメールのような人間の脳をプロセッサとして必要とする（人間の処理能力がボトルネックとなってしまう）非標準アプリケーションだけで終わってしまうということがあるだろうか。そこにはのっぴきならない現実のニーズがある。だからこそ、超一流のプロフェッショナルたちが信念を失わずに、一歩間違えれば慈善活動になりかねないボランティア作業に全力投球できるのだ。私はこれを「スーツたちのオープンソースプロジェクト」と勝手に呼んでいる。

あるエマージングなテクノロジーを前にしてそれを評価する場合、この「単純明快なゴールが設定されているか」が何よりも重要であるということを忘れてはいけない。何時の世も、難解で高度なテクノロジーを見せびらかし「どうだ、きみたち凡人には理解できまい」ということそれ自体を価値だと思っている人たちがいるものだが、そんなことは気に揉む必要はない。あなたがそのゴールに共感し、貢献しようと考えているならば、自分に理解できないような難しい技術は「もっと簡単に、判り易く説明しろ」と言う権利があるのだ。このことは先日の機会にTim McGrathとも合意したポイントなのだが、UBLはまだまだとっつきにくいが、それではいけないということは強く意識されている。

日本でのUBLへの取り組み

UBL関連の今後の活動では、OASISでアリバの伊藤さんが議長、ECOMの斉藤さんが副議長となってJPLSCという日本語ローカライズのサブコミッティを立ち上げる。まずはUBLを理解することと普及啓蒙がミッションとなるが、いずれ日本からのフィードバックということも視野に入ってくることだろう。私も何らかの形でこの取り組みに協力していきたいと考えている。

今回は左脳系セマンティクスを話題にしたくてUBLという大きなテーマに手を出してしまったため、かなり内容が散漫になってしまった。しかし、これは結構大事なテーマなので、またいずれ折に触れて取り上げようと思う。とりあえず今日はこのへんで。

♪ STEVIE WONDER / YOU ARE THE SUNSHINE OF MY LIFE