第 6 章: OSPO における指標の使用

序文

注記: 本章は、CHAOSS オープンソースプロジェクトと CHAOSS OSPO Metrics ワーキンググループの参加者の専門知識を結集し、TODO Group の支援を受けて作成されました。

指標は、現代のあらゆる組織にとって重要な要素です。効果的に使用すれば、チームとそのプロジェクトの影響を追跡するための貴重な手段となります。OSPO にとって、指標は業務の計画と影響の測定を支援するだけでなく、組織が依存するオープンソースプロジェクトに関するより深い洞察も提供します。

かつては、主要なオープンソースプロジェクトについてあまり知識がなくても許容されていたかもしれません。しかし、オープンソースを取り巻く規制やセキュリティの状況は進化し続けており、もはや持続可能なアプローチではありません。私たちにとって重要なオープンソースプロジェクトへの理解が深まるにつれ、コミュニティ指標は不可欠なツールとなります。本章では、これらの指標を文脈の中でどのように位置づけ、組織全体の戦略的意思決定を導くためのより優れた洞察をどのように提供できるかを探ります。

組織がオープンソースプロジェクトの可視性を必要とする理由はいくつかあります。たとえば、

  • 組織はオープンソースを活用しており、主要プロジェクトへの貢献を追跡したいと考えている。
  • 組織はオープンソースエコシステムに参加しており、潜在的なリスクを特定し、必要に応じてサポートを提供する必要がある。
  • 組織は、オープンソース、特にビジネスに不可欠なソフトウェアの持続可能性に貢献したいと考えている。
  • 組織は、アップストリームのライセンス要件を遵守し、業務に影響を与える可能性のあるセキュリティ問題に対応する必要がある。

目標・質問・指標のフレームワーク

指標のための指標は誰の利益にもなりません。以下の指標を考えてみましょう。

  • 課題の平均経過時間は 10.3日である。
  • 先月のプルリクエストの総数は 121 件であった。
  • 過去 15 日間で 3 社の新しい企業がコミュニティに参加した。

文脈がなければ、これらの指標は洞察を提供しません。そのため、「目標・質問・指標」のようなフレームワークを使用して、目標に反するのではなく、目標をサポートする指標を得ることが重要です。

CHAOSS プロジェクト（Community Health Analytics for OSS）は、「目標・質問・指標」の使用を推奨しています。これは、組織の目標と整合した指標を導き出すための構造化された手法だからです。このフレームワークには、以下の3つの主要なステップがあります。

目標

組織の目標を特定し、理解します。目標は大きく異なる場合がありますが、一般的には、人材の採用やコミュニティのエンゲージメント強化などの目標が含まれます。

質問

これらの目標を、具体的で実行可能な質問に分解します。たとえば、採用活動を評価するには、「重要な貢献者は誰か？」や「我々が採用を支援した人数は何人か？」といった質問をします。

指標

これらの質問に答えるための指標を開発します。指標は、名前ごとの貢献数、採用の成功率、プロジェクトの活動レベルなど、運用可能でデータに基づいたものでなければなりません。ソフトウェアプロジェクトにおけるコミット数のような有用なデータポイントは、答えるべき質問とは必ずしも関連がない場合があります。

オープンソースコミュニティ指標の役割を理解する

オープンソースコミュニティ指標が、組織が使い慣れている他の指標とどのように連携しているかを理解することは重要です。オープンソースコミュニティ指標は、OSPO にオープンソースイニシアチブの影響、有効性、戦略的価値を測定するための具体的な方法を提供します。

貢献、関与レベル、プロジェクト間のコラボレーションを追跡することで、OSPO は組織がオープンソースエコシステムにどの程度参加し、サポートしているかを評価できます。

これらの指標は、イノベーションの加速、開発コストの削減、優秀な人材の獲得、製品の認知度向上など、オープンソース活動がより広範なビジネス目標に及ぼす影響を示すのに役立ちます。また、指標はコミュニティの健全性と持続可能性に関する洞察を提供し、プロジェクトの注目度、コラボレーションの促進、アクティブなユーザーや貢献者の獲得状況を明らかにします。

コミュニティ指標を組織の KPI に結び付けることで、OSPO はコードにとどまらない、製品フィードバックループの改善、市場投入までの時間の短縮、開発者とのより強固な関係、技術的信頼性の向上などのオープンソースの価値を示すことができます。このプレイブックは、OSPO がこれらの指標を効果的に追跡、分析、伝達し、オープンソースへの参加を測定可能なビジネスインパクトへと変換するためのガイダンスを提供します。

OSPO のインパクトを伝えるための指標の使用

指標は、インパクトを伝える上で重要な役割を果たします。目標・質問・指標のアプローチに従い、OSPO が検討できる 4 つの目標と、それに応じた質問をご紹介します。

CHAOSS Health Impacts

1: パートナーの影響

目標

オープンソースのコラボレーションが、市場洞察を深め、ベンダーとの関係を強化し、個々の技術を超えた共通価値を創造できる戦略的パートナーシップをどのように育むかを理解する。

解説

オープンソースプロジェクトの活動はコラボレーションを前提としており、そのコラボレーションには予期せぬパートナーシップが伴うことも少なくありません。これらのパートナーシップは、各パートナーが必要としているものの必ずしも単独で開発するリソースや意欲がない、差別化につながらない技術の開発を目的としています。オープンソースプロジェクトは、組織のメンバーが共通の課題に取り組むために協力し合う場であり、この緊密な関係は、単一のオープンソース技術を共有する以上のメリットをもたらす可能性があります。オープンソースパートナーシップの強化は、上流ベンダーとの連携強化、市場での競合状況の理解向上、下流ユーザーとの直接的な交流など、プラスの副次効果をもたらす可能性があります。

質問

  • 関心のあるオープンソースプロジェクトには、他にどのような企業が関与しているか？
  • プルリクエストには、他にどのような企業が関与しているか？
  • プルリクエストには、他の企業がどのように関与しているか？
  • 関与しているベンダー、競合他社、顧客の構成はどのようなものか？

指標

これらの質問に答えるために利用可能なデータを検討し、数値が増加または減少した場合に目標にどのような影響を与えるかを確信するために必要なその他の情報を検討してください。

2: コミュニティの影響

目標

オープンソースコミュニティへの従業員の関与が、組織貢献、個人のスキル開発の強化、そして主要プロジェクトにおける組織の存在感と影響力の強化にどう反映されているかを評価します。

解説

組織が従業員のコミュニティへの関与を支援する方法はいくつかあります（例：貢献ガイドライン、知的財産管理、ライセンスサポート）。支援には、コミュニティが組織にとってなぜ重要であるか、つまり、従業員が社外やアップストリームの活動に費やす時間や優先順位といった要素も含まれることがよくあります。企業は、個人的および組織的な利益の観点から、従業員を良き市民とみなし、組織とコミュニティの架け橋としての役割を従業員が理解できるよう支援することができます。

質問

  • 従業員の貢献のうち、マージされている割合はどのくらいか？
  • 従業員が提出するイシューのうち、話し合いなくクローズされている割合はどのくらいか？
  • 主要なオープンソースプロジェクトでメンテナーまたはリーダーシップの役割を担っている従業員は何人か？
  • アップストリームへの貢献は、従業員の技術スキルの最新化に役立ったか？
  • 従業員の貢献が 50% 以上を占めているプロジェクトはどれか？

指標

これらの質問に答えるために利用可能なデータを検討し、数値が増加または減少した場合に目標にどのような影響を与えるかの確信を得るために必要なその他の情報を検討してください。

3: エコシステムの影響

目標

オープンソースエコシステムの健全性とレジリエンス（回復力）を監視、貢献することで、長期的な存続可能性を確保し、リスクを軽減し、主要な依存関係の戦略的持続可能性をサポートします。

解説

オープンソースとの連携は決して容易ではありません。組織が関心を持つアップストリームプロジェクトが競合企業に独占されていたり、アップストリームプロジェクトのライセンスが予期せず変更されたり、個人または組織間の貢献者契約の理解と遵守が複雑だったりする場合があるからです。しかし、こうした課題は克服可能であり、組織が恩恵を求めるプロジェクトへの戦略的関与が含まれることも少なくありません。オープンソースエコシステムは、生産と需要を支えることを目的とした、さまざまな企業、動機、要件で構成される経済的、社会的システムです。あらゆるオープンソースエコシステムの効率性と持続性を確保するためには、企業はエコシステムの長期的な存続可能性を監視するだけでなく、問題が特定され安定化が必要になった場合には、エコシステム内で積極的に関与する必要があります。

質問

  • サプライヤーのうち、オープンソース部品表を提供している割合はどのくらいか？
  • 私たちが依存しているオープンソースプロジェクトの長期的な存続可能性はどの程度か？
  • オープンソースプロジェクトが存続不能になった場合、エコシステムへのリスクはどの程度か？

指標

これらの質問に答えるために利用可能なデータを検討し、数値が増加または減少した場合に目標にどのような影響を与えるかの確信を得るために必要なその他の情報を検討してください。

4: 組織への影響

目標

オープンソースへの取り組みを、社内ガバナンス、セキュリティ、製品開発と連携させ、組織の戦略と運用におけるオープンソースの価値を最大化します。

解説

オープンソースコミュニティとの連携には、組織の製品でオープンソースを効果的に活用するために、アップストリームでの取り組みが含まれます。そのためには、情報セキュリティ、法的、エンジニアリング上の理由から、オープンソースの導入状況を監視する必要があります。企業はソフトウェア導入プロセスを確立し、チームと協力してオープンソース導入に関する問題を技術的に追跡したり、社会的に検討したりすることができます。組織への影響には、組織の製品に依存しているプロジェクトや企業とのダウンストリームでの取り組みも含まれます。これには、出荷した製品に含まれるオープンソースをより明確に把握するための取り組みも含まれます。組織は、製品開発活動を改善するために、社内のオープンソースプロセスのセキュリティ確保と規制に取り組むことができます。

質問

  • 組織は、オープンソースの導入に関してどのような特性を検査するか？
  • 本番レベルのソフトウェアとインフラストラクチャのうち、オープンソースへの依存関係を含むものはどれか？
  • OSPO 戦略は、組織戦略および部門目標とどのように整合しているか？
  • OSPO 戦略は、ビジネス上の意思決定プロセスの指針としてどの程度活用されているか？
  • オープンソースの利用は、組織の価値にどのような影響を与えるか？

指標

これらの質問に答えるために利用可能なデータを検討し、数値が増加または減少した場合に目標にどのような影響を与えるかの確信を得るために必要なその他の情報を検討してください。

オープンソースプロジェクトを管理している場合

独自のオープンソースプロジェクトを作成・管理している組織、あるいはそれらの管理に深く関わっている組織向けに、さまざまなユースケースに適した指標を選択するためのガイドとなる、指標関連の CHAOSS 実践者ガイド 1 シリーズが用意されています。

オープンソースプロジェクトを利用している場合

オープンソースプロジェクトを利用し、プロジェクトの健全性を把握したい組織にとって、以下の情報は最適な指標の検討に役立ちます。

OSPO がオープンソースプロジェクトの健全性の複雑さを乗り越える方法

オープンソースプロジェクトの健全性を理解することは容易ではありません。オープンソースの健全性には、プロジェクトレベルまたはより広範なエコシステム全体に現れる可能性のある、技術的および社会的なさまざまな懸念事項が含まれます。既存の研究のレビューでは、107 件の懸念事項が特定されています 2 。この複雑さを理解するために、研究者は業界およびオープンソースコミュニティの 17 人の専門家と協力し、これらの懸念事項を 21 の健全性の側面からなるフレームワークに整理しました。

これらの健全性の側面は、次のような重要な領域に焦点を当てています。

  • コミュニティの生産性と安定性
  • プロジェクトのオーケストレーションとリーダーシップ
  • 生産プロセスとアウトプット

それぞれの健全性の側面は、属性、より細かく詳細な要素を用いてさらに詳細に記述されており、組織がプロジェクトの健全性を体系的に検証するのに役立ちます。

適切な文脈に合わせたフレームワークの選定

インタビューした専門家は、組織は分析対象の各オープンソースプロジェクトの種類と特性を考慮する必要があることを強調しました。すべてのプロジェクトが同じというわけではなく、さまざまな特性が健全性の評価方法に影響を与える可能性があります。考慮すべき重要な要素には、以下のものがあります。

  • プロジェクトのライフサイクル段階（例：初期段階 vs. 成熟段階）
  • プロジェクトの複雑性（プロジェクトの規模と技術的要求の厳しさ）
  • ガバナンスモデル（意思決定の方法と意思決定者）
  • プロジェクトが組織にとって持つ戦略的価値

オープンソースプロジェクトを比較する場合、OSPO は類似した特性を持つプロジェクトをグループ化して評価する必要があります。大きく異なる種類のプロジェクトを比較すると、誤った結果につながる可能性があります 3 。

測定対象を賢く選択する

組織ごとに文脈（市場、技術、リスク）が異なります。そのため、オープンソースの健全性を評価するための「万能」なアプローチは存在しません。OSPO は以下の点に留意する必要があります。

  • 組織のニーズに基づき、最も重要な健全性の側面と特性を決定する。
  • 取り組みの優先順位を付ける（すべてを測定するのは時間と費用がかかりすぎる）。
  • リスク管理と意思決定に最も役立つ洞察を提供するデータに重点​​を置く。

OSPO は、すべてを一度に測定しようとするのではなく、小規模から始め、初期の取り組みから学び、時間をかけてアプローチを改良していく必要があります。健全性評価は、経験を積むにつれて進化する、実用的でスケーラブルなプロセスの一部として実施することで、最も効果的に機能します。

事例: グローバル自動車会社におけるオープンソースプロジェクトの健全性評価方法

オープンソースの依存関係の評価と管理への実践的なアプローチ

2024年、Linåker 氏とその同僚は、大手グローバル自動車会社と協力し、オープンソースソフトウェアプロジェクトの健全性を評価するためのシンプルかつ効果的な方法を開発しました 4 。この事例は、組織がニーズとワークフローに合わせてヘルスチェックをカスタマイズする方法を示しています。

健全性評価プロセスの構築

チームはまず、インタビューとフォーカスグループを通じて従業員へのヒアリングを行いました。これらの知見に基づき、企業の環境に合わせた簡単なアンケートとプロセスを開発しました。

プロセスの主な特徴:

  • 標準化されたチェックリストを用いた受入段階での手動検査
  • 必要に応じた自動ツールによるサポート
  • 将来のレビュー、フォローアップ、トレーニングのために、発見事項を追跡するためのシンプルなドキュメント作成

目標は、オープンソースプロジェクトにおける重要な健全性リスクを把握しながら、プロセスを軽量かつ効率的に維持することでした。

既に利用中のプロジェクトの監視

同社は、既にシステムに統合されているオープンソースプロジェクトを追跡する方法も必要としていました。これらのプロジェクトは多くの依存関係を持つことが多いため、手動でのチェックは現実的ではありませんでした。

提案されたソリューション:

  • 自動ツールを使用して定期的にヘルスチェックを実行する。
  • エコシステムと依存関係の種類に基づいてツールをカスタマイズする。
  • リスクの高いプロジェクトにフラグを付け、開発者やアナリストが必要に応じてより詳細な検査を行えるようにする。

GrimoireLab や Augur といった CHAオープンソース コミュニティのツールは、良い出発点となります。会社はこれらのツールを社内のニーズに合わせてカスタマイズできます。

健全性評価を日常業務の一部にする

新しいプロセスを成功させるために、チームからの推奨事項は、トレーニングとチームの関与に重点を置いていました。

  • チェックリストとツールを紹介するワークショップを開催する。
  • 実際のオープンソースプロジェクトをレビューするための定期的なフィードバックセッションをスケジュールする。
  • チーム間での議論と知識の共有を促進する。

時間の経過とともに、企業はオープンソースのヘルスチェックをソフトウェア開発および品質保証のワークフローの一部に定常化することができます。

OSPO が学べること

この事例は、リスクを軽減し、オープンソースの長期的な信頼性を向上させたいと考えている OSPO にとって有益な教訓となります。

重要なポイント:

  • 手動のチェックリストと明確な受入プロセスからシンプルに始める。
  • 多数の依存関係の継続的な監視には自動化を活用する。
  • 既存のワークフローにヘルスチェックを統合する。
  • トレーニング、ツール、そして定期的なチームディスカッションによってプロセスをサポートする。

問題を早期に特定し、迅速に対応することで、組織はリスクを軽減し、オープンソースソフトウェアの安全性、安定性、持続可能性を確保できます。

CHAOSS プロジェクトや OpenSSF スコアカードなどのリソースは、OSPO が取り組みを開始したり、アプローチを強化したりするのに役立ちます。

リソースと脚注

リソース

脚注

  1. CHAOSS 実践者ガイド: https://chaoss.community/about-chaoss-practitioner-guides ↩︎

  2. Linåker, J., Papatheocharous, E., & Olsson, T. (2022). How to Characterize the health of an Open Source Software project? A snowball literature review of an emerging practice. In the 18th International Symposium on Open Collaboration. DOI: https://doi.org/10.1145/3555051.3555067 ↩︎

  3. Lumbard, K., Germonprez, M., & Goggins, S. (2023). An Empirical Investigation of Social Comparison and Open Source Community Health, Information Systems Journal, 34(2), 499-532: https://onlinelibrary.wiley.com/doi/abs/10.1111/isj.12485 ↩︎

  4. Linåker, J., Olsson, T., & Papatheocharous, E. (2024). How to Assess the Health of Open Source Software dependencies in an Organization’s Intake Process: Insights from an Interview-survey and Case Study: https://www.linaker.se/assets/slides/OSS_Health_Interview_Survey.pdf ↩︎

更新日 July 17, 2025: Fix image URL on 06-chapter.md (a162c7d)