第 4 章: 日々の業務
序文
戦略を策定したら、次に必要なのは計画です。この計画は、戦略を実現するための定期的な活動を策定し実行するものです。本章は、OSPO の活動範囲と、各活動が組織に提供する価値を理解するのに役立ちます。
一般的な活動
OSPO の日々の業務は、組織内のオープンソースへのエンゲージメントとコンプライアンスを強化するための幅広い活動を含みます。具体的には次の通りです。
直接的なオープンソース支援: ライセンスコンプライアンス、オープンソースの選択、ベンダーとのやり取りなど、オープンソースに関するあらゆる疑問に答える活動。また、コミュニティやパートナーとの関わり、スポンサーシップの獲得、オープンソースイベントの企画・運営も含まれる。
自動化ツール: ポリシーだけでは常に効果的であるとは限らないため、オープンソースポリシーを支援するためのプロセス自動化は重要である。管理層は、組織内のメンバーが必ずしもポリシーを遵守しないことを認識しているため、オープンソースコンポーネントの利用、管理、追跡を自動化する効果的なオプションを求める。自動化はライセンスコンプライアンスやセキュリティなど、オープンソースの多くの領域で役に立つ。
ドキュメント作成、トレーニング、教育: OSPO は、組織内で活用するオープンソースプロジェクトを評価し、組織にとって重要なオープンソースプロジェクトに貢献できる人材を確保する上で、主導的な役割を果たす。自らトレーニング資料やドキュメントを作成したり、異なる部門間でこれらの作成を支援したりすることは重要なタスクである。
リソース配分: OSPO が組織に価値を提供できる領域は多岐にわたる。したがって、業務の優先順位付けと、戦略的・戦術的なリソース配分は、OSPO の影響力を高める上で重要な活動である。
リスク管理: OSPO は、組織がオープンソースプロジェクトを利用する際のリスクを包括的に評価する立場にある。OSPO が組織の技術スタック全体を把握してリスクを評価することは有用である。これには、オープンソースに加え、ベンダー製ソフトウェア、レガシーソフトウェア、プロプライエタリソフトウェアのリスクを OSPO で検討可能にする SBOM の生成が含まれる。リスクは管理できても排除できないため、これは単なるデータ収集ではなく、ビジネス評価の観点に重点を置くものである。SBOM を最適化するには、リスクとメリットのバランスを取ることが重要になる。
オープンソースコミュニティと財団の支援: 組織はオープンソースに依存している。オープンソースプロジェクトの健全性はコミュニティの健全性に左右され、コミュニティを支援するために直接または財団を通じて時間や資金を投資できる。プロジェクトと組織の両方にメリットをもたらすためには、これらの関係を理解し、慎重に管理する必要がある。お金が最良の解決手段ではない場合もある。より緊密なパートナーシップを築き、開発、マーケティング、プログラム的な支援を提供する方がより有用な場合もある。
技術的負債の測定: オープンソースプロジェクトにおける技術的負債の測定方法に関する知識を提供することは、プロジェクトに関連するリスクを判断するのに役立つ。また、プロジェクトのコミュニティと協力して行う場合、これはプロジェクトの改善と持続を支援する教育的提言となる。
組織内の各部門との調整: すべてのステークホルダーを把握し、適切な量のコミュニケーションを取っているか確認することが重要である。関係性のマッピングについては、第 3 章の OSPO フラワーダイアグラムを参照すると良い。
オープンソースの利用に関する助言: OSPO は、どのオープンソースプロジェクトを採用すべきかについてと、選択したプロジェクトを効果的に利用するためのベストプラクティスについての両方の戦略的な視点を考慮する。また、企業がどのオープンソースプロジェクトを利用するかを選択し、どのように管理すべきかに関する参考資料とガイドラインを提供する必要がある。ガイドラインやポリシーは、技術的な内容に限定されることもあれば、Secure Supply Chain Consumption Framework (S2C2F) 1 のように、オープンソースプロジェクトの健全性とプラクティスに基づく考慮事項を含むこともある。
組織への適用
OSPO マインドマップ
OSPO マインドマップ 2 は、ここでも有用なツールです。これを使用すると、OSPO の潜在的な活動を概観できます。OSPO マインドマップは、OSPO のエコシステム内における主要な責任、役割、行動、チーム規模を整理します。ただし、これはあくまでもあなたの活動に対して情報を提供しているのであり、従うべき決まった計画ではありません。ニーズに合わせて調整してください。
成熟度段階別の活動
次の表は、Ibrahim H. のオープンソース活動エンゲージメントモデル(第 2 章で紹介済み)が、OSPO 内の活動を一覧化し探索するためのマップとして使用されています。
ステージ: 利用者
活動 | OSPO への価値 | 組織への価値 |
---|---|---|
オープンソースコンプライアンスのルールとプラクティスの定義 | 法務部門とビジネス部門のステークホルダー間での組織のオープンソースコンプライアンスのルールとプラクティスに関する明確な合意形成をすること。 | オープンソースの利用に関する法的側面に対して管理されたアプローチを有しており、これを時間をかけて維持・改善できることを認識している。各組織は、オープンソースのコンプライアンスに関する異なる側面、ライセンスの解釈、および異なるリスク許容度(例: 規制対応など)を有している。明確に定義されたコンプライアンスのルールとプラクティスは、確固たるオープンソースコンプライアンスへの第一歩である。 |
オープンソースの利用に関する規則とポリシーの定義(オープンソースの健全性に関連するオープンソースの利用基準) | オープンソースプロジェクトの利用は、コンプライアンスの観点からのみ捉えられるのではなく、より包括的な視点で検討され、不健全なプロジェクトに関連するリスクも考慮される。利用されるオープンソースコンポーネントの健全性に関して、社内でコンセンサスが形成される。組織には、遵守すべき明確なポリシーが定められる。 | 利用されるオープンソースプロジェクトは健全であり、セキュリティの脆弱性を修正し、新しい機能を実装し、定期的にリリースするため、リスクが低くなる。 |
オープンソースへの貢献方法に関するルールとポリシーの定義(コミュニティへの関与方法、権利の移転方法、コントリビューターライセンス契約/CLA) | オープンソースプロジェクトとの双方向の関係性に対する認識を高めることができる。ポリシーの活用は、一貫性と倫理性に基づいたアプローチをサポートする。組織には遵守すべき明確なポリシーがある。 | ポリシーとプラクティスは、組織とオープンソースプロジェクトが共に価値を構築する方法について考慮することを保証する。貢献は、会社の評判を損なうよりも向上させる可能性が高い。 |
ISO/IEC 5230(OpenChain)への準拠 | 一から作成するのではなく、国際的に定義された標準を実装できる。 | 国際的に認められた標準への準拠を証明できる。 |
組織内で利用されているオープンソースのインベントリの管理 | 管理対象のオープンソースの全体像を把握している。 | 全体的なリスク管理の基盤を確立している。これは、特定のプロジェクトに関連する問題(セキュリティ問題、ライセンス変更、ライフサイクル問題など)に対処するための重要なツールである。 |
オープンソースへの意識向上のためのトレーニング | オープンソースに関するトレーニングを提供することで、オープンソースの役割、OSPO の役割と価値の認知度が向上し、組織がオープンソースをどのように利用し、関与しているかについての理解が深まる。 | オープンソースの価値、ライセンス、貢献などに関する認識を通じて、組織内のオープンソースの能力を向上させる。 |
ライセンスコンプライアンスのためのツールの採用 | 組織内のライセンスコンプライアンスを構造化・可視化することで、管理戦略の策定を支援する。 | 自動化は、合理的な努力でリスクに対応し、コンプライアンス改善の有効性を測定するために不可欠である。 |
オープンソースの支援方法の明確化 | オープンソースが適切な理解に基づいて採用されていることが保証される。 | 本番環境でのオープンソース利用に伴う潜在的なコストを認識する必要がある。オープンソースコンポーネントの外部サポートをベンダーやサービスプロバイダーから購入できる場合がある。または、コミュニティの支援を受けて自社でサポートを管理する(コミュニティがサポートできる範囲を現実的に考慮する)か、リスクが低いシナリオでは、サポートがないリスクを受け入れる選択肢もある。 |
ステージ: 参加者
活動 | OSPO への価値 | 組織への価値 |
---|---|---|
オープンソースコミュニティへの財政的援助 | コミュニティとの関係を強化し、影響力の拡大する。 | 組織が依存するエコシステムとソフトウェアサプライチェーンの安定性を向上する。 |
オープンソース組織への加盟 | 共同マーケティングやイベント割引などの加盟特典がある。 | 組織が依存するコミュニティに関与する。戦略的に有用な情報に影響力を発揮し、アクセスする。エコシステムを支援する。 |
InnerSource の試行 | 組織内のスタッフはオープンソースの方法論を実際に体験し、認識、理解、支持を育む。 | オープンソースプロジェクトのより有効な利用と関与に寄与するスキルがメンバーに育つ。 |
ステージ: コントリビュータ
活動 | OSPO への価値 | 組織への価値 |
---|---|---|
貢献ポリシーとプロセスの作成 | オープンソースへの貢献の管理が容易になる。 | 明確な手順があることで、オープンソースプロジェクト、組織、組織内のメンバーは、法的に安全な方法でオープンソースに貢献できる。 |
コントリビューターの資格要件 | コントリビューターは監督する必要が少なく、良い橋渡し役となる。 | 熟練のコントリビューターは公開されているプロジェクトに質の高い貢献をするため、組織のリスクが軽減される。 |
ステージ: リーダーシップ
活動 | OSPO への価値 | 組織への価値 |
---|---|---|
プロプライエタリプロジェクトのオープンソース化 | エンジニアリング部門(および他の部門)の負担を軽減できる。 | オープンな連携を通じて、コモディティ化されたコンポーネントのコードベースを改善するための新たな機会が生まれる。オープンソースへのより戦略的な関与、新たな専門知識へのアクセスが可能になる。 |
「アップストリームファースト」ポリシーの確立 | 同じ、またはより少ない労力で、より多くの価値を得られる方法を組織に提供する。 | 競争優位性を失わずにコミュニティ全体の貢献からメリットを得つつ、オープンソースプロジェクトをサポートしたり、主導したりして、それらを組織の主要な価値創造の一部にすることができる。 |
オープンソースプロジェクトのコントリビュータやメンテナーの自律性の支援 | 組織内のオープンソースの専門家は OSPO にとって貴重な存在である。 | オープンソース活動に専念する人材を雇用することで、最も有機的かつ効果的な方法で重要なオープンソースプロジェクトを戦略的に強化できる。 |
起こりうる問題とその克服方法
問題
新しい OSPO は非常にゆっくりと目立たずに進歩するため、OSPO の必要性に対する疑念が浮上しています。
推奨事項
あらゆる新しい取り組みと同様に、短期と長期の両方で有意義な影響を与えることに焦点を当て、それを維持することが非常に重要です。短期的な影響は、ステークホルダーに OSPO の必要性と能力を確信させ、OSPO 担当者に自信を与えます。長期的な影響は、組織に持続可能な価値を生み出し、OSPO を組織内に確実に定着させます。最初の 3 ~ 6 ヶ月で実現可能な重要な目標を特定し、同時に 6 ~ 12 ヶ月、12 ~ 24 ヶ月、2 ~ 5 年で成果を出す長期プロジェクトにも取り組むようにしてください。最初の段階では、アクティブなプロジェクトの数を少ない状態にし、品質と納期を守って成果を上げるようにしましょう。OSPO への信頼が高まるにつれて、価値を提供してきた実績が確固たるものになれば、より多くのリソースを強く要求できるようになります。
リソースと脚注
リソース
- A Guide to Enterprise Open Source: https://www.ibrahimatlinux.com/wp-content/uploads/2022/05/LFR_LFAID_Guide_to_Enterprise_Open_Source_052522.A4.pdf
- 深層考察:『オープンソース プログラム オフィス』組織構成、役割、責務、および課題: https://www.linuxfoundation.jp/wp-content/uploads//2023/05/ja5_LFR_LFAID_Deep_Dive_Open_Source_Program_Offices_0830.pdf
- OpenSSF Scorecard: https://github.com/ossf/scorecard
- Software Bill of Materials (SBOMs): https://www.ntia.gov/SBOM
- Computer Emergency Response Team (CERT): https://www.cisa.gov/uscert/
脚注
Secure Supply Chain Consumption Framework (S2C2F): https://www.microsoft.com/en-us/securityengineering/opensource/osssscframeworkguide ↩︎
OSPO マインドマップ: https://todogroup.org/ja/resources/mindmap/ ↩︎