Page tree
Skip to end of metadata
Go to start of metadata

1) 標準化過程と作業方法

 標準化は,関心を共にする人々のグループによる知的生産活動で,生産結果は標準という文書あるいはソフトウェアです.その過程と作業方法を図10-11にまとめました.

 


図10-11 標準化過程

標準化作業は,作業項目の提案に始まり標準の承認,出版で終わります.一連の作業を動かすのは,作業参加者が提出する寄書です.提案であれ意見表明であれ,全て寄書に書いて表現します.これらを審議する場は,標準化団体によって,あるいは作業レベルによって異なりますが,集まって会議をする,音声会議やウェブ会議などのテレコンファレンスによる,メーリングリストによる,のいずれかあるいは複数が併用されて行われます.標準化作業過程の随所で決定が必要になってきます.参加者の間にコンセンサスの得られることが決定の条件です.

 

 標準化活動は,新たな作業項目の提案から始まります.今までにない技術領域で産業にインパクトがある標準の必要性が予見される,あるいは,ある機能の実現方法,例えばテレビ会議でPCによるプレゼン画面を送る方法,に各社で独自の技術が使われ始め相互には動作しない事態を解決したい,などといった提案です.
 ここで重要なのは,新たな標準が解決すべき問題,要求条件,標準化時期の明確化です.現代では素材となる技術は豊富ですから,問題が明らかになれば解決方法も自ずと見えてくる,と言えます.
 次の段階は実現技術の検討です.一つの問題の解決方法は複数あり得ますので,最初はいろいろなアイデアを出し合う,言わば発散のフェーズを経て,ある時点でまとめに入る,すなわち収束のフェーズに入ります.
 作業結果は,標準草案として文書化し,レビューを重ねることで完成させます.
 これと同時進行で,標準草案に従って実装した技術が確かに要求条件を満たすものであるか,選ばれたパラメータは最適であるかが検証されます.検証方法は,ソフトウェア・シミュレーションによる特性の確認であったり,独立に実装したプロトコルが確かに相互接続できるかの試験であったりします.システム標準(例えばH.323のような)の場合には,机上の検討で全体に矛盾がないかの点検に頼る場合もあります.
 最終段階は,標準草案をあらかじめ定められた会議で承認し,標準の文書を出版することです.
 これら標準化過程の全てで,提案や情報や意見は寄書(寄与文書)にして提出します.文書がなければ何も進まないのが標準化の世界ですので,とにかく書いて(国際標準化では英語で書いて)表現することが求められます.
 寄書に基づく議論は,多くの場合集まっての会議によりますが,音声会議やウェブ会議が補助的に用いられたり,特にIETFではメーリングリスト上の議論が用いられます.
 標準化の過程では,いろんな場面で大なり小なり決定が必要です.決定の方法は,標準化団体が定めています.投票による場合もありますが,多くはコンセンサスに基づく決定がとられています.コンセンサスに至ったか否かは,標準化団体の定めるところ,あるいはグループの判断によりますが,コンセンサスは全会一致のことではありません.ガイドラインとしては,影響力のあるメンバーが持続的に反対しない状態,とされています[10-1].

2) コンセンサスに至る方法

 標準にどの技術を採用するかは,最終的にはグループの総意,智恵,センスで「コンセンサスに至った」と判断して行われます.従って何かお決まりの方法があるという訳ではありません.
 映像符号化標準の場合には,半ば自動的にコンセンサスに至る方法としてレファレンス・モデル手法があります.1984年〜1990年に行われたH.261の作業で開発された方法で,筆者はそのグループのリーダを務めました.
 レファンス・モデル手法を図10-12に示します.テーマは映像符号化ですので,どうすれば効率よく(すなわち低ビットレートで)符号化できるかを目指します.

 

図10-12 コンセンサスをもたらすレファレンス・モデル手法

映像符号化では,コンセンサスに半ば自動的に至る方法として,合意の得られる要素で最初の符号化モデルを作り,次にそれに新たな要素を付け加える提案や既存要素を取り替える提案が行われます.提案の良し悪しはもとのモデルに比べ改善効果があるか否かを数値や映像で確認し,効果ありと認められれば次の符号化モデルに採り入れます.これを何度か繰り返すことで最終のモデル,すまわち標準に到達します.

 

 図10-11のところで述べた発散から収束に転じるタイミングで,誰も異論のない要素を集め,最初の符号化モデルとします.次はこれに新たな要素を付け加える提案,あるいは既存の要素を別のものに取り替える提案がなされます.その有効性の判断は,最初のモデルと比較し符号化に伴う雑音を示すSNRという数値(Signal to Noise Ratio,映像信号レベルSと符号化雑音レベルNの比を表す),あるいは符号化結果の映像を視覚的に確認します.有意な改善効果が認められればその提案は次のモデルに採り入れられます.これを何度か繰り返すことで最終的な標準案に到達します.提案の有効性を分かりやすい物差しで測っている点がミソで,揉めないですむという特徴があります.
 H.261のレファンス・モデルRM1からRM8までの特性がどのように進歩したかを図10-13に示します.H.261では目標のビットレートを最初はn x 384 kbit/sとしていましたが,途中からp x 64 kbit/sに下方修正しましたので,二つの図になっています.

 

図10-13 H.261用レファレンス・モデルの成長模様

H.261の標準化作業ではRM1からRM8まで,専門家グループの会合毎にモデルを更新してゆきました.その成長の跡をSNRで示しています.同じビットレートでだんだんに符号化品質が上がって行った様子が分かります.

 

 この方法は有効な作業方法として認められ,図10-14に示すように以降の符号化標準の作業でも適用されました.

 

図10-14 レファレンス・モデル手法を適用した標準化

レファレンス・モデル手法はH.261標準化で最初に用いられ,標準化作業に有効なことが実証されましたので,最新のH.265/HEVCに至るまで,その後の歴代映像符号化方式標準化に適用されました.そのほかにMPEG-2 AAC音声符号化の作業でも適用されています.

3) 標準化活動が盛り上がる条件

 標準化に長く携わっていると,新たな作業項目が合意され作業が始まった後,活発に展開される場合だけでなく尻すぼみに終わる場合にも遭遇します.どういう条件が整えば標準化活動が盛り上がるかを図10-15に示します.

 

図10-15 盛り上がる標準化活動

標準化作業の中には時間の経過とともに盛り上がって行くものもあれば,途中で勢いを失うものもあります.それを左右する要素を経験に基づいて挙げました.何よりも世の中に必要とされる標準であること,関心を寄せる専門家が5人程度以上いること,が大切です.

 

 まず,産業界が標準を必要としていることが大切です.現在のデジタル放送に採用されているMPEG-2標準を押し進めたのは,1990年代初めに差し迫った衛星デジタル放送のニーズでした.
 一旦動き始めた標準化活動が,その後続いて行くか,さらには盛り上がって行くかは,熱心な専門家の有無が左右します.筆者はenthusiastic fiveと呼んでいますが,3人でも4人でも構いません.核分裂の世界では,連鎖反応が持続する最小の質量をcritical mass(臨界質量)と呼んでいるのになぞらえ,標準化の場合もそう呼んでいます.一人や二人だけが関心を持つテーマでは,うまく展開しない場合が多いと思います.
 本節の冒頭に標準化はグループによる知的生産活動,と述べましたが,グループで行う活動を成功させる智恵の一つは,メンバーが苦労を共にすることです.レファレンス・モデル手法のように同一の符号化モデルを全員が実装し,そのうえに自らの工夫を加えることで,自ずとグループの一体感を醸成しコンセンサスに達しやすくなります.
 標準化を盛り上げるもう一つの要因は,関与する専門家の裾野を広げることです.それには技術情報へのアクセスが容易であることが大切です.IETFの成功要因として,作業グループへの参加が自由で,誰でも作業文書(internet draft)にアクセスできることが挙げられています.レファレンス・モデル手法ではその仕様書が最新の符号化技術を記述していますので,技術情報の普及,さらには専門家の裾野を広げる点でも効果的です.

4) 標準ができるまでの時間

 標準ができるとよいが,どうも手間暇かかって,という反応を耳にします.確かに標準はコンセンサスを基にして作られることから,時間がかかることは否めません.特に利害が反する参加者,企業が加わっている場合にはそうなりがちです.この点から公的標準化機関に提起するのではなく,フォーラムを結成して仕様をすばやく合意しようとする例も見られます.しかし,フォーラムであってもコンセンサスに基づく決定をする限り,潜在的には同じ問題を抱えています.
 標準化作業に最短でどれだけの時間を要するか,を図10-16に示します.

 

図10-16 標準作成に要する期間

ITU-Tでの標準承認手順と,作業開始の提案から実際に標準が承認された期間の最短例(音声翻訳に関わる勧告ITU-T F.745/H.625)を示しています.勧告成立には少なくとも2回のSG (Study Group)レベルの会合を経なければなりません.

 

 これはITU-Tに日本のNICT (National Institute of Information and Communications Technology,独立行政法人情報通信研究機構)から提起された音声翻訳システムの標準(F.745[10-11],H.625 [10-12])に関わる例です.ITU-Tでは少なくとも二つのSG (Study Group)会合を経ることが必要で,SG会合は大凡9ヶ月間隔で開かれます.最後のSG会合で勧告草案を承認手続きに入ることが議決されれば(Consentと呼ばれる),その勧告草案は4週間のLast Callに付され,この間,会合に参加したメンバーもそうでないメンバーも草案を検討し,コメントすることができます.もしコメントが表現上のものだけであればLast Call期間終了をもって承認となり発効します.もし技術内容に関わるコメントが出た場合には,関係者で協議した改訂草案が作られ,さらに3週間のAdditional Reviewが行われます.
 F.745/H.625の場合は,勧告の必要性を提起してから1年弱で勧告草案が作られ承認されました.

 

  • No labels