オープンソースを活用する企業にオープンソースプログラムオフィスは必要か？

Capital OneのOSPO

ここからCapital OneにおけるOSPOの紹介するフェーズとなる。

Capital OneにおけるOSPOの紹介

ここでは、Capital Oneが金融機関としてリスクマネージメントが必須であったこと、厳しい法規制の下でビジネスを展開していることなどを背景として説明し、自社のテクノロジーの主要な部分をオープンソースソフトウェアによって実装することを、2014年に宣言という形で作成したと説明した。

Capital Oneはオープンソースソフトウェアを軸に実装することを宣言

そして2015年にOSPOを設立した。ここではその目的として「オープンソースソフトウェアによるセキュリティ及び法的リスクを管理すること」、「資産を守りつつ、貢献することを維持」、「プロジェクトのリリースを管理」することの3点を挙げた。

Capital OneにおけるOSPOの目的

企業内でオープンソースソフトウェアを使う際のポリシーや標準を作り、ライセンス違反に関してはちゃんとレポートをあげることをルールとしたことなどを主な活動内容として説明した上で、試行錯誤した部分についても解説を行った。特に「OSPOを組織の中でどこに位置付けるのか？」に関しては、テクノロジー関連のチームの中に配置した後にリスク管理との関連が強いことが判明し、その後はリスクマネージメントチームの中の組織として配置換えを行ったという。

その後、徐々に組織としては成熟し、2017年にはライセンスコンプライアンスのチェックの自動化までシステム化されたことを説明した。

またオープンソースコミュニティとの関わりについても年々進化を続けており、制限された活動スタイルから始めて、制限を外していったやり方を解説している。ここでは許可されたメンバーがホワイトリストに従って実行できることを遂行するRestrictiveという状態から、ブラックリストに従ってやってはいけないことを除外するPermissiveな状態に移行し、2019年にはコンプライアンスチェックなどが自動化された状態に移行することを目指していることを解説している。

2014年から2019年に向かって進化するCapital Oneのオープンソース利用

そして究極的にはリスクを管理しながらオープンソースソフトウェアの使用を限りなくシンプルにすること、コラボレーションを社内外で実行するカルチャーを育てること、ビジネスを支えるシステムとオープンソースソフトウェアを統合することなどをビジョンとして掲げていることを紹介してAniszczyk氏にプレゼンテーションを譲った。

Capital Oneにおけるオープンソースソフトウェアのビジョン

TODO Group

ここからChris Aniszczyk氏によるTODO Groupの紹介が始まった。

TODO Groupの始まり

TODO Groupは、2014年にメーリングリストなどによる議論を経て非営利団体として発足、その後2016年にThe Linux Foundationのコラボレーションプロジェクトとして加わったことなどを紹介。

TODO Groupのメンバー（2018年時点）

メンバーにMicrosoft、Google、Facebookといったインターネットジャイアントに加えて、Samsungなども参加しているという。実際のメンバーは以下のリンクから参照されたいが、トヨタを始めとして中国のBaidu、DiDi、Tencent、インドのWiproなどの企業の名前もあり、多様化していることがわかる。

参考：Members

またCNCFのランドスケープのインタラクティブ版と同じソースコードでインタラクティブ版が設定されており、OSPOを設置している企業／組織とメンバーを確認することができる。

参考：OSPO Landscape

ここから実際に「OSPOとは何か？」「創設するために必要なポイントは？」などを解説することになるが、最新の情報はTODO Groupのサイトにガイドとして公開されている。

参考：TODO guides

OSPOとは何か

まず「OSPOとは何か？」については「組織においてオープンソースソフトウェアの構成や使い方、方向性などを集中的に管理する部門として機能し、必要とされるコンポーネントを集約する」部門としている。この場合のコンポーネントはソフトウェアだけでなく、規約、ルール、コミュニティ、エンジニアなどの要素も指すと理解すべきだろう。また企業や業界、規模などによって実装方法は千差万別であるとして、万能の正解はないとしているところに多くの事例を理解しているAniszczyk氏の洞察が現れていると言える。

またその活動内容や責任の範囲についても、戦略を決め社内および対外的にコミュニケーションを行うこと、ライセンスのコンプライアンスを維持することなどが挙げられている。これについても組織によって異なり、万能の正解はないと解説している。

その後に続くスライドで、最も大事なポイントが挙げられているので紹介したい。

OSPOを作るための最初の仕事はリーダーを見つけること

このスライドでは、OSPOを率いるリーダーを見つけることが成功の最初のステップと語られている。これはこの仕組みが未だに属人的な特性に依存していることを表していると言える。社外の人材とも協調できるデベロッパーでありつつ、ITに詳しくない組織内でのコミュニケーションにも長けている能力を持っているというのは、実は相当なスーパーマン／スーパーウーマンであると言えるだろう。

企業が必要とするソフトウェアの良し悪しを理解しながら社内の調整ができるのは、かなりの能力を要する。ただし、一人ですべてを背負う必要はないし、組織として役割分担は必要というのが、このスライドには書かれていないメッセージかもしれない。

より詳細にはTODO GroupのWebサイトやGitHubのレポジトリを参照されたい。

参考：https://github.com/todogroup/todogroup.org/blob/main/content/en/guides/_index.md

まとめとして、組織を作るというのが最初のゴールだとすれば、それを評価するメトリクスを作る必要があることを説明しているスライドを紹介したい。

組織としてのゴールを設定し評価することが大事

商用ソフトウェアを購入するのであれば、購買担当とシステム部門がベンダーの指針に従ってソフトウェアを実装すれば、たとえ結果が出なくてもベンダーに責任を問える可能性がある。しかしオープンソースソフトウェアを使うと決めたからには、ユーザーが自身でその決断を評価する必要がある。OSPOに所属するエンジニアやその他の人材が他部門との兼任だとしても、ちゃんとゴールを設定してそれに対して評価を行うということは必要だろう。

このプレゼンテーションでは、主にライセンスと自社が開発したソフトウェアを公開することに対する施策が大多数を占めている。そのため日本企業における「バグの修正をベンダーが行わないソフトウェアを企業が使うための理論武装」としては不十分かもしれない。しかしこれまでの組織とは異なる「オープンソースソフトウェアを使うための多くの作業を集約するための組織」としてOSPOを位置付けるならば、先駆者の経験をなぞることは大いに意味があるだろう。

2021年9月末には、オープンソースソフトウェアプログラムオフィスに特化した初めてのOSPOConが開催される。これまでネットの中で議論されていた内容やユースケースが多数集まるカンファレンスとなるだろう。成功事例だけではなく、失敗事例を教訓として取り上げる傾向にあるLF/CNCFが失敗事例を取り上げる可能性は大いにある。

参考：OSPOCon

TODO GroupのOSPOの作り方ガイド：How to Create an Open Source Program