標準化戦略としてのデファクトスタンダードとデジュールスタンダードとの使い分け

小町 祐史
大阪工業大学 情報科学部

1. はじめに

日本規格協会から“デファクト国際会議とデジュール国際会議の違い”についての執筆依頼を受けた。執筆を開始したとき,このテーマの表記に違和感を感じた。デファクトスタンダード,デジュールスタンダードという言葉は標準化の分野でよく使われるが,デファクト国際会議,デジュール国際会議という表現はあまり目にしない。デファクト国際会議とは,もちろんデファクトスタンダードを議論し開発する国際会議という意味であろうことは容易に推察できるが,たとえ標題に用いるにせよ,それをデファクト国際会議とまで短縮するには躊躇を感じる。

そこで本稿ではスタンダードの開発を意図する者がどのように開発過程(つまり国際会議)を選択し,その結果としてデファクトスタンダードまたはデジュールスタンダードが作られたかを検討する。

標準化の話をする際に常に問題となるのが標準化対象分野であり,標準化対象分野を一般化して議論することはかなり困難である。それを一般化することによって議論がほとんど無意味になることも多い。そこでここでは,筆者がこれまで関与してきた情報技術分野について,幾つかの事例に基づき,標準化過程における戦略としてのデファクトスタンダードとデジュールスタンダードとの使い分けを紹介する。

2. デファクトスタンダードとデジュールスタンダード

本稿の多くの読者には冗長な記述になるかもしれないが,確認のため,両スタンダードの意味を次に示す。

(1) デファクトスタンダード
事実上のスタンダードであって,市場での使用実績,実装を前提として合意されることが多い。明示的な標準化組織が存在しないこともあるが,幾つかの関連企業等が集って標準化組織を構成することも多い。

(2) デジュールスタンダード
公的な標準化組織によって開発されたスタンダードであって,国が法基準を適用するときその技術的根拠を示すために採用できる。国際的な公的標準化組織(国際標準化機関)として,IEC(国際電気標準会議), ISO(国際標準化機構), ITU(国際電気通信連合)の3機関がある。

デジュールスタンダードの標準化過程においては,何回にも及ぶ投票,投票結果に関する議論等によって関係者の合意を得ていく際に,原案が大きく修正されることが多い。そこで既に市場で広く利用され実装されている規定内容が変更されることを嫌う場合,または極めて短い開発サイクルの商品に利用される規定を開発する場合に,デファクトスタンダードが採用されることが多かった。既にデファクトスタンダードとして承認されている規定内容をさらにデジュールスタンダードとして追認して,市場拡大を図る戦略が採用されることもある。表1に,CD(コンパクトディスク)に関連するデファクトスタンダードがデジュールスタンダードとして追認された例を示す。

表1 CDに関連するデファクトスタンダードのデジュールスタンダードとしての追認例
番号規定内容デファクトスタンダードデジュールスタンダード
1CD オーディオRed Book: Compact Disc Digital Audio System DescriptionIEC 60908(908), Audio recording -- Compact disc digital audio systems
2CD-ROMの物理的特性,トラックフォーマット,情報の符号化Yellow Book: Compact Disc Read Only Memory System DescriptionISO/IEC 10149, Data interchange on read-only 120mm optical data disc (CD-ROM)
3CD-ROMのボリュームフォーマット及びファイルフォーマットHigh Sierra Format[1]ISO 9660, Volume and file structure of CD-ROM for information interchange

特にWTO/TBT協定(貿易の技術的障害に関する協定)が発効して,国際規格(国際標準化機関が制定した規格)を基礎とした国内規格策定の原則遵守が強く求められるようになってからは,この戦略の採用が増加している。

しかしデジュールスタンダードもその開発過程において,幾つかの加速化手続きを用意して,規格開発期間の短縮を図っており,デファクトスタンダードより制定までの期間が必ずしも長いわけではない。デファクトスタンダードの標準化組織においては,参加メンバの増加に伴って,規格開発手続きが煩雑化する傾向があり,結果として社会的認知の高い標準化組織はデファクトスタンダードといえども発行までにかなりの期間を必要とする。したがって規定したい内容をデファクトスタンダードとして発行するか,デジュールスタンダートを開発するかの選択には,制定・発行までの期間をも要素として含むかなり戦略的な判断を迫られる。

ISO,IECが規定する条件を満たす標準化組織によって開発された規格文書は,加速化手続きを用いて国際規格として追認を受けることができる。この制度を積極的に利用して,ISO,IECの通常手続きによって国際規格を開発するよりも短期間に国際規格を開発できることを売り物にするようなデファクトスタンダード標準化組織も現われている。

3. 戦略としての使い分け

3.1 膠着したデファクトスタンダードをデジュールスタンダードで追撃 -- スキーマ言語の事例

インタネットの普及に大きく寄与したウェブの普及は,HTML(HyperText Markup Language)の標準化によるところが大きい。その標準化作業はIETF(Internet Engineering Task Force)で開始され,その後その作業はW3C(World Wide Web Consortium)に移されて,そこでHTML3.2, HTML4.0が開発され公表された。W3Cでのこの活動は,利用者要求に応える形でXML(Extensible Markup Language)の標準化へと発展した。この時期のW3Cの活動は,ISO/IEC JTC1において1986年に制定され安定した規格であるSGML(Standard Generalised Markup Language)を利用してHTMLを開発すると共に,SGMLをさらに使いやすく拡張してXMLを開発するという,文書記述言語分野でのデファクトスタンダード開発における輝かしい成果を達成した。

しかし当時のW3CのトップはHTMLのより一層の普及を目論んでいたため,XMLの開発に対して理解を示さず,XML開発プロジェクトは幾多の不便を強いられた。そのため,XMLの最大の敵はW3Cであるとすら噂されることがあった。デファクトスタンダードの標準化組織がまだ上り坂にある段階(ルールや手続きが確立途上の段階)では,トップの意向が規格開発に大きく影響することがあることを示す事例である。

XMLの大成功の後,W3Cには多くの企業が参加し,XML関連規定に関する多くのプロジェクトが作られ,そこに多くのエキスパートが参加することになった。その結果,プロジェクトでの議論には多くの時間がかかるようになり,開発過程におけるデファクトスタンダードの利点が失われていった。

この盲点を突いてスキーマ言語の国際標準化を推進したのが,日本の戦略であった。XMLはインスタンスに組み込まれたタグによって,データ構造を示す。データ構造の枠組みを規定するために,SGMLの時代から,独自の構文を用いるDTD(文書型定義)が使われてきた。構文にXMLを用い,データ型の記述を容易にすると共に,モジュール化への配慮をも施して,データ構造の枠組みを規定する言語がスキーマ言語である。

W3CにおけるXML Schemaの議論の膠着状態を打開するため,日本は国内で開発された類似の規定であるRELAXをまず標準情報(TR)として公表[2]し,それをISO/IEC JTC1にFast-track手続きを用いて提案した。この提案に驚いたW3Cは,RELAXの投票期限直前に突然,XML Schemaの勧告を公表した。

文書記述言語における重要技術の国際的合意を日本からの提案に奪われることを嫌った欧米は,RELAXの公表を阻止しようとさまざまな画策をした[3]が,規定内容として洗練されしかも正規の手続きに従って進められたこの日本提案を阻止できず,その提案内容はISO/IEC TR 22250として発行[4]された。

それでもなおスキーマ言語においてリーダシップを取ろうとする欧米は,別のスキーマ言語規格を作る課題提案(NP)を行ってISO/IEC TR 22250を事実上使われないものにしようと画策した。そのNP投票が承認されてDSDL(Document Schema Definition Languages)プロジェクトができると,さらに同様の繰返しを回避するため,欧米は,類似規格の課題提案NPを事前にチェックする手続きをJTC1 Directivesに導入して日本を牽制した。

最初に英国からDSDLプロジェクトに提案された素案をレビューした結果,それが技術的に貧弱なものであったため,日本はそれに全面的に反対して素案の取り下げを求めると共に,DSDLのマルチパート化を提案し,その主要パートを,RELAXをさらに改良したRELAX NG関連規格にすることを目論んだ。

その結果,表2のパート構成の中で主要パートのPart 2, 4が日本提案の国際規格となった。Part 2のRELAX NGは,今ではISO, IECではもちろんのこと,W3Cの関連規格の構造記述にも広く利用されている。 Part 2, 3, 4は既に翻訳されJIS(それぞれJIS X 4177-2, -3, -4)として制定されている。

表2 デファクトスタンダードに対抗して開発されたDSDLの主要パート
パート表題プロジェクトエディタ発行/ステータス
1OverviewMartin BryanCD
2Regular-grammar-based validation -- RELAX NGJames Clark and Makoto Murata2003-12
2 Amd.1RELAX NG Amendment 1: Compact syntaxJames Clark and Makoto Murata2006-01
3Rule-based validation -- SchematronRick Jelliffe2006-06
4Namespace-based validation dispatching languageMakoto Murata2006-06
7Character repertoire description languageMakoto MurataFCD
8Document semantics renaming language (DSRL)Martin BryanFDIS
9Namespace and datatype declaration in Document Type Definitions (DTDs)Francis CaveFDIS

3.2 デファクトスタンダードを経由して加速化手続きを使う国際標準化の問題 -- 文書交換フォーマットの事例

デファクトスタンダードを経由して加速化手続きを用いてISO/IEC JTC1の追認を受けた文書交換フォーマットの二つの事例が話題を呼んでいる。

3.2.1 ODF(オフィス応用のための開放形文書フォーマット,ISO/IEC 26300)

マイクロソフトのWordによるワードプロセッサの独占状態を打開するため,IBM, SunなどはXMLに基づく文書処理系の開発を進め,その交換様式をODF(Open Document Format for Office Applications)としてOASIS(Organization for the Advancement of Structured Information Standards)に提案した。OASISでの承認(OASIS規格ODF 1.0)の後,OASISはISO/IEC JTC1が規定するPAS(Publicity available specification)のFast-track手続きを使ってISO/IEC JTC1でのODFの追認を求めた。

2006年5月を期限とするISO/IEC DIS 26300(ODF)についての投票の結果,反対投票なしでDISが承認された。これはマイクロソフト固有の閉じた仕様からオープンな規定への利用者要求の顕在化と見ることができよう。JTC1/SC34は,JTC1セクレタリアートの助言に従って投票結果対処会議の予定を取消し,OASISのODF TCがコメント対処を行って,改訂テキストとコメント対処とをSC34セクレタリアートが各国に送付して,30日デフォルト投票が開始された。デフォルト投票での承認を受けて,ISO/IEC 26300が2006年12月に出版された。

その後,この規格のJIS化作業に際して幾つもの技術的問題点が明らかになり,日本からのその指摘に基づいてISO/IEC 26300のプロジェクトエディタであるP. Durusauが技術訂正案を用意して,SC34/WG1からリエゾンステートメントをOASISに送付した。しかしOASISでの対応がないため,SC34の中にODFメンテナンスのための作業グループを作ろうとする動きがある。

3.2.2 OOXML(オフィス開放形XMLファイルフォーマット,ISO/IEC 29500)

ODFのISOでの追認に対抗するため,マイクロソフトはWord処理系に基づくXMLベースの交換フォーマットOOXML(Office Open XML)をECMAに提出してECMA規格とした後,ECMAからFast-track手続きを用いてISO/IEC JTC1に提出した。

この規格原案はISO/IEC DIS 29500として配付され,2007年9月を期限とするDIS投票が行われた。日本は次の技術的理由で条件付反対を表明した。
・ほとんどのXML検証器で,規格の一部であるW3C XML Schemaが動作しない。
・IETFの承認なしにpack URIスキームを利用している。
・パッケージ中のパート名としてASCII以外の文字が使えない。
・利用できるスキーマ言語がW3C XML Schemaに限られている。

DIS投票の結果,Pメンバの賛成投票が53.2%であったため原案承認に至らず,膨大な投票コメントに対する対処を検討するため(各国のコメントに基づいてISO/IEC DIS 29500を改善するため)の投票結果対処会議(BRM)が2008年2月にジュネーブで開催された。

このBRMにおいて,日本から提出した主要コメントの中で,OOXMLとODFとの協調要請についてはスコープ外として審議されなかったが,他の主要コメントについては満足すべき対処が行われた。他国からの主要コメントについても積極的な対処が検討され,アクセシビリティの改善,過去との互換性のための機構を切り出すフレームワーク,マルチパート化などに大きな改善がなされた。

BRMの対処結果を考慮して,2008年3月を期限とする再投票が行われ,Pメンバの賛成投票75%を得て,ISO/IEC DIS 29500は承認された。この再投票に際して,日本は賛成を投じている。しかし反対投票を投じた国がこの結果に不満を感じ,特に4ヶ国は承認手続きに対して不服申立て(appeal)を行った。このような議論になると,もはや加速化手続きを使った意味はなくなる。ISO,IECの通常手続きを用いて国際規格を開発するよりも短期間に国際規格を開発できる有料トンネルとも言うべきデファクトスタンダード標準化組織の活動に対する否定的な意見も出始めている。

4. むすび

デファクトスタンダードは,戦略的に使うことによって有効に機能することがあるが,その導入に際してデファクトスタンダードの標準化組織に関する次のようなことに注意する必要がある。

(1) デファクトスタンダードの標準化組織はデジュールスタンダードのそれに比べて,組織としてのライフサイクルが短く,規定内容改訂の頻度,各種ルールの見直しの頻度等が大きい。

備考: RSS 1.0はNetscapeの原案に基づき,RSS-DEV作業グループによって開発された[5]が,その後Userlandによって何度もの改訂の後,RSS 2.0が発表された[6]。名称はRDF Site SummaryからReally Simple Syndicationに修正され,規定内容もRDF(Resource Description Framework)に基づくものから,RDFではないXMLによって記述するものへと拡張された。

(2) デファクトスタンダードの標準化組織はデジュールスタンダードのそれに比べて,組織のトップの影響を受け易く,それに伴って方針の変更,組織の分裂なども起こり易い。

(3) デファクトスタンダードがデジュールスタンダードとして追認された場合,規定内容のメンテナンスに関する責任の所在が不明確になり易い。

(4) デファクトスタンダードがデジュールスタンダードとして追認された場合,それぞれの標準化組織が非同期で規定内容の更新を行って,利用者に混乱を与えることがある。

(5) デファクトスタンダードの標準化組織へのプロジェクトメンバ参加には,かなりの作業量割当てが求められることが多く,他の関連標準化組織への兼任参加を行い難くなることがある。

デファクトスタンダードの標準化組織に関するこれらの特徴を熟知した上で,さらに巧妙かつ適切な標準化戦略の策定を期待したい。

文献

[1] Working paper for information processing -- Volume and file structure of compact read only optical discs for information interchange, CD-ROM Ad Hoc Advisory Committee, 1986-05.
[2] TR X 0029:2000, XML正規言語記述 RELAX コア,2000-05.
[3] 2001年度ネットワークの標準化に関する調査研究委員会(NGN)報告書,INSTAC/JSA, 2002-03.
[4] ISO/IEC TR 22250-1:2002, Information technology -- Document description and processing languages -- Regular Language Description for XML (RELAX) -- Part 1: RELAX Core, 2002-03.
[5] RSS-DEV Working Group: RDF Site Summary (RSS) 1.0, http://web.resource.org/rss/1.0/spec, 2000-12.
[6] RSS Advisory Board: Really Simple Syndication RSS 2.0 Specification, http://www.rssboard.org/rss-2-0, 2002-08.