深層考察：『オープンソース プログラム オフィス』
組織構成、役割、責務、および課題
2022年8月
Ibrahim Haddad, Ph.D.
Vice President of Strategic Programs, Linux Foundation
and General Manager, LF AI & Data
『序文』 Chris Aniszczyk,
Chief Technology Officer, Linux Foundation
and Co-Founder, TODO Group
翻訳：工内隆・伊達政広（The Linux Foundation Japan）
協力：目次
序文........................................................................................ 3
概要 ........................................................................................ 5
はじめに .................................................................................................. 6

オープンソースのポリシーとプロセスの確立 ............................................................... 21
アップストリーム オープンソース開発を優先順位付けし、それを推進 .......................................................................................22
オープンソース組織との協力.........................................................................22

OSPOの定義............................................................................. 7

パフォーマンス指標のトラッキング.................................................................22

OSPOの特徴............................................................................. 7

OSPOとOSSの使用またはコントリビューションにおける摩擦の排除 .... 25

OSPO成熟度モデル.................................................................... 8

カルチャー.................................................................................................25

ステージ0：アドホックなアプローチ ............................................................................. 9
ステージ1：法務教育中心の導入......................................................................9
ステージ2：コミュニティ教育中心の導入...........................................................9プロセス....................................................................................................26
継続性.......................................................................................................26
教育..........................................................................................................27

ステージ3：エンゲージメント中心の活動.........................................................10

TODO Group ....................................................................................... 28

ステージ4：リーダーシップ中心の活動 ....................................................................... 10

まとめ.......................................................................................................28

OSPOの組織構成......................................................................11

謝辞.......................................................................................29

例1：研究開発部門内のOSPO..................................................................................... 11
例2：企業レベルのOSPOと部門レベルのサポートOSPO .......................................... 12Linux Foundationの支援リソース ....................................................... 29

例3：CTOオフィスやエンジニアリング部門の一部としてのOSPO.............................. 12

フィードバック..........................................................................29

例4：仮想OSPO........................................................................................................... 13

著者について............................................................................30

例5：公式OSPOがないケース........................................................................ 13

OSPOへの人員配置 .............................................................................. 14
法務顧問 ...................................................................................................................... 14

OSPOの責務............................................................................15
オープンソース戦略の確立と実行 ............................................................................... 15
オープンソース コンプライアンスの管理..........................................................19

免責条項.................................................................................30

序文
あなたは多くの企業のリーダーと同様に、オープンソースに精通し、すでにオーTODO Group は、オープンソース プログラムの成功に向け、それをマネージ

プンソース プログラムを導入しているかもしれません。 しかし、オープンソー

メントするためのベストプラクティスとツールの構築に尽力している組織のグ

ス プログラム オフィス（Open Source Program Office: OSPO）とは正確にループです。私たちは、いくつかの世界最大級の組織を含め、拡大している『実はどのようなもので、どのような役割や責務があり、組織の成功にどのように

践共同体 (community of practice: CoP)』と共に、オープンソース プログラ

貢献できるのでしょうか。

ムのマネージメントに関するすべてのことについて、先導的意見を表明していOSPO は、組織内でオープンソース関連の活動の管理と調整に責任を持つ 1つの組織機構（corporate entity）の位置づけです。OSPO は、組織のオーます。プラクティス リーダー ( 実践指導者 ) として関わっている方、あるいはOSPO の設立を検討している方は、ぜひ TODO Group にご参加ください。

プンソース戦略の中で中枢神経系と見なすことができ、オープンソースに関連

本稿は、OSPO 設立のための概論を提供します。OSPO の役割とメリットにするすべてのものにガバナンス、監督、および支援を提供します。

焦点を当てながら、オープンソース プログラムのマネージメントについて、「そThe Linux Foundation では、OSPO を組織が成功するための重要な構成要素と見なしています。私たちは、「組織がオープンソースの力を活用してビジネスの目標や目的を達成するには効果的な OSPO がいかに助けになるか」をこの目で見てきました。TODO Group は、OSPO を設立したり、既存のオープンソー
ス プログラムを次のレベルに引き上げたりするのを支援します。

れは何か」、「なぜ必要か」、「どのように進めるのか」、を説明します。また、
OSPO のさまざまな組織構成モデルについても説明し、成功のためのヒントとベストプラクティスを提供します。オープンソースの旅に乗り出す際に、本稿がお役に立てることを願っています。
Chris Aniszczyk
CTO, The Linux Foundation

Co-Founder, The TODO Group

深層考察：『オープンソース プログラム オフィス』

3

OSPOとは何か？
OSPOは、
組織のオープンソースの運用と体制に関する
コンピテンシー センターとなるように企図。

組織におけるOSPO
OSPOs may exist
unoﬃcially;
virtually; within research and
OSPOは、非公式に存在したり、仮想
development (R&D), engineering,
的に存在したり、研究開発 (R&D) 部
or other corporate departments;
門、エンジニアリング部門、またはそorin executive-level oﬃces ofの他の企業部門内に存在したり、また
theChief Technology Oﬃcer
は、最高技術責任者（CTO）や最高法務(CTO)
or Chief Legal Oﬃcer.
責任者（CLO）のような経営幹部のオ

OSPOによる恩恵：プロセス

OSPOスタッフ

OSPOによる恩恵：ツールフィス内に存在している場場合もある。

なぜOSPOを設立するのか？
OSSのリーダーシップを発揮
し、強固な外部の研究開発エコシステムで重要な足場を築く
ために、さまざまな業界の組織がOSPOを設立。

OSPOは、
ソフトウェア アーキテクト、such as software architects,
テクニカル エバンジェリスト、
technical evangelists, compliance
コンプライアンス エンジニア、
engineers, and legal counsel.
法律顧問など、高度なスキルを持つ人たちにより運営される。

成熟度の高いOSPOの特徴
高い成熟度に達したOSPOは、

OSSの活用、ガバナンス、
戦略、コントリビューション、
プロセス、およびツール利用を監督。

OSPOの責務
OSPOは、

オープンソース戦略の策定と実行、優先順
位の設定、パフォーマンス トラッキング、
コミュニティ参加の推進などを含めて、時間の経過とともに変化するさまざまな事項に対して責任を負う。

OSPO成熟度モデル

OSPOによる恩恵：カルチャー

OSPOの成熟度は、

OSPOは、
従来のソフトウェア開発
プラクティスとオープン
ソース開発の要件との間のカルチャーギャップを埋めるのに役立つ。

アドホックな採用 ->法的なモチベーション ->コミュニティ主導 ->エンゲージメント主導 ->リーダーシップ主導のステージで進化。

Copyright © 2022 The Linux Foundation | August 2022
This report is licensed under the Creative Commons Attribution-NoDerivatives 4.0 International Public License

OSPOは、急速に変化するダイナミックな環境で、オープンソース ソフトウェア（OSS）のコンプライアンスをより適切にマネージメントするための社内ポリシーの確立・適応を統括推進。

OSPOは、企業の情報技術ガイドラインを満たしながらOSS開発
モデルをサポートする
ユニークで柔軟なツール
セットの構築を支援。

OSPOによる恩恵：継続性組織のニーズや戦略が進化するにつれて、OSPOは経営幹部の後援、予算確保、
ソフトウェア開発プラクティス、および OSSプロジェクトの優先順位付けにおける継続性を可能にする。

OSPOによる恩恵：教育
OSPOは、組織内のあらゆるレベルのチーム メンバーに対して、技術、メンターシップ、およびコンプライアンス
関連の教育やトレーニング
プログラムを改善。

概要
オープンソースのプロジェクトとイニシアチブは、他の組織と協力し、新しいテクノロジーを生み出し、新しいコミュニティの形成をサポートするために、実証された成功モデルを企業に提供します。多くの業界の組織がオープンソース プ
ログラム オフィス（OSPO）を設立し、高度なスキルを持つ人材を配置して、
オー
プンソース ソフトウェア（OSS）でリーダーシップを発揮し、この外部の研究開発（R&D）エコシステムで重要な足場を築いています。
本稿は、企業が OSPO をどのように組織化し、運営に必要な最小限の人員配置を行っているかを調査し、そのような OSPO の責務について議論し、オープンソースを企業で採用する際に、直面する課題について詳しく説明します。

深層考察：『オープンソース プログラム オフィス』

5

はじめに
オープンソース ソフトウェア（OSS）の活用で、製品の開発・提供方法が変化

ビジネスニーズをアップストリーム オープンソース プロジェクトに反映させるこ

しています。透明性のある開発コミュニティと公開されたソースコードへのアクとで、OSS は製品開発を加速し、市場投入までの時間を短縮するのにも役立セスを組み合わせることで、組織はソフトウェアの調達、実装、テスト、展開、 ちます。組織がオープンソース プロジェクトに関与するのは、それが楽しいか
および保守の方法について、従来とは異なる考え方を持つことができるようにらではありません。ビジネスや製品戦略の一部だからです。OSPO はそのようなりました（図 1）。OSS は、関与するすべての人々に豊かな利益をもたらすエ

な関与を管理し、調整します。

コシステムを構築しました。あらゆる業種・ドメインのあらゆる形態の組織が、オープンソースをより効率的かつ効果的に使用し、またオープンソースにコント
リビュートし、その戦略的なインパクトから利益を得ることを支援するために、
オープンソース プログラム オフィス（OSPO: Open Source Program Office）の下でオープンソース オペレーションの構築と育成を競っています（図 2）。

図1

OSPO 設立に向けた最初のステップは、今日存在するほとんどすべてのソフト
ウェア製品が OSS に依存しており、オープンソースがソフトウェア エンジニア
リングを習得するための鍵であるということを理解することです。ますます多くの業界において、先進的な組織は、ソフトウェア開発のリーダーになることによってその地位を確立し、OSS はそのリーダーシップの重要な要素となってOSS は、開発の共有を可能にし、研究開発（R&D）コストを削減します。これいます。第 2 のステップは、OSPO の設立をサポートし、予算を確保し、当該は、組織が数十億ドルに相当する OSS の恩恵を受け、より優れた製品やサー組織におけるオープンソース エンジニアリングの強化と拡大に対する長期的なビスを開発するために、それを利用することによって実現されます。さらに、確約を行ってくれる経営幹部レベルの役職者の協力を得ることです。OSPO を

1

オープンソース
は技術市場の加速原動力

2
協業・交流のための
中立的環境

6

3

リファレンス アーキテク
チャの認定

深層考察：『オープンソース プログラム オフィス』

断片化を最小限に抑え、アップストリーム開発
モデルをサポート

コミュニティ主導型のイノベーションを倍増させるシステム

7

4

8

6

より良い
相互運用性の実現

9
柔軟なライセンス モデル
によって支えられる
ビジネス機会を実現

新しいドメインへの参入障壁を低く5
オープン技術の標準化を促進10
より良い製品、改善された品質、および高度なセキュリ
ティに直結

短期に成果を生み出し、開発コストの共有も可能

開設し、さらに発展させることのできる信頼性のあるオープンソース リーダーを特定する上でも、その役職者は重要な役割を果たします。

図2

OSSの戦略的インパクト

OSPOの定義
OSPO は、次のことを行うように企図されています。(1) 組織のオープンソース
運用とその組織のコンピテンシー センターになること。(2) 組織のオープンソー
ス活動の戦略と一連のポリシーを設定すること。これには、コードの使用、配布、
 オープン ソリューション
開発の加速
 オープン スタンダードの実装を提供

 市場のコモディティ化
 非戦略的ソフトウェア資産の価格低下
 開発コストの共有

選択、監査などのポリシーの設定、開発者のトレーニング、法令遵守の確保、
 製組織に戦略的利益をもたらすコミュニティへの参加促進とその構築などが含ま品とサービスのエコシス 社外との提携
テムを構築して需要を喚起
 による
顧客との
連携定義を参照してください。
れます。詳細については、
TODO GroupOSPOOSPOの特徴 共通目標に向かって関係性を強化

自らを OSPO と名乗る組織は、その組織が成熟段階に至り、その企業においてクリティカルマスの支持を得ていることを示しており、次の 5 つの主要な特徴を持っています。

 市場のコモディティ化
 非戦略的ソフトウェア資産の価格低下

 製品とサービスのエコシス
テムを構築して需要を喚起

 開発コストの共有

1.

従業員は、OSS活用方法の育成と拡大を正規の業務としている。

2.

組織は、OSSの使用、および製品化に関する正式なポリシーを有する。

3.

経営幹部は、OSSとオープンソースが重要な戦略的資産であることを認識している。

 社外との提携
 顧客との連携

4.

 共通目標に向かって関係性を強化

かなりの数の従業員がオープンソース プロジェクトにコードを提供している。

5.

オープンソースの利用と参加を効率化し、促進するためのプロセス、手順、ツールが整備されている。

深層考察：『オープンソース プログラム オフィス』

7

OSPO成熟度モデル
OSPO の進化をよりうまく説明するために、TODO Group は、OSPO 成熟度モデル（図 3）を作成しました。これにより、組織が OSPO の状況を判断し、OSPO の成熟度を向上させるために実施する必要のある要素を特定するのを支援します。このモデルは、以下の 2 つの変数と 5 つのステージから構成されています。

モデル変数：

モデル ステージ：• Y軸変数：実行能力• ステージ0：アドホックな導入• X軸変数：OSPOレベル• ステージ1：法務教育• ステージ2：コミュニティ教育• ステージ3：エンゲージメント• ステージ4：リーダーシップ

図3

OSPOの
成熟度ステージ

高い

リーダーシップシップ
戦略的な意思決定
パートナーとして活動

出典：

エンゲージメント

TODO GroupOSSプロジェクトのホストおよびコミュニティの育成

ステージ 4

ステージ 3

コミュニティ教育

実行力

ステージ 2OSS利用の普及活動とエコシステムへの参加

法務教育

ステージ 1OSSコンプライアンス、インベントリ、開発者教育の提供

導入

ステージ 0アドホックなOSSの採用

低い

深層考察：『オープンソース プログラム オフィス』

ヌル

OSPOレベル低8高ステージ0：アドホックなアプローチ

一般的に組織が OSPO を形成するのは、その組織の今や、適応方法や導入時の使用方法はさまざまですが、ほとんどすべての組

人々が、ほぼすべてのエンジニアリング部門・開発

織が OSS を使用しています。OSS は、製品やツールのビルディング ブロック
やライブラリーとして、ベンダーのソリューション スタックの重要な部品として、部門および業務でオープンソース製品とそのコード

またはサービス提供を支えるものとして使用されています。最新のクラウドネを使用していることに気付いたときです。通常このイティブ アプリケーションでは、ほぼデフォルトとして、コンテナ オーケスト
レーション、可観測性、データ ストレージ、メッセージングなどにオープンソー
ス システムを使用しています。言い換えれば、ほぼすべての組織がオープンソー
スを使用しています。しかし、開発者はすぐに利用可能なツールや技術を使用

使用は、顧客やユーザーに対する製品やサービスの一部としてではなく、社内利用として行われます。

して問題を解決するため、最も初期の導入形態はアドホックです。通常この「アドホックな導入」は、基本的なデフォルト以外のライセンス コンプライアンス
や、OSS の利用や OSS コンポーネントで構築された製品の配布に起因する長期的な影響についてほとんど考慮されないことを意味します。

ステージ2：コミュニティ教育中心の導入
初期段階

ステージ1：法務教育中心の導入

組織は、OSS の価値や、コンプライアンス、教育、およびソフトウェア部品表

一般的に組織が OSPO を形成するのは、その組織の人々が、ほぼすべてのエ（SBOM: Software Bill of Materials）の必要性を認識すると、その後、OSS

ンジニアリング部門・開発部門および業務でオープンソース製品とそのコードの使用による経済的利益を認識し始め、OSS の使用を拡大しようと努力するを使用していることに気付いたときです。この使用は、通常は顧客やユーザーようになります。ステージ 2 の OSPO は、正式に承認された OSS 製品の使に対する製品やサービスの一部としてではなく、社内利用として行われます。

用を促進するアンバサダーとして、適切な OSS 活動に関する教育プログラム、

この初期段階では、組織は OSPO に対して多くの異なる名前を使用すること

および技術トレーニングや OSS スキル構築と認定のための授業受講の費用償がよくあります。たとえば、IBM は当初、このようなオープンソース運用活動を

還などの内部メカニズムを作成します。これらの措置により、組織は OSS の「Open Source Steering Committee（オープンソース運営委員会）」と呼んで使用を拡大し、OSS が重要であるだけでなく、プロプライエタリ ソフトウェア

いました。

よりも望ましく、かつ好ましいというメッセージを増幅できます。

ステージ 1 にある組織は、OSS がビジネス・技術戦略の重要な部分であることを認識しています。また、OSS プロジェクトのセキュリティ プラクティスがプ
ロプライエタリ ソフトウェア企業のそれとは異なっていることを理解しています。

この段階に達すると、組織は、運用にクリティカルな OSS プロジェクトに対して、開発者が非常にアクティブなコントリビューターや主要メンテナーになる

組織は、このステージにおいて法務的リスクとセキュリティ リスクを特定する必要があります。リスク軽減戦略には、次のものが含まれます。
• ライセンス遵守

ほどまでに取り組みを強化することを奨励し始めます。この段階で、OSPO は開発者のために、オープン アウトバウンド ソース コントリビューション（オープンソースの外部コントリビューション）を効率化および最適化しするようになり、さらに、オープンソース コミュニティにおいて幅広い信頼性を確立するために、オープンソース プロジェクトを創設・開始するようになります。

• 開発者教育• ソフトウェアのインベントリ トラッキング
深層考察：『オープンソース プログラム オフィス』

成長段階

9

ステージ3：エンゲージメント中心の活動

ステージ4：リーダーシップ中心の活動

ステージ 3 において、組織は OSS プロジェクトを開設し、ホストし、また主

この成熟段階において、OSPO は（コミュニティにおける）技術決定の戦略的パー

要なスポンサーとして活動します。組織は 1 人以上のフルタイムの従業員をプ

トナーとなり、取るべき道をガイドし、プロジェクトへの長期的なコミットメン

ロジェクトに専任させ、プロジェクト コミュニティを育成し、その健全性を確トを形成します。さらに、組織の最高技術責任者（CTO）やその他の技術リー保する責任を引き受けます。組織は、このレベルの組織的コミットメントを、

ダーは、どのオープンソース技術を信頼するか、およびオープンソース プロジェ

プロジェクトをオープンソース化することを決定した従業員の個人的活動と混クトを判断する際にどの判断基準を用いるかについて OSPO やそのリーダーと同することはありません。さらに、このステージでは、当該組織のリーダーが協議します。主要なオープンソース技術の選択は、多くの二次および三次コスOSS プロジェクトを育成し、パブリックな領域に立ち上げることをサポートしトを発生させたり、さらに上流および下流の技術や要員採用計画に影響を及ます。なぜなら、これらのプロジェクトがどのように組織に恩恵をもたらすか

ぼしたりすることが多いため、オープンソース プロジェクトの選択がビジネスを理解しているからです。このようなプロジェクトは、組織のバリュー プロポ

上の重要な意思決定になります。この最終段階では、次の 3 つの戦略的ガイ

ジション（value proposition：価値の提案）の中核でなくとも、その組織のダンスが具体化されます。

技術基盤にとって重要な機能群に対し、パフォーマンスと経済性を向上させる
ことがよく見られます。
さらに、このステージで OSPO は、オープンソース プロジェクトを綿密に検討し、組織化し、運営し、またリーダーを用意し、指導を行うために、以下のようないくつかのメカニズムを開発します。
• 内部プロセス• プレイブック• チェックリスト• ツール開発

深層考察：『オープンソース プログラム オフィス』

10

1.

組織の技術スタックとして採用/削除するオープンソース技術について、CTOと技術リーダーに助言

2.

受け入れ可能なOSSプロジェクトとみなされるもののベンチマークを主導

3.

組織がプロジェクトの政治状況を理解し、ナビゲートできるよう支援

OSPOの組織構成

図4

研究開発組織内に構築されたOSPO

このセクションでは、一般的な OSPO の組織構造について説明します。組織
は、どの 2 つを比べても、同一なものはないことに留意してください。そのた研究開発責任者

め、クッキーの型で切り出したかのような型にはまった OSPO の構造はありません。そのかわりに、オープンソースへの関与に関して長い実績を持つ組織を含む多くの組織が、さまざまな設定を試しています。一般論として、全社的なソフトウェア戦略、オープンソースへの期待、製品における OSS への依存性、

OSPO

オープンソースにおける空白領域などの要因に基づいて、最も適切で効率的な構造を見つけることが組織の目標です。

エンジニアリング

戦略

支援

例1：研究開発部門内のOSPO
OSとシステム
ライブラリ

ポリシーと
プロセス

グラフィックス

技術的エバン
ジェリズム

メディア

開発者との
関係性

IoT

オープンソース
ファウンデーション

OSPO の一般的な配置は、研究開発組織内にあります。たとえば、本稿の筆

ツール ＋ IT

者は、Samsung 社の Open Source Group を設立するために、2013 年初頭に同社に採用された時に、このモデル（図 4）を採用しました。この例では、オープンソース リーダーがオープンソースに関わるエンジニアリング、および戦コンプライアンス

略と支援業務の責任を負い、研究開発部門の責任者に直接レポートする構造です。Samsung OSPO には、オープンソース イベントのための要員・旅費・ス
ポンサーシップ費用、オープンソース ファウンデーションの会費、ハードウェ

イベント

アおよびソフトウェア費用、その他のさまざまな雑費（T シャツや帽子などの販促アイテムを含む）をカバーするための専用予算があります。このやり方は、
長年にわたって非常にうまく機能しています。

企業内の開発OSPO を研究開発業務（部門）のもとに設置するおもな理由は 2 つあります。
クラウド

オープン
スタンダード1 つ目は、製品部門から独立させ、製品部門の補助的な開発部門とならない

ソフトウェアの調達ようにすることです。これによって OSPO が財務的にもプロジェクト的にも一定の独立性を維持し、製品部門に左右されることなく最優先のオープンソース
技術に集中できるようになります。2 つ目は、日常の製品圧力から離れて、他AIの組織や大学などの外部関係者を巻き込んだ取り組みをより強く支援することが挙げられます。

その他

深層考察：『オープンソース プログラム オフィス』

11

例2：企業レベルのOSPOと部門レベルのサポートOSPO

サポート OSPO は、部門レベルでオープンソース戦略を実行し、スタッフが全

このモデル（図 5）は、複数の製品部門を持つ大規模な組織で最も効果的にントする責任があります。企業レベルの OSPO は、技術的専門知識とリーダー

社ポリシーとプロセスを遵守することを確保し、トレーニングを提供し、多く機能します。このモデルは、企業レベルの OSPO と、それが活動を調整す
る複数の部門レベルのサポート OSPO で構成されています。企業レベルのOSPO は、組織全体のポリシーとプロセスの確立、戦略の決定、オープンソー
ス組織との協力、主要なオープンソース イニシアチブの推進、全社レベルでのオープンソース関連のマネージメント全般に責任を持ちます。

の場合、アップストリームのオープンソース エンジニアリング活動をマネージメ
シップを提供する上級エンジニアやシニア アーキテクトを除き、エンジニアリ
ング要員を持っていない場合があります。

例3：CTOオフィスやエンジニアリング部門の一部としてのOSPO
中規模組織では、OSPO をエンジニアリング部門内、または CTO オフィスの下に置くことが一般的です。この構造の OSPO には、通常、経営幹部（エンジニアリング担当シニアバイスプレジデントまたは CTO）が管理する専用予算が割り当てられます。OSPO に独自予算が確保される場合もありますが、すべての支出や対外的なコミットメントには、経営幹部の承認が必要です。OSPO は、

企業レベルのOSPOと部門
レベルのサポートOSPO

組織のニーズに応じてアップストリーム プロジェクトで作業する専用のエンジ

CEO オフィス

図5

ニアリング要員を持つ場合もあります。図 6 は、この 2 つのシナリオを示しています。

ビジネスユニット１

ビジネスユニット2

コーポレートCTO

エンジニアリング
担当SVP（または部門CTOオフィス）エンジニアリング
担当SVP（または部門CTOオフィス）

企業レベルの
OSPO

部門OSPO部門OSPO

戦略

図6

エンジニアリング部門やCTOオフィスの一部としてのOSPO（専任オープンソース開発者を伴う）

コンプライアンス

CEOオフィス
CEOオフィス

エンジニアリングエンジニアリングエンジニアリングサポート

OSPOOSPO
オープンソース
オープンソース
開発者開発者

その他
深層考察：『オープンソース プログラム オフィス』

12

CEOオフィス
CEOオフィス

エンジニアリングエンジニアリング

CTO CTOOSPOOSPO
オープンソース
オープンソース
開発者開発者

図7

例4：仮想OSPO

仮想OSPO仮想 OSPO（図 7）は、オープンソースの責任者 ( 通常はエンジニアリング部
門内 ) がいるが、専任スタッフがいない組織では一般的な仕組みです。オープ

CEOオフィス

ンソースの責任者は、法務、エンジニアリング、マーケティングなどの異なるチー
エンジニアリングプラットフォーム

法務
オープンソース
カウンセル

マーケティング
オープンソース
開発者との
関係性

IT

ムの個人で構成される仮想 OSPO スタッフと一緒に作業します。それぞれのス
タッフは、時間の一定割合をオープンソース活動の支援に割り当てます。仮想
OSPO には通常、専用予算はありません。かわりに、オープンソース支出の予

オープンソースのITとツール

算は、エンジニアリング部門または CTO オフィスから提供されます。

例5：公式OSPOがないケース

サービス

この例（図 8）は、正式な OSPO を持たない組織を示しています。これは、さまざまな個人が OSPO に関連付けられた職務を遂行する小規模な組織およびハードウェア

新興企業における一般的な設定です。この構造は、小規模な組織に柔軟性を提供しますが、組織の成長に応じて拡張することは困難です。

オープンソース
責任者

図8

エンジニアリング要員（色付きの円で表される）は、小規模な組織においてOSPOの職務を遂行

法務CEO オフィス

マーケティング

事業開発

IT
深層考察：『オープンソース プログラム オフィス』

13

OSPOへの人員配置
OSPOの人員配置は多くの変数に依存します。ただし、特定のOSPOの構造に

TODO Groupは、この職責のための職務明細書のテンプレートを公開してお関係なく、複数の業務を必要とします。これらの業務は個別の職位である必要

り、必要性に応じてカスタマイズできます。

はありません。場合によっては、一連のスキルを持つ優れた個人が複数の業務を果たすことができます。

ソフトウェア アーキテクト
OSPOには、プラットフォームやコーディング基準などの設計上の選択から技術

OSPO室長標準に至るまで、OSSに関連したトピックに関する高度な技術的意思決定者とOSPOの室長は、組織とオープンソース チームの規模に応じて、オープンソース

して行動する上級ソフトウェア アーキテクト、またはプリンシパル エンジニアのディレクター、またはバイスプレジデントと呼ばれることもあります。オープを置くことが必須であると考えます。

ンソースの責任者として、全社のオープンソース戦略とビジネス指標を管理し、また遂行し、オープンソース プログラムのビジネス、および技術的成功をトラッキングする責任を負います。OSPOの構造によっては、室長がオープンソース エ
ンジニアリングに関するリソースに責任を持ち、オープンソース コンプライアン
スを遵守し、オープンソース団体に対して組織を代表したり、オープン標準規格の取り組みに参加したりすることもあるでしょう。

テクニカル エバンジェリスト
テクニカル エバンジェリストとは、強力な技術的バックグラウンドを持つ人物
で、オープンソース グループによって開発されたオープンソースへのコントリビ
ューションやソリューションを、組織の顧客、見込み客、パートナーに向けて、さらにはオープンソースコミュニティに対して伝道（evangelize）することをおもOSPO 室長は以下の特徴を有します。

な役割とします。テクニカル エバンジェリストは、イベントでのデモの実行、技• ソフトウェア開発における強力なエンジニアリング バックグラウンドと経験

術的なプレゼンテーションの提供、ドキュメントの作成、時には特定の技術がクリティカルマスに到達するまでの支援の構築に責任を持ちます。

• オープンソース団体とのつながり• オープンソース ライセンスに関する包括的な理解

コンプライアンス エンジニア• 業界のベストプラクティスに関する知識

コンプライアンス エンジニアは、組織のコンプライアンス ポリシーおよびプロ• 全社的な方針およびプロセスの策定に関する知識および経験

セスの実行をサポートし、組織の製品、およびサービスで使用しているOSSの• 組織の製品、およびサービスに関連する技術知識

ライセンス義務をすべて確実に履行するようにします。一部のOSPOは、オープ
ンソース コンプライアンス業務の完全な責任を負っており、その場合、OSPO• オープンソースの歴史に対する見識• さまざまな技術プロジェクト コミュニティがどのように運営されているかに関する知識は複数のコンプライアンス エンジニアを在籍させる必要があります。

法務顧問
OSPOのスタッフとして法務顧問が在籍していることはまれです。中小規模の組織では、ほとんどの場合、オープンソース ライセンスに精通した法務顧問にアクセスできれば十分です。

深層考察：『オープンソース プログラム オフィス』

14

OSPOの責務
OSPOは、時間の経過とともに変化するさまざまな責任を引き受けます。次のプンなアクセスと透明性のある開発コミュニティにより、ソフトウェアの提供者

サブセクションでは、これらの責任について説明し、詳細に議論します。これら

は、開発プロセスへの積極的な参加を維持し、なおかつ開発コストを削減できの責任は、インタラクティブなOSPO Mind Mapで確認できます。

るようになりました。さらに、ソフトウェアのエンドユーザーは、ソフトウェア ベンダーから提供された製品の受動的な受領者ではなく、アップストリーム プロ

オープンソース戦略の確立と実行

ジェクトに直接コントリビュートすることによって、開発プロセスに積極的に参ソフトウェア産業が始まって以来、ほとんどすべてのソフトウェア組織が同じ加することもできます。この開発モデルにより、組織はソフトウェアの調達、実ビジネスモデルに従ってきました。すなわち、ソースコードは従業員によって開装、テスト、展開および保守方法について異なる考え方を持つことが可能にな発されるか、または第三者からライセンス供与され、知的財産は非公開で保持りました。本稿では OSSを活用し、製品に統合する組織の4つの基本戦略：消され、ソフトウェアはバイナリ形式でクライアントに配布されてきました。しか費者、参加者、コントリビューター、リーダーについて説明します。

し、エンタープライズ グレードのOSSが利用可能になったことにより、組織が製品を開発、および配布する方法が変わりつつあります。ソースコードへのオー

図9

リーダー

オープンソース戦略の4つのコアステージ—消費者、参加者、
コントリビューター、リーダー

コントリビューター
参加者
消費者
ンソ

オープ

深層考察：『オープンソース プログラム オフィス』

へ

ェクト

ロジ
ース プ

15

コン

参加と

的な
の継続

ション

ュー
トリビ

図 9 は、消費、参加、コントリビューション、リーダーシップの 4 つの主要なOSS 戦略を示しています。各戦略は、組織が１つ前の戦略ステージで成功することを必要とします。組織がこのステージをどこまで進むかは、その組織の目

オープンソースコードを利用するだけで目標を達成でき、そのレベルにとどまることに満足する的と全社的なオープンソース戦略に依存しています。

組織もあれば、特定のリーダーシップ ポジショ

これら 4 つの戦略は、組織があるステージから別のステージに移行する際にンを獲得したいという野心を持つ組織もある。

オーバーラップします。通常、初期ステージは、エンジニアが製品開発でオー
プンソース コンポーネントを使用することによるもので、エンジニアリング主導型です。当初、戦略的オープンソース プロジェクトへの彼らの参加は、会話への参加、またはわずかなコントリビューションに限定されます。時間の経過とともに、このような利用は組織内で増えていき、牽引力を得て、ビジネス戦
略の一部になる可能性があります。

• オープンソースの利用を評価/承認するための自動化されたワークフロー
ソフトウェアを導入する。

オープンソースコードを利用するだけで目標を達成でき、そのレベルにとどま• クローズドソース ソフトウェアとオープンソース ソフトウェアの複雑な組ることに満足する組織もあれば、特定のリーダーシップ ポジションを獲得した

み合わせを管理するために必要とされるエンジニアリング、製品管理、法いという野心を持つ組織もあります。あなたの組織もすでにこれらのステージ

務部門の人員数とインフラストラクチャへの追加投資計画を作成する。

のいずれかに到達している可能性が高いので、現在のステージと目標とするス
テージの両方を明らかにすることが重要です。

商用製品においてOSSの使用を奨励するソフトウェア戦略を確立する場合、
OSSの採用を成功させるために以下の措置を講じることができます。

消費者のシナリオ• OSSの使用に関する戦略を広く伝える。

一般的なスターティング ポイントは、製品やサービスへのOSSの採用、あるい• オープンソース コンプライアンス、ライセンス義務、オープンソース開発

はOSSの組み込みです。オープンソース コンポーネントを意欲的に活用することは、製品やサービスを差別化する力を高め、それらの製品やサービスを提供するための全体的な時間とコストを削減します。以下のアクション アイテムはこの戦略において非常に重要です。

モデルについてスタッフを教育する。
• 製品への組み込みの候補となるOSSを決定するための明確な基準を確立する。例としては、新機能の利用可能性、プロジェクト ソースコードの成熟度、プロジェクト開発コミュニティの規模と構成、それを保守している• ライセンス コンプライアンスを含むすべてのオープンソース活動の情報センターとして機能するオープンソース レビュー委員会を設立する。
• 戦略的な分類体系を使用し、どのOSSを使用するかを決定する際の指針とする。

人とコードの状況を評価するファクターなどがある。
• オープンソース コンプライアンス プログラムを確立して、製品で使用しているOSSのライセンス義務を満たすプロセスが存在していることを確認する。

• SBOMを活用して、使用されているすべてのソフトウェアのインベントリを• 社内コラボレーションの改善、透明性の高いチーム コミュニケーションの作成し、使用中のOSSのライセンスをより詳細に識別して、企業がすべて向上、開発サイクルの短縮を可能にするオープンソース開発ツールを特定のライセンス義務を遵守しているかどうかを判断したり、既知のセキュリ

し、開発者が採用するよう奨励する。

ティ脆弱性を特定したりするために使用する。

深層考察：『オープンソース プログラム オフィス』

16• オープンソースのメーリング リストへの登録や関連した雑誌の購読、ブログのフォロー、ディスカッション フォーラムへの参加をスタッフに推奨する。
• 学習や人的交流の機会を目的としたオープンソース カンファレンスへのス組織が製品やサービスでOSSをうまく利用できるようになると、オープンソース コミュニティに参加するための戦略を拡大することができる。

タッフの参加を奨励し、そのための資金を提供する。
• Linux Foundationなどのオープンソース業界団体やファウンデーションに参加し、開発や法務に関連したベストプラクティスを業界のリーダーと共有する機会とする。

コントリビューターのシナリオ
組織が定常的にコミュニティに参加することのメリットを真に理解するようになると、プロジェクトやコミュニティにコードを提供することのアドバンテージを評価することができます。コード コントリビューターは、将来の機能を形作• オープンソース コミュニティから開発者を採用する。

る役割を果たすため、企業のビジネス目標にとって重要なオープンソース プ• 地域のオープンソース ユーザー グループをホストし、スタッフが地域のオープンソース活動に参加するよう奨励する。
• コミュニティ メンバーを招いて、プロジェクトに関連するトピックについて開発チームに発表してもらう。

ロジェクトにソースコードを提供することは、それらのプロジェクトに影響を与え、肯定的な評判を獲得するための最善の方法です。このシナリオでは、次のアクション アイテムが不可欠です。
• コミュニティ開発のベストプラクティスについてチームを教育する。
• メーリング リスト、Slack、ディスカッション フォーラムなどの技術ディス

参加者のシナリオ

カッションに積極的に参加し、推進力になる。

組織が製品やサービスでOSSをうまく利用できるようになると、オープンソー
ス コミュニティに参加するための戦略を拡大することができます。経験豊富な開発者を雇用していない場合は、コミュニティとより密接に関わり、認知度を高め、必要な人材を惹きつけることが必要になるでしょう。参加者としての活動には、以下のアクション アイテムが不可欠です。
• チャット サーバー、メーリング リスト、フォーラム、Webサイトなどのコミ• オープンソース コミュニティの確立された作業方法とプロセスをフォローする。
• バグ レポートを作成し、既存バグの修正でコントリビュートする。
• 機能を改善、または拡張するコードでコントリビュートする。

ュニティ コミュニケーション プラットフォームなどをモニタリングし、プ• 新機能を実装するコードをコントリビュートする。

ロジェクトの開発状況を把握し続ける。

• バグ修正やその他のセキュリティ対策でコントリビュートする。

• コミュニティとの関係性を確立するために、関連する会議やミートアップに参加する。
• 企業の認知度を向上させるためにプロジェクト イベントやファウンデーシ
ョンのスポンサーになる。

• 文書化作業でコントリビュートする。
• テストと統合の取り組みでコントリビュートする（テスト コードの開発、テ
スト ケースの作成など）。
• あなたのコントリビューションのフィードバックに耳を傾け、それに基づいて行動する。
• あなたのコントリビューションと積極的な参加を通じて、プロジェクト メ
ンテナーや他のプロジェクト参加者からの信頼を確立する。

深層考察：『オープンソース プログラム オフィス』

17• オープンソース戦略をリードし、OSPOを管理するためのディレクターを採用する。

 コミュニティにとって使いやすく有用なものとなるようなオープンソー
ス ライセンスのもとで、内部開発のプロプライエタリ ソースコードを• 製品やサービスに不可欠なオープンソース コミュニティへのコントリビューターやコミッターを雇用する。
• オープンソースの利用とコントリビューションをサポートするためにオープ
ンソース コラボレーション ツールを導入する。
• 外部コミュニティに関与するためのエンジニアリング、製品管理、法務の人員に段階的に投資する。

オープンソース プロジェクトに（関連する場合に）提供することで、誠実さを示す。
• 重要なソフトウェア製品開発のためにオープンソース コミュニティと協力したことにより、組織が目に見える利益を達成したことを公に認める。
• 従業員に権限を与えて、プロジェクト内でメンテナーの地位を求めることができるようにする。
• イベントのスポンサー、プロジェクト インフラストラクチャーへの財政支リーダーシップのシナリオ

援、プロジェクトの著名なオープンソース開発者の採用を検討する。

オープンソース戦略の最高の形態はリーダーシップです。オープンソース リー
ダーは、同プロジェクトのメンバーとの信頼関係を確立し、高いレベルの継続• 関連するオープンソース団体やファウンデーションへの参加を増やす。

的なコントリビューションを維持することによって戦略的地位を獲得します。リ• 長期的な商業目的を達成するために、さまざまなコミュニティやコンソー

ーダーシップが発揮できる組織は、最新動向の技術から利益を得ることがで

シアム内でアーキテクチャーや要件収集のイニシアチブを主導する。

きます。

• オープンソース アーキテクトの職務を確立して、OSSの利用とコントリビ

このシナリオでは、リーダーとしての方針を確立するために、ターゲットを絞った、オープンソース コミュニティやコンソーシアムに多額の投資が必要です。さらに、外部コミュニティや業界コンソーシアムにおいてリーダーシップを確立するためには、エンジニアリング、製品管理、および法務への追加投資が必要になります。以下は、特定のオープンソース プロジェクトで組織をリーダーシップの役割に導くのに役立つ戦術的なステップの一部です。

戦略目標に対する選択肢は数多くありますが、OSSを使用、および開発する組織では、次の戦略目標が一般的です。
• 開発コストの削減• 製品の品質と柔軟性の向上

計画、開発、テスト、リリース管理など、プロジェクトのあらゆる側面に積極的、かつオープンに参加し、それによってプロジェクトの優れた世話役として行動する能力を発揮します。
• より高いレベルの参加とコントリビューションを達成する。
 さまざまなプロジェクト参加者と交流する。
 概説したベストプラクティスを通じて、既存のオープンソース プロジェ
クトのバグ修正パッチの適用、新機能の追加、機能拡張にコントリビ
ュートする。

深層考察：『オープンソース プログラム オフィス』

ューションを積極的に指導させる。 		

18• 製品の市場参入時間を短縮• コミュニティ参加を通じてエンジニアリング能力の向上• オープンソース活動に対する開発者コミュニティの関与を拡大・深化

オープンソース コンプライアンスの管理• サードパーティ ソフトウェア サプライヤーの契約義務を遵守。

オープンソース イニシアチブは、オープンソース コミュニティとのコラボレーシ• 商用製品の差別化を保護。

ョンを通じてイノベーションを加速する手段を組織に提供します。組織の核心的な責任の1つは、オープンソース ライセンスの遵守です。オープンソース コン

OSPOは一般に、次の2つの方法でオープンソース コンプライアンスに関与しま

プライアンスとは、ユーザー、インテグレーター、およびソフトウェア開発者がす。

適切に著作権表示を認識し、OSSコンポーネントのライセンス義務を履行する

1.

プロセスです。

OSPOは、OSSを扱うすべての組織、関係者に完全なコンプライアンス プ
ログラムの実装と実行に責任を負います。これには、ポリシー、プロセス、
ツール、自動化、教育、および製品・ソフトウェア・サービスに組み込まれる

オープンソース コンプライアンスは、次の4つの目標の達成に役立ちます。

OSSのすべての義務の最終的な履行が含まれます。

• オープンソース ライセンス義務の遵守。

または• 商用製品、およびサービスにおけるOSSの効果的な利用を促進。

2.

組織の一般的なオープンソース ポリシーを確立する責任を負い、これらのポリシーの実行と執行を組織全体のさまざまな部門に行き渡らせます。たとえば、オープンソース コンプライアンスの確保は、OSPOはポリシーとプロセスにフォーカスし、プロダクト側の専任チームはコンプライア
ンス プログラムの実際の実装と実行、それ以上のことも任されていると

図 10

いったシナリオが好例です。

オープンソース コンプライアンスの確保は部門横断的な活動

OSPOは、コンプライアンスに関するすべての責任に直接、影響を及ぼします。OSPOの具体的な役割がどうであれ、オープンソース ライセンス、コンプラ
イアンス プラクティス、エンジニアリングに精通した人員が少なくとも1人必要です。

企業内の開発コアコンプライアンス チームの中核をなす最小限のメンバーには、法務部門の法務部門

エンジニアリング

担当者、エンジニアリング部門、または製品部門の担当者、および(OSPOのメ
ンバーであることが多い)オープンソース コンプライアンスの専門家が含まれま

製品部門

オープンソース
コンプライアンスす。以下の表では、オープンソース コンプライアンス チームの中核を構成する
これらのメンバーのおもな役割について簡単に説明します。オープンソース コ

IT

ンプライアンスに関する詳細な議論については、Linux Foundationの無料の電子書籍Open Source Compliance in the Enterpriseをダウンロードしてく

ドキュメント作成部門

サプライチェーンださい。この電子書籍は、製品やサービスでオープンソースコードを使用し、オープンソース コミュニティに法的責任を持って参加するための最善の方法に関する実践的なガイドです。

ローカリゼーション

深層考察：『オープンソース プログラム オフィス』

19

図 11

コア コンプライアンス
チーム メンバーの業務と責任

コア オープンソース
コンプライアンス チーム

おもな責任

法務部門の担当者• OSSの利用とOSSプロジェクトへのコントリビューションをレビューし、承認する。

この担当者は、取り扱うタスクによ• すべてのソフトウェアの受け取り時のライセンス、および配布時のライセンスに関するガイダンスをり、法律顧問からパラリーガル（弁護士業務の補佐）までさまざまであ
る。

提供する。
• オープンソース トレーニングの作成にコントリビュートする。
• コンプライアンス プログラムの作成・改善にコントリビュートする。
• ライセンス コンプライアンスのドキュメントと情報リソースの内容を確認し、承認する。
• 製品に含まれる各ソフトウェア コンポーネントに必要な義務のリストをレビューし、承認する。

エンジニアリング部門、および製品• コンプライアンス ポリシーとプロセスを遵守する。

部門の担当者• コンプライアンス プラクティスをソフトウェア開発プロセスに組み込む。

エンジニアリング部門と製品部門を区別していない組織もある。

• コンプライアンス プログラムの改善にコントリビュートする。
• 技術コンプライアンス ガイドラインを遵守する。
• コンプライアンス関連のすべての質問に迅速に対応する。
• 設計、アーキテクチャー、コードのレビューを実施する。
• セキュリティのベストプラクティスを導入する。
• 配布用オープンソース パッケージを準備する。

コンプライアンス担当者• ソースコード監査の実施など、ライセンス コンプライアンス活動を推進する。

オープンソース コンプライアンス オ• オープンソース ライセンス義務履行の一環として、オープンソース パッケージの配布を調整する。

フィサーは、必ずしも専任ではない。
ほとんどの場合、オープンソースのマ
ネージャーまたはディレクターの役割も果たす。

深層考察：『オープンソース プログラム オフィス』• コンプライアンス トレーニングの作成にコントリビュートする。
• コンプライアンス プログラムの改善にコントリビュートする。
• OSS検出の自動化を容易にするための新しいツールの作成にコントリビュートする。
• オープンソース コンプライアンスの視点から製品リリースを承認する。

20

これら3つの職務（法務、エンジニアリング、コンプライアンス）は、一体となって次の3つの主要なタスクを担当します。
1.

オープンソースのポリシーとプロセスの確立
OSPOが作成すべきポリシーとプロセスは、戦略ステージにおける、組織の現サードパーティ ソフトウェア ライセンス、およびOSSライセンスの相互準

在の立ち位置と目標とする立ち位置によって異なります。第1ステージ（利用）で拠を確保する。

は、OSPOは、OSSの利用とコンプライアンスの側面をサポートできるオープン
ソース インフラストラクチャーを実装することが必要です。図 12 は、OSS を

2.

OSSの利用とコントリビューションを促進する。

3.

オープンソース ライセンス義務がプロプライエタリ ソフトウェアやサー
ドパーティ ソフトウェアに伝播しないようにすることで、プロプライエタ
リな知的財産（および製品差別化）を保護する。

使用するための組織のガイドラインを定義する、単純なポリシーを超えたイン
フラストラクチャーを示しています。同図は、使用とコンプライアンスをカバーし、開発プロセスにコンプライアンス チェックポイントを組み込み、オープンソースの適切な使用を管理するチームを設立し、必要なトレーニングを提供し、ツールの利用を可能にし、関連するオープンソース組織との関係を促進する戦略を含むところまで拡張されています。

図 12オープンソースの利用とコンプライアンスのための
基盤を実現

戦略

ポータル

ポリシーとプロセス

開発チーム

Education

ツール

Linux Foundation

コンプライアンス

社内サイト
(教育用)

使用およびコンプライ
アンス ポリシー

開発およびQAプロセスにコンプライアンスを組み込む

コンプライアンス チーム(コア&サポート)

企業ポリシーのトレーニング

ソースコードスキャン

OpenChain

スコアボードと成功指標

ガイドラインとベストプラクティス

リンケージ
解析

オープンソース
ライセンスに関する
トレーニング

依存関係
解析

新入社員研修セキュリティ
脆弱性分析(外部からの)照会の管理

ライセンス管理とリスク許容度

外部サイト(義務履行、
ソースコード配布)

M&Aと事業開発

社内メッセージング

ソフトウェアの調達

外部メッセージング

配布
監査
告知
使用

コンプライアンス
ツールを
ビルド システム
および開発者
ワークフローに
組み込む

義務履行

製品部門用
チェックリスト

異なるライセンス下のコードの混合開発者用チェックリスト
ソフトウェア調達用
チェックリスト
コンプライアンス
メンターシップ
プロフェッショナル用
公式トレーニング

深層考察：『オープンソース プログラム オフィス』

21

ソフトウェア部品表

オンライン フォームとワークフローの自動化
IP評価ツール
ソフトウェアインベントリ管理
プロジェクト管理

SPDX: Software
Package Data Exchange
オープン コンプライアンス
プログラム
TODO GroupOSSF: Open Source
Security Foundation

る投資利益を明示することができます。OSPOとオープンソース エンジニアリン
グがコストセンターである企業においては、製品開発を直接サポートしているオ

図 13ープンソース プロジェクトに焦点を当てて推進していくべきです。

オープンソース コントリビューションに必要なインフラストラクチャー

図 13 は、オープンソース コントリビューションをサポートするためにOSPOがコントリビューション

専任グループオープン スタンダード

プロジェクト
コントリビューション
に関するポリシーとプロセス

OSPOを設立

関連するオープン標準の規格化活動に参加

ガイドラインとコントリビューション
トレーニングオープンソース
プロジェクトから雇用

社内技術を
リファレンス実装としてオープンソース化することを検討

コントリビューション
承認チーム

オープンソース
ファウンデーションへの
支援と参加

重要な
オープンソース プロジェクトへの参加の拡大

オープンソース イベントの開催

実装する必要がある追加要素を示しています。

オープンソース組織との協力
オープンソース ファウンデーションは、オープンソース エコシステムの中であなたの影響力を拡大するために大きな助けになります。最適な出発点は、あな
たの組織の製品や技術的な関心に直結したイニシアチブをホストするオープ
ンソース ファウンデーションとの協力です。多くの組織は、Linux FoundationのTODO Group、Mozilla Foundation、Apache Foundationなどの著名で確立されたファウンデーションに参加することに価値があると考えています。あなたの組織が主にリーガル関連の動向・力学に関心を持っている場

オープンソース開発をサポートするITインフラストラクチャー

合は、Software Freedom GroupやOpen Invention Networkなどに参加することが有益です。これらの協力によってめざすものは、あなたの組織が依存しているエコシステム内で、あなたの組織の活動機会を見つけることでオープンソースのキャリアパスを確立/認知す。OSPOは、組織のオープンソース戦略と製品優先順位に基づいて、これらの関係をドライブする存在です。

依存しているプロジェクトのコミュニティをサポート

パフォーマンス指標のトラッキング
OSPOにとってより困難なタスクの1つは、エンジニアを望ましい行動に向けるためのインセンティブとして、OSPOがトラッキングすべき主要なパフォーマン
ス指標、またはメトリクスに関して意思決定をすることです。製品組織でよく使アップストリーム オープンソース開発を優先順位付けし、それを推進用される従来のメトリクスは、オープンソース開発の状況では適用できず、新しOSPOの主要な責任の1つは、製品やサービスで使用されている重要なオープン
ソース プロジェクトへの組織の関与を強化させることです。その最初のステッ
プは、すべての製品を調査し、SBOMをレビューすることによって、組織がどこでOSSに依存しているかを特定することです。その次のステップとしては、すでに使用されているOSSに優先順位を付け、コントリビューション戦略を確立することです。このような狙いを絞ったアプローチにより、OSPOは複数の製品にわ

深層考察：『オープンソース プログラム オフィス』

22

いメトリクスが必要になります。多くのOSPOは、専用のツールを使用して、組織のオープンソース プロジェクトへのコントリビューションをトラッキングし、組織からのコントリビューションのタイプを分析し、コントリビューションのパ
ターンを特定し、開発効果を向上させるための推奨事項を提供しています。

インナーソース プラクティスの実践
インナーソースとは、オープンソース開発の方法論から学んだ手法を社内プロジ
ェクトに適用するプロセスのことで、その目標は、協調、オープン ソースの開発モ

OSPOとしてオープンソースの影響力を拡大するための優れた方法は、インナーソース プラクティス

デルに共通する価値観を企業内で育むことです。

を使用した社内コラボレーションを促進すること。

OSPOとしてオープンソースの影響力を拡大するための優れた方法は、インナー

これらの社内コラボレーションは、組織内の他のソース プラクティスを使用した社内コラボレーションを促進することです。これらの社内コラボレーションは、組織内の他の部門やチームに、OSPOのビジビ
リティ向上のための大きな機会を提供します。さらに、このような相互交流やコラボレーションは、OSPOスタッフをオープンソース プラクティスに関する社内部門やチームに、OSPOのビジビリティ向上のための大きな機会を提供する。

の専門家として位置づけることに寄与し、研究開発チームや製品チームとコラ
ボレーションする新たな機会を創出します。

オープンソースに関するアドバイスの提供

組織内のオープンソース人材の育成
OSPOの中核的な責任の1つは、組織内でオープンソースの人材を育成することです。そのために、OSPOはワークショップ、トレーニング、メンタリング、社内エ
バンジェリズムなどのさまざまなプログラムを実行するとよいでしょう。教育は
OSPOの活動の重要な構成要素であり、オープンソースの技術的知識を広げるための技術トレーニング、およびOSSの使用を管理するポリシーを従業員が十分に理解できるようにするためのコンプライアンス トレーニングの2つのカテゴ
リに分類されます。後者の目的は、オープンソースのポリシーと戦略に対する意識を高め、オープンソース ライセンスの問題と事実、および製品やソフトウェア
ポートフォリオにOSSを組み込むことのビジネスリスクと法的リスクについて共通の理解を構築することです。さらに、このトレーニングは、組織内のコンプラ
イアンス ポリシーとプロセスを宣伝・推進し、コンプライアンス文化を育成する場としても機能します。
さらに、OSPOはメンタリング プログラムを作成するとよいでしょう。メンタリ
ング プログラムでは、上級オープンソース開発者が初級開発者を指導し、コー

OSPOは、組織の内部問題であろうと、コンプライアンス、オープンソース ファウンデーション、オープン標準、合併・収などに関連する外部問題であろうと、OSSに関連するすべての問題についてアドバイザーとして機能します。このアドバイザーの役割の重要性から、OSPOの上級スタッフは、組織のソフトウェ
ア戦略を形成する上で重要な役割を果たします。なぜなら、OSSはより大きなソフトウェアエコシステムの中でも重要だからです。

オープンソースITインフラストラクチャーの管理
OSPOの課題の1つは、組織がオープンソース開発者に、最小限のオーバーヘッ
ドでオープンソース プロジェクトとのコミュニケーションや共同作業が行えるよ
うなITインフラストラクチャーを提供することです。オープンソース開発では、
一般的に、次の3つのITサービスのプライマリー ドメインが存在します。
1.

知識の共有:wiki、協調編集プラットフォーム、公開Webサイト

2.

コミュニケーションと問題解決:メーリングリスト、フォーラム、リアルタイ
ム チャットド コミットをレビューし、アップストリーム プロジェクトに送信する前にコードに関するフィードバックを提供し、幅広くアドバイザーとして行動します。そこで目指すものは、学習を加速し、初級開発者がオープンソース プロジェクトでより大きな成果をあげ、影響力を発揮できるように支援することです。

深層考察：『オープンソース プログラム オフィス』

23

3.

コード開発と配布:コード リポジトリとバグトラッキング プラットフォー
ムオープンソース開発を効果的に支援するには、これらのツールの一部、または合併・買収すべてを社内で利用できるようにする必要があります。これらのオープンソー

組織が合併を検討している場合や買収のターゲットである場合、OSPOはオープ

ス プラクティスには、一般的な企業環境よりも制限の少ないITインフラストラ
クチャーが必要です。この状況が既存の組織全体のITポリシーと矛盾する場合
は、これらの矛盾を解決し、オープンソース開発者が最も使い慣れたツールを使用できるようにすることが不可欠です。大企業の一部のOSPOでは、企業のIT部門とは独立して独自のITインフラストラクチャーを作成、および管理していることは注目に値します。

ンソース技術とコンプライアンス デュー デリジェンスのための優れた専門知識源となります。OSPOは、デュー デリジェンス プロセスの一部として、対象組織が使用しているオープンソースコードと、その影響を理解するのに役立ちます。

外部委託開発OSPOは、ソフトウェアの外部委託開発を交渉する際に事業開発を支援することもできます。これにより、組織のポリシーとプロセスに従って適切なコンプラ「No」と言うことは、間違いなく筆者が最も大切にするOSPOの責務。
OSPOは、新しいプロジェクトや重要なプロプライエタリ コードのコントリビューションなど、組織を離れるすべての主要なコントリ
ビューションの「ゲート」の役割をする。オープンソース プロジェクトのイアンス手順に従っていることを確認できます。

オープンソース プロジェクトで大学と協力
多くの大学は、学生に学習機会を提供し、彼らに実際の開発経験を提供する(企業などの)組織との協力を切望しています。多くの場合、この関係は組織にとっても有益です。なぜなら、既存のオープンソース コミュニティの中に新しい成果を公開する提案や重要なコードをコントリビュートする提案が、人材を育成し、信頼できる人材供給源から新しい開発人材を集めるための優

成功のための適切な要件を満たしていない場合、「No」と言うことは用が難しいプロジェクトで特に役立ちます。有能なプログラマーの供給は限られた方法になり得るからです。これは、経験豊富な開発者が不足しており、採れており、新しい知識を活用し、学界を含む外部プロジェクトで成果を出す方

OSPOリーダーの責務。

法を見出すことは非常に重要です。

オープンソースの利用とコントリビューションに関する「NO」と言うタイミングを知る

摩擦を排除「No」と言うことは、間違いなく筆者が最も大切にするOSPOの責務で

OSPOは、組織が社内政策やポリシーをナビゲートし、戦略的に重要なコミュ
ニティとの関係を維持し、プロセスやツールを継続的に改善して、必要とされる学習曲線の短縮化や手作業を軽減させるのに役立ちます。

ビューションなど、組織を離れるすべての主要なコントリビューションの「ゲート」の役割をします。オープンソースプロジェクトの成果を公開する提案や重要なコードをコントリビュートする提案が、成功のための適切な要件を満たしていない場合、「No」と言うことはOSPOリーダーの責務です。

事業開発を支援OSPO は、事業開発の一環として、オープンソースのデュー デリジェンス (技術およびコンプライアンス) に関与する必要があります。この領域における2つの重要なシナリオは、合併・買収取引と外部委託開発です。

深層考察：『オープンソース プログラム オフィス』

す。OSPOは、新しいプロジェクトや重要なプロプライエタリ コードのコントリ

24

OSPOとOSSの使用またはコントリビューションにおける摩擦の排除
OSPOは、多くの課題に直面していますが、カルチャー、プロセス、ツール、継続性、教育の5つの領域にグループ化できるでしょう。図 14 は、これらの課題領域を示しています。OSPOの全体としての目標は、組織のビジネス目標を支える

これらの専門家は、以下を支援するためのガイダンスを提供できるでしょう。
• オープンソース開発プラクティスに沿ったリリースに関する社内プロセスを作成、とくに、リリースを早期かつ頻繁に行うことや、ピア レビューの実ことを目指して、容易にOSSを使用し、OSSにコントリビュートできるようにする

行に特徴がある。

ことです。したがって、これらの課題、さらには組織固有のその他の課題に向き• 部門間の透明性を向上させ、職種横断的なコラボレーションを促進す

合い、それらを解決することは、OSPOの目標の達成に有益です。

る。

カルチャー

• 能力主義の理想に沿ったエンジニアリング チームを形成する。

カルチャー、すなわち企業文化の課題は、多くの場合、従来のソフトウェア開発
手法とオープンソース開発の要件とのギャップに起因しています。このギャップ• オープンソースや部門横断的なコントリビューションを促進するための適を埋めるために、オープンソースの専門家を雇用し、オープンソース開発モデル

切な成功指標を確立する。

に不慣れな他のメンバーをトレーニングするように依頼することができます。

図 14

OSPOが直面する
課題

カルチャー

プロセス

ツール

継続性

教育

開発モデル

ガバナンス
使用
コンプライアンス
コントリビューション
承認
運用モデル

ITインフラ
開発ツール
評価指標のトラッキング
知識の共有
コードの再利用
ソフトウェアの構成
分析ツールの利用

戦略
プロジェクト
優先度
資金
経営幹部のサポート

経営幹部教育

コラボレーション
透明性
能力主義
チーム編成
採用活動
パフォーマンス指標

深層考察：『オープンソース プログラム オフィス』

25

知識の伝達
技術トレーニング
コンプライアンス トレーニング
メンターシップ プログラム

プロセス

ツール

オープンソース開発はダイナミックであり、動きが非常に速く、またコンプライ組織が用意するIT環境では、開発者が作業方法を大幅に変更することなくチー

アンスには固有の要件があります。ソフトウェア主導の業界で、このような開発をサポートするために社内プロセスを適応させていない組織は、取り残されてしまうでしょう。開発者はアップストリームにコードを迅速にコントリビュート
しなければならず、企業はこのような開発を妨げる社内コード ポリシーがあれば、それを変更しなければなりません。社内プロセスを改善するために、次のよ
うなプロセスの実装を提案します。
• 法的な問題を回避するためにオープンソース コンプライアンスの維持を担当するチームを配置し、オープンソースの使用とコントリビューションに関するシンプルな内部承認モデルを設定。
• 複雑で扱いにくいポリシーから、ソースコード コントリビューションを受
け取り、レビューし、承認するためのより簡素なアプローチに移行。
• 法務、エンジニアリング、オープンソースの各部門の利害バランスを取り、専任オープンソース チームが多数のオープンソース プロジェクトへのコン
トリビューションを包括的に承認。
• コントリビュートされるコードの性質（単純なバグを修正するためのコード、既存機能改善のためのコード、新機能に影響を与えるコード、新しい
プロジェクトを開始するためのコードなど）に応じて、異なるレベルの承認プロセスを適用。

ムに参加できるようにする必要があります。ツールはオープンソース開発モデルをサポートし、OSPOのニーズを満たし、さらに企業のITガイドラインに準拠している必要があります。オープンソース エンジニアは、電子メール、チャット、およびコード開発プラットフォームを介して外部参加者とコミュニケーションするための十分な柔軟性を必要とし、またITツールはこのコミュニケーションを容易にする必要があります。たとえば、オープンソース プロジェクトへの電子メールには、内容が電子メール送信者の組織の知的財産であると主張するようなものを添付ファイルに含めるべきではありません。OSPO内でコミュニケーションを促進するために、次の変更を実装することをお勧めします。
• 組織のアカウントから障壁なく、公開メーリング リストとのコミュニケー
ションが可能。
• 開発配布物をサポートするデバイスとして、エンジニアが選択したものを用意。
• すべてのオープンソース開発者が、Linux上または別の互換デバイスを介して、すべての重要な内部ツールおよびリソースにアクセスできるようにする。
• リモートサイトで作業する分散したチームをサポートし、仮想プライベー
ト ネットワーク（VPN）または同様のテクノロジーを通じて社内のビジネ
ス リソースに接続できるようにする。
• ヘルプデスク サポートに関するITポリシーを評価し、リモート従業員のIT組織が用意するIT環境では、開発者が作業方法を大幅に問題を解決するためのセキュアな方法を用意する。

変更することなくチームに参加できるようにする必要がある。

継続性

ツールはオープンソース開発モデルをサポートし、一部の組織では、（ビジネスの）「継続性」とは、誰も読まないような長くて退OSPOのニーズを満たし、さらに企業のITガイドラインに

ジネス戦略、および業界の変化に組織が適応するための常に存在する課題です。実際には、継続性は次の3つのカテゴリに分類できます。

準拠している必要がある。

深層考察：『オープンソース プログラム オフィス』

屈なドキュメントを示唆します。OSSに関して言うと、継続性とは、ビジネス、ビ

26

1.

オープンソース戦略の継続性。現在および将来の従業員に、常に進化すコンプライアンス トレーニング

るオープンソース戦略を知らせ、新しい開発や変更に関する最新情報をリ

OSSの採用に伴い、適用されるオープンソース ライセンスの知的財産義務を尊アルタイムで提供。
2.

重し、履行する責任が生じます。そのために、組織は、OSSの基礎、オープンソー

プロジェクトと優先度の継続性。オープンソース プロジェクトやオープン
ソース イニシアチブへの継続的な関与を保証し、組織がおかれている環境の変化や混乱のタイミング、契機を活用。

3.

経営幹部のサポート、および資金の継続性。継続的な財政的、および経営幹部の支援を確保し、オープンソース プログラムを支える十分なリソースを提供する。経営幹部のサポートは、組織全体にオープンソースの取り組みの価値と期待を継続的に伝達するのに不可欠。それによって、オープ
ンソース プロジェクトの採用、実装、コントリビューションの成功を促進。

レーニングを提供します。

メンターシップ プログラム
オープンソースの知識と技術スキルを向上させるために、組織はメンタリング
プログラムを設定します。このプログラムでは、上級オープンソース開発者が初級開発者を、しっかりとした、しばしば1対1の関係性の中で指導をします。その目的は、知識を伝達し、特定のドメインにおける技術的能力を向上させながら、オープンソース プロジェクトと効果的に協力する方法についてメンティーを訓練することです。

教育
オープンソース ソフトウェアはソフトウェア全体の不可欠な部分であり、ユーザ
ーとエコシステムに多大な利益をもたらす可能性を有しています。しかし、これらの利益を享受するためには、組織は次のような教育とトレーニングを通じて知識の不足を克服する必要があります。

技術トレーニング
技術トレーニングは、スタッフの技術的知識ベースを向上させます。それは、新規の異なったタスクを行うために、従業員の弱点を改善し、技能を向上させます。オープンソース トレーニング業界が繁栄しているのは、オープンソース スキ
ルと最新のオープンソース技術に関するトレーニングに対する需要が高いため経営幹部向けトレーニング
これらのコースは、経営幹部やマネージャーが、効果的なオープンソース プラク
ティスを構築するための基本的な概念を明確に理解するのを助けます。このようなコースでは、OSSを利用し、新しいオープンソース プロジェクトを創設し、プロジェクトにコントリビュートし、オープン エコシステムにおけるソフトウェ
ア リーダーシップを発揮するための効果的なプロセスや戦略を構築するテクニックを取り上げることが良くあります。

深層考察：『オープンソース プログラム オフィス』

ス ライセンス、著作権のしくみ、組織のポリシーとプロセスに関する従業員ト

27

です。

TODO GroupTODO Groupは、OSPOのリソース ハブであり、実践者のオープン コミュニテ
ィです。OSPO、ないしはそれと同様のオープンソース イニシアチブを成功させるための知識の創出と共有、およびプラクティスやツールなどにおけるコラボレーションを目的としています。TODO Groupは、さまざまなセクターや地域にまたがる1,700人以上のコミュニティ参加者と80人以上の一般メンバーによって形成され、Linux Foundationのオープンソース プロジェクトとして運営されています。TODO Groupは、OSPOの長い道のりを歩むのを支援する成熟度モデ

まとめ
OSPOは、組織がOSSをマスターするのを支援し、製品、サービス、およびITソリューションにクリティカルなオープン テクノロジーのリーダーとしての地位へと組織を導く上で重要な役割を果たします。OSPOは、次の4つの主要分野で組織をサポートできます。
1.

ポリシー、プロセス、チェックリスト、トレーニングを取り入れた社内イン

ル、ガイドセット、
マインドマップ、101コース、年次調査、および事例研究を提フラストラクチャーを確立。

供しています。これらのOSPOリソースは、TODO GroupがLinux Foundationや大規模オープンソース コミュニティと協力して開発しています。あなたが組織内でOSPOを構築したい、OSPOをリードしたい、また他の組織の仲間と交流し

2.

参加 — コミュニケーション プラットフォームやイベントでオープンソース
コミュニティに参加。自社の製品やサービスが依存している重要なOSSのたいとお考えならば、todogroup.org/communityにアクセスして、Slackチャネ
ルやOSPOフォーラム ディスカッションに参加してください。

利用 — 適切なオープンソース プラクティスを可能にし、オープンソースのプロジェクトや組織のスポンサーとなる。
3.

コントリビューション — オープンソース コントリビューションに特化した開発者を雇用またはトレーニングし、社内オープンソース エンジニアリン
グをサポートするために必要なツールを配置、展開。

4.

リーダーシップ — オープンソース コミュニティ、オープン標準規格化団
体、オープンソース ファウンデーションとの関わりを深め、新しいオープ
ンソース イニシアチブやプロジェクトを立ち上げ、オープンソース コミュ
ニティにおける組織の認知度を高める。

製品やサービスがOSSに依存している組織に所属していて、正式なOSPOがまだ存在しないなら、本稿は、まさにそのための行動喚起であるとお考えください。

深層考察：『オープンソース プログラム オフィス』

28

謝辞

フィードバック

著者は、Linux FoundationとTODO Groupでの同僚、Chris Aniszczyk、Hilary

スペルミスや間違いの可能性があることについて、事前に謝罪致します。まCarter、Ana Jimenez、Jason Perlow、Melissa Schmidt、および Barry Hallた、ibrahimatlinux.com/contact.htmlにて修正や改善のための提案を頂けれからの有益なレビューとフィードバックに心から感謝の意を表します。本稿は、ば幸いです。

彼らの経験とコントリビューションの恩恵を多大に受けています。

Linux Foundationの支援リソース• E-book: Guide to Enterprise Open Source• E-book: Open Source Compliance in the Enterprise• E-book: Open Source Audits in Merger and Acquisition
Transactions• Linux Foundation Enterprise Guides• Linux Foundation Open Compliance Program — オープンソース コン
プライアンスに関して、組織を支援するリソース。
• TODO Group — オープンソースプログラムをうまく運営するためのベス
トプラクティス、ツール、およびその他の方法について協力する実践者と組織で構成されたオープンコミュニティ。

深層考察：『オープンソース プログラム オフィス』

29

著者について
Dr. Ibrahim Haddad は、Vice President of Strategic Programs、The Linux Foundationであり、かつGeneral Manager、LF AI & Dataです。LF AI & Data は、開発者が重要なオープンソースの人工知能（AI）
およびデータ プロジェクトを構築、管理、規模拡大するための信頼できるハブを提供します。 The LinuxFoundation の前には、Samsung Electronics のVice President of R&D 兼 Head of the Open Source
Divisionを務めていました。 Haddad はキャリアを通じて、Ericsson Research、Open Source Development
Labs、Motorola、Palm、Hewlett-Packard、および The Linux Foundation でテクノロジーおよびポートフォ
リオ管理を支えてきました。 Concordia University（Montréal, カナダ）を優秀な成績で卒業し、Computer
Scienceの博士号を取得しています。 ​Twitter: @IbrahimAtLinux
Website: IbrahimAtLinux.com

免責条項
本稿は、現状有姿で提供されます。The Linux Foundationおよびその著者、コントリビューター、スポンサーは、本稿に関連する商品性、
非侵害性、特定目的への適合性、権原の黙示的保証を含めいかなる保証（明示的、黙示的、またはそのほか）も明示的に否定します。TheLinux Foundationおよびその著者、コントリビューター、スポンサーは、契約違反、不法行為（過失を含む）、それ以外に基づくかどうかにかかわらず、またそのような損害の可能性を通知されていたかどうかにかかわらず、本稿に関するあらゆる種類の訴訟原因による逸失利益
またはあらゆる形態の間接的、特別、付随的、あるいは派生的損害に対して他者に対して一切責任を負わないものとします。本稿の作成にスポンサーがついていることは、スポンサーがその調査結果を保証していることではありません。

深層考察：『オープンソース プログラム オフィス』

30

2021年に設立されたLinux Foundation Researchは、拡大するオープンソース コラボレーションを調査し、新たな技術トレンド、ベストプラクティス、およびオープンソース
プロジェクトのグローバルな影響に関する洞察を提供しています。Linux Foundation Researchは、プロジェクト

The Linux Foundationの一部であるLF AI & Dataは、人工知能、機械学習、ディープラーニング、およびデータにおけるオープンソース イノベーションをサポートしています。LF AI & Dataは、オープンソース技術を使用して、AI・データの製品やサービスの開発を容易にする持続可能なオープンソースAIエコシステムをサポートするために設立されました。私たちは、オープンソース技術プロジェクトの調和と加速をサポートするために、オープン ガバナンス
モデルを備えた中立な環境の下でコラボレーションを促進しています。

のデータベースとネットワークを活用し、定量的/定性的手法のベストプラクティスに取り組むことで、世界中の組織に役立つオープンソース インサイトのための頼れるレ
ポジトリを作成しています。

TODO Groupは、オープンソース プログラムの運営に長年の経験を持つ70以上の組織からなるオープングループであり、オープンソース プロジェクトやオープンソース プログラムを成功させ、効果的に運営するためのプラクティス、ツー
ル、その他の方法について協力したいと考えています。経験を共有し、ベストプラクティスやガイダンスを開発するとともに、世界中のあらゆるセクターのOSPOの採用と教育を改善するための共通ツールに取り組んでいます。現在進行中のTODOイニシアティブの詳細については、こちらを参照してください。OSPOのランドスケープもご確認ください。

twitter.com/linuxfoundation
facebook.com/TheLinuxFoundation

twitter.com/todogroup

facebook.com/todo

linkedin.com/company/todo-grouplinkedin.com/company/the-linux-foundation
youtube.com/user/TheLinuxFoundation

Copyright © 2022 The Linux Foundation

このレポートは、Creative Commons — 表示 - 改変禁止 4.0 国際 — CC BY-ND 4.0 の下でライセンスされています。この資料は、クリエイティブ コモンズ ライセンスの条件に基づいてコピーおよび配布することができます。
参考文献として以下のように記してください。
“A Deep Dive Into Open Source Program Offices: Structure, Roles, Responsibilities, and Challenges “
foreword by Chris Aniszczyk, August, 2022.
31