本文へジャンプ

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む


お客様が developerWorks に初めてサインインすると、プロフィールが作成されます。プロフィールで選択した情報は公開されますが、いつでもその情報を編集できます。お客様の姓名(非表示設定にしていない限り)とディスプレイ・ネームは、投稿するコンテンツと一緒に表示されます。

送信されたすべての情報は安全です。

  • 閉じる [x]

developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む


送信されたすべての情報は安全です。

  • 閉じる [x]

XML的思索: 金融サービス業界におけるXMLを垣間見る

XMLに関する現実的な分野での興味深い教訓

Uche Ogbuji (uche@ogbuji.net), Principal Consultant, Fourthought, Inc.
Photo of Uche Ogbuji
Uche Ogbuji は、次世代の Web 技術を専門とするサービスの会社である、Uli, LLC の代表者です。Ogbuji 氏は XML、RDF、およびナレッジ管理アプリケーション用のオープン・ソース・プラットフォームである 4Suite の開発リーダーであり、Versa RDF 照会言語の開発リーダーでもあります。ナイジェリア出身のコンピューター・エンジニア兼ライターで、米国コロラド州ボールダー在住です。彼に関して詳しくは、彼のブログである Copia を見てください。

概要: 金融サービス業界で最近開催されたXMLに関する会議は、実世界におけるXMLに関して冷静に考える良い機会となりました。XMLは現実的な解決に向けての道を見いだしたのでしょうか・・・。どんなベスト・プラクティスでXMLの採用を促進しようとしているのでしょうか・・・。このコラムでは、Uche Ogbujiが金融サービス業界というプリズムを通してXMLを考察し、この業界に関連する、より重要なXML標準のいくつかを紹介します。

日付:  2004年 2月 20日
レベル:  初級 この記事の原文:  英語
アクティビティー: 2308 ビュー
お気軽にご意見・ご感想をお寄せください: 


2004年1月ニューヨークにて、金融サービスにおけるXML第3回年次会議(Third Annual XML for Financial Services conference)が開催されました。通常のXML関係の会議とは少し趣の異なるものでしたが、XMLの現実的な使用に対する明確な展望が得られるという点で大いに参考になるものでした。XMLはその用途として、主流となっているアプリケーション・プログラミングからデータベース管理まで、また工業規模の文書管理や電子データ交換(EDI)、さらにそれを超えるものにまで専門的に特化されています。私は以前から、XMLはこうした様々な専門化の産物であり、またこうした専門化を通してXMLが発展・成熟し、成功してきたのだと繰り返し述べてきました。金融サービス業界は、こうした多岐に渡る関心領域を網羅する、顕著な縮図のようです。そしてXMLは、あらゆる先行技術との直接的な競争に直面しているように思われます。

こうした状況においては、私がこのコラムや他の文書で追求してきた多くのテーマ、つまり意味体系の透明性(semantic transparency)、トップダウンなのかボトムアップなのか(XML的思索: XMLのセマンティック・アンカを見てください)、また生のテキストや山括弧を隠すようなツールや、勝手に変更してしまうようなツールがもたらす危険性などが大いに関係してきます。この記事では、金融サービス業界に反映された、こうした一般的なテーマに関して考察し、その後でこの業界に特化したXMLアプリケーションについて簡単に説明したいと思います。

経済学に注目したXML

金融サービスにおけるXML会議の出席者の大半は、金融サービス業界の技術マネージャであり、私が見慣れているような、理想家で多彩なXMLの中核をなす専門家ではありませんでした。技術を議論する上で焦点となったのは、成熟具合や実用性、運用効率、企業レベルでの拡張性、ビジネス面での継続性、国際的な視点、規制に関する配慮などであり、また権威を持つ標準化組織はW3CやOASIS、それにWS-I等ではなく、ISOや国連、あるいは金融監督機関です。文書や金融証書(financial instruments: 金融関係の管理で用いられる正式な契約書や取引に対する汎用的な用語)は、XMLで表現されたものであっても他の形式で表現されたものであっても、なるべく可能な限り機械的に標準化されていますが、最終的には現場における管理方法と、その文書をどのように取り扱い、解釈するかが最も重要な考慮対象となるのです。

こうした特徴のうちの幾つかは、全体として金融サービス業界が高度に自動化されてはいない、という事実に由来しています。商取引の大半は、電話やファックスによって行われています。この会議の出席者は、一般的にこの業界ではかなり技術的に精通している人達ですが、そういう人達ですら、(多くはあまり技術的に高度ではない)ビジネス・パートナーとの取引という現実から、コンピュータ化への野心を抑えざるを得ないのです。

この業界や他の類似の業界で一般的となりつつある必要性と、実世界でのXML開発において(Webサービスや密結合のミドルウェアの役割に関して)今まで当然と思われていたこととは必ずしも一致しません。Webサービスが組織間で標準フォーマットを使って文書を交換するための手段ではなく、アプリケーションをつなぎ合わせる魔法の統合ツールとして売り込まれている限りは、Webサービスは単なる興味の対象にすぎません。実際この業界の人たちにとってWebサービス技術の趨勢は、企業レベルでの展開を決意するような代物ではなく、未だに興味を引くだけの提案だと見なされています。この業界では基本的なミドルウェアの採用においてさえ、データを透過的に処理し、コンポーネント間は疎結合であるような、簡単なソリューションを好む傾向があるのです。従って、XMLの円滑な採用を促すべく販売されているような、アプリケーション開発ウィザードに対する関心は高くありません。ビジネスの原動力とXML文書を可能な限り直結できるように意図したXMLの動きが、この業界における採用に向けての唯一の道への入り口なのです。ebXMLや金融サービスに特化したXMLフォーマットに向けての行動指針の多くは、意味論的に透明性を持つ機構で基本的なXML構文を増強することに焦点を当てており、それによって各組織が商取引の一部分を自動化できる能力を完全に失うことなく、特化したXML処理システムを開発できるようにすることをねらっているのです。

以前私は、十分に確立された先行技術を上回る明らかな利点を証明できた後でないと、XMLは採用されない、と書いたことがあります。私はこの会議の出席者達とのやり取りの中で、それを再確認しました。たいていのXMLに関する会議で私は、例えばW3C XML Schema (WXS) とRELAX NGのどちらを使うべきか・・・、とか、XQueryを素晴らしい成果と見なすべきか、行きすぎと見なすべきか・・・、といった議論に加わることには慣れています。この会議で私は、XMLに関する議論の初期の日々、つまり重要なビジネス機能に使用する技術としてXMLは必ずしも確実なものではない、といった議論がなされていた頃に引き戻されたのです。EDIの仲介業で働くある女性は、自分達の使うべき技術として同僚の多くがXMLをとりあげたものの、古典的なEDI技術で行われている重要なビジネス機能の現実を見ると、とてもそうした変更の正当性を訴えられない、と話していました。また資産運用会社でITを扱うある男性は、意志決定を促すため、また規制への適合性を確実にするために、非常に様々なデータを統合する必要性を説いていました。彼らはそうしたデータのベース・フォーマットとしてXMLを使い始めています。ところが企業向けであることを目標としたXML処理ツールの多くは、業務処理と(必要最低限の機能だけを持った)実際のXMLコンテンツとの間に大きな距離を置こうとしているように思われ、彼らは呆然としているのでした。


金融関連のXML言語

金融サービス業界では、業界特有の要求に応えるために、様々な標準XMLフォーマットを作成しています。文書がどのようにやり取りされるかに関わらず、標準化作業の大部分は明瞭な意味体系を持つ文書フォーマットに焦点を当ててきました。この業界は細分化されており、困惑するほど専門分野が重複しながら絡み合っているため、様々な領域を網羅するために無数のXMLフォーマットが出てきています。ですから次に挙げるものは全てを網羅したものではなく、会議で表明された関心事項に焦点を当てたもので、多くは証券や株式市場に関するものです。例えばIFX (Interactive Financial Exchange )OFX (Open Financial Exchange ) などについては触れないことにします。これらは、個人やリテール・バンク(retail banking: 小口の顧客取引を中心とする米国の商業銀行)などで利用される形式です。

この業界で取引を自動化するための試みとして、最も初期に行われたのはEDIベースのものです。もう少し最近では、株取引データ用の標準的な通信プロトコルとしてFIX (Financial Information eXchange )(現在バージョン4.4)が出てきました。FIXは取引の経営幹部向きで、取引の交渉と実行に関連した部分に焦点を当てています。FIXは10年ほどの歴史があり、XMLよりも前に出てきたものです。実際のデータ部分(ペイロード)は、最初バイナリ形式でしたが、最近のバージョンではXMLを使ってFIXプロトコルのビジネス・メッセージを表現するFIXML (FIX Markup Language ) が開発されています。当初XMLメッセージは大きすぎるという問題がありましたが、新しいスキーマ設計ルールではメッセージ・サイズも控えめなものになっています。残念なことにFIXには5つ以上の違った種類があって実際に使われており、また類似の領域にはSWIFT下記参照)のような他の仕様もあるのです。それを踏まえて、FIXを維持管理する協議会であるFIX Protocol Limitedを含む様々な団体が、ISO 15022 XMLワーキング・グループ (TC68/SC4/WG 10) の傘下で真の標準化に向けて協力することに同意しています。このワーキング・グループは、「銀行業務、証券業務およびその他関連金融サービス(Banking, Securities, and Related Financial Services)」を対象とするISOの専門委員会の一部です。

SWIFT (Society for Worldwide Interbank Financial Telecommunication ) では、独自の通信プロトコルを持っています。このプロトコルは、取引実行後に必要となる、決済などのような事務管理部門での取引操作に焦点を当て、FIXを補完するために現れてきたものです。FIXと同様、SWIFTも最初はXMLデータ形式を使っていませんでした。けれどもISO 15022 XMLワーキング・グループに参加する際に、長年使用してきたデータ・モデルをXMLスキーマ形式に変換することでXMLを主要な表記法として採用したのです。

FpML (Financial Products Markup Language ) (現在4.1になろうとしています)も、XMLベースの交換フォーマットですが、金融派生商品市場という、一般的により複雑で入り組んだ交渉が必要とされる市場での取引のためのものです。FpMLは、金融派生商品関係の主要企業から成る国際的な業界団体であるISDA (International Swaps and Derivatives Association: 国際スワップデリバティブ協会)の成果です。FpMLはSWIFTから使用できる部分(例えば、事務センターの命名規約など)を借用しており、それだけでなくISO 15022やMDDL下記参照)などとともに活動しています。

MDDL (Market Data Definition Language ) (現在バージョン2.3)は、金融商品の取り扱いにおいて、市場価値の分析や取引、収支計算のために必要となるこのようなデータを含めた市場データをXMLによって定義し、そして交換するための協議会標準です。リアルタイムで得られる交換データは、顧客やブローカーなどのような仲介者に通知されて市場取引やその他の取引を促し、(MDDLでの混乱を別として)典型的なデータ交換はすべてXML形式を使用して行われます。MDDLは現在ISO 15022 XML Editionに統合されつつあるところです。

XBRL (eXtensible Business Reporting Language )(現在2.1)は、そのホーム・ページによると「財務報告書やデータの準備・交換のためのXMLベースの仕様」です。これは、様々な組織や団体からなる国際的な協議会によって開発されたものです。XBRLは、公開財務報告書を発行することが義務づけられている全ての組織を対象としているので、本来の対象は金融サービス業界よりもはるかに広いものです。けれども確かにXBRL文書は、さらなる投資情報サービスを分析するための出発点として重要なものです。XBRLは、財務報告書の最も複雑な形式である10Kファイリング(10K filing: アメリカの公開企業に提出が義務づけられている年次会計報告書式の一つ)も処理できるように意図されています。XBRLマークアップは、財務関連のデータ要素の基本的な意味体系を定義したFinancial Reporting Taxonomy Architecture(FRTA: 財務報告用タクソノミを設計する上での推奨規定)における一連のタクソノミに基づいています。そのためトップダウン、ボトムアップ両面から意味体系の透明性を追求するものとなっています。

ISO 15022もまたFIXやSWIFT、その他関連の仕様から採用した基本的なデータ要素のリポジトリを確立することで、トップダウン、ボトムアップ両面からの取り組みを行っています。そうすることでこのリポジトリ内で構築された基本的なデータ・モデルは、XML設計ルールからはずれることなく、首尾一貫した文書標準として出現してくることになります。


まとめ

以前から私は、ソフトウェア業界によって市販パッケージ化されたXMLの内で主流となりつつある幾つかが、実際にはテキスト型のデータであると言う共通語としてのXMLが持つ基本的なビジネス価値を損なうものだと考える人々の中の一人でした。私の経験の大半は、ハイテク企業に対するコンサルティングでしたが、そうした企業では技術の動向は素早く捉えられ、逆にためらいもなく捨て去られてもいました。そのため、どのようにすればXML技術をうまく採用できるか、という点に関しての自分の直感を確認する機会はあまり多くありませんでした。金融業界は必ずしも技術の採用に消極的ではないものの、非常に明確なビジネス上の要求がない限り採用はしませんし、かといってベンダーから取り残されてしまうのも困るのです。私自身の疑念の一端がこの業界と出会ったことで増大させられたことは非常に刺激的でした。


参考文献

著者について

Photo of Uche Ogbuji

Uche Ogbuji は、次世代の Web 技術を専門とするサービスの会社である、Uli, LLC の代表者です。Ogbuji 氏は XML、RDF、およびナレッジ管理アプリケーション用のオープン・ソース・プラットフォームである 4Suite の開発リーダーであり、Versa RDF 照会言語の開発リーダーでもあります。ナイジェリア出身のコンピューター・エンジニア兼ライターで、米国コロラド州ボールダー在住です。彼に関して詳しくは、彼のブログである Copia を見てください。

不正使用の報告のヘルプ

不正使用の報告

ありがとうございます。 このエントリーは、モデレーターの注目フラグが設定されました。


不正使用の報告のヘルプ

不正使用の報告

不正使用の報告の送信に失敗しました。


developerWorks: サイン・イン


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 利用条件

 


お客様が developerWorks に初めてサインインすると、プロフィールが作成されます。 プロフィールで選択した情報は公開されますが、いつでもその情報を編集できます。 お客様の姓名(非表示設定にしていない限り)とディスプレイ・ネームは、投稿するコンテンツと一緒に表示されます。

表示名をお選びください

developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

(半角英数字で3文字以上31文字以下にする必要があります)


「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 利用条件

 


この記事を評価する

コメント

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=XML
ArticleID=241776
ArticleTitle=XML的思索: 金融サービス業界におけるXMLを垣間見る
publish-date=02202004
author1-email=uche@ogbuji.net
author1-email-cc=

タグ

Help
このタグで、My developerWorks のすべてのタイプのコンテンツを見つけるために検索フィールドを使用します。

スライダーバーを使用することで、より多く(少なく)タグを表示します。

人気のタグは、この特定のコンテンツ・ゾーン(例えば、Java テクノロジー、Linux や WebSphere など)に対するトップのタグを表示します。

マイ・タグは、この特定のコンテンツ・ゾーン(例えば、Java テクノロジー、Linux や WebSphere など)に対するお客様ご自身のタグを表示します。

このタグで、My developerWorks のすべてのタイプのコンテンツを見つけるために検索フィールドを使用します。人気のタグは、この特定のコンテンツ・ゾーン(例えば、Java テクノロジー、Linux や WebSphere など)に対するトップのタグを表示します。マイ・タグは、この特定のコンテンツ・ゾーン(例えば、Java テクノロジー、Linux や WebSphere など)に対するお客様ご自身のタグを表示します。