筆者はOMGという国際標準化団体に関わっていたので、そこでの活動の表と裏を見る機会があり、多くを学ぶことが出来た。いちばん感銘を受けたことは、激論やごり押しや根回しといった（どこにでも見られる）風景だけではない、高い知性と公徳心を持つ人々の理性的な議論と、稀にしかお目にかかれない民主主義というものだった。そこでは言葉の壁などは、あまり問題にならない。ちゃんとした技術を持ち、目標を共有している限り、味方はつくれるのである。そうした意味では戦いは「日本対世界」といったものでは絶対にない。
市場の節目を逆算して始める長丁場のゲーム
標準というものが成功するかどうかは、時を得るかどうかにかかっている。いかに周到に準備し、よく出来た仕様でも、市場が標準を待たずに走り出した後では無視されるし、別の標準で代用されて市場の形成が当初の予想と変わることもある。だから標準化のイニシアティブは、市場が動き出すタイミングを読み、その直前に、市場のニーズに最大限応える仕様を、主要なステークホルダーの納得を得られる形で策定し、製品として実現できるようにしなければならない。これは相当な集中を要するスリリングな作業で、強いリーダーシップとチームワークが噛み合わないと成功しない。ゲームにたとえれば、野球やバレーボールよりは、時間制のサッカーやバスケットの試合のようなものだと考えている。
ITなど動きの速い分野では、コンソーシアムの標準化作業に与えられる期間は、ほぼ18ヵ月、プラスマイナス6ヵ月と考えられる。すでに市場で使われている技術の仕様が公開され、そのまま採用される場合はこれよりも速いが、ゼロからスタートする場合はそのくらいはかかってしまう。つまり、市場が動き出す直前（と言っても事前に決まっているわけではない）という1点に向け、そこから逆算する形でスケジュールが立てられる。コンソーシアムにおける標準化のプロセスは、団体や技術の性格、案件によって違いはあるが、おおむね以下のように流れる。
- 市場ニーズや、製品技術、周辺技術、関連標準等についての調査、意見の収集
- 方向性の決定、作業グループ(WG)の設置、スケジュール等の決定
- 対象範囲の限定、目標の設定（提案のための要件）
- 提案の募集と集約、相違点の確認と調整(修正)、草案、最終案の採択
- 理事会(ボード)での採択と最終承認
このプロセスは、最初は漠然としていた事柄について、しだい明確にし、絞り込んでいくもので、途中でその方向性や範囲が市場の現実にそぐわなくなる(最悪の)事態が起きない限り、WGは必ず1点に収束するように運営していかなければならない。そうならないと瓦解し、作業は無駄となり、議長(通常2名)は面子を失うので、リーダーシップはWG設立以前の段階から発揮されなければならない。ここでのんびりしていると、挽回するには相当のエネルギーが要る。議長(名称は様々)の権限＝責任は、実質的に相当に大きい。しかしある程度の独断や裁量が許されるのは、プロフェッショナルとしての力量、人格への信頼と期待があればこそで、議長の地位に付いて回るものではない。
議長は、他のメンバーよりも技術的実績において同格以上であることが求められ、かつ新規参加者や外部との応対において、どんな質問やクレームにも辛抱強く対応できないといけない。ITメーカーには「エヴァンジェリスト」というポストを設けている企業が少なくないが、筆者はWGの議長こそが本物のエヴァンジェリストだと考えている。作業メンバーには自信満々の連中が多いので、対応できないとすぐに学級崩壊が起きかねない。
標準はよい技術を決める場ではなく、競争のルールを決める場である
ここで勘違いしてはならないのは、情報技術の標準化とは、基本的に異なるソフトウェアの間でのデータの互換性や相互運用性、移植性といったことを実現するための共通仕様であって、一番よい実装(製品化)技術を決めようとするコンテストではないことだ。つまり様々な実現方法が前提とされており、製品が違っても、データが読めなかったり、システムとして連携できないようなことがないようにしようというものだ。別の言い方をすれば、競争のルールを決めるのが標準といえる。もちろんルールはプレーヤーの能力やゲームの戦術や局面に大きな影響を与えるので、ゲームの参加者は誰もが重視する。最近は（これをメーカーに任せたくない）ユーザー企業も、ルール作りに積極的に参加するようになっている。IDPFでは、大手出版社やB&Nも参加してEPUBの機能に注文をつけている。
さて、日本では「標準」というと「誰かが決めて、みんなで守らなければならない、法律のようなもの」と考えている人が少なくない。これは大きな誤解だ。ルールはステークホルダー（ユーザー、メーカー、研究機関、政府機関…）すべての要求に応えてつくられるとされるものなので、態度を示さず、要求を出さないと声の大きい人だけで決めてしまう。「さっさと決めてくれ」という態度でいながら、後で不平を言ってもヒンシュクを買う。どうもこれは民主主義の成熟度と関係がありそうで怖いところだ。また、ルールは法律ではないから、守る必要はない。しかしルールを無視するとユーザーの信頼を失うリスクを冒すことになる。
ITの標準が一般社会のルールと違うところは、それを守るかどうか、そしてどのように守るかが個々の主体に任されていることだ。ペナルティはない。標準以外の機能を盛り込んでもよいし、標準にある機能をすべて実現する必要もない。標準への準拠とその証明をユーザーが要求する場合には、第三者機関が試験環境をつくって認証することが多い。しかし、ISO9000などとは違って、例えばEPUBでブラウザのコンプライアンスが問題になるようなことは、たぶんないだろう。
標準化に参加するメーカーの技術者にも「標準技術」というものを理解していない場合が少なくない。日本人に多いのだが、会議の場で自信満々、自社の製品技術についてのプレゼンを行い、いかにもその仕様を標準として採用して欲しいという態度をとることがある。どんなに立派な技術でも、多くの人はこれを聞いて絶句する。場違いなのだ。場違いな発言をすれば子供とみなされる。これは求められているルールではない。彼は、自社の技術を含む、現在と将来の様々な実現方法の間で互換性、相互運用性、移植性を実現するルールについて語らなければならなかったのだ。もちろん、そのためには世の中にある技術、他社の技術について、ある程度以上に知っていることが必要とされている。
標準化というルールづくりのゲームに参加するには、標準化に対するリテラシーが必要だ。それは技術的には、複数の代替手段の違いを超える上位(あるいは基底)技術についての知識であり、また小手先の英語ディベートではない、理性的な議論による合意形成という民主主義の実践能力だ。これさえあれば必ず味方が現れ、助けてくれる。現場では、大企業も個人企業も独りなので、個人の力量がモノをいうのである。 （鎌田、2011-12-05）
