1
ECOSS のための判定手順の利用の手引き
平成 27 年度版
2015 年 12 月
2 目 次 1 はじめに ... 4 1.1 ECOSS の評価基準が対象とする技術標準分野 ... 5 1.2 利用者の前提知識 ... 5 1.3 文書体系 ... 5 1.4 評価基準のカテゴリーと標準分類 ... 6 1.5 判定項目について ... 6 2 「区分」による標準仕様の整理 ... 8 2.1「区分」とは ... 8 2.2「標準分類」と「区分」による標準仕様の整理 ... 8 3 判定項目の構成と読み方 ... 10 3.1 判定結果を得るための手順 ... 10 3.2 判定結果の種類 ... 11 3.3 当該標準仕様がその評価項目の判定対象とならない場合について ... 11 3.4「注釈」について ... 12 3.5 ECOSS の評価基準の判定対象の 3 つのタイプ ... 14 3.6 判定対象が団体の場合の具体的なケース ... 14 4 「ECOSS のための判定手順」を使って標準仕様の適合性を判定する方法 ... 17 4.1「ECOSS のための判定手順」による評価項目の適合性判定のための準備作業 ... 17 4.2 判定対象となる標準仕様の版の特定 ... 18 4.3「判定作業記録テンプレート」の説明 ... 23 4.4「判定結果一覧表テンプレート」の説明 ... 23 4.5 判定に際してのノウハウ ... 25 附属書A（規定）用語集 ... 27 【参照資料】 ... 34
3 更新履歴 版 日付 内容 1.0 2015 年 10 月 23 日 公開 1.1 2015 年 12 月 4 日 ・ 附属書 B を独立させ、「ECOSS に基づく W3C XML の版特 定作業の例」という資料として公開 ・ “4.2 判定対象となる標準仕様の版の特定”の第１段落に おいて、判定対象を決定するために必要な情報の特定に 関して誤解される表現を修正 ・ “4.3「判定作業記録テンプレート」の説明”及び“4.4「判定 結果一覧表テンプレート」の説明”の誤りを訂正
4 1 はじめに 「情報技術に係るオープンな標準の評価基準（ECOSS）」の中に、調達において優先的に 採用すべきオープンな標準に求められる要件が評価項目としてまとめられている。 ちなみに、「情報技術に係るオープンな標準の評価基準（ECOSS）」に記載されている評 価項目の集合、すなわちオープンな標準を推奨するための評価基準は、欧州委員会が開発・ 公開しているCAMSS（Common Assessment Method for Standards and Specifications） と連携して開発され、欧米諸国ではECOSS（Evaluation Criteria for Open Standards and Specifications）として知られている。以降、オープンな標準を推奨するための評価基準を ECOSS の評価基準と呼ぶ。 ECOSS では、評価基準の各評価項目に対する適合性を、具体的な尺度を用いて表現され た条件を絞り込んで行くことにより客観的に判定するための枠組みを想定しており、これ を「ECOSS のための判定手順」と呼ぶ。図 1 に「情報技術に係るオープンな標準の評価基 準（ECOSS）」と「ECOSS のための判定手順」との関係を示す。「判定手順」では、ECOSS の評価基準の各評価項目に対応して判定項目を作成する。ちなみに、IPA では、「判定手順」 の例として「ECOSS のための判定手順」を独自に提供している。本書は、この「ECOSS のための判定手順」を用いて判定を行う場合の手引き書（解説書）である。 情報技術に係るオープン な標準の評価基準 （ECOSS） ECOSSのための判定手順 評価項目 判定項目 評価項目 評価項目 判定項目 判定項目 図1. ECOSS の評価基準と ECOSS のための判定手順の関係
5 1.1 ECOSS の評価基準が対象とする技術標準分野 ECOSS の評価基準は、情報通信技術（ICT）全般に関わる標準仕様（及びその制定団体） を評価するために用いることができる。 従って、農産物加工、金属加工、建設・土木材料加工などにのみ関わり情報技術とは関 連しない技術標準はECOSS の評価基準による評価の対象とはならないが、それらの分野に 関わるものであっても情報通信技術を使って業務を支援するための標準仕様であれば評価 の対象となる。 1.2 利用者の前提知識 本書の利用者は標準仕様策定に関する以下の知識をもっていることを前提とする。 ・ 情報通信技術（ICT）についての一般的知識を有していること ・ 標準制定団体の資料や仕様書そのものを英語でも読めること ・ 標準仕様の典型的な審議プロセスについて一般的知識を有していること ・ 国際標準化団体（ISO、IEC、ITU-T、ISO/IEC JTC1 など）、国内／地域内の標準化団 体（JISC、ANSI、BSI、CEN/ISSS など）、業界標準化団体（W3C、OASIS、DMTF、 OMG など）についての一般的知識を有していること 1.3 文書体系 本書は、オープンな標準の評価手法に関する一連の文書の一つである。本書を含むオー プンな標準の評価手法に関する文書の体系及び関連文書について以下に記す。 • オープンな標準の評価手法 • 「情報システムに係るオープンな標準の評価基準（ECOSS）」 オープンな標準の評価を行う際に使用する評価項目の提供 • 「情報技術に係るオープンな標準の評価基準（ECOSS）」のための判定手順 IPA として、評価対象の技術標準が各評価項目に合致しているか否かを客観的に判 定するための具体的な判定項目を提供したもの • 「情報技術に係るオープンな標準の評価基準（ECOSS）」判定手順のための利用の 手引き 本書。IPA 提供の判定手順を使用してオープンな標準の判定作業を行うためのガイ ドを提供 情報システムの構築及び調達に際して優先的に採用されるべきオープンな標準を選定す るために用意されたこれら一連の文書を用いて客観的な判定を行うことにより、技術標準 の評価結果が第三者でも検証可能なものとなり、その結果を基にして行われる技術標準選
6 定の信頼性も高いものとなる。 ちなみに、上記のうち「情報技術に係るオープンな標準の評価基準（ECOSS）」は、昨年 度（25 年度版）までは「情報システム調達のための技術参照モデル（TRM） 推奨技術標 準編」又は「情報システム調達のための技術参照モデル（TRM） 本編」として公開されて いる。 1.4 評価基準のカテゴリーと標準分類 「情報技術に係るオープンな標準の評価基準（ECOSS）」では、その「3. 技術標準の評 価指針」において、技術標準を評価するための 6 つのカテゴリー（オープン性、公平性、 業務要件への適合性、相互運用性／可搬性、潜在的発展性、政府規制への準拠）と各々に 含まれる評価項目が設定されている。このカテゴリーは、オープンな標準がもつべき性質 を表したものであり、それら 6 つの観点で判定を行うことによって技術標準を網羅的に評 価することができる。 また、技術標準の規定内容には様々な分類があるが、評価項目は一律にそれらすべてに 適用できるとは限らない。そこで、「情報技術に係るオープンな標準の評価基準（ECOSS）」 では 10 の「標準の分類」（データの記法、メタデータ定義、データ定義、データと構造の 規定、アルゴリズムの記法、プレゼンテーション、API、プロトコル、アルゴリズム、プロ セス要件）を設定し、ある評価項目が、特定の分類には適用できない内容になっている場 合、あるいは、特定の分類を対象とした内容になっている場合、それらを明記している。 これによって、標準仕様の規定内容に合った的確な判定を行うことができる。 このほか、「情報技術に係るオープンな標準の評価基準（ECOSS）」では、評価結果に基 づいて決めるべき標準仕様の推奨度についても規定されている。 1.5 判定項目について 「ECOSS のための判定手順」に記載されている判定項目は、ECOSS の評価基準の各評 価項目に対する具体的な尺度を定めることにより、評価項目に対する適合性を、客観的に 判定できるようにすることを目的としている。 ECOSS の評価基準の評価項目の判定結果は、「情報技術に係るオープンな標準の評価基 準（ECOSS）」の「4.1. 標準仕様の推奨度」で定義されている、例えば、調達仕様書作成に おいて採用すべき、5 つの推奨度（1：必須、2：推奨、3：可能、4：注視、5：除外）のい ずれに標準仕様が該当するかを決定する際の基礎情報として用いることができる。 推奨度は、以下に挙げる作業を順に行うことによって、求められる。 1）ECOSS の評価基準の評価項目それぞれに判定項目を使って客観的に合否（PASS 又 はFAIL 若しくは N/A）を判定する 評価対象となっている標準仕様に対して評価項目への適合性を判定する際、評価項目毎
7 の判定項目で設定されている幾つかの具体的な条件を絞り込んで行くことにより合否が導か れる。 2）それらの判定結果から何らかの方法で定量的な集計データを算出する 適合しているもの（判定結果がPASS となったもの）の数を特定の方針に基づいて計算する ことによって定量的な値を算出する（単純集計、重み付け集計など）。 3）その集計データを基に検討を行い、標準仕様の推奨度を決める ECOSS の評価基準の評価項目の判定結果として得られた定量的な集計データは、例 えば、別途設置される審議委員会などにおいて集計データを基に様々な角度から検討 を行い、標準仕様の推奨度を決める。 「ECOSS のための判定手順」に記載されている判定項目は、1）のみを扱っている。ち なみに、「情報技術に係るオープンな標準の評価基準（ECOSS）」では 1）を実施し、2）に おいて単純集計や重み付けを加えた集計などの方法を用いて数値化した上で、3）について は、審議委員会などを設置し、推奨度を決めることが望ましいとしている。 なお、ここまでの説明から分かるように、本書では、各評価項目に対する適合性を判定 項目に従って判断することを「判定」と呼び、その結果が、総合的な観点で行われるECOSS の評価基準による「評価」の判断材料として用いられる。このように、「判定」と「評価」 という言葉を明確に区別して使っていることに留意されたい。
8 2 「区分」による標準仕様の整理 「情報システムに係るオープンな標準の評価基準（ECOSS）」の「3.2.標準の分類と評価 基準」で説明されている10 の標準分類は、標準仕様の技術的な性質や特長を認識するため の有用な指標である。その上で、判定項目で標準仕様を具体的に判定するために、更に「区 分」という分類を設けた。上記10 の標準分類と「区分」を組み合わせて標準仕様を分類す ることによって、判定項目での判定が可能になる。 2.1「区分」とは 標準仕様として公開されているものは、技術内容の構想に基づくモデル、実装可能な詳 細規定、そして、実装可能な詳細規定の活用に関する指針といった、技術仕様が規定する 対象の抽象性／具体性、及び規定の範囲に対応した幾つかのレベルがある。 大別すると、（1）技術のモデルとなる抽象的な規定「抽象構造」、（2）それを実現するた めの技術仕様として具体化したもの「具体的技術」、（3）それらの実装に際してどのように 利用すればよいかなどの指針となるような活用のための規約「活用規約」、という3 つのレ ベルの標準仕様に分類される。これを「区分」と呼ぶことにする。 （1）抽象構造: 当該技術の内部構成や、他技術との関連における位置付けなどを俯瞰的 ／体系的にモデル化して提示した標準仕様。何らかの技術の概念的なモ デル、アーキテクチャなどを指す。 （2）具体的技術: 当該技術の直接の処理対象として、構造、データ項目、それらに対する 処理内容、手順を規定した標準仕様。 （3）活用規約: 何らかの技術の相互運用性確保を目的とした活用ガイド（ガイドライン）、 オプション機能項目の選択や組み合わせを提供する標準仕様（プロファ イル）などを指す。 2.2「標準分類」と「区分」による標準仕様の整理 「情報システムに係るオープンな標準の評価基準（ECOSS）」の「3.2.標準の分類と評価 基準」で説明されているとおり、評価対象となる標準仕様は、一つ又は複数の標準分類に 属す。さらに、その標準仕様は一つ又は複数の区分に属す。この組み合わせに応じて、評 価対象となる標準仕様は、次の図のマトリクス上の一つ又は複数の箇所に位置付けられる。
9 メタデータ 定義 データ 定義 データと 構造の 規定 アルゴリ ズムの 記法 API プロトコル アルゴリ ズム プロセス 要件 標準/仕様 の分類 プレゼン テーション 具体的技術 活用規約 抽象構造 区分 データ の記法 図 2. 「標準分類」と「区分」のマトリクス このようにして、標準仕様の評価を行う前に評価対象の標準仕様がどの標準分類及び区 分に属すかを決めておくことにより、標準仕様の属する区分を問う条件の判定や特定の標 準分類を除外する評価項目の判定の際、その結果を用いることができる。
10 3 判定項目の構成と読み方 各評価項目の判定に使う判定項目は以下のような構成となっている。 表 1. 判定項目の例 【評価項目識別子】 （《対象とする標準分類: xxxx》あるいは《除外となる標準分類：yyyy》、特に記述がない場 合は標準分類を特定しない。） 【評価項目】 【判定項目】 ＜判定対象＞ ※【前提条件】"標準仕様を判定するための下記の表の条件が、他の評価項目の判定結果 や標準仕様の特定の状態を前提として設定されている場合、その前提条件を示すとともに、 前提を満たさない場合の判定結果を示している。" 条件1 条件2 結果 判定対象 場合分け 判定対象 場合分け 【判定にあたっ て検討すべき内 容、論題、題材】 【選択肢１】 【判定にあたって検 討すべき内容、論題、 題材】 【選択肢1】 【判定結果】 【選択肢2】 【判定結果】 【選択肢3】 【判定結果】 【選択肢2】 【判定にあたって検 討すべき内容、論題、 題材】 【選択肢1】 【判定結果】 【選択肢2】 【判定結果】 【選択肢3】（※1） 【判定結果】 ※1）【注釈】"判定項目の表中のどこかで「（※α）」とマーク付けのある箇所についての説明" 3.1 判定結果を得るための手順 判定項目では、以下のような手順を実施することにより判定結果が得ることができる。 「条件1」や「条件 2」などは、上記のように「判定対象」と「場合分け」の対で構 成されている。「判定対象」について考慮した結果、該当する選択肢（例えば【選択 肢1】）を見つけ、それに対応する行の右の条件の欄（「条件 2」や「条件 3」）に進む。 そして、結果欄に到達するまでこれを繰り返す。 上記の「条件2」の欄の最下段が空欄になっているが、このように「判定対象」と「場 合分け」の欄が繋がって空欄になっている場合、その手前で判定が終了しており、 その行の右端の結果欄にその【判定結果】が記されている。
11 3.2 判定結果の種類 【判定結果】は、以下の3 種類である。 PASS：評価項目を満たしていると判定された場合 FAIL：評価項目を満たしていないと判定された場合 N/A：当該標準仕様がその評価項目の判定対象とならない場合 なお、後述するように、この欄に注釈のマークが入る場合もある。 3.3 当該標準仕様がその評価項目の判定対象とならない場合について N/A（Not Applicable）は「該当せず」という意味で、「ECOSS のための判定手順」にお いては、評価対象となっている標準仕様が当該評価項目で判定不能な場合（評価項目で問 われている内容が当該標準仕様の技術や規定内容と関係ないなど）に用いる。 N/A となるケースとしては、以下のような場合が考えられる。 ■特定の標準分類が N/A となるケース 「情報システムに係るオープンな標準の評価基準（ECOSS）」の「3.2.10.プロセス 要件」に記述されているように、特定の標準分類に属する標準仕様が、その技術的な 性質上、特定の評価項目の判定対象として当てはまらない場合がある。そのような標 準仕様は、その評価項目に対しては判定対象とはならないのでN/A となる。 このケースについては、「情報システムに係るオープンな標準の評価基準（ECOSS）」 の「3.2.10.プロセス要件」でも、標準分類「プロセス要件」が判定対象とならない評 価項目であることが列挙されているが、「ECOSS のための判定手順」においても、評 価項目識別子の下に「≪―プロセス要件除外―≫」と記されており、どの評価項目に 対しどの標準分類が判定対象外かが分かるようになっている。その場合、判定は N/A となり、判定項目の表による判定は行わない。 ■何らかの条件によって標準仕様の内容に関係なく N/A となるケース 判定項目の表を使って判定を進める中で、何らかの条件でその内容が標準仕様の内 容と関係なく、判定対象外となる場合がある。その場合、判定はN/A となる。 2. で記したように、標準仕様は、「抽象構造」「具体的技術」「活用規約」のいずれか の区分に分類されるが、それぞれの区分の性質上、評価項目の判定対象にならない場 合（例えば、活用規約の存在を問う評価項目に対しては「活用規約」に属する標準仕 様は判定対象とならない、実装に関する評価項目に対しては「抽象構造」に属する標
12 準仕様は判定対象とならない、など）がこのケースの一例である。 3.4「注釈」について 前項の「表1. 判定項目の例」で説明した【注釈】は、表中に用いる短い文だけでは表現 し切れない情報を記述するために用いられる。注釈として表現される情報の内容をタイプ 分けすると以下のようなものが考えられる。 追加・詳細説明 判定項目の表の中で表された短い文だけでは表現し切れない情報を記述する 例）"※）電子データ（XML スキーマファイルなど）を CD-ROM／ダウンロードな どで入手可能。" 用語説明 判定項目内で使った用語について、その意味を解説する 例）"※）"特権条項"とは「拒否権を有する者が存在する」「複数の議決権を有する議 決権者が存在する（ある企業が複数の代表を委員会に参加させることが可能で あり、それぞれが議決権をもっている場合を含む）」などを指す。" 例示 判定項目の内容の理解を促進するため、例を用いて説明する 例）"※）「特定の OS に依存」「特定のハードウェアに依存」など。" 判定のための補足説明 特定の状況の判定の仕方についての補足説明を行い、判定をガイドする。 例）"※）「定期性」についてはその間隔に違いがあるかもしれないので、それは問わ ない。" "※）実際に改定されていなくても、改定しようとしたことが分かる根拠（資料 や情報）があればよい。" 具体的判断材料 数値や具体的状況を基準として提示する。 例）"※）例えば、活用規約がガイドラインであって、対象分野にそのガイドライン を活用した実装・サービスの割合が 30%以上である場合、活用規約がプロファ イルであって、その実装した製品が 5 つ以上ある場合（同一ベンダーが開発す る複数の製品に同一機能を組み込む場合は1 つとみなす）、など。"
13 特定ケースの扱い 具体的な事例や状況を挙げ、その場合にどう判定を行うかを説明する。 例）"※）委員会への報告、技術論文、技術情報誌などでの指摘があれば「該当する」 とする。" 作業指示 合否を決めるだけでなく、何らかの資料を作成して添付するよう求めるなどの指示。 例えば、次のように、判定にあたって調査した内容をリストアップして根拠を残し、 後からその正当性を確認できるようにするためのものがある。 例）"※）参照している数及び具体的な標準仕様の名称も記録する。" "※）具体的な製品やサービスの名称を記録する。" これらに加え、表を簡略化するため便宜的に注釈を用い、以下のような情報を表現して いる場合もある。 条件文／GOTO 文 何らかの条件を提示し、その結果に応じて合否の判断を行ったり、表中の条件判断 に進むなどの指示を与える。 例）"※）対象となる具体的技術が直接間接を問わず存在すれば、それに対して具体 的技術の条件2 で判定する。それ以外は FAIL。" "※）具体的技術が存在し、かつ、その標準仕様の改版があれば、それに対して 具体的技術の条件 2 を判定する。具体的技術が存在しない、あるいは存在して も標準仕様の改版（バージョン）がなければN/A。" 評価対象変更 現在評価対象としている標準仕様から、関連する他の標準仕様に評価対象を切り替 えて判定を進める（次の条件に進む）という指示。 例）"※）活用規約については、対象となる具体的技術について判断する。そして、 その名称を記録する。"
14 3.5 ECOSS の評価基準の判定対象の 3 つのタイプ ECOSS の評価基準の評価項目の判定の対象は、大きく以下の 3 つのタイプに分類される。 分類は、判定項目の＜判定対象＞の箇所で以下のように記載される。 ＜標準仕様＞ 技術標準の仕様書自体 標準仕様の技術的優位性を評価するため、標準仕様が規定する技術の有用性や仕様 書としての記述内容の完成度など、標準仕様そのものに関わる特性を判定対象とす る。これに該当する評価項目では、技術としてのオープン性、独立性、公平性、妥 当性、可搬性と相互運用性、将来性、成熟度、などの観点で標準仕様を判定する。 なお、政府規制への準拠の観点での判定も標準仕様を対象に行う。 ＜団体＞ 技術標準を開発及び保守する団体 標準仕様を策定し保守する団体がオープンな標準仕様の開発に相応しい健全性を備 えているかどうかを評価するため、団体の組織としての形態や運営方針、技術審議 における意思決定方針など、標準化団体の仕組みや特徴を判定対象とする。これに 該当する評価項目では、団体としてのオープン性、公平性、妥当性、などの観点で 団体を判定する。標準化団体をまたがって開発される標準仕様も存在する。その場 合3.6 参照のこと。 ＜環境＞ 技術標準の実装又は実施の状況 標準仕様を選択した場合に、それが実際に容易に活用できるかどうかを評価するた め、実装製品の採用状況など、標準仕様を取り巻く環境を判定対象とする。これに 該当する評価項目では、実装製品の市場における普及度、また例えば、可搬性や相 互運用性などの観点で問題がなかったか、など標準仕様の実装や実施に関連した 様々な状況を判定する。 3.6 判定対象が団体の場合の具体的なケース ECOSS の評価基準の評価項目には、標準仕様自体を評価する項目、標準仕様の活用状況 や普及度合い、対象となる標準仕様の策定及び保守を行った団体を評価する評価項目が存 在する。 団体に対する評価は、「提案」→「審議」→「承認」、というプロセスを実際に行った標 準化団体及び担当委員会を評価することになる。このプロセスは一般には同一団体内で完 結するが、例外的に複数の団体にまたがって、若しくは重複して行われることがある。 団体をまたがって標準化作業が行われる例としては、業界団体で標準仕様が開発・承認 されて業界標準となった後に国際標準化団体に提出され、国際標準化団体としての審議を
15
経て国際規格として承認・公開される場合がある（例えば、ISO/IEC JTC1 には、PAS （Publicly Available Specification）あるいは Fast Track という審議／承認形態があり、 OASIS の OpenDocument1.0 が、JTC1 での PAS 審議を経て ISO/IEC 26300:2006 とな った）。他にも、業界団体を JIS（日本工業規格）として制定する場合や、JIS から国際標 準化団体へ標準が提出され国際規格として承認・公開される場合もある。さらに、国際規 格をJIS 化するという場合も考えられる。
これらのケースを分類すると以下のようになる。
A: 業 界 標 準 や 国 内 規 格 か ら 国 際 規 格 （ ISO 、 IEC 、 JTC1 の IS 、 ITU-T の Recommendation）になるケース B: 業界標準から国内規格（日本の場合は JIS）になるケース C: 国際規格から国内規格になるケース A については、当該標準仕様が国際標準化団体に対して他団体から提出されたものの場合、 提出元の標準化団体及び最終的に当該標準仕様を承認した国際標準化団体の両方を判定対 象とすることになる。 B も同様に、業界標準化団体と国内規格の審議団体である日本工業標準調査会（JISC） の両方を判定対象とすることになる。 また、C についても、国際規格を開発・承認した国際標準化団体、それを翻訳するなどし て国内規格として承認した日本工業標準調査会（JISC）の両方を判定対象とする。 さらに、これらの組み合わせで、例えば、業界標準化団体から国内規格となり、更に国 際標準化団体に提出されて国際規格となった場合も考えられるが、その場合、当該標準仕 様を最初に開発・承認した業界標準化団体、国内標準化団体（JISC）、国際規格として承認 した国際標準化団体の3 団体を判定対象とすることになる。 つまり、当該標準仕様が、他の団体での標準仕様制定を経て当該標準化団体に提出され たものの場合、その審議に関わった団体が 2 つあるいはそれ以上存在することになるが、 関わった団体は全て判定の対象とする。 このように、複数の団体が標準仕様の開発・承認に関係する場合、判定対象を明確にす るため、判定項目に以下の＜団体：＞が記載されているので、説明に従って対象とする団 体を特定する。 ＜団体：開発元／承認＞ 業界標準や国内規格から国際規格 当該標準仕様が、他の団体での標準仕様制定を経て当該標準化団体に提出されたも のの場合、当該標準仕様に至るまでの標準仕様を策定した団体すべてを判定対象に 含める。全てこの判定項目によって評価項目に適合していると判定されれば、当該 標準仕様がこの評価項目に適合していると判定する。
16 ＜団体：開発元＞ 業界標準から国内規格 当該標準仕様が、他の団体での標準仕様制定を経て当該標準化団体に提出されたも のの場合でも、技術審議を行った主たる開発元の団体を判定対象とする。 ＜団体：承認＞ 国際規格から国内規格 当該標準仕様が、他の団体での標準仕様制定を経て当該標準化団体に提出されたも のの場合でも、最終的に当該標準仕様を承認した団体を判定対象とする。 また、技術標準の開発プロセスにおいては、国際規格を含む標準制定後、メンテナンスの プロセスが存在する。このため、標準仕様のメンテナンスのみに注目した評価項目が存在 するため、以下に従って対処する。 ＜団体：メンテナンス＞ 実際にメンテナンスを行っている団体を判定対象とする。
17 4 「ECOSS のための判定手順」を使って標準仕様の適合性を判定する方法 「ECOSS のための判定手順」を使って評価項目の適合性判定を行う際、調査すべき関連 資料は事前に準備しておくとよい。また、標準仕様の技術的概要や制定経緯などの背景情 報を予備知識として得ておくことは判定時の参考になる。さらに実務工程として、判定に 入る前に判定対象とする版を決める必要があり、判定時には、判定結果とその根拠となる 情報などを統一書式で記録することにより、判定の客観性を担保すると共に他者による妥 当性の検証を容易にする。さらに、他者が行った判定／評価の結果の容易な再利用が可能 になる。この目的を達成するために、判定結果を記録するための統一書式として、判定作 業記録テンプレート及び判定結果一覧表テンプレートという２つのテンプレートを提供し ている。 このように、実際の判定を行うあたって行うべき準備なども、ECOSS の評価基準を用い た技術標準の評価の工程の重要な一部である。 そこで以下に、判定前や判定時の具体的な作業の進め方について説明する。 4.1「ECOSS のための判定手順」による評価項目の適合性判定のための準備作業 「ECOSS のための判定手順」を用いた評価項目の適合性判定には、団体が公開している 様々な情報が必要である。そこで、事前に所在を確認して準備しておくべき主な資料を以 下に記す。 なお、これらの資料は、その有無自体も判定対象となることもあるので、見つからない 場合にはその旨記録しておくとよい。また、下記の内容を収めた資料の名称は様々であり、 幾つかの情報が一つの資料にまとめて記載されている場合もある。 4.1.1 標準仕様関連の資料の準備 実際に標準仕様を調査し、「ECOSS のための判定手順」を使って評価項目の適合性を判 定するには、まず標準仕様を入手する必要がある。また、標準化団体などが発行している 技術解説資料も参考になる。 ■ 標準仕様の内容に関する資料 －判定対象となっている標準仕様 －当該標準仕様の技術解説資料（入門解説、活用ガイド、ホワイトペーパ、など） 4.1.2 標準化団体関連の資料の準備 標準化団体についての評価項目の判定を行うには、団体の構成、運営形態、技術審議の 体制などを調査する必要がある。このため、以下のような資料を探しておくとよい。
18 ■ 団体の運営に関する資料 －決算報告 －年次報告 －定款／運営規約 －議事録／決議録 －倫理規定 －知的財産権（IPR）に関する規定 －会員リスト ■ 技術審議に関する資料 －技術審議規約 －議事録／決議録 －委員会設立趣旨書 －委員会参加者リスト 4.2 判定対象となる標準仕様の版の特定 ECOSS を用いて判定の対象となる標準仕様を判定するには、「標準化団体名」「標準仕様 名」「版」の 3 つが指定されていなければ判定できないが、「標準仕様名」のみが指定され 判定対象として依頼されることがある。その場合には、「標準仕様名」に加えて「標準化団 体名」及び「版」を特定しなければならない。 標準仕様名が与えられれば、標準団体名が連想できるが、必ずしもそれが意図した標準 仕様の団体とは限らない。例えば、同じ内容の標準でも、"OpenDocument"と言えば 「OASIS」、"ISO/IEC 26300"と言えば「JTC1」というように、標準化団体が連想されるが、 "OpenDocument"と呼んで「JTC1」で審議された"ISO/IEC 26300"を指すことがあり得る。 したがって、「標準化団体名」及び「標準仕様名」を各々特定する必要がある。 「版」について言えば、多くの場合、一つの標準仕様でも、改定が行われ、複数の版が 存在する。その場合、どの版を判定対象とするかを決めなければ具体的な判定を行うこと はできない。そこで以下に、版の区別、そして判定対象となる標準仕様の版を特定するた めの事前調査作業について説明する。 4.2.1 標準仕様の改版に伴う比較の考え方 標準仕様の開発には、原案作成から標準制定、そして廃止に至るまでのライフサイクル が存在する。そして多くの場合、その中で何度か改版が行われるが、改版は、表記の誤り 訂正、説明文の明確化などの修正を行う編集上（Editorial）の改版、機能の追加・変更な どの技術上（Technical）の改版など、その内容の程度は様々であり、それに応じて改版の 呼称が定められている。
19 したがって、標準仕様のどの版を判定対象とするかの検討にあたっては、当該標準化団 体での改版の呼称とそれが表す改版内容の程度を理解しておくことも必要であり、それは 的確な版選定に役立つ。このことは、改版に関する評価項目の判定において、比較すべき 他の版の候補を選定する場合においても同様である。 4.2.2 判定対象となる標準仕様の版の特定のシナリオ 「標準仕様名」と「標準化団体名」が決まったとしても、版が指定されていない場合に は、複数の版の中から特定の版を選定することになる。 ■判定対象特定のシナリオ 1) 特定の版が指定される 指定された版の標準仕様を入手し、判定を行う。 2) 標準仕様名のみ指定される 2-1) 標準仕様に一つの版しか存在しなければ、その標準仕様を入手し、判定作業に 入る。→「1) 特定の版が指定される」とする。 2-2) 標準仕様に複数の版が存在すれば、Web などで公開されている技術資料、解説 資料などから現在最も普及していると思われる版を探す。（まずは最新版が普 及しているかどうか調査し、それが使われていないと思われる場合は他の版に ついての解説資料があるかどうか調べる） ※ここでの版の選定では、以前に選定した版は除いて探す。 a) 当該版の普及度を知るために、ECOSS のサブセットとして、判定項目 （E44-01）「多くの標準から参照されている」の「(a) 当該版（バージ ョン）及び、（E44-04）「複数の独立した採用実績がある」の「(a) 当該 版（バージョン）自体に関する評価」）を調べる。 a-1) 両方とも PASS であれば、その版を判定対象として確定し、標準 仕様の判定に入る。→1)
a-2) いずれかが FAIL であれば、Web などで公開されている技術資料、 解説資料などを基に他の版を選び、a)を繰り返す
どの版もa-1)に至らなければ、最初に選定した版と最新版の 2 つを候補とする。 →「1) 特定の版が指定される」とする。
20 ECOSSサブセット （(E44-01)(a)、 (E44-04)(a)）が両 方ともPASS Web情報などに基づく 候補の選定
ECOSS
による判定
標準仕様
名の指定
（標準化団体の 指定を含む） No Yes Output 別の版が 存在 複数の版が 存在 Yes No Yes No 最初に選定した版と最 新版の2つを候補とする 版が指定 されている No （版指定なし） Yes (特定版指定) ※[Web 情報などに基づく候補の選定]では、以前に選定した版は除いて選定する。21 業界標準が国際標準化団体に持ち込まれて国際規格となり、その後も業界標準と国際規 格が同期をとって改定されるものの場合、業界標準と国際規格は同等とみなされて、製品 実装において、業界標準名のみがサポートしている標準として示されることがある（例外 的にその逆もあり得る）。このような場合、上記シナリオの（E44-04）「複数の独立した採 用実績がある」の判定においては、同等な業界標準のサポートしている実装製品は、国際 規格をサポートしているとみなす（例：ISO/IEC10646 と Unicode）。 これを示すため、該当する評価項目には、以下のような説明が記されている。 ※）当該標準仕様が国際規格であり、それと同等な業界標準仕様が存在する場合（例え ば、業界標準がJTC1 に PAS や Fast Track で提出され国際規格となったなど）、同等 の業界標準仕様を適用している実装製品やサービスは、当該国際規格を適用している とみなす。 4.2.3 標準仕様のプロファイル情報 上記のシナリオを使って判定対象となる標準仕様が決まり、判定を始めることになる。 その際、判定対象となった標準仕様の以下のプロファイル情報は、後述する「判定作業記 録テンプレート」と「判定結果一覧表テンプレート」に記載する。 ■ 標準仕様のプロファイル情報 －標準仕様名／版番号 －発行年月日 －当該標準仕様の入手先（及びそのURL） －標準化団体名（及びそのURL） －代替名称 －言語 －標準分類 －区分
22 記述例：
－標準仕様名／版番号：
ISO/IEC 10646:2003 Information technology – Universal Coded Character Set (UCS) 及び追補※（Amd：Amendment）1～6
（これらが定義した文字はUnicode5.2 と同一である） －発行年月日： 2003 年 12 月 15 日 （ISO/IEC 10646:2003） 2005 年 11 月 15 日 （ISO/IEC 10646:2003/Amd.1:2005） 2006 年 7 月 1 日 （ISO/IEC 10646:2003/Amd.2:2006） 2008 年 2 月 15 日 （ISO/IEC 10646:2003/Amd.3:2008） 2008 年 7 月 1 日 （ISO/IEC 10646:2003/Amd.4:2008） 2008 年 12 月 1 日 （ISO/IEC 10646:2003/Amd.5:2008） 2009 月 10 月 13 日 （ISO/IEC 10646:2003/Amd 6:2009） －当該標準仕様の入手先：最新の標準仕様は以下のサイトから入手可能だが、当該標準 仕様は廃止（最新の標準仕様に含まれる）。 URL：http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=63182 Unicode5.2（http://www.unicode.org/versions/Unicode5.2.0/） －標準化団体名：ISO/IEC JTC1 URL：http://www.iso.org/iso/jtc1_home.html
－代替名称：Universal Coded Character Set (UCS) －言語：英語 －標準分類：「データと構造の規定」 －区分：「具体的技術」 ※"追補（Amendment）"とは、JTC1 の用語であり、JTC1 の国際標準に対する技術的規定の追加・ 変更のため、標準とは別に出版される資料のことである。この追補が累積されると、それらの改定を 標準本体に統合した新しい版が出版される。このように、JTC1 では、標準本体はそのまま残して" 追補"や"技術修正（Technical Corrigenda）"を別文書として出すという改定の方法をとることがある。 なお、"追補"は技術規定の改変や追加なので改版とみなすが、"技術修正"はエラー修正や曖昧性の排 除であるので、改版とはみなさない。
23 4.3「判定作業記録テンプレート」の説明 「ECOSS のための判定手順」による評価項目の適合性判定を行う際には、【結果】【根拠】 【関連URL】を書き込むことのできる以下のようなテンプレートを用いるとよい。 ―――――――――――――――――――――――――――――――――――――――― ■（E01-01） 【評価項目】 団体の運営に関する規約類が一般に公開されている 【判定項目】 条件1 結果 評価要素 場合分け 団体の規約類の閲覧・入手が団体メンバー以 外でも可 該当する（※1） PASS 該当しない（※2） FAIL ※1）入手可能であれば、何らかの手段（インターネット、メール、書面など）での登録（申請）などの手 続きを求められてもよいこととする ※2）規約類とは、団体の運営全般に関わる、定款、規約（By-Laws）などを指す 【結果】 【根拠】 【関連URL】 ―――――――――――――――――――――――――――――――――――――――― 【結果】には、適合性判定の結果（PASS、FAIL、あるいは N/A）を記す。 【根拠】には、その判定結果に至った理由を説明する文章などを記す。 【関連 URL】には、判定を行うにあたって使った資料の URL を記す。特記がない場合で も、必ず判定した根拠となる情報（資料、URL など）を記録すること。 4.4「判定結果一覧表テンプレート」の説明 前述の「判定結果一覧表テンプレート」からは、評価項目一つ一つの判定結果について 記録することができるが、判定結果を全体として一覧することはできない。そこで、スプ
24 レッドシート形式などで判定結果を一覧できるような以下のようなテンプレートを用意し、 判定結果を記載すると視覚的に把握し易い。 これは、「標準仕様名」「版番号」「評価の日付」「標準仕様の入手先URL」「標準化団体」 「標準制定の日付」を記した上で、各評価項目の合否、及び備考を入力する形式となって いる。 さらに、このテンプレートの末尾には、全体の評価を通して気づいた点や所感、評価対 象とした団体・委員会の情報を記録する。 開発元団体： 開発元委員会： 承認団体： 承認委員会： メンテナンス担当団体： メンテナンス担当委員会： ＜所感＞ ＜テストをした際の評価対象団体の情報＞
25 4.5 判定に際してのノウハウ 4.5.1 技術的に同等な標準仕様の判定 3.6 節で挙げたように、技術的には同等と考えられる標準仕様が複数の団体にまたがって 制定され、結果的に複数の標準仕様名をもつことがある。その際、4.1 節で説明した、 「ECOSS のための判定手順」による評価項目の適合性判定のための準備作業に先立ち、ど の団体が制定した標準仕様を判定対象とするのかを決定し、その標準仕様名を確定してお く必要がある。制定団体が異なるが技術的に同等であると考えられる複数の標準仕様をそ れぞれ判定した結果は、一般には制定団体を対象とする評価項目の判定のみが異なること になると考えられる。 4.5.2 標準仕様に関する情報収集 実際に標準仕様を調査し、判定項目を使って評価項目の適合性を判定するには、その標 準仕様の技術概要、開発経緯、主な実装製品などを知っておくと役に立つ。 そのような情報は、例えば、技術専門誌や Web の技術関連サイトの標準仕様の解説記事 などで得られるので、ECOSS を用いた標準仕様の判定を行う前に簡単に調査し、予備知識 を得ておくとよい。 4.5.3 標準仕様／団体規約の入手の可否と判定結果 ECOSS を用いた判定を行う際に、標準仕様又は団体規約が入手でき、それが日本語ある いは英語で読めることが判定にとって必要となる判定項目がある。 団体の規約類が入手できること（（E01-01）の判定結果が PASS）が前提となる判定項目： （E01-04）（E01-05）（E01-06）（E01-07）（E01-08）（E01-09）（E02-01）（E02-02）（E02-03） （E02-05）（E02-06）（E02-10 -a）（E04-01）（E11-01）（E11-02）（E12-02）（E12-01） （E13-01）（E13-02）（E13-03）（E13-04）（E15-01）（E15-02）（E26-02）（E26-03）
仕様書が日本語又は英語で提供されていること（（E03-03）の判定結果が PASS）が前提と なる判定項目：
（E03-02）（E03-04）（E05-01）（E05-02）（E05-03）（E05-04）（E06-02）（E07-01）（E21-02） （E23-01）（E23-02）（E24-02）（E25-01）（E25-04）（E25-02）（E25-05）（E31-01）（E32-01） （E33-03）（E34-01）（E34-03）（E41-01）（E41-03）（E41-02）（E42-01）（E43-03）（E45-01）
4.5.4 「データ形式」と標準分類との関係
評価項目（E05-01）（E05-02）（E05-03）（E05-04）で用いられている“データ形式”と いう表現は、標準分類の「データの記法」のことを指している。したがって、これらの判
26 定手順の条件 1 の判定要素「当該標準仕様の実現に必要なデータ形式がある」は、当該標 準仕様を実現するために何らかの「データの記法」を使っているかどうかを問うものであ る。「データの記法」は、自分自身をデータ形式と見なす。この前提に基づいて「データ定 義」、「メタデータ定義」、「データと構造の定義」と「データ形式」の関係を考えると以下 のようになる。 「データ定義」については、例えばOOXML は XML というデータの記法を基底と し、X.509 証明書は、ASN.1 エンコーディングというデータの記法を基底としてい る。したがって「データ定義」はデータ形式を必要とする。 「メタデータ定義」では当該標準内に構文を規定しているが、その構文の表記に「デ ータの記法」を用いる場合がある。例えば、XML Schema では、構文に XML を用 いている。このように、「メタデータ定義」にデータ形式が存在する場合がある。 「データと構造の定義」では、「メタデータ定義」と同様に、データを何らかの表記 を用いて表す場合がある。例えば、ISO/IEC 10646 では、コードポイントを表す UID の形式として"U+"（オプション）の後に 16 進数を 4 桁~6 桁で表記する。したがっ て「データと構造の定義」中でデータ形式を用いる場合がある。 他の標準分類を含め、標準分類とデータ形式の関係は様々であり、上記を参考に、条件1 の「当該標準仕様の実現に必要なデータ形式がある」を個々に判定されたい。
27 附属書 A（規定）用語集 以下に、ECOSS の評価基準の評価項目及び「ECOSS のための判定手順」の判定項目で 使われる用語についての定義を示す。評価の際は、これらの定義に沿って評価項目と判定 項目の意味を解釈すること。 項番 用語 定義 1 技術標準 ある一定の条件下で、目的とする機能を充足させるために、 工業製品又はその部品が満たすべき仕様、あるいはその仕様 を満足していることの試験方法、若しくはこれらを実現する ために必要な手順を定めたもの。目的とする機能には、品質、 性能、安全性、互換性、相互運用性などがある。これを「標 準仕様」と呼ぶ場合もある。 2 評価基準 情報システムの調達において、オープンな標準を推奨するた めに、オープンな標準に求められる要求される要件を評価項 目としてまとめた評価基準。欧州委員会では、
CAMSS(Common Assessment Method for Standards and Specifications)を開発しており、日本では、「情報技術に係 わるオープンな標準の評価基準（ECOSS:Evaluation Criteria for Open Standards and Specifications)が開発さ れている。 ECOSS では、情報技術に係わる標準をその適用分野に応じ て分類した「標準分類」に則して評価を可能とする評価基準 を提供する。 3 評価項目 具体的に技術標準の評価を行う判定を行う際に評価される 項目であり、評価基準を構成する要素。 4 判定手順 評価基準に従って具体的な技術標準を評価するための手順 を示すもの。評価基準に対して判定手順は必ずしも唯一に定 まるわけではなく、視点の異なる複数の判定手順が存在する こともあり得る。判定手順は、評価項目とそれに対応する判 定項目を列挙する形式で表現される。 5 判定項目 評価対象技術標準の各評価項目に対する適合性の合否判定 を、証拠資料を参照することで客観的に行えるよう具体的な 手順として記述したもの。
28 項番 用語 定義 6 技術に関わる委 員会 標準化団体において、技術標準の作成・審議を行うための委 員会。複数の技術標準を取り扱う標準化団体においては、 WG(Working Group)、TC(Technical Committee)といった 名称の委員会となっていることが多い。 7 運営に関わる委 員会 標準化団体において、具体的な技術標準の作成・審議ではな く、定款、規約（By-Laws）、各種ポリシー、倫理規定、メ ンバーの承認、委員の選出、活動計画などを審議する委員会。 8 審議プロセス 技術標準を策定するにあたって、提案から最終承認に至る過 程を定義したもの。策定された技術標準の改定及び廃止の作 業について規定も含む。 9 規約 標準化団体において、メンバーの資格要件、メンバーの義務 と権利、委員会の設置/廃止の手順、委員会メンバーの選択 手順、審議プロセス、IPR ポリシー、紛争発生時の管轄裁判 所などを規定した文書。 10 IPR ポリシー 技術標準を実装するために、必ず必要となる特許（必須特許） が存在する場合がある。このような場合の扱いを規定する文 書。一般的に、該当する技術標準を審議する技術に関わる委 員会に参加する企業は、IPR ポリシーに基づき、自社が保有 する必須特許について、開示の義務を有したり、適切な条件 で当該特許を他社にライセンスすることが義務付けられる。 11 異議申し立て （appeal) 標準化団体における技術に関わる委員会での技術標準の作 成・審議、あるいは運営に関わる委員会での規約の作成・審 議などが規約に反していることを、裁定を下す権限のある委 員会などに訴えること。異議申し立ての方法については規約 に定められていることが多い。 12 適合条件 製品・サービスなどが、技術標準の要件を満たしているため の条件 13 互換性 同等の機能を示す複数のデバイス又はシステムの間に存在 する状態で、変更しないで別のものと交換することが可能 で、かつ、同じ動作サービスを実現するインタフェースの特 性及び性能。（参照：JIS X 0500-3 RFID)
29 項番 用語 定義 14 相互運用性 それぞれの機能単位に固有な特性に関する知識を利用者が ほとんど又は全く必要とせずに、各機能単位が互いに通信 し、プログラムを実行し又はデータを転送する能力。 15 可搬性 プログラムに関する可搬性とは、プログラムを、異なった言 語に変換することなく、かつ、ほとんど又は全く変更するこ となく、異種のデータ処理システム上で実行できるプログラ ムの能力。（参照：JIS X 0001） データ形式に関する可搬性とは、データ形式が再入力を必要 としないデータ変換を含む容易なデータ移行により、アプリ ケーションが異なったりプラットフォームが異なる異種の データ処理システム上で、扱うことができるように定義され ていること。 16 実装オプション 技術標準を実装する場合に実装者に選択可能となっている 仕様。実装選択肢/実装任意選択がimplementation option の訳語として使われている。（参照：ISO/IEC 14776-412) 17 実装依存 この規格で定義されず、かつ実装での定義の必要がない動 作。さらに、その動作は、各動作間での一貫性を保障する必 要がない。(参照：JIS X 5902 IRDS) 18 区分 技術標準をそれが規定する対象のレベルにより「具体的技 術」「抽象構造」「活用規約」の3 つに分類したもの。 19 具体的技術 当該技術の具体的な構造、データ項目、それらに対する処理 内容、手順などを規定する技術標準。 20 抽象構造 当該技術の内部構成や、他技術との関連における位置付けな どを俯瞰的/体系的にモデル化して提示する内容を規定する 技術標準。 21 活用規約 当該技術の相互運用性確保など有効性の向上を目的とし、オ プションの機能項目の選択や組み合わせなどを規定する技 術標準。 22 上位 利用者に対してサービス・製品を提供するために必要となる 一連の技術群には、階層構造が存在する場合がある。この場 合に他の技術を使用してより利用者に近い階層の機能を提 供する技術を使用されている他の技術に対して上位の技術 という。
30 項番 用語 定義 23 下位 上位の技術に機能を提供する技術を下位の技術という。 24 上位互換 旧来標準に準拠する実装あるいはプロセスが、新たな標準に おいても有効である場合、新たな標準は旧来標準に対して上 位互換であるという。また、旧来標準に準拠する実装あるい はプロセスなどの出力が、新たな標準に準拠する実装あるい はプロセスにおいても有効あるいは、処理可能である場合に も、新たな標準は旧来標準に対して上位互換であるという。 後方互換と呼ばれることもある。 25 後方互換 上位互換と同意。本資料では、用語として上位互換を適用す る。 26 倫理規定 オープンな標準を制定及び保守する団体並びにその団体に 参画する者としての行動を律するための自己規範。法令や規 則の順守のみならず、オープンな標準を通して公共の利益に かなう活動を行うための規範及び社会常識を踏まえた行動 指針が示される。 27 品質基準 標準仕様の審議プロセスにおいて、次のステージに進むため に必要な条件。審議プロセスで明文化されていることが望ま しい。 28 コンセンサス 主要な項目に関する反対意見が存在せず、概ね合意に至って おり、すべての参加者の観点が考慮され、後の議論で大きな 対立が生じないようになっている状態。必ずしも満場一致で の賛成を意味するものではない。
（参照：ISO/IEC Directives Part 1－2.5.6）
一般的な同意の手続きに基づいて確認されることが多い。 29 ラフコンセンサ ス 挙手、ハミング、委員会で合意した方法によってコンセンサ スが得られたことを判断するプロセス。 （参照：IETF RFC2418） 30 活用ガイド 標準仕様を実際の製品、あるいはプロセスに適用する際に参 考となる標準仕様自身以外のドキュメント。 31 プロファイル 相互運用性や、可搬性を高める目的で、標準仕様の使用範囲 を限定するなどの規定を定めたもの(WS-I など）。若しくは、 標準仕様で定められた機能を更に細分化した機能を規定す るためのドキュメント（DMTF CIM など）。プロファイル 自身が、標準仕様となっている場合もある。
31 項番 用語 定義 32 メンテナンス 標準仕様の制定後に、記述の誤りの修正を行ったり、仕様の 拡張・修正を行うこと、並びに標準仕様の廃止を行うこと。 メンテナンスは新規制定と同様に予め決められた審議プロ セスに沿って行われる。 33 一般的な同意の 手続き 個々の投票権者ではなく投票権者全体に対する意思確認の 質問に対する投票権者の 回答を斟酌した上で議長が示した 行動案に対し、投票権者が明示的な反対の意を示すことなし に黙認したことをもって、示された行動案が承認 されたも のとする簡易的なコンセンサス確認の手続き。 34 利害関係者 標準仕様に関する利害関係者とは、「当該標準仕様に関心を もつか又はその影響を受ける人又はグループ」である。標準 仕様に基づく製品/サービスの供給者、販売者、直接・間接 の使用者、当該製品分野の監督官庁、代替製品の製造者、販 売者、使用者などが含まれる。 35 中立者 技術に関わる委員会あるいは運営に関わる委員会の委員で、 直接的な利害関係者ではない立場で参画している委員。会議 の議長は、中立公平の原則に従い、中立者であるかのように 議事運営を行うことが望まれる。 36 版 標準仕様は、内容の改定、スコープの拡大などにより制定後 に変更が行われることがある。変更は逐次行われるのではな く、まとまった単位で行われることが一般的であり、その区 切りを版と呼ぶ。標準化団体によって、バージョン、リビジ ョン、エディションなど異なる名称が使われる場合がある。 例えば、ISO/IEC Directives, Part 2 Rules for the structure and drafting of International Standards では、version は、 English version、French version など記述言語を表現する ために使われており、変更の単位にはedition が使われてい る。 37 基礎を成すデー タ形式 標準仕様の「基礎を成すデータ形式」とは、当該標準仕様を 定義するために使われるデータ形式のことである。例えば、 XML でデータを表現する標準仕様では、XML Schema を用 いてXML 形式を定義することが多いが、このような場合に は、XML Schema がそれらの標準仕様の基礎を成すデータ 形式となる。
32 項番 用語 定義 38 データファイル データファイルとは、標準仕様が基礎を成すデータ形式を用 いて定義されている場合に、標準仕様の中でそのデータ形式 で記述された定義の部分である。標準仕様の実装などで利用 する場合の利便性を考慮し、データファイルは標準仕様のド キュメントの中に埋め込まれるだけでなく、電子的に利用可 能な形式で入手可能となっていることが望ましい。 39 開発元団体 標準仕様のライフサイクルは、標準仕様の開発、開発された 標準仕様の承認、制定された標準仕様のメンテナンスの3 つ のステージから成る。ステージ毎に異なる標準化団体が担当 する場合があり得るが、標準仕様の開発に携わる団体を開発 元団体という。PAS 提案で制定された ISO/IEC JTC1 標準 の提案元団体は、開発元団体の例である。 40 承認団体 標準仕様のライフサイクルは、標準仕様の開発、開発された 標準仕様の承認、制定された標準仕様のメンテナンスの3 つ のステージから成る。ステージ毎に異なる標準化団体が担当 する場合があり得るが、標準仕様の承認に携わる団体を承認 団体という。通常は、開発元団体が承認団体であるが、PAS 提案で制定されたISO/IEC JTC1 標準では、開発元団体は PAS 提案を行った標準化団体であり、承認団体は JTC1 と なる。 41 メンテナンス団 体 標準仕様のライフサイクルは、標準仕様の開発、開発された 標準仕様の承認、制定された標準仕様のメンテナンスの3 つ のステージから成る。ステージ毎に異なる標準化団体が担当 する場合があり得るが、標準仕様のメンテナンスに携わる団 体をメンテナンス団体という。PAS 提案で制定された ISO/IEC JTC1 標準の場合、通常の標準化プロセスと異なり 標準を管理するWG が存在していないため、メンテナンス 団体を決める必要がある。
33 （空白）
34 【参照資料】 ・情報技術に係るオープンな標準の評価基準（ECOSS） ・ECOSS のための判定手順 ・判定作業記録テンプレート ・判定結果一覧表テンプレート
