【ソニー×メルカリ×日立ソリューションズ】先輩事例に学ぶ！OSSの専門組織（OSPO）の作り方 セミナーレポート（2/2）

イベント概要

あらゆる産業において欠かすことのできない存在となっている「オープンソース・ソフトウェア（OSS）」。無償で利用でき、プログラムのソースコードが公開されていることが特徴で、オペレーティングシステムであるLinuxやデータベース管理システムのMySQL、プログラミング言語のJava、Perl、PHP、Pythonなどが知られています。企業のOSSマネジメントの重要度が増す中で、株式会社日立ソリューションズはOSS管理を支援するソリューションを提供しており、2021年12月にOSSマネジメントフォーラム2021を開催しました。本記事では、当該イベント内で行われた「先輩事例に学ぶ！OSSの専門組織（OSPO）の作り方」と題したパネルディスカッションの模様をお届けします。OSPO立上げ時の苦労や課題などの経験談、社内外からの反応・効果について、具体的事例が語られました。

パネリスト

福地 弘行 氏 ソニーグループ株式会社

佐藤 和美 氏 ソニーグループ株式会社

上野 英和 氏 株式会社メルカリ

渡邊 歩（モデレーター） 株式会社日立ソリューションズ

セミナー内容

※セミナー当日は、パネリスト様からプレゼンテーション資料の投影がありましたが、本セミナーレポートでは掲載しておりません。

はじまりはエンジニアからのチャット

渡邊歩（以下、渡邊）：自己紹介とOSPOのご紹介をそれぞれいただきましたけれども、おそらくいま「こんなOSPOを作りたいな」と皆様思っているのではないかと思います。これからOSPOを作りたいなと思っている皆様に対して、「どうやって作ったか」とか、「こういうターニングポイントがあったよ」とか、「コツはこういうのがあったよ」とか、OSPOの作り方という観点で何かお話できることがあればお願いします。

渡邊：まず上野さんお願いできますか？

上野英和氏（以下、上野）：はい。ではOSPOを立ち上げるために「何をしたか」と、「何が大変だったか」をご紹介しようと思います。

「何をしたか」ですけれども、そもそもやろうと決めたのが大きいかなと思います。私は2018年の8月入社ですが、10月に社内のチャットで「エンジニア側でオープンソースの活動をやりたいんだけど、今何もルールがなくて、コーポレートの人も入っていなくてよくわからないんです。」といった連絡がエンジニアの方から来たんですね。

私としては「OSS利用に関するコンプライアンスだけだとちょっとな」と思っていたんですが、話をしたら「メルカリは公開をどんどんやっているので、それをもうちょっとちゃんとしたい」という話があったので、面白そうだなと思い直しました。その最初のミーティングか次のミーティングくらいで「プロジェクトにするくらいの仕事だよね」ということで、プロジェクトを立ち上げることになりました。

ただ最初はまったくの知識不足だったので、ネットで調べたり、知り合いのツテでいろいろな人に話を聞いたりしました。先ほど福地さんが言及されていたOpenChainも、トヨタの遠藤さんに紹介していただきました。今回のファシリテーターの渡邊さんや福地さんとは、その活動を通じて知り合いました。そうやって情報を集めながら社内では一緒にやってくれるメンバーを集めました。先ほどCTOの声明を紹介しましたけど、エンジニアリング部門の上の人たちに、「こういうことを考えているんですけど、やった方がいいですよね」という話をしてまわって合意を取りました。

やはり大きかったのが、先ほどご紹介したメルカリOSPOのミッション・ビジョンと活動の三本柱を決めたことで、これが立ち上げにおけるターニングポイントかなと思っています。これを決めるのに結構時間がかかっていて、2から3ヵ月はこれをやっていたかなと思います。立ち上げの時期から毎週30分の定例ミーティングを行っていたんですが、最初の頃の議題は大体これだったという印象です。ミッション・ビジョンと活動の三本柱を決めた後、実際に実務を始めるような時期に入ります。

エンジニア採用やセキュリティにも関係するOSPO

次に「大変だったこと」ですね。主に2点ありまして、1つ目が「専任ではないこと」です。ソニーさんの話を聞いて、やはりソニーさんほどの大企業でも専任の方が6人・2人・2人くらいしかいらっしゃらないということなので、やっぱり専任化はメルカリにはまだまだ早いなという感じはしつつも、なかなかリソースが割けないということでこの点には苦労しました。

ただメルカリはプロジェクトで働くことが多い会社です。組織の壁というのが低いですし。ダイバーシティでいろいろな人がいて、バックグラウンドも全然違ったりするんですけれども、ミッション・ビジョンみたいなものがあってプロジェクトとして「これをやりたいんだ」と言ってそれに共感してもらえると、すごく協力的に働いてくれるような人たちが多いので、そういうやりやすい面はあったかなと思っています。

大変だったことの2点目は、「OSPOの必要性の理解を促す」というところですね。これがおそらくどの会社でも大きな課題になるところかなと思います。「専任ではないこと」というのも、結局必要性がそれほど認識されていないからでもあると思いますので、結局この点が根本的な問題かなと思います。

渡邊：どうもありがとうございます。はじまりがエンジニアさんの1つのご相談だったというところが、まずすごいと思ったところです。おそらくエンジニアの皆さんは誰かに相談したいとか、誰か手伝ってくれないかなとか、思っている方がいらっしゃると思うんですけれども、それを上野さんが拾って、そこからプロジェクト化して大きくしたっていう、これで動き始めることがすごいなと、まず思いました。

もう１点、やっぱり「上がわかってくれない問題」というのは、昨日のパネリストの方も仰っていました。やりたいし、重要性もすごくあるんだけれども、なかなかそこに対して予算がつかないとか、上の理解が得られないとか、お悩みの方はすごく多いですね。ありがとうございます。

ソニーにおけるOSPOの歴史

渡邊：では同じくソニーさん、いかがでしょう。OSPOの作り方であったりとか、ここがポイントであるだとか、教えていただけますでしょうか？

佐藤和美氏（以下、佐藤）：佐藤の方から話します。先ほど2000年くらいからのLinuxに関する話をしたと思いますが、一応いまここに出してあるのが、ソニーの（2003年以降の）組み込み機器系の歴史になります（資料投影）。

最初、ビデオレコーダー、テレビからスタートして、デジタルカメラやデジタルビデオカメラに行って、オーディオにも入って、さらに最終的にはaiboみたいなところまで入っています。もう20年以上やっていることになるんですけど、OSPO自体は実は、必要でやっていた活動が最終的にOSPOにつながっていった形になっています。

だいたい3つくらい（の時期）に分かれるんですけれども、2000年くらいから2010年くらいは大量生産系の機器にLinuxが入っていて、私たちがLinuxを使って商品を開発していた時代になります。この時代は結局、Linuxの開発チームがオープンソースをどうやって製品に搭載するのかということを自分で考えなければいけなかった時代なんですね。なので、エンジニアが中心となって法務とか知財と連携して、オープンソースライセンスをどうやって処理すればいいかとか、技術的にどういうふうにすればコンプライアンス遵守した状態で製品を出荷できるかとか、全部Linuxの開発チームのメンバーが対応をしていた時代です。

技術部隊と商品部隊は、OSの供給元とそれを受け取る側という関係でコミュニティが形成されていて、その中で仮想的なOSPOが形成されていました。なので実オペレーションとしては、実は技術部隊の中でポリシーを考えて、技術的にどうすればいいかとか、先ほどのビジョンみたいなものもそこから生まれて、ドキュメントとして事業部に配布されていました。先ほどあったようなOSSライセンス委員会というのもこのあたりでだんだんでき始めまして、このあたりが最初のステージになります。

次のステージになるとAndroidも出てくる時代になりましたので、Linuxの開発チームではないエンジニアがオープンソースを使う場面もどんどん増えてきました。ここで、技術部隊と商品部隊という関係ではなく、OSSライセンス委員会というものが（正式に）作られました。これも技術系階層の中に技術委員会として作られていて、そこに法務と知財が入ってくれて、仮想組織としてやっていました。

徐々にOSPOが形成される

佐藤：2015年くらいになったときに、もうソニーグループのさまざまな事業体がオープンソースを使ったりコントリビュートしたりしている状態になっていて、専任部隊がなければ回らないような状態でした。ここでオープンソース推進の専任部隊ができて、そこがOSSの委員会をまわすという形になりました。

これがソニーのOSPOの歴史になっています。最初は技術的に必要だったからできて、次に社内のコミュニティとして拡大して、次に回らなくなったので専任部隊ができたという、そういう流れになっております。

渡邊：ありがとうございます。成り立ちの部分に関しては、少しメルカリさんとは違った経緯という感じがしましたね。どちらかというと、いきなりOSPOを立ちあげるぞという感じで始まったのではなく、必要な人がやっていたところからどんどん形になってきて、それが最終的に組織の形になったというところについては、また全然違う成り立ちであるという気がします。

ちなみに、この図からすると（2003年から今までの）17から18年間くらい、会社の中でずっとOSSに関する活動がされている感じですかね。

佐藤：そうですね。それ以前にもLinuxに関する開発はしていて、その後にこれらソニーの商品にということなんで、実は2002年よりも前もあるんですけど、表に入らないので省略しています。（この図は）メイン商品のところからスタートしてるという感じなんです。

渡邊：なるほど、ありがとうございます。エンジニアさんがやっていた活動が形になっていくという成り立ちもすごく面白いですね。印象に残りました。ありがとうございます。

パネリストの皆様からいろいろと興味深いお話をたくさん伺っているところではございますけれども、このあたりでそろそろ後半ということで、ご聴講の皆様からの質問にお答えいただく時間になってまいりました。皆様、ご質問の投稿の準備はいかがでしょうか？まだ聞いてみたいことがあるけれども投稿してないよという方いらっしゃいましたら、Q&Aの機能を使って質問のご投稿をお願いいたします。

OSPOはどこまでの権限を持つのか？

渡邊：会場の皆様から非常にたくさんのご質問をいただいております。どうもありがとうございます。限られた時間にはなりますけれども、皆様からいただいた質問に対してお答えしていきたいと思います。

それでは1つ目「製品に対するOSPOの責任や権限はどうなっていますか？例えば、差し止め権限などはありますか」というご質問です。おそらく出荷のときなど、何かあったときに止めるような権限があるかというご質問だと思うんですけれども、こちらソニーさんいかがでしょう？

福地弘行氏（以下、福地）：直接我々が権限は持っていないんですけど、出荷するためのボトムラインというか、「これを守らないと出荷できない」というような内部規則があるんですけど、その中のOSSに関する項目を我々が作っていますので、間接的に関わっているという形になってます。

エンジニアへのエンゲージメントをどう見える化するか？

渡邊：はい、どうもありがとうございます。それでは、2つ目のご質問に行きたいと思います。「エンジニアへのエンゲージメントをどのように見える化しているのか、どのように活動しているのか、実際にやったことや将来やってみたいことが何かあればお聞かせください」というご質問です。こちら上野さんいかがでしょう？エンジニアさんのエンゲージメントのお話を最初にしていただきましたけれども。

上野：良い質問ありがとうございます。結局エンジニアにアンケートを取るくらいしかないかなということをOSPO内で話していますね。それを目標にしておきながら、なかなか数値で測るのって難しいよねという話をしています。

ただ実際にあった事例としては、メルカリの場合エンジニアの採用でもリファラル（社員紹介）というのをかなり重視しているんですけれども、あるエンジニアリングマネージャがエンジニアの全社集会で「メルカリではOSSの活動が活発なので、それを知り合いに紹介してアピールポイントとして使っては？」といったことを言われているのを聞いて、すごくありがたいなと、OSPOをやっていた甲斐があったなと、そう思ったことはあります。

渡邊：はい、ありがとうございます。ソニーさん、いかがでしょう？お願いします。

福地：エンジニアへのエンゲージメントというのが正しく理解しているかどうかわからないんですけど、社内イベントで事例をなるべく共有して、どうやったらうまくいったかとか、こんなふうにうまくいったみたいなものを共有することで、そこのリアクションを見る、とか、そういうのをやっています。あとアワードで良かったものを表彰したりとか、社内SNSのようなチャンネルでディスカッションする場みたいなものを作って、そこでコミュニティとして引き込んだりとか。

あと先ほどちょっと説明しましたけど、OSSライセンス委員会自体は代表者レベルでありますが、そういう場でいろいろな情報共有や議論をして、そこに引き込むことでそういうエンゲージメントを高めるといったことをやっています。

渡邊：はい、どうもありがとうございます。このエンゲージメント、結構大事なポイントではあるんですけど、なかなか見える化って難しいと思います。皆さんお悩みポイントだと思うんですけれども、ご回答いただいた内容が参考になるかと思います。

コントリビュート時の特許の扱いは？

渡邊：ではもう1つご質問いただきましたのでお読みします。「コントリビュートの手続き、特にコントリビュートに含まれる自社特許の抽出、自社特許があった場合の社内調整をどのように行っているのかご教示ください。自社特許の保護のため、コントリビュートを制限するのか？また、コントリビュートが優先されるのか、このあたりの線引きをどのように判断されているのか、合わせてご教示ください」とのことです。ソニーさん、お願いできますでしょうか？

佐藤：ソニーではオープンソースの取り扱いに関するテクニカルガイドラインが公式文書としてあるんですけど、その中でコントリビュートの手続きとかそういったものを規定しています。ソニーの場合はパーツレベルの特許がたくさんあって、このあたりは問題になるので一応ルールが決まっています。基本的にはその規定の中で、オープンソースを使ったりコントリビュートしたりすることとその特許を維持することの重要性について、知財を含めて議論したうえで可否をとる、みたいなプロセスになっています。

ただ、知財の方だけだと技術的な判断ができない場合もありますので、そこは先ほど「OSSボード」という、コントリビュートのための組織がありますという話をしたと思いますけれども、そこで「この特許が明らかにそのオープンソース単体で構成されるのかどうか」みたいな技術的なディスカッションをしたうえで、コントリビュート可能なのかどうかというアドバイスを、OSPOがしているという形になっています。

渡邊：なるほど、「最後はOSPOが」というところなんですね。

佐藤：いえ、アドバイスするだけなので、知財の重要度とかコントリビュートすることの重要度というのは、コントリビュートしたい当事者と知財とでちゃんと調整して判断いただきます。そして、然るべき人の決裁をとっていただくという形になっています。

渡邊：なるほど、ありがとうございます。実はですね、会場の皆様からのご質問はまだまだたくさんいただいている状況ではあるんですけれども、時間が迫っておりますので、質問はここまでとさせていただきます。ご質問いただきました皆様、どうもありがとうございます。申し訳ございません。

今後OSPOを立ち上げる方へのアドバイス

渡邊：では最後にクロージングということで、本日いろいろなお話を聞かせていただいたサマリーとして、今後に向けて何か一言ずついただければと思います。まず上野さん、お願いします。

上野：はい。最後に今後ということで、これからOSPOを立ち上げようとしている方へアドバイスを3つ記載しております（資料投影）。

私も知財なので、知財の方を想定しているんですが、1つ目は完璧を求めないということかなと思います。コンプライアンス系の仕事は、リスクをゼロにするのは難しいという認識です。今弊社のプロダクトでも膨大な数のオープンソースが使われていて、かつ、そのライセンスの法的な解釈は答えがない部分もあるので、リスクを完全にゼロにすることをめざすとコストにメリットが見合わないなと思います。ですので、最初から完璧を求めないという態度は重要なのかなと思います。

2つ目は手段的なところで、情報収集に関しては詳しい人に聞くのがおすすめです。OpenChainの話をしましたけれども、オープンソースコミュニティはコミュニティなので、コンプライアンスに関するノウハウや知識みたいなことは聞けば教えてくれる方が多いのでまず聞いてみるのがオススメです。

3つ目がツールと自動化の重要性ですね。1つ目とも関係するんですけど、OSSのコンプライアンスを人力でやるのは本当に難しいなと、無理なレベルだなと思います。なるべく自動化してツールに頼って、人が関わらないようにするというところを意識されると良いのではないかなと思います。

渡邊：はい、どうもありがとうございます。最後のツールのところに関しては明日のパネルディスカッションでも少し触れたいと思っているところですので、ご興味のある方は明日もご参加ください。それではソニーの福地さん、佐藤さん、お願いします。

福地：最初に、今日の話の概要を説明した資料として、実はOSSのイベントで喋ったものがありますので是非ちょっとこれをご参考になさってください（English/日本語(20分~)）。

今後の展望みたいなものを、いくつか喋らせてください。1つは、我々の事例もそうなんですけど、やはり各社のビジネスの状況だとか、技術の状況だとか、そこの状況に合わせてやっていくべきなのかなと思います。そのときにUSのOSPOの事例が全体的に先を行っているので、それを参考にしながら自分たちで何に取り込むべきかを考えていくのがいいのかなと思います。

あともう1つは、やはり同じレベルの会社や事例を知るというのが一番有効なんじゃないかと思います。上司を説得するのにも同じくらいのレベルの会社を見つけるのがすごく早道じゃないかなと。そういう意味で、上野さんも仰ってましたけど、コミュニティみたいなもの、あるいはOSPOのネットワークみたいなものができて、そこの中で共有しながら互いに切磋琢磨してどんどん日本のレベルを上げていけると良いんじゃないかと思っています。その一例としてOpenChainみたいな活動もいいんじゃないかなと思います。佐藤さんどうぞ。

各部門の相互理解が重要

佐藤氏：先ほどメルカリさんから「厳密を求めない」という話があったと思うんですけど、やっぱり知財とか法務の人と（エンジニアが）OSPOを組もうと思うと、エンジニアの方ってYes/Noで答えてもらいたくなってしまうんですよね。けど、基本的にそれはやってはいけないことで。エンジニア側は、いかに法務や知財の人に「リスクが少ない」と判断してもらえるか、そのための技術情報を出すか、というのが重要で、そういう視点でここ20年ぐらいずっと技術側の立場としてOSPOに参加しています。

そうすることによって、知財とか法務の人と友好な関係を築くことができて、例えば先ほど「コントリビュートするときに知財の判定どうするんですか？」みたいな話があったかと思うんですけど、あのような場面で技術的なところをかみ砕いていくと「あ、これって実は（特許を）踏んでないんですね」と判断されることが結構あるんですね。なのでOSPOって結局、知財系の人、それから法務系の人、オペレーションの人、そして技術者が、みんなでコミュニティとして運営していかないといけないものなので、お互いの相互理解が一番重要なんだと思うんです。

ストレートフォワードにそれぞれの立場でぶつかると課題があると思うんですけど、相互理解を作ることによって多分その課題は解けていくと思いますし、それぞれの上を説得するときにも、エンジニアの人は「知財の人や法務の人がこう言ってますよ」と言えますし、知財の人や法務の人たちも「エンジニアがこういうのが必要なんですって言ってますよ」みたいなことを言えて、お互いにうまく回せるようになると思うので、是非そうしていただければと思います。

最近うちのガイドラインをコントリビューション促進のために改訂したんですけれども、そこでもそういう議論をしたうえで、コントリビューションをよりエンジニアがしやすくなるように変更することができたので、その事例もお知らせしておきます。はい、以上です。

渡邊：はい、どうもありがとうございます。それでは丁度時間になりましたので、ここまででパネルディスカッションを終了したいと思います。パネリストの皆様、どうもありがとうございました。本日はご参加いただきまして、ありがとうございました。