オープンソース・プログラム・オフィスとは何か？ (ぼくがかんがえた最強のOSPO)

GoogleやMicrosoftといったビッグテックにOpen Source Program Office (OSPOという略で界隈では通じる)という部署が存在することは日本でも知られているが、現在では多くのグローバルIT企業にも同名の部署が存在する。近年では中国系の企業での設置が目立つが、日本でもサイボウズ、メルカリといった企業には存在するようだ。

名前で勘違いする方もいるかと思うが、このOSPOという部署はオープンソース開発を行っている部署のことではない。一言で言えば、オープンソースの世界と企業の内部との全ての接点に関与し、それを支援することで円滑にオープンソースの価値を享受するための部署である。時には法務やコンプライアンスの部署に見えるし、マーケティングや広報のようにも見える。また、社内の情報システム部門の一部のように見えることもある。もう少し詳細にOSPOの役割を列挙すると以下のようになると思う。

自社の事業に合わせたオープンソース戦略と全社ポリシーを策定、監督、実行する
イベント等を通じてオープンソースコミュニティとその周辺に対し、自社活動と戦略への理解を促す
自社内でオープンソース戦略への理解を浸透させ、適切な知識を習得させる
ライセンスを含むオープンソース関連での法務的問題、コンプライアンスへの対処、支援、教育活動を行う
オープンソースへのコード貢献やフィードバックの社内への展開の管理やライセンス等のコンプライアンス面の監視プロセスの効率化、自動化を進める
自社利用オープンソースとその周辺または代替のアップストリームコミュニティの継続的リサーチおよび支援を行う

少々難解に書いてしまったが、くだけて書けばオープンソースを戦略として取り込むために、企業としてのルールを定め、コミュニティと協働し、社員のオープンソースへの知識を高め、コミュニティと問題が起きないように努め、出来るだけラクをするようにし、将来のエコシステムの変化にも備えるということなのだが、これらは90年代の初期のフリーソフトウェア/オープンソース企業であれば空気を吸うように行動していたようなことである。昔の方が凄いという話ではなく、単純に90年代のオープンソース界隈の規模は現在よりもはるかに小さく、ムラの掟のようなものをそのままビジネスに持ち込むことで対応できていただけのことだ。

それがオープンソースムーブメントとバブル以降、企業でのオープンソース採用は急激に進み、コミュニティも巨大化かつ複雑化していき、オープンソースのエコシステムが形成されていく中、オープンソースという自社外とのリレーションが自社の経営戦略と密接にリンクするようになり、より専門的な法務、マーケティング、広報、リサーチの能力を持つ組織が必要になったという流れである。ありそうな流れを書くと、
昔のムラの掟を分かっている人が窓口 -> 何人かの有志で業務外で担当 -> 関係各部署から正式に担当を出した会社横断的グループ -> 専従者がいる組織
のように組織的には変化していってるということだろうか。

現代のOSPOのロールモデルとなったのはGoogleである。「ムラの掟」世代の私からすれば、Cygnus、VA Linuxという名前を出したいところだが、Googleが2004年に創設したグループがOSPOの原型と言い切って差し支えはないだろう。Googleは2004年8月にIPOを実施しており、その前後でGoogleの企業文化が変質化する可能性が囁かれていたが、そのタイミングでオープンソースの利用や貢献のプロセスを全社的に定めておきたかったのかもしれないし、単に今もGoogleのオープンソース戦略を支えているChris Dibonaの入社のタイミングで自然にOSPOのような組織が作られたのかもしれない。

ともかく、GoogleのOSPOは、先ず最初はライセンス等のコンプライアンス監督、教育から入り、翌年にはGoogle Codeや今も続くGoogle Summer of Codeを開始し、オープンソースコミュニティとのリレーションを強める役割を果たした。有名な20%ルールによって内外のプロジェクトに従業員が関わるようになったのもOSPO主導によるものである。Googleはこれらによってそれまでの単なる個別のプロジェクト単位でのコード貢献から、コミュニティによるエコシステム全体を自社のビジネスに取り込むようになったのである。

オープンソース・プログラム・オフィスの組織構造

オープンソースのコミュニティがほぼソフトウェアの世界を覆い尽くしている現在においては、前項で挙げたOSPOの役割を果たすためにより専門的な能力が必要になっている。大概の場合、OSPOのトップにはオープンソースプロジェクトの方法論に詳しく、そのコミュニティの中で活動してきた経験を持ち、その企業の顔として活動しながらもCEO、CTOに対して自社が取るべきオープンソース戦略を詳細に説明できる能力を持った人間が据えられるが、その直下のチームには複数の分野の専門家が配置されることが一般的である。OSPOは、時には法務に見え、時には広報に見えるというようなことを先に述べたが、一般的なOSPOには法務、マーケティング、ソフトウェアエンジニアの担当者もしくはチームが配置される。

法務、コンプライアンス

法務チームで担当する役割は前節で掲げたOSPOの役割の4項である。オープンソースライセンスの社内の実情把握と管理、コンプライアンス面で自社の内外で発生する問題への対処、社内での教育と周知が主なタスクとなる。米国企業では一般的に法務部門は弁護士資格を持つ者が主体となるが、OSPOの場合は必ずしもそうとは限らない。

もちろんリアルな世界における法律的な側面からの解釈やレクチャーというものは重要であり、実際に米国企業のOSPOの法務担当は弁護士がほとんどだと思われるが、オープンソースの価値を取り込み、エコシステムに自社を融合させるためにOSPOが存在していることを踏まえると、資格よりもコミュニティへの理解の方をより重視すべきである。

一昔前であれば自社で使用されているオープンソースのコードを監視、特に日本国内でよくあった感覚からすればコンタミが起きていないかのチェックといった保守的なスタンスが主だったかもしれないが、あらゆる分野と工程においてオープンソースが主役になっている昨今においてはより戦略的にコードを取り込んでいくためにライセンスの把握、組み合わせのチェック等を行わなければならないし、Code of Conductを核としたコミュニティの規範、コミュニティの行動原理に沿うように自社の行動を誘導しなければならない。そのために何らかの問題が起きてからの対処だけではなく、予め自社がコミュニティと一体的に協働できるようにするためのライセンスやコンプライアンス面での最低限の素養を身につけさせる教育もこのチームには期待されることになる。

マーケティング

一般の外部から見えやすい活動を行っているのはマーケティングチームだろう。マーケティングチームでは前節での2項、3項に相当する役割を果たすことになるが、自社のオープンソース戦略を自社内およびコミュニティに対して理解を周知させ、自社技術の広報、技術共有、コミュニティとの交流を行うことになる。多くのIT企業にはイベントでの登壇やSNSなどでよく見かける顔役の人物がいて、何か技術的な問題が発生すると即座に現れるということが往々にしてあるわけだが、多くの場合このようなタイプの方々がチームに属することになる。

このような役割をディベロッパーリレーションという役職や部署で表現することもあるが、一般的なディベロッパーリレーションは自社の技術についての広報活動や技術サポートというユーザーに価値を与える片面的な活動が主体であることに対し、OSPOに期待されることはオープンソースコミュニティと協働し、自社の戦略や技術をオープンソースのエコシステムの一部として機能させるという相互的な活動になる。例えば、自社が公開するAPIや製品のSDKについてだけ対応するディベロッパーリレーションの立場の方も多いと思うがOSPOではそれに留まることはない。そのような性質の違いにより、自社の技術を広めるだけでなく、コミュニティの技術を広めるということもあり得るし、立ち位置としても自社だけでなくコミュニティ側の立場として活動することもあるだろう。

Red Hatは全ての製品がオープンソースであることで知られているが、そのため必然的に開発の中心は上流となるプロジェクトのコミュニティの中にある。このような場合、オープンソースプロジェクトの健全に成長していくことが重要となり、Red HatのOSPOでは関連するコミュニティが効率的かつ適切に機能させるために労力を費やすことになる。つまり、これはコミュニティ構築ということである。彼らはより健全で活動的なコミュニティを構築することに注力し、場合によってはそのエコシステムに顧客までをも巻き込んでいる。一般的な尺度からすればRed Hatの戦略は極端な例とまだ見做されることが多いが、自社内とコミュニティの線引きを行い、シームレスな結合を図るという点以外については、Red Hatのような動き方は理にかなっている。

日本においては昔からコードを公開することをオープンソースと呼ぶことがあるが、このような不足した理解からアンチパターンの一つであるThrowing Code over the wall (壁の向こうにコードを投げる)という状態に陥ることが散見される。オープンソースは生き物であり、手間をかけ続けてコミュニティを構築して初めて価値を得ることができるが、マーケティングチームはこれに向けて自社のエンジニアと経営陣を導く役割を果たすことになる。

エンジニアリング

冒頭でオープンソース開発の部署ではないとも書いたこともあるし、前節で示した役割からしてもOSPOにはエンジニアリングの要素が一見少なく見えるかもしれない。しかしながら、オープンソースのエコシステムを取り入れれば入れるほどコミュニティと自社という現場が分けられることになり、そもそもオープンソースプロジェクトのコミュニティは無数に存在する。Googleのように社員が数千以上のオープンソースプロジェクトに関与するような組織でなくとも、自社が関係する外部のプロジェクトを列挙すれば大抵の企業では一目で把握できる数にはならないだろう。

OSPOのエンジニアリングチームは、この自社が関わるオープンソースプロジェクトとの全ての関わりについてOSPOにて定めたポリシー、プロセスに従って管理、監視を行い、またそれによるオーバーヘッドを減らすための自動化を含むツールの開発、運用を行うことになる。場合によっては自社内外を問わず、ソースコードやリリース管理の基盤からコミュニケーションツール、プロジェクトの健全性を分析するためのトラッキング、分析、品質管理ツール、ライセンス管理ツール等の導入、運用を行うこともあるだろう。重要な点は自社の事業部門のエンジニアリングチームに極力負担をかけないようにする仕組みを構築することである。

このような役割は企業の情報システム部門と被るところもあるわけだが、マーケティングでも触れたことと同様に外部の多様性があるオープンソースプロジェクトとの協働にも関係する箇所に関しては機動的に判断すべき課題も発生する。企業によっても事情は異なってくるが、多くのOSPOに専従エンジニアが所属していることはそれが合理的ということなのだろう。

部署の配置

OSPOのリーダーは前述の各チームをまとめ、CEO、CTOに自社が取るべきオープンソース戦略の立案を行うことになる。この結晶が自社のオープンソースポリシーであり、全社的にそのポリシーに従って行動することになる。こういったポジションを考慮すると、企業組織内でのOSPOの位置はCEOやCTOの直下であったほうが自然に見えるかもしれない。また、知財を重視する考え方なら法務部門とするかもしれないし、あくまでディベロッパーリレーションとしてマーケティング部署と考えることもできる。

実際のところ、OSPOの配置は企業によって異なるし、どの会社も自社の事情に合わせているとしか思わないが、私としては自社のエンジニアにより近い場所でさえあればそれで問題ないと考える。OSPO所属のメンバーが行う仕事はオープンソースコミュニティとの相互の協働関係を促進するための仕組みの提供とコミュニケーションであり、実際にコミュニティの一員として活動するのは事業部門のエンジニアなのであるから、エンジニアと近い場所にてエンジニアの感覚にそって支援を行うほうが望ましいからである。エンジニアらが法的な問題、コミュニティとの協働、広報活動等の間接的な業務への作業に時間をさくことを軽減させることができれば、それでOSPOには価値があると言えるわけである。

オープンソース・プログラム・オフィスが優先すべき方向性

ここまで書いてきておいて恐縮だが、私が経営していたOSDN社は単なる零細企業だったわけであるし、それ以前もOSPOでの勤務経験があるわけではないので実情と異なる部分もあるかもしれない。ただ、私は先に書いたように「ムラの掟」の時代からこの世界に生きており、オープンソースという言葉の誕生時に同じ掟の一員だった元同僚らが中心になってGoogleのOSPOを作り上げたので少しは理解があるほうだろう。その私から言えるOSPOの設置でオープンソース戦略を加速させるために必要な点として、下記の三つを挙げておく。

1. ポリシーは常に変わることを前提に

オープンソースの世界は変化が早い。ライセンス等に関してはさほど大きな変化が起きないものだが、それでもSSPLのような話もあるし、クラウド環境においてどのように世界が変化していくのか分からないところもある。特許や商標に関しても考え方は変化していくものと考えられる。また、コンプライアンス面に関してはオープンソースの世界の肥大化、多様化がさらに進むことでより複雑で混沌とした問題が表面化してくるだろうし、オープンソース界隈の開発プロセスはさらに大きな進化をしていくと考えられる。このような変化、進化に合わせて機動的に自社のオープンソースポリシーと戦略を変化させていくことは極めて重要だと考える。

2. オープンソース戦略を社内に理解させる

OSPOが果たすべき役割には自社外にむけた広報活動だけでなく自社内に向けた活動も含まれる。Red Hatのような最初から全てがオープンソースという戦略ならまだしも多くの企業ではアップストリームへの貢献や自社のソフトウェアのオープンソース化については戦略に従って個別に判断することが多くなる。しかしながら、伝統的なソフトウェア業界のビジネス慣行はオープンソースコミュニテイにおける哲学と大きく異なることもあり、特に企業経営における意思決定者の理解が不足していることは往々にして起こり得る。また、オープンソースのエコシステムによる価値の享受はコミュニティとの協働によって発生するものであり、全ての社員がその意味を理解してこそなし得るものだと考える。このため、社内にオープンソースの有用性を理解させ、オープンソースを戦略に組み込むことへの理解を深めることに意味があるのである。

3. 常にアップストリームを優先

定番過ぎるフレーズではあるが、アップストリーム優先 (upstream first)のポリシーは常に採用するよう努力すべきである。最初にアップストリームへの貢献を徹底することで、自社側のダウンストリームにおけるリエンジニアリングの膨大な時間と費用を削減することができるという大きなメリットもあるわけだが、アップストリーム優先こそがコミュニティとの協働関係の源泉となり、信頼を高める上での鍵となるのである。

日本におけるOSPOの必要性

私はごく最近までOSPO的な部署を設置している国内企業はないと考えていた。実際には幾つかの企業に同等の役割の部署が存在することは確認したのだが、それでも国内では少ないのが実際のところだと思う。法務は法務、マーケティングはマーケティングと既存の部署が各々に役割を果たせばいいとする論もあるとは思うが、このような場合でも現在の日本の一般的なオープンソースへの理解度を考慮するとオープンソース戦略をまとめ上げて実行するための先導役となる人物は必要であるし、欧米や中国に倣って専門部署を設置するほうがより機動的にコミュニティとの協働関係を築けるだろう。

ビジネスの形態にも依るので杓子定規的には言えないが、ソフトウェア企業の場合、従業員が100人規模であればOSPO的な役割を果たす専従者がいるほうが望ましいケースも出てくるだろうし、500人規模にもなれば専従のチームとしてのOSPOが設置されるほうがオープンソースの戦略的取り込みが進むのではないかと思う。

特に日本の場合、オープンソースの活用といった名目で無料でそこらに落ちているソフトウェアを利用するという感覚から抜け出せないCEO、CTOが多いのではないかと感じているが、現実としてオープンソースの使わないという選択肢はあり得ない状況になっている昨今であることから、そのようなタイプの感覚がはびこる社内であってもエンジニアリングの現場においては如何に効率的なオープンソースのエコシステムからの恩恵をどのようにして享受すべきか思考を巡らせている方がいるのだと思う。OSPOはそのような状況を打破する一つの解となるだろう。

OSPOについてここでは概念的な事柄しか述べておらず実際の業務の進め方については一切触れていないが、OSPOの立ち位置や役割については大体のところは網羅しているのではないかと思う。IT系の職種の方が普段使用するサービスを提供している企業は、ほぼすべからくオープンソースのエコシステムへの多大な投資を行い、OSPOのリーダーシップの下で自社の戦略を進めていることを理解すれば、次に何をすべきか見えてくるのではないだろうか。