第 3 章: OSPO の設立

• 序文
• 戦略から始める
• OSPO の設計
• OSPO 成熟度モデルを活用する
• 組織への適用
• 起こりうる問題とその克服方法
• リソースと脚注

序文

OSPO は多岐にわたるため、組織の目標を達成するための OSPO を設計する時間は重要です。

本章ではまず、組織が取り組むべき業務の計画立案の基盤となる戦略と、OSPO のあるべき組織構造を明確にできるようにします。

次に、組織が求めるオープンソース関連のタスクと責任を網羅できる、安定的で強固な OSPO を設計し構築する方法について説明します。

最後に、本章では、ニーズの変化に応じて現在および将来の OSPO の適切なレベルを判断するための成熟度モデルを紹介します。

戦略から始める

戦略の策定方法

OSPO のメンバーが、C レベルの経営幹部にオープンソース戦略を効果的に伝えるためには、業界の動向を深く理解し、CEO や CFO の主要な考慮事項と一致させる必要があります。一致させるためには、企業全体の戦略を明確に理解し、組織の戦略目標達成を後押しするオープンソース領域内の技術を特定する必要があります。

Victor Lu と Rob Moffat のプレゼンテーション - Strategy - End Game for FINOS Maturity Model ¹

OSPO は、戦略、ガバナンス、コンプライアンス、コミュニティエンゲージメントなどの側面を網羅するフレームワークを構築し、維持することでこれを実現します。OSPO の戦略は、組織のオープンソースの利用、貢献、コンプライアンス活動を、プロジェクト、製品、サービス、社内インフラ全体にわたる組織全体の目標と一致させることに焦点を当てます。

戦略は、具体的なトピックとそれらが組織およびその組織内のメンバーに与える影響に関する高レベルの合意を形成します。

戦略を策定する際の考慮事項は次の通りです。

1. 戦略文書を策定する: 良いプラクティスとして、この戦略をオープンソース戦略文書 ² に文書化することが推奨される。このガイドでは、そのプロセスを段階的に説明する。

2. 組織の目標を理解する: 前章で述べたように、組織の目標と現在のオープンソースへの関与を理解する必要がある。

3. コンテキストを考慮する: OSPO の戦略と設計を開発する際、人員、技術、予算を検討する前に、組織図内における OSPO の構造と位置付けを決定するいくつかの異なる方法がある。TODO Group が作成した深層考察：『オープンソース プログラム オフィス』 ³ という優れたガイドでは、OSPO の構造と運用に関するすべての重要な情報が説明されている。

4. OSPO の構造例を確認する: OSPO の潜在的な活動の概要を把握するには、OSPO マインドマップ ⁴ を確認すること。マインドマップでは、OSPO のエコシステム内での主な責任、役割、行動、チーム規模を概説している。

OSPO の設計

OSPO が管理すべき範囲の特定

OSPO が適切な役割を果たすためには、組織の運営方法を理解する必要があります。企業の目標を理解することで、オープンソースの活用に関する適切な判断を下せます。たとえば、ビジネスシーンにおいて、オープンソースがどのように適合するかを確認するために、OSPO は次の領域を分析します。

各組織で価値観、ビジネスドライバー、文化が異なるため、具体的な内容を提示することは困難です。しかし、次の質問に答えることで、文書を効果的に構成化できます。

• 組織の目標と製品ロードマップにとって現在重要なオープンソース技術は何か？また、今後重要になるものは何か？
• これらの技術や組織の目標に直接的または間接的に影響を与えるオープンソースプロジェクトは何か？
• 持続可能なオープンソースエコシステムを促進するための最適な具体的プラクティスは何か？
• 改善の余地がある組織のプロセス領域はどこか？
• オープンソースはそうした改善をどのように支援できるか？
• 組織内のメンバーをオープンソースの支持者にするためにはどうすれば良いか？
• 管理層に理解してもらうために効果的にメッセージを伝える方法は何か？

OSPO が付加価値を提供できる領域を理解するために時間を取ることは、ステークホルダーを特定する役に立ちます。

OSPO のステークホルダーを特定する

OSPO がステークホルダーを特定する際に共通するビジネス領域が存在します。ステークホルダーとは、あなたが行なう業務の影響を受けるすべての人々です。OSPO フラワーダイアグラムは、さまざまなステークホルダーグループを可視化するのに役立ちます。各花びらは、特定のステークホルダーグループと、そのグループに関連する特定の活動を表しています。OSPO フラワーダイアグラムは、各ステークホルダーグループが使用する具体的なコミュニケーションチャネル、ドキュメント、その他の資料をマッピングするのにも役立ちます。

組織の複雑さや OSPO が利用できるリソースに応じて花びらはさらに細分化され、異なる名前を持つ花びらを追加することもあります。

ospoflower.pdf

• 個人貢献者（Individual Contributors）: この花びらは、OSPO が組織内で協力する人々を表し、個人としてオープンソースに貢献する内的および外的な動機付けに焦点を当てている。この動機付けには文化的変革の努力が必要であり、それにはメンタリングプログラムの設立などの活動を含む場合がある。

• 管理（Management）: この花びらでは、OSPO は戦略に焦点を当て、オープンソースと全体的なビジネス／組織戦略との整合性を探っている。管理層は独自の課題に直面しているが、オープンソースの強みを活用することで、効果的にこれらの課題を克服できる。

• 法務（Legal）: この花びらは、オープンソースの法的側面を表している。法務は、組織内のオープンソースの取り組みに関連する法的要件と義務を理解し、管理する。これにより、コンプライアンスが確保され、法的リスクが軽減される。

• ビジネス（Business）: この花びらは、OSPO が組織構造のあらゆる要素の連携をどう確保するかに焦点を当てている。これには、異なるビジネス／チームユニット間でベストプラクティスを共有し、連携と知識移転を促進することが含まれる。

• オープンソース・エコシステム（Open Source Ecosystem）: この花びらは、組織外のより広範なオープンソースコミュニティとプロジェクトのエコシステムを表している。OSPO は、アイデアを交換し、連携し、より広範なオープンソースコミュニティへ貢献するために、他の組織、プロジェクト、個人を含め、このエコシステムと関わる。

• OSPO: これは OSPO 自体の内部の仕組みを表している。OSPO のメンバーは、組織内のすべてのオープンソースの取り組みを連携させ、調整する。また、活動を監督して円滑な運営を確保し、オープンソースに関わる他のステークホルダーにガイダンスとサポートを提供する。

外部規制機関との連携

外部規制機関は特別なケースであるため、フラワーダイアグラムには含まれていません。

組織は、そのポリシーやプロセスに影響を与え、形作るさまざまな外部の規制に従う必要があります。これにより、規制機関は、法的要件、倫理基準、業界固有のガイドラインの遵守を確保します。外部規制機関には、次のようなものがあります。

• 政府機関: 組織に影響を与える法律や規制を制定し、施行する。
• 業界規制機関: 多くの業界には、組織が遵守すべきガイドラインや基準を設定する独自の規制機関や業界団体がある。
• 消費者保護機関: 組織が消費者に対して公正で安全な製品やサービスを提供することを保証する。

オープンソースが組織内で成功し持続可能であるためには、オープンソースコミュニティだけでなく、外部規制機関との連携も不可欠です。この連携により、エコシステムに影響を与えるポリシーを策定する際、オープンソースの原則を明確に理解できます。主な目的は、オープンソースとそのコミュニティが及ぼす影響を完全に理解した上で、協働して適切な意思決定を行なうことです。したがって、OSPO は、規制機関にアプローチしてコミュニケーションをとるための計画を作成し、ポリシー策定プロセスにおける規制機関の役割を明確に定義する方法を検討することが推奨されます。

OSPO 成熟度モデルを活用する

成熟度モデルの紹介

組織のオープンソースへの関与は、通常、戦術的から戦略的までのスケールに沿って位置付けられます。成熟度モデルは、組織の各部門がこのスケールのどこに位置しているのかを理解し、それが適切な位置にあるかどうかについて議論するのに役立ちます。

オープンソース成熟度モデルにはさまざま種類があり、一般的なものから専門的なものまであります。政府、NGO、企業など、さまざまな組織向けの成熟度モデルがあり、あらゆる組織に適したバージョンやサブバージョンもあります。

注：成熟度モデルは、OSPO やオープンソースへの関与をどのように発展させるべきかを示す指針と見なすことができます。成熟度を高めることが常に良いことだと考えがちですが、OSPO や OSPO の各機能にとって適切な成熟度レベルを検討する必要があることを覚えておいてください。すべての部分が高度に発展する必要はありません。これ以上発展しなくても、すでに必要な価値を提供している場合もあります。成熟度モデルが OSPO に合わない場合は、能力モデルや好みの別のモデルを使用することを検討してください。

成熟度モデルの例

各成熟度モデルは少しずつ異なりますが、どのモデルも、戦術的で意図的でないものから戦略的でより意図的なものへと、オープンソースへの関与を分類しています。

成熟度モデル 1 - Open Source Engagement Adoption by Dr. Ibrahim H ⁵:

• 否認 - オープンソースを全く利用していない、または無意識に利用している。
• 消費/利用 - オープンソースを受動的に利用している。
• 参加 - オープンソースコミュニティへ関与している。
• 貢献 - オープンソースプロジェクトへ実践的に貢献している。
• リーダーシップ - ビジネスの価値を高めるためにオープンソースへ戦略的に関与している。

成熟度モデル 2 - Carl-Eric による企業のオープンソース採用の 5 段階のトーク ⁶:

• 偶発的 - 組織が利用していることを認識せずにオープンソースを利用している。
• 反復的 - 消費と貢献の両方のプロセスを設けているが、貢献は散発的である。
• 指示的 - 重要なオープンソースプロジェクトへ積極的に参加している。
• 協力的 - ビジネスの価値を生み出すツールとしてオープンソースの連携を活用している。
• 主導的 - ビジネスと技術の戦略的領域に影響を与えるためにオープンソースを活用している。

成熟度モデル 3 - TODO Group による OSPO 成熟モデル ⁷:

• ステージ 0: 場当たり的（アドホック）にオープンソースを採用している。
• ステージ 1: オープンソースコンプライアンス、インベントリ、開発者向け教育を提供している。
• ステージ 2: オープンソースの利用とエコシステムへの参加を啓蒙している。
• ステージ 3: オープンソースプロジェクトをホスティングし、コミュニティを育成している。
• ステージ 4: 戦略的意思決定のパートナーとなっている。

組織への適用

ここでは、上記のアイデアとアドバイスを参考に OSPO を設立する方法をいくつか紹介します。これらは、TODO Group による OSPO 成熟度モデル 3 に基づいています。

シンプルなチェックリストの使用

TODO OSPO チェックリスト ⁸ は、初期段階と経験豊富な OSPO の両方が、前述の OSPO 成熟度モデルの各段階をスムーズに進むための、簡潔な共通のマイルストーンを提供しています。OSPO は組織のニーズに合わせてチェックリストの一部を削除、追加、編集することが必要な場合があることに注意してください。

成熟度モデルの利用

オープンソースの成熟度モデルに一定の理解が得られたら、それを利用して戦略を構築し、計画を作成し始めることができます。

TODO Group と OpenChain の支援を受けて、OSPO Japan Local Meetup ワーキンググループは、OSPO に関するシンプルな FAQ を開発しています。このガイドは、さまざまなオープンソース活動をステージ 0 からステージ 4 にまで分類した OSPO 成熟度モデルの各段階における疑問に答えることを目的とし、各レベルにおける OSPO の役割を概説しています。

以下は、このワーキンググループの活動から抜粋した主なポイントです。参考にしてください。

注: これは OSPO メンバーの 1 人が執筆した Qiita の記事で、OSPO の活動の概要を日本語と英語の両方で確認できます ⁹

OSPO を計画する際には、マネージャー、上級幹部、日々の業務でオープンソースを利用しているか、（ライセンス、セキュリティ脆弱性の観点から）戦略上オープンソースプロジェクトの取り扱いに関わっているさまざまなチームの従業員／契約社員と 1 対 1 で対話すると非常に役立ちます。こうした対話から得られた洞察を基に、組織独自の動機付け要因を定義し、オープンソースが価値をもたらす組織内の領域にマッピングします。

また、OSPO が正式に設立・開始される前から、これらは組織全体にわたるあなたの取り組みを支持するでしょう。

OSPO 成熟度モデルを用いて段階に応じた各組織独自の分類する 2 番目の区分を作成し、これらの動機付け要因を組織全体のさまざまなタイプの活動にマッピングしてください。そして、ステークホルダーと関わる際やコミュニケーションを取る際にこれを参照してください。

例:

起こりうる問題とその克服方法

問題

OSPO を作成する過程で、多くの質問を受け、新しい情報を考慮して計画を調整する必要があります。組織全体でオープンソースの理解と価値の認識に一貫性が欠如しているようで、それが混乱や潜在的なリスクを引き起こしています。

推奨事項

すべてのステークホルダーを特定し、そうした人々の動機を理解する時間を確保してください。すべてのチームと子会社間で価値観、原則、目標に関する共通の理解を促進する効果的な手段として、誰でも利用可能なオープンソースのマニフェスト、原則、Web サイトを作成してください。組織全体でオープンソースに関する一貫した理解を確立して徹底的に実施することに時間をかけることで、OSPO は安定した強固な基盤を確保できるでしょう。

リソースと脚注

リソース

• TODO guide to outbound OSS: https://todogroup.org/resources/guides/a-guide-to-outbound-open-source-software/
• オープンソース コミュニティへの参加: https://todogroup.org/resources/guides/participating-in-open-source-communities/
• DevOps uses Capability, not Maturity: https://octopus.com/blog/devops-uses-capability-not-maturity
• Porsche Open Source Website: https://opensource.porsche.com/
• Open Source Program Office (OSPO) の進化: https://www.linuxfoundation.jp/resources/publications/the-evolution-of-the-open-source-program-office-ospo/
• OSPO 101 training module - OSPO and your organization: https://github.com/todogroup/ospo-career-path/tree/main/OSPO-101/module3

脚注