CAMARAプロジェクトの組織構成

はじめに

一般的に「オープンソースプロジェクト」といえば，ソフトウェアを開発する組織を思い浮かべると思います。

しかし，CAMARAはLinux Foundation配下の「オープンソースプロジェクト」ですが，成果物はソフトウェアではなくNW-API仕様（極端にいえばOpenAPI準拠のAPI仕様を書いたYAML）です。実装ではなく仕様を作っているわけなので，実態としては標準化団体に近い性質を持っているといえます。

また，CAMARAプロジェクトと他標準化団体の関係で紹介したように，CAMARAはテレコム系の業界団体であるGSMAと相互に密接な関係を持っており，実態としてはGSMAと連携してNW-API標準を策定していると言えるでしょう。

本記事では，そういった標準化団体的な側面を持つCAMARAプロジェクトの組織構成について解説します。

CAMARAプロジェクトの組織構成

CAMARAプロジェクトは運営組織と作業部会から構成されます。運営組織としては，資金・運営面を担うGoverning Board（GOB）と，技術面を担うTechnical Steering Committee（TSC）があります。作業部会としては，Working Group（WG），Sub Project（Sub-Pj），Independent Sandbox（Sandbox）があり，それぞれTSCの配下に位置します。

プロジェクトの構造を図示すると以下のような形になります。当チームでは技術サイドの活動を行っていることから，TSCとその配下の組織を中心に解説します。

Technical Steering Committee (TSC)

TSCは技術関連の意思決定・統括を行う組織です。

例えば，新規APIを策定するSub-Pjの設置などに関しては，配下のAPI Backlog WGから提案を行い，TSCで承認するという流れになっています。

また，CAMARAでは，複数のCAMARA APIを束にして年2回（春・秋）リリースをしており，これを"メタリリース"と呼んでいます¹が，このメタリリースの最終承認もTSCが行います。

TSCは，3GPPでいうところのプレナリの役割を持っているといえます。3GPPの組織構成に関しては，当チームのブログにて解説していますので，興味のあるかたはそちらをご覧ください²。

Sub Project (Sub-Pj) / Independent Sandbox (Sandbox)

Sub-PjとSandboxは実際のAPI仕様を策定する組織・チームの総称で，基本的にはAPI毎に設置されます。当チームは，Sandboxの WebRTC でCode Ownerとして活動しています。

Sub-Pjは，TSCによって承認された組織単位であり，複数のAPIリポジトリをまとめて管理します。

一方で，SandboxはSub-Pjに所属せず独立して運営される，チームとそのリポジトリの総称であり，各APIのCode Ownerがガバナンスを担います。Sub-Pjと比べてより柔軟・迅速に仕様検討を進めることができます。

Sub-PjやSandboxには，CAMARAのOrganization内にGitHubのリポジトリが割り当てられます³。主な成果物は，OpenAPI 3.0ベースのAPI仕様書と，APIテストシナリオです。APIテストシナリオは，API実装のCAMARA仕様への準拠性を検証するために用いられます。

仕様検討は，このリポジトリとIssueやPull RequestといったGitHubの機能を活用して進めていきます。ただし，WebRTCの場合は隔週のWeb会議を設けており，方針レベルの意識合わせや最終的なPR承認の意思確認等を行っています。

3GPPでは要求条件→アーキテクチャ→プロトコル仕様と段階的に確定していくウォーターフォール的な進め方が取られますが，CAMARAでは，要求条件と仕様を並行してアップデートしていくアジャイル的な進め方が取られています。

これは，利用者側からのニーズに応じて柔軟かつ迅速にAPIをリリースするための工夫です。3GPPでStage3まで仕様が完成するには，Stage1から始めて2～3年程度かかりますが，CAMARAでは早いものですと半年程度でAPIをリリースしているケースもあります。

また，仕様策定にGitHubを使用するという点ではIETFの多くのWGと類似し，Office系ファイル形式（.docx等）で仕様書を策定する従来型の標準化団体と比べて現代的なアプローチといえます。

以下では，API仕様策定の活動において特に関係する2つのWGについて簡単に触れておきます。

Commonalities WG

本WGでは，CAMARA API共通仕様として，主にAPI仕様書及びAPIテストシナリオのガイドラインを規定しています⁴。

CAMARA APIが想定する利用者であるアプリケーション開発者からみて，CAMARA APIが一貫性のある設計になっていないと使いづらくなってしまうため，このような共通仕様が設けられています。

この共通仕様に整合していないとAPI仕様はリリースできません。そのため，リリース前には最新のガイドラインとの整合性確認・修正が必要であり，この作業分の時間を計画に組み込んでおく必要があります。

CAMARA APIはREST系のAPIを主に想定して共通仕様を策定しているため，例えばWebRTCではWebSocketベースのAPIを策定したいと思っても現状のガイドラインではできません。そこまで極端な例でなくとも，意外にガイドラインと整合しない設計になってしまっていてCommonalities WGのチームから修正を求められることは多々あるため，注意が必要です。

Identity & Consent Management WG (ICM WG)

本WGでは，CAMARA API共通仕様として，OIDCベースの認証認可フローとユーザー同意の取得・管理方式を規定しています⁵。

具体的には，OIDCとCIBAで利用可能な一部のオプションをCAMARAとして制限するプロファイリングなどを行っています。加えて，GDPR等のプライバシー規制を考慮した独自拡張も定めています。

このWGの規定は，各APIの仕様書において，そのAPIを利用する際に必要な認証認可の方式(OpenAPIのsecurityフィールド)として記述されます。具体的な記述方法は，本WGの要件を踏まえてCommonalities WGで定められていますので，APIのリリースにあたっては本WGの規定への準拠も必須要件となります。

おわりに

本記事では，CAMARAプロジェクトの組織構成について解説しました。

CAMARAはTSCによるガバナンスなど標準化団体的な構造を持ちながら，GitHubベースのアジャイル的な仕様策定を行っており，OSSと標準化団体の双方の特徴を併せ持つプロジェクトといえます。

CAMARAで活動するにあたっては，実際のAPI仕様を検討するSub-PjやSandbox内だけでなく，Commonalities WGやICM WGのガイドライン動向も把握しておくことが重要となります。本記事が，CAMARAでの活動を始める方の参考になれば幸いです。

---