1．はじめに

PROMCODE（PROject Management for COntracted DElivery）は，情報システム開発の複数組織による受託開発において，組織間で管理データを相互運用するためのWebを基礎とするインタフェース仕様である[1] ．国内主要システムインテグレータである日本アイ・ビー・エム（株），富士通（株），日本電気（株），（株）NTTデータ，（株）日立製作所，（株）野村総合研究所と南山大学が2012年に設立したPROMCODEコンソーシアムで技術開発と仕様策定を行い，公開している．筆者はコンソーシアムの設立とともに代表として技術開発と仕様策定にかかわってきた．さらに，本仕様の国際標準化のため，OASIS OSLC PROMCODE TC （Technical Committee）を設立し，そのChairを務めている．

PROMCODEはOSLC （Open Services for Lifecycle Collaboration）[2] が開発したWeb上でソフトウェア開発ツールを連携する技術を基礎としている．OSLCの成果はWebアプリケーション技術の国際標準化団体OASIS （The Organization for the Advancement of Structured Information Standard）[オアジスと呼ぶ][3] 傘下にOASIS OSLC MS（Member Section）と呼ぶグループを設立して標準化が図られることとなった．このため，PROMCODEもOASIS OSLC MSのメンバとしてOASIS傘下でPROMCODE TCを設立し，国際標準化を進めることとなった[4] ．

多くの情報システム開発は，オフショア開発などグローバルな組織で遂行されていることから，PROMCODEの国際標準化は必須であると考えている．あわせて，PROMCODEコンソーシアムは技術開発のための時限組織であることから技術の維持，管理のためにも国際標準化が有用であると考えている．

本稿では，OSLCとの連携によるPROMCODEコンソーシアムの設立からOASIS OSLC MSにおけるPROMCODE TCでの国際標準化に至る一連の経験から，国際標準化の課題と教訓を紹介する．

2．PROMCODEコンソーシアムの設立とOASISにおける標準化

図1にPROMCODE，OSLC，それに関連する標準化団体であるOASISとW3C（World Wide Web Consortium） LDP（Linked Data Platform） WG[5]における技術開発と標準化の経緯を示す．ここで，PROMCODEコンソーシアム，OSLCはいずれも技術開発組織であるが，標準化団体ではない．そのため，OASIS内にPROMCODE TC，Core TCなどのTCを設立し，開発した技術の標準化を図っている．OASISとW3CはいずれもWebソフトウェア技術の国際標準化団体であるが，W3CがXMLなどの基盤技術を担い，OASISがそれを利用したアプリケーションなどの応用技術を担っている．そのため，OSLCの基盤技術であるLDPはW3C内にLDP WGを設立して標準化された．この結果，OSLCの主要メンバがLDP WGの主要メンバを兼ねることになった．

このように，PROMCODEとその基盤であるOSLCという技術開発組織に加え，その標準化に複数の標準化団体がかかわっていることが標準化を難しくしている．

2.1　PROMCODEコンソーシアムの設立へ

OSLCはIBMが中心となり，Web上でソフトウェアツールを連携する基盤技術の開発を目的として2008年に設立された個人として参画するオープンな技術開発団体である[2]． OSLCには，個人としてではあるが，BoeingやAirbusなどのユーザ企業やSiemensなどのPLM （Product Lifecycle Management）, ALM （Application Lifecycle Management）ツールベンダなど80社以上からメンバが参加している．しかし，それ自体は標準化を目的としていない．

OSLCの主要な応用分野はPLM, ALMである．これらは統合管理ツールであることから，複数の個別管理ツールとの連携が必須である．このため，異なるツール間で，異なる構造のデータを相互運用する必要があり，そのためのインタフェース仕様の策定が求められた．このインタフェース仕様の基礎技術として，OSLCはW3C標準でセマンティックWebやリンクトデータ（Linked Data）の基礎であるRDF（Resource Description Framework）を採用した．RDFによりデータとその関係の意味が定義できることから，データの意味を含む相互運用性を実現する狙いである．このため，相互運用するために用いるリソースとその関係をRDFで定義し，かつ拡張可能としている．リソースシェイプ（Resource Shape）はこのリソースの内容とその関係の制約定義であり，インタフェース仕様とともに定義する．

2009年にOSLCの技術が日本の主要ITベンダへ紹介されたことを契機に，勉強会が開始された．この活動が発展して，2010年に情報システム開発におけるプロジェクト管理データ相互運用性の実現に応用することが検討され，その有効性などが評価された．これらの結果を踏まえ，2011年に富士通（当時）の藪田和夫氏が中心となって活動された結果，2012年5月にPROMCODEコンソーシアムが設立された．

PROMCODEでは現場で実践できるインタフェース仕様の開発を目的とした．そのため，現場の実開発データを用いて検討する必要性があることからコンソーシアムそのものはクローズドとしたが，その成果はオープンとすることを当初から運営規約に盛り込んだ．成果は随時，国内外の学会やメンバ企業のイベントなどで積極的に発表し[6]，Webでも公開している[1]．

PROMCODEコンソーシアムはインタフェース仕様第1版を2013年10月に公開した．この仕様を含め，コンソーシアムの成果はオープンソースとして誰でも自由に利用可能である．合わせて，PROMCODEの商標登録も行った．

図2にPROMCODEを取り巻く組織間の関係を示す．PROMCODEはOSLC内でドメインと呼ぶ特定分野の技術を対象とする仕様の1つと位置づけられている．

これらの仕様の共通基盤として，OSLC Coreの検討が2010年に開始され，2013年にCore V2として公開された．Coreは各ドメインで利用するリソースとそのオペレーションを規定する．一方，ドメインは変更管理（Change Management）, 構成管理（Configuration Management）, 要求管理RM （Requirements Management）など応用分野固有のリソースとそのオペレーションを規定する．

2.2　W3C におけるLDPの標準化とOSLC

PROMCODEが大きな影響を受けた標準化活動としてW3CのLDPがある[5]．LDPはRDFを用いてREST （REpresentational State Transfer），すなわちHTTPメソッドによりデータの相互運用性を実現するためのリソースとオペレーションを規定している．2012年にW3C内にLDP WGが設立され，2015年に仕様の第1版がW3C勧告として公開され，活動を終了した．

一方，LDPの標準化と並行してOSLCにおいてLDPに基づくCore V3の仕様検討が2012年に開始された．それまでのCore V2はRDFは利用するが，LDP準拠ではない．したがって，OSLCが2013年に公開したCore V2仕様もLDP準拠となっていない．これは，後にOASISでの仕様策定上で大きな問題となった．

2.3　OASIS OSLC PROMCODE TCの設立と標準化

PROMCODEの基盤であるOSLCは標準化を図るため，OASISにOSLC MSの設立を提案し，2013年5月に設立が承認された．さらにOSLC Coreで検討してきた仕様を標準化するCore TCが12月に設立された[7]．これに伴い，PROMCODEもOASIS内でPROMCODE TCを設立し，国際標準化を図ることを決定した．

設立に先立って2013年6月にOSLC MSの設置とあわせて開催されたイベントでOSLC MSのステアリング委員会のメンバと会合を持った（図3）．この会合は，翌年にPROMCODE TCをOSLC MSに設立する道筋を付けるための顔合わせと合意形成の役割を果たした．

PROMCODE TCはOASIS内の独立したTCではあるが，OSLC MSとの連携を図るためOSLC MSにも所属するMSの加盟TC（Affiliated TC）となっている．

国際標準化団体としては，ISO, IECなどもある．PROMCODEはOSLC CoreなどのOSLC MSのメンバとの協調が必要なこともあり，OASISで標準化することを選択した．

また，PROMCODEコンソーシアムは技術開発が目的であることから，開発した仕様の保守やその国際的な位置づけを明らかにしておく必要もある．その点からも国際標準化は必要であった．

ところで，IBMにいたSpeicher氏はOSLCの主要なメンバで，かつ，LDP仕様のエディタ[5]として仕様策定の中心メンバでもあった．米国でOSLCに関するイベントでは必ずSpeicher氏と会い，さまざまな議論や助言を頂いた．図4は2014年に，当時のOASIS OSLC MSの主要メンバと米国Orlandoで開催されたイベントにおいて議論している様子である．左端がSpeicher氏である．

3．OASISにおけるオープンな標準化

3.1　OASISのオープンな標準化プロセス

OASISは当初SGML Openとして1993年に設立された比較的新しい標準化団体である．現在，65ヶ国以上の600を超える組織から5,000人以上が参画している[3]．OASISは透明性のあるガバナンスと運営，標準化の軽量プロセス（Lightweight Process）を標榜している．主として，Webサービス，クラウド，ビッグデータ，セキュリティ, 電子政府など，Webの応用技術を対象としている．

一般に標準化におけるオープン性は，そのステークホルダの視点から次の3つの特性として議論できる[8]．

• （1） 標準策定者の視点：標準化プロセスのオープン性
• （2） 標準を利用した製品などの実装者の視点: 標準の利用に関するオープン性．オープンソースと同様，ライセンスやIPRポリシも含むオープン性．
• （3） 標準を利用して実装した製品などのエンドユーザの視点: 標準に対する複数の実装や製品があることによる実装の利用に関するオープン性．特定の実装に束縛されないこと．
  

OASISでは，この3つのオープン性を次のようにして担保している[9]．

• （1） 標準化プロセスのオープン性
  TCの設立から運用に至るプロセスを公開し，OASISの会員に関してではあるがオープンな運用を図る．さらに，標準化のプロセスと活動はWebで公開されていることから，OASIS会員以外もその状況を知ることができる．
• （2） 実装のオープン性
  標準は仕様を規定しており，その実装は利用者に任されている．
• （3） 実装の利用可能性
  標準の実装はその利用者の判断によるので，これを保証することは本質的に困難である．しかし，OASISでは標準化の条件として3つ以上のSOU （Statement Of Use）の提示が義務づけられていることから，（2）の実装のオープン性を含めて確信度を高めている．

このようなオープン性の保証は，標準開発における作業の増大を招く．実際に運営をしてみると，負担が少なくないことを実感している．

3.2　TC（Technical Committee）設立

3.2.1　TC設立プロセス

OASISではTC設立と運用のプロセスがTC Processとして公開されている[9]．PROMCODE TC設立に至る直接的な活動の経緯を図5に示す．ここに至る問題は，憲章（Charter）の起草，その中で規定すべき標準化対象のスコープ，知財の扱いなどについて，TC設立の発起人となる少なくとも3社間での調整である．これらを元に，発起人となる企業のOASISへの代表者による支持表明（Endorsement）が必要である．このように標準化においては独特のプロセスとプロトコルがあることから，OSIで長年標準化の経験のある藪田氏やOASIS OSLC MSの主要なメンバを出しているIBMのネットワークは大きな助けになった．

TC設立にあたってメンバ募集を兼ねて，発起人代表がWeb CastingでTC活動の紹介を行うことが義務づけられている．このような手順を踏むことがオープン性の担保のためにも必要となっている．

3.2.2　IPRポリシ: 知財の扱い

コンソーシアムによる技術開発，国際標準化では知財の扱いを規定するIPR（IP Rights）ポリシ（パテントポリシとも呼ばれる）が重要である[10]．ISOなどでは2000年代初めから利用者に合理的な条件でライセンスを与え得る合理的無差別条項RAND （Reasonable And Non-Discriminatory terms and conditions）が導入されている[11]．ただし，RANDはいわば善意のポリシであり，その運用は規定されていない[10]．

OASISでもRANDを含むIPRモードと呼ぶ下記3つのIPR Policyのいずれかに従う必要がある[12]．

• （1） RF（Royalty Free） on RAND Terms : ロイヤルティは無料であるが，利用にあたってRANDに基づくライセンス条項（RAND Terms）を含み得る
• （2） RF on Limited Terms : ロイヤルティは無料であり，その使用に付加的な条件もないが，運用にあたって適切な条件を付加し得る
• （3） Non-Assertion : OASISの世界共通の特許非係争条項（Non-Assetion Covenent）に従う

PROMCODE TCではCore TCのIPRモードと同一となるRF on Limited Termsを選択した．これは，TCメンバの所属企業の知財部門にも確認をいただいた．

3.3　TC運営

TCの運営はすべてOASISのWebで実行できるようになっている．TCの招集から議事録の管理などすべての活動とドキュメント管理はWebと電子メールで運用できる．標準のドラフトも構成管理ツールで管理され，また，問題は問題管理ソフトウェアJIRAで管理される．

TCそのものは電話会議で行っているが，これはOASISでは支援されず，メンバ企業であるIBMで利用しているグローバルな遠隔会議システムを利用させて頂いている．OASISではグローバルな標準化が基本であることから，グローバルに誰でも利用できる遠隔会議システムが利用できることが前提となる．

4．標準化の技術面での課題と実際

4.1　スコープ定義と規範的仕様

ソフトウェア開発において最も重要な要求定義と同様，標準化においてもスコープ定義が最初に行うべき重要な意思決定になる．しかし，PROMCODEは，OSLC MSの1つのドメインとして位置づけられていることから，そのスコープ定義はOSLC Coreを前提とする必要がある．さらに，Core上でPROMCODEと並立する要求管理やCCM（変更構成管理）などのドメイン仕様と重複しないことも条件となる．

一方，PROMCODEに対する要求は，我が国における複数組織による受託開発（Contracted Delivery）を前提として，組織間で管理データの相互運用性を実現することが目的である．このような受託開発は米国では通常行われていない．そのため，PROMCODEのスコープは我が国における受託開発の実践に根ざしている．

このような条件の下で，PROMCODE TCの憲章で定めたスコープは，ほかのTCと比較すると我が国のビジネス慣行を反映していることから，特殊といえる．

実際に標準化を行う上で，課題となるのは，標準化の範囲である．PROMCODEの仕様は図6に示す8章と付録A~Dから成る．付録の中で，付録Aは元々は1つの章として記述していた内容を付録に移したもので，8章までの内容を補完する．

このような仕様の中で準拠すべき内容を規範的（Normative）と呼ぶ．それに対して，規範的な内容の前提となる内容や説明を補完する内容などで準拠する必要がない部分を非規範的（Non-normative）と呼ぶ．

PROMCODEでは3章で規範的な部分と非規範的な部分を定義している．図6で，規範的な部分は太字の2, 3, 5, 6章であり，それ以外は非規範的である．全体として51ページある中で，規範的な部分は約22ページである．しかし，標準とするためには非規範的な部分も規範的な部分と同等の完全性，一貫性，明確性（曖昧でないこと）とその内容の正しさが求められる．このため，TC設立後，PROMCODEの仕様は作成よりもその検証に多くの時間を要することになった．

4.2　関連国際標準化との整合性

PROMCODEに限らず，国際標準では他の国際標準や技術との整合性をとることが必然となっている．特に，PROMCODEはOSLC Coreを前提としていることから図7に示すように，Coreの仕様に依存する．当初，PROMCODEコンソーシアムで仕様を策定した時点ではOSLC Core V2が前提であった．これに対して，OSLCのOASISへの移行とともにCore V3が策定された．Core V3はV2に加えてLDPも含むことになったことから，PROMCODE TCでの仕様策定でも新たにLDPの条件を満たす要求が加わった．これは具体的には，HTTPレベルでサービスディスカバリーを行うためのOPTIONSメソッドへの対応とLDP上でリソース管理を行うLDPコンテナへの対応である．このようなプラットフォームの変更はそれに準拠するPROMCODE仕様への大幅な変更をもたらした．

また，Coreの標準化とPROMCODEの標準化とが同時並行して進行したため，Coreの標準化の状況を常に把握しておく必要もあった．たとえば，Coreの標準化では，当初，V3のみを標準化する方針が打ち出された．しかし，すでにV2で実装したシステムがあり，これらのシステムがV3で実装するとは限らないことから，V2とV3の両方を標準として認めるように方針が変更された．PROMCODEでは，本来はV3が標準の中核であることから当初V3に準拠した仕様を策定した．しかし，コンソーシアムではV2を基礎として仕様を策定し，実証実験を行っていたため，V3へ対応するための仕様の追加に加え，実証実験に必要な実装工数の捻出などの問題が生じた．

4.3　ドメインモデルとリソース定義

PROMCODE仕様の実体は異なる構造のプロジェクト管理データの相互運用性を実現するためのRDFリソース定義である．しかし，このリソース定義はプロジェクト管理の基本構造を反映していなければ，適切にデータを交換できない．そのため，プロジェクト管理知識体系PMBOK[13]を参考にし，合わせて，実際のプロジェクト管理データに基づきプロジェクト管理のモデルをUMLで定義した．これをPROMCODEドメインモデルと名付け，仕様の第4章で定義している．

PROMCODEの仕様策定ではこのドメインモデルからRDFのリソースを定義した．しかし，UMLで定義したドメインモデルは管理対象をオブジェクト指向に基づきクラスとして定義している．一方，RDFを用いると管理対象を主語，述語（動詞），目的語の3つ組から成るグラフの連結（リンク）で定義する．したがって，RDFではUMLで表現されたドメインモデルにおけるクラスの継承や集約を用いた階層構造をそのままでは表現できないことから，モデルとリソース間にギャップが生じることとなった．この結果，モデルを変更するとそれに対するRDF定義にも変更が必要となった．

4.4　仕様適合性定義

国際標準の仕様への適合性とその評価は仕様の内容が複雑になるにつれ困難となっている[10]．そのため，ISO/IEC 17000（JIS Q 17000）では適合性評価機関の規約が定められている[11]．しかし，適合性の定義には，適合性キーワード（Conformance Keyword）の定義, 適合性条項 （Conformance Clauses），適合性要求定義（Definition of Conformance Requirements）を明確にする必要がある[14]．適合性キーワードはPROMCODEでも使用しているRFC 2119が広く認知されている．しかし，適合性条項や適合性要求定義は，作成者ごとに異なっているのが実態である．

PROMCODEの標準化の過程でも適合性の定義が問題となった．特に，PROMCODEでは，次の2つの視点から適合性を定義する必要があった．

• （1） プラットフォーム適合性
  PROMCODEが準拠するOASIS OSLC CoreはV2, V3の2つの仕様を認めたため，PROMCODEもこの2つの仕様に応じた適合性の定義が必要となった．
• （2） プロジェクト管理データ適合性
  PROMCODEが対象とするプロジェクト管理データの対象範囲の適合性．PROMCODEでは，複数の受注者が発注者へ計画（Plan）に対する実績の報告（Report）を行うユースケースが基本である．さらに，プロジェクト管理の中核的管理データであるスコープ（ScopeItem），作業（WorkItem），成果物（Artifact）の3つの管理データを対象とすることが求められる．

この結果，PROMCODEではサーバ実装上，上記の2つの視点に基づき，次の段階的適合性水準を定義した．

• 　a） プラットフォーム適合性：Basic, Full
• 　b） Basicが提供するリソースの範囲による細分化
  　i） Standardサーバ：ScopeItem, WorkItem, Artifctを提供
  　ii） Reportサーバ：PlanとReportを提供
  　iii） Issueサーバ：IssueとRiskを提供．

4.5　SOU : 標準仕様の妥当性確認

OASISに限らず国際標準の仕様の妥当性を明らかにする必要性の認識が高まっている．そのため，公開で相互運用性の実証などを行う例もある．

OASISでは，規格の標準化の投票を開始するまでに3例のSOUの表明を義務づけている．しかし，SOUの内容に関しては規定されていないので，TCごとに対応が求められる．

PROMCODEでは，コンソーシアムで第1版の仕様作成後にメンバ各社で実装を行い，実証実験を行った．この結果は仕様書と合わせてWebで公開している．

その後，OASISのTCにおける仕様策定の過程でSOUの検討を行ってきた．上述の適合性に基づき，コンソーシアムでは実証WGを設立してCoreが要求している条件を整理し，メンバ各社で実証方法を検討した．

コンソーシアム仕様に対してOASISで策定した仕様には差異があることから，2017年にメンバ企業の実際の大規模プロジェクト管理データを対象として，品質管理のユースケースを設定して，再度，実証を行った．この結果もPROMCODEのWebページで公開している．このような一連の実証によって，仕様の細部にわたる課題が明らかになり，仕様の品質が向上した．

一方，PROMCODE仕様は複雑度が高いことから，このような限定したユースケースを用いた実証には限界がある．そのため，SOUは主要なユースケースを用いて実証することにより，仕様に大きな誤りがないことを示すことに意義があると考えている．

5．標準化の管理面での課題と実際

5.1　TCマネジメント

TCは，それ自体がまぎれもなく1つのプロジェクトであり，TCマネジメントはプロジェクトマネジメントそのものである．本稿での経験からTCマネジメントにはソフトウェア開発などのプロジェクトマネジメントとは異なると思われる点を指摘したい．このような点はオープンソースソフトウェア開発のプロジェクト管理[15]と共通性があるように思われる．

• （1） 本来業務と異なるボランティアベースの活動
  OASISのTCへの参画はOASISメンバ企業に限られ，所属企業で参画を承認されている．しかし，通常専任ではなく，各企業での本来の業務との兼任であり，また業務というよりメンバの自主性によるボランティアベースの活動である．一方，仕様策定とその実証などに要する工数は少なくない．したがって，業務の状況によってこのような工数の確保が困難となる時期がある．この結果，仕様策定が計画通り進捗しないことがある．実際，PROMCODEでもスケジュールは当初の計画から延びている．
• （2） 標準化プロセスと人材
  仕様開発と標準化のプロセスに関してOASISやW3Cではガイドを公開している[3]，[16]．しかし，それらはごく概略に留まっている．一方，ISOでは各国の標準化団体がメンバであることから，国内でも長年標準化に従事している人材があり，かつ，標準化団体内で標準化のプロセスや調整などに関する知識，ノウハウが蓄積，共有されているように思われる．OASISのようなオープンな標準化団体ではこのような前提が期待できない．また，標準化に関する書籍なども限られている．実際，著者はこれまで標準化にはかかわったことがなく，すべてが，学習過程であった．コンソーシアムとTCの運営にはISOなどで標準化に長年かかわってきた経験者の存在が大きな助けとなった．このことは，標準化活動が必ずしも広がらない原因になっていると思われる．
• （3） 標準への要求と利用
  オープンソースと同様，標準も必ずしも利用されるとは限らない．PROMCODEでは標準の想定ユーザは策定した企業を含むIT産業とそのユーザ企業である．しかし，TCでは特定ユーザの要求を満たすよりは，多くのステークホルダが利用できるように，常に，仕様全体のバランスをとる必要がある．これは，ソフトウェア開発における要求マネジメントに相当する．OASISのような企業ベースの実システム開発に近い標準化団体では，このような要求のスコープや内容のマネジメントが求められる．

5.2　標準化団体，関連TCとの調整

図2に示したようにPROMCODEの標準化には複数の標準化団体が関連している．特に，Core TCのような強く依存する標準化が同時並行して進行する状況にあった．したがって，Core TCの状況を常に把握するとともに，Core TCと仕様の整合性について常に調整が必要であった．また，PROMCODE仕様で用いる名前空間の定義などは，OSLC MSでだけではなくOASISの担当者とも調整が必要であった．PROMCODEの仕様策定と並行してCoreの仕様が変更されることもあって，問題発生の都度このような調整を行う必要が起きることから，個別対応を迫られることが多かった．

6．OASISでの標準化の経験から

OASISでの標準化の経験から得られた示唆をいくつか共有したい．

6.1　国際標準化の意義

これまで述べた経緯とそれに伴うコストを要したとしても，PROMCODEなどのインタフェース技術の仕様を国際標準化することは次のような意義がある．

• （1） 技術の永続性と公開性
  PROMCODEを開発したコンソーシアムは時限組織であることから，その成果を維持する組織が存在しない．そのため，技術を利用できるためには，その永続性を保証する必要がある．一方，技術が広く利用されるためにはベンダや特定の国から独立した中立的組織で技術を提供できる必要がある．この要求を満たす技術の維持，公開の形態として国際標準化は適切かつ有効である．
• （2） インタフェース技術の持つ本質的な役割
  PROMCODEの対象は製品などを実現する技術ではなく，組織間でのインタフェース仕様であることから，標準化は不可欠である．

6.2　プロセス，方法論，人材の欠如

筆者は長年ソフトウェア開発に従事し，ソフトウェア工学を専門としている．ソフトウェア工学を含む工学では，プロセスと開発方法論，成果物（プロダクト），人材（ピープル）の3要素は基礎技術として一定水準に達することが求められてきた．OASISの標準化を通して実感するのは，プロセスの記述が簡略で，具体的な進め方はその都度OASISの事務局にメールで問い合わせる必要があるなど，プロセスもプロダクトも確立されているとはいえない水準にある．その一因は標準化が，製品開発にくらべ，標準化団体における特殊な活動とされている点にあるのではないか．また，国際標準化に参画できる人材として「国際標準専門家」があるが，我が国ではその育成が遅れているとの指摘もある[17]．今後，標準化を戦略的ツールとするのであれば，このような点をまず，認識する必要がある．

6.3　時間との勝負

上述したように，標準化活動はボランティアベースであることもあって，工数が確保できないことがある．あわせて，その成果が事業に必ずしも直接貢献するわけではないので，メンバはその所属企業で評価されにくいという難しさがある．したがって，標準化活動はできるだけ短期間で終えることが望ましい．一方，標準の影響の広さと大きさを考えれば，その正当性や妥当性の確認に多くの時間が必要となる．1つの解決方法は，ソフトウェアの要求と同様，標準の対象とするスコープを絞ることである．したがって，標準化活動の開始時点でのスコープ定義とその後のスコープ管理がきわめて重要である．

6.4　英語との戦い

PROMCODEの仕様書はOASISの形式で50ページ，通常のA4, 10ポイントで印刷すると100ページを超える．この仕様は元々PROMCODEコンソーシアムで作成したことから，メンバ各社で分担して執筆した．そのため，内容以前に英文の品質を確保するために英文ツールチェックに加え，度々レビューを行った．仕様の記述量が増えると英文作成も大きな負担となる．当初，英語を母国語とするメンバもいたが，諸事情から継続できなくなった．国際標準を策定する上で英文作成も含むメンバの確保が重要である．

6.5 国際標準化活動を主導すること

PROMCODE TCの設立，運営から得た知見をまとめる．

• （1） 標準化活動の開放性と参入容易性
  OASISのTCは3社以上の会員企業が参画すると設立の申請が可能である．ISOなどの国単位，かつ，階層的委員会組織に比べ，参入が容易である．さらに，すべてのTC活動がWebと遠隔会議で完結でき，オフラインミーティングも必要ないことから運営も比較的容易である．このことからPROCMODEではOASISでTCを設立し，標準化を進めることができたと考えている．
• （2） 標準化の中核組織：ステークホルダからチームへ
  標準化には利害調整がつきものであり，TCなどの標準化活動への参画はステークホルダとして利害調整も担う．しかし，標準化活動を円滑に進めるためにはメンバがゴールを共有し，その達成のためにチームとして協働することが不可欠である．PROMCODEでも利害や運営に関する議論はあった．しかし，幸いにも，国際標準化，技術検証，実装など，それぞれの深い知見や技術を有したメンバがTCに参画し，かつ，チームとして協働できたことがこれまで標準化を進めることができた原動力である．

7．まとめ

本稿では，OASISというオープンな標準化団体において，我が国の技術者が中心となってさまざまな標準化団体などと調整を行いながら国際標準化を進めてきた経験を紹介した．本稿で述べたように国際標準化には多様なステークホルダが関与し，その調整にも多くの労力を必要とし，ポリティカルな活動であることは否めない．しかし，ソフトウェア工学の研究者の視点からは，標準そのものがソフトウェアであり，標準化はソフトウェア開発そのものであるように思われる．このような視点から，標準化への工学的なアプローチがもっと進められてもよいと思われる．

一方，ISOなど国が支援する標準化団体を基礎とする標準化に比べ，民間主体であるOASISにおける我が国のプレゼンスは低いのが現状である．OASISがWeb技術の標準化団体であることから，今後，我が国のプレゼンスを高める必要がある．

謝辞 PROMCODEコンソーシアム，ならびに，OASIS OSLC PROMCODE TCの皆様に感謝します．丁寧なコメントをいただきましたデジタルプラクティス編集委員の斎藤 彰宏氏，ならびに，PROMCODE TCの上村務氏にお礼申し上げます．