XMLフロンティア探訪
第4回 XML技術者として学ぶべきこととは？

XMLは、さまざまな分野で利用される基盤技術であるため、XML技術者として学ぶべきことの範囲を簡単に決めることができない。では、これからXMLを学ぼうという人は、いったい何を学べばいいのか？ XMLの教育機関の学長でもある筆者が、分野別に「学ぶべきこと」を解説する。（編集局）

川俣 晶
Advanced IT School学長
2001/8/31

今回の主な内容 XMLの教育は難物？ 簡単なのに難しいXML Webデザイナーを目指すなら プログラマを目指すなら データベースエンジニアを目指すなら 企業間電子商取引エンジニアを目指すなら 電子政府エンジニアを目指すなら 文書管理技術者を目指すなら すべてのXML技術を学ぶ必要はない

■XMLの教育は難物？

　筆者は1991年ごろから雑誌原稿の執筆に手を染めるようになり、最初はWindowsを中心に解説を書き、雑誌に「API散歩道」などの連載を書いた。次に、Visual Basic 1.0（英語版）にほれ込んで、Visual Basic 2.0の解説書も書いた。そのほかLinuxを解説したこともあれば、DirectXを解説したこともある。ネットワークプログラミングやJavaを解説したこともある。そしていまは、XMLの解説がメインになってきている。

　このように、いろいろなテクノロジの解説に手を染めて、それなりに情報を伝える方法論というものが筆者の中に出来上がったはずなのに、XMLというのはどうもうまく解説できない。だからといって、それは決して筆者の能力が低下したのが原因ではない。その証拠に、Insider.NETフォーラムで連載中の「C#入門」は、迷わずサクサクと書ける。XMLだけが、筆者にとって、解説しがたい難物なのである。

　そのような状況なのに、Advanced IT School学長などという肩書きをもらってしまった。名前は「IT」というとらえがたいジャンルを示しているが、これは出資者側の好みであって、要はXMLを教える場として企画されたものだ。その場に立ってみると、解説しがたい難物であるというのは、単なる私の個人的な感想ではないことが明らかになってきた。だれがやっても、XML教育は難物なのだと確信するようになってきた。

　だが、いったいどうして、ほかの技術と比較して、そんなにもXMLは難物なのだろうか？ XMLはシンプルで分かりやすい技術ではなかったのだろうか？

■簡単なのに難しいXML

　W3Cが勧告しているXML本体（XML1.0）を「技術」としてとらえ、それを教えるのはそれほど難しいことではない。最近見られる大規模技術の数々と比較すれば、オモチャのように簡単といってもよい。確かに、DTDや実体など少々面倒な部分もあるが、それらを飛ばして学んだとしても、ある程度実用的にXMLを使えるようになる。そういう意味では、XMLを教えることには何も問題がないように思える。

　では、このXML1.0を学ぶことで何ができるようになるのだろうか？ その答えは、XMLで情報を書き表すことができるようになるだけである。書き表した情報は、きれいにレンダリングされてウィンドウの中にレイアウトされるわけではなく、何か有意義な処理が実行されるわけでもない。ただ、情報が記述されて、そこにあるだけだ。たったそれだけの知識を得て、うれしい人はいないだろう。

　では、次のステップに進んだらどうなるのか。ただ情報を書くだけでなく、それを有意義に活用する部分まで含めて学んだらどうなるだろうか？ 確かにそれなら、1つの情報処理プロセスを構築する手法を学ぶことになり、何か立派なことを達成した満足感も得られるだろう。

　だが、ここで重大な問題が発生する。

　XMLを「活用するための技術」にまで踏み込む、というのは簡単だが、具体的にいったい何に踏み込むというのだろうか？

　例えば、XML1.0が提供するのは、静的な文書・データを記述する手段であり、それを能動的に処理するには何らかのプログラム言語／スクリプト言語のたぐいが必要となる。XMLといってもXHTMLやSVGのような定番言語を扱う場合は、専用ソフトが世の中にあるので、プログラミングとは縁を持たずに済ませることもできる。だが、そうでなければ簡易な言語か本格言語かはともかくとして、何らかのプログラム言語／スクリプト言語が使えなければ困る。では、いったい、どれを使えばXML技術者として適切なのだろうか？

　スクリプト言語を使うとしたら、JavaScriptやXSLTなどが考えられる。本格的なプログラミング言語ならJavaやC++の出番が多い。しかし、これらのプログラム言語のどれか1つを学んでも、XMLが登場するすべての状況で十分な技能を持つとはいいがたい。XMLが使われるあらゆる領域に対応することを目指すなら、これらすべての言語を使いこなす必要がある。いや、それだけではない。新しいC#のようなプログラム言語も生まれてくるし、これまで存在した無数のプログラム言語がXML対応を進めているのである。古き良きCOBOLだろうと、マニアしか知らないマイナー言語だろうと、それでXMLを処理する作業が発生しないとは限らない。つまり、全部知らないと、オールマイティなXML技術者にはなれないということだ。

　そんなむちゃなことできっこない、と思った人も多いだろう。

　そのとおり。そんなこと、できるはずがないのだ。

　XMLの応用範囲は極めて広い。併用される技術の種類もとてつもなく多い。それを全て網羅した万能のXML技術者などというものは、空想上の存在に過ぎない。また、それを全て網羅したXML業界のような世界が成立するというのも、空想に過ぎないだろう。

　現実に存在するのは、XMLを知っているJavaプログラマや、XMLを知っているデータベースエンジニアなど、世の中にある個々の分野の専門家が、教養としてXMLを身につけた技術者と言うべきかもしれない。このような切り口になって、初めて、意味のある学習内容についての議論が可能になる。

　というわけで、ここでは「どんなXML技術者を目指すか？」という目的別に、なにを学ぶべきかを考察してみる。

■XMLを知るWebデザイナーを目指すなら

　一口にWebデザイナーといっても、昨今は分業化が進んでおり、一概に○○を学ぶ必要がある、とはいいにくい状況になっている。そのことを踏まえて考えてみる。

　「XMLを知るWebデザイナー」を目指すなら、最低限度XML、名前空間、XHTMLあたりはマスターしておく必要があるだろう。そこから先は、どんな手順で仕事をするかによる。

　直接XHTMLを記述してWebブラウザに表示させて終わりなら、これだけの知識でもできるが、それでは従来のHTMLと比べて代わり映えのしないコンテンツだ。途中で文書の変換を入れて、コンテンツにさまざまな付加価値を付ける余地を持ちたいのなら、何らかのスクリプト言語／プログラム言語を利用することは避けられない。この用途で最もポピュラーなのはXSLTで、サーバ側で使われることもクライアント側で使われることもある。しかし、XSLTは静的な変換しかできず、ユーザーの操作に応じて形が変わるようなダイナミックなコンテンツで使うには向かない。

　ダイナミックな変換には、JavaScriptを用いて、DOM（Document Object Model）を使ってXML文書から情報を取り出したり、データを挿入したりするのが一般的だ。そのため、JavaScriptから使うDOMを学ぶ必要が生じる。サーバ側で変換する場合は、XSLTを使うほかに、Servelet、JSP、ASPなどの選択肢が存在する。Servlet、JSP（JavaServer Pages）ならJavaを、ASP（Active Server Pages）なら、VBScriptなどの言語からDOMやSAX（The Simple API for XML）といった標準APIを用いてXML文書にアクセスするプログラミングを学ぶ必要がある。

　SVG（Scalable Vector Graphics）を用いてコンテンツをリッチにする方法も可能だ。SVGはベクターグラフィックのインターネット標準だが、XML文書として記述される。表示中にDOMを通して中身を書き換えれば、グラフィックスを変化させることができる。そこで、JavaScriptから使うDOMとSVGを学んで、ユーザー操作で変化するビジュアルを持ったページ作りを行うのも1つの選択である。

■XMLを知るプログラマーを目指すなら

　普通のシステム開発、プログラミングを行うプログラマーにも、XMLというキーワードが押し寄せている。例えば、企業間電子商取引といえば、XMLを使うのがいまの流れだ。在庫照会のリクエストがXML文書という形でほかの組織から飛んでくるとなれば、そのシステムを構築するプログラマも、XMLをある程度知らねばならない状況に追い込まれることになる。

　このケースではWebデザインの場合と異なり、美しさや見やすさなどは問題にならない。それよりも重視されるのは、正確さだ。間違った情報を送受信しては、いろいろな意味でトラブルのもとである。ということは、XSLTのスタイルシートのような技術よりも、スキーマ言語の方が重要である。DTD、XML Schema、RELAX NGなどのスキーマ言語の中で、自分に関係しそうな言語をしっかり学ぶ必要がある。もちろん、スキーマ言語によっては送受信する内容をチェックする機能を、プログラミングする可能性も大きい。

　実際にXML文書を送受信することを考えた場合、XML文書の構文解析や単純な送受信は既存のアプリケーションで済むと考えてよいだろう。基本的にプログラマーが知るべきことは、XMLパーサのAPIまでである。XMLパーサのメジャーなAPIには、DOMとSAXの2種類がある。この2つは、それぞれ異なる機能的特徴があるので、どちらか一方だけが主流になるような性格のものではない。できれば両方とも学んでおくとよいだろう。それが無理ならDOMだけでもよいが、SAXは非常にシンプルな仕様なので、学習の負担は大きくないはずだ。

　しかしDOMとSAXを学べば完璧かというと、そうではない。DOMもSAXも低レベルのインターフェイスなので、ソースコードが煩雑になりがちだ。これを一気に改善するものが、前回「Relaxer：XMLがJava開発を変える」で取り上げたRelaxerのようなデータ構造のマッピングツールだ。このようなソフトを使えば、DOMやSAXの詳細を知らないまま、普通のクラスのメンバを処理するだけでXMLを扱うプログラミングが実現してしまう。筆者は、この手のツールがXMLを用いたプログラミングの主流になると考えている。その場合、DOMやSAXの知識は必須ではなくなるかもしれない。XMLを利用するプログラミングのスタイルは、まだ完成されたとはいいがたく、この先しばらくは、さまざまな試みが行われていくだろう。まだ、1つのスタイルに決めつけるには早い。

■XMLを知るデータベースエンジニアを目指すなら

　データベースの情報を交換するためにXMLを利用する、というのはよくある話である。その場合のXMLの位置付けは、さして重要なものではない。要するに、データが欠けることなく確実に相手に届けばよいのであって、XML文書の構造が重要な意味を持つことも、XML文書を加工するということもない。

　そのことから考えると、少なくとも同一データベース間でのデータ交換は、ベンダが提供するXML変換ツールがあれば容易に実現できそうだ。ツールの使い方が分かれば、XML固有の技術を学ぶ必要すらないかもしれない。

　異種データベースソフト間でのデータ交換ということになると、お仕着せのツールではうまく処理できないかもしれない。その場合は、データ構造を定義しているXMLのスキーマ言語を理解する能力と、XSLTのような簡単なスクリプト言語で、XML文書を多少なりとも変形する手順を記述できる技能があるとよいだろう。

　それはさておき、これとは逆のケースもある。つまり、もともとあるXML文書をデータベース化したいという状況も起こり得る。この場合は、容易にリレーショナルデータベースに収まらないケースもあり、XML文書をそのまま格納できるXMLデータベースなどを使わなければならない場合もある。しかし、XMLデータベースはまだ若いジャンルであり、実績豊富なリレーショナルデータベースと同等の使い勝手や信頼性に達していないこともある。それだけでなく、リレーショナルデータベースに特化した方法論やテクニックは、XMLデータベースでは使用できない。そのことから考えると、リレーショナルデータベースのプロフェッショナルを自負していても、XMLデータベースを扱う場合は初心に戻って基本から学び直す必要が生じる可能性もある。この場合は、いくつかの個別技術を学べば済むという状況では済まされない。

■XMLを知る企業間電子商取引エンジニアを目指すなら

　企業間電子商取引は筆者の守備範囲を出てしまうので、詳細を説明することはできない。しかし、明らかにここまで説明してきたケースとは違う傾向の技術知識が必要とされる。上記の「XMLを知るプログラマー」に要求されるのは、すでに詳細が決まった言語として、XML文書の入出力機能を記述することが求められるが、「企業間電子商取引エンジニア」ともなれば、だれかが言語の詳細を決めてくれるだろうとのんびり構えているわけにはいかない。言語の標準を確定させ、それによって記述されたXML文書がどういう組織をどういう経路で流れ、処理されていくかの全体的なシステムデザインを描き出さねばならない。そこで重要なことは、低レベルのDOMやSAXを知っているかどうかではなく、カスタマーの要求を、どうXMLと関連技術の組み合わせで表現していくか、という点にある。

　また、企業間電子商取引は「企業間」というぐらいだから、1つの組織だけで問題を解決することはできない。その結果、常に標準を定め、遵守するということが求められる。既存のebXMLやRosettaNetやBizTalkなどが作り出すさまざまな標準について知っていることはもちろん、その下で機能するSOAPなどのプロトコル系の技術も知っていなければならないだろう。

■XMLを知る電子政府エンジニアを目指すなら

　正直なところ、日本政府の電子政府構想の中で、XMLがどのような位置づけになるのか分からない。しかし、XMLをはやくJIS規格にしてくれ、というリクエストは各方面から出ているので、XMLが電子政府の基盤技術として使われることは間違いないだろう。現時点で「XMLを知る電子政府エンジニア」というカテゴリが成立するかどうか分からないが、この路線を目指すなら、XML本体のほかに安全性を確保する暗号化や電子署名関係などの注目すべきだろう。また、XML対応する帳票システムのようなものも注目しておく価値がある。

　以上は電子申請などを想定したものだが、その他に文書の長期保存の問題があるので、そこは次の「XMLを知る文書管理技術者」と共通の技能が必要になる。

■XMLを知る文書管理技術者を目指すなら

　XMLには、情報の長期保存に向くという特徴がある。長期保存する公文書などを、XML形式で保存すれば、いろいろとメリットがある。例えば、適切なタグ付けが行われていれば、単なる全文検索ではなく、タグの意味から絞り込んで、より精度の高い検索が実現できる。また、基本的にスタイルシートが分離されているので、まったく異なる表示テクノロジの時代になっても、スタイルシートを直すだけで対応が可能になる。

　このような技術を扱う技術者を目指すなら、XMLとスタイルシートはもちろんとして、スキーマ言語の使い方に精通する必要がある。というのは、数十年にもわたって膨大な文書が蓄積された状態で、必要な文書だけを検索して取り出すのは非常に難しいからである。これを少しでもマシにするには、検索を少しでも有利にする意味あるタグ付けを行わねばならない。どんなタグ付けが、後々の検索に役立つかは、そう簡単に分かるものではない。知識を付け、経験を積んで、初めて分かってくるものだ。そして、それを満たすスキーマさえ書けるようになれば、ほかの技術など、些細な問題といえる。

■すべてのXML技術を学ぶ必要はない

　以上を見て分かるとおり、ジャンルによって、学ぶ必要のある技術は大きく変わる。これらのすべてを見通そう、などというのは神ならぬ人間の身には不可能なことといってよいだろう。テクノロジオタクで比較的広い範囲を知っている筆者にしても、全部カバーするにはとうてい足りない。まして、普通にコンピュータを学び、普通に仕事をしている人なら、なおさらだろう。だが、自分のホームグラウンドの世界で必要な技能だけを磨こうと思うなら、けして難しい話ではない。世の中に氾濫するすべてのXML関連技術を学ぶ必要などない。自分が必要とする技能を見極めて、そこに集中しよう。そうすれば、おのずと道は開けるだろう。

「連載 XMLフロンティア探訪」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）