【Yahoo! JAPAN Tech Conference 2022】ヤフー・サイボウズ・ZOZOが語る、OSSへの貢献活動で得られたこと【イベントレポート】

世界をリードするAIテックカンパニーを目指し、ヤフーがどのような技術的な取り組みを行っているのか紹介する「Yahoo! JAPAN Tech Conference 2022」が2月3日〜2月4日の2日間にわたって開催されました。本レポートでは、ヤフー・サイボウズ・ZOZOの3社で展開されているOSS活動について語られた「個人や企業によるOSSへの貢献」のセッション内容を紹介します。

第2弾はこちら
【Yahoo! JAPAN Tech Conference 2022】ヤフー・MonotaRO・LIFULLが語る、組織におけるデータ文化の育み方【イベントレポート】

• keyboard_arrow_down ヤフー・サイボウズ・ZOZO。3社はOSS貢献にどのように取り組んでいるか
• keyboard_arrow_down OSSコミュニティとの共存・共栄に向けて大切にしていること
• keyboard_arrow_down OSS貢献活動に取り組む中で得られたこと
• keyboard_arrow_down パネルディスカッション

服部 典弘（ヤフー株式会社 、以下・服部）：ヤフーに限らず、サービス開発は多くのOSS（オープンソースソフトウェア）に支えられています。OSSを正しく理解し、OSSコミュニティに貢献していくことも必要不可欠。本セッションでは、皆さんの企業や個人としてどのようにOSSへの貢献を実践しているか、語っていただきたいと思います。

まずは、各社が取り組まれているOSSコミュニティへの貢献と、個人としての活動について教えてください。

武内 覚（サイボウズ株式会社、以下・武内）：私個人はストレージアーキテクトとして、次期インフラのストレージ開発や、ストレージ関連のupstream OSS開発を行っています。特に、分散ストレージCephのオーケストレータ「Rook」のメンテナンスを業務としてやっています。複業として、低レイヤーソフトウェア技術の書籍や記事を書いたり、YouTubeで動画を公開するなどの普及活動もしています。

サイボウズではOSS推進室が設けられており、OSSポリシーを策定し、社員のOSS活動をバックアップします。OSSをただ利用するのではなく、自社のリソースをもってコミュニティに還元したいという気持ちから、ポリシーでは、業務遂行中に見つかったOSSのバグに対して報告・修正をする「努力義務」を定めています。

また、社員の社外OSSへの参加をサポートしたり、毎年企業利益の一部を日頃お世話になっているOSSへの寄付も行っています。さらに、コミュニティの発展に役立つと思われる一部の社内プロジェクト、例えば私が今携わっている次期インフラ開発のプロジェクトなども、進んでOSSとして一般公開しています。

瀬尾 直利（株式会社ZOZO、以下・瀬尾）：個人の活動としては、RubyやFluentdといったOSSのコミッターを務めており、Rubyやデータ基盤関連のライブラリを多数自作しています。

ZOZO社では、社内に対してOSSポリシー・ガイドラインを策定しており、日常の評価制度に組み込み、OSS活動をポジティブに評価しています。OSSコミュニティに対する活動としては、自社OSSの公開や利用しているOSSへの積極的なバグ報告・修正、機能追加のコントリビューションなどを行っています。

テックブログにも書かせていただきましたが、弊社のOSSポリシーの特徴としては、個人のOSS活動にも業務時間を利用することができるというものがあります。また、OSSの公開にも注力しており、ガイドラインに準拠している限りは、公開時に会社側の許可を得る必要がないようになっています。

ZOZOは3年前まで、技術情報の対外公開が一切許されていませんでした。その局面を打開し、ZOZOをテックカンパニーにすべく、この3年でテックブログの執筆や社員のOSS活動を推奨してきました。OSSポリシーの策定によって、社員によるOSS活動が活発になってきたと感じています。

事例としては、内定者アルバイトのメンバーが入社前にOSSをつくって公開する事例もありますし、Kubeflow、gRPC、Reactなどの著名OSSへのコントリビューションを積極的に行うメンバーも増えてきました。

また、ZOZOは技術戦略上、運用を楽にするためにマネージドサービスを積極的に採用しています。なので、OSSのミドルウェアを自分たちでデプロイ・運用することは基本的にありません。そこは、ヤフー・サイボウズとの技術戦略の違いかもしれません。

服部：ヤフーにおけるOSS活動は主にOSSコミュニティに対する活動と社内向けの取り組みの2つに分けられています。

OSSコミュニティに対する活動としては大きく3つあります。1つ目はヤフーのサービス開発で利用したOSSに対して、バグの発見や機能の追加など、プロダクトへのコントリビューションを行っています。

2つ目は、日々の開発でお世話になっているコミュニティなどに対して、スポンサードといった形で金銭的な支援を行っています。3つ目は、OSSの開発初期に主体となる企業のほうに人員をアサインし、OSSの立ち上げをともにすることもあります。

ヤフー社内に対する活動としては、OSSを社内で活用するリスクを減らし、社員がOSSの貢献活動をする際に不安を感じないように環境整備を行っています。具体的には、OSSガイドラインを策定し、各OSSに関わる際のリスクや注意事項などを提示しました。また、コミッター活動を支援する「OSSデベロッパー認定制度」も設けています。

栗原 望（ヤフー株式会社 、以下・栗原）：「OSSデベロッパー認定制度」は、私がいま主に取り組んでいるApache Pulsarをはじめ、ヤフーが戦略的に採用しているOSSを対象としたコミッター活動の支援制度です。業務と直接関係ないOSS活動も、業務時間に計上することができるようになっています。また、カンファレンスやミーティングへの参加費用、開発環境整備のための物品ソフトウェア購入など、年間100万円の活動予算が与えられます。私も実際この制度を利用して開発用PCや関連書籍などを購入しました。

参考資料：Yahoo! JAPAN Tech Blog「ヤフーにおけるOSS開発・貢献がどのように行われているか」（2019/02/19）

私は現在「Apache Pulsar」というOSSを使って、ヤフーの社内向けにメッセージングプラットフォームの開発・運用を行っています。

個人としてもApache PulsarのPMCとして、プルリクのレビューや機能のリリース、メンテナンスなどを行っています。「Apache Pulsar」のクライアント言語にNode.jsがもともと用意されていなかったので、数年前にチームで開発して、オープンソースとして公開しました。また、テックブログの執筆やイベント・ハンズオンの主催など、日本国内をターゲットにしたApache Pulsarの認知拡大活動も行っています。

服部：次のテーマは、OSSコミュニティと共存・共栄していくにあたって大切にしていることです。OSS活動する企業側とOSSコミュニティ、それぞれの立場としてのお話を聞かせてください。

武内：企業としても、私個人としても大事にしているのは、「コミュニティの良き一員として振る舞う」ことです。

OSSコミュニティと一言で言っても、統一した文化があるわけではなく、ソフトウェアによって全然文化が違うんですよね。例えば、開発スタイル一つとっても、Linuxのように個人が独立で開発したものを集約していくコミュニティもあれば、デザインをじっくりとすりあわせてから実装するコミュニティもあります。それぞれの違いをきちんと認識して、自社のやり方を押しつけない、そこの文化に沿って行動する。それが最も大切だと思います。

もう一つは、先ほどOSSへの貢献の「努力義務」について話しましたが、それをやらねばならないと深刻に捉えすぎると、逆に通常業務を圧迫することになりますので、できる範囲でやることが大事だと考えています。

瀬尾：独自にカスタムしたものを社内だけで運用しないことは企業として重要だと考えています。それをやってしまうと、貢献にならないだけでなく、社内の技術負債となってしまうこともあります。

さらに、コミュニティとしては、情報の公開と公平性を大切にしています。自分が参加しているRubyコミュニティを例に挙げると、すべてのイシューやフィーチャーリクエスト、意思決定の記録やコミッターの開発者会議記録を全部公開していて、「オープンな場をつくる」ということを意識しています。

また、脆弱性のケアに関してはプライベートな報告の場所を用意するなど、ゼロデイ脆弱性にならないように気をつけています。

栗原：OSSはあくまでもオープンソースであり、企業の持ち物にしてはいけないということを心がけていますね。私が関わっているApache Pulsarには、Apacheソフトウェア財団が策定するApacheのポリシーがあり、そこでも、「一企業一ベンダーが支配することをしない」ことが繰り返し強調されています。

コミュニティの一員としても気をつけなくてはいけないし、貢献する企業側としても自社のためだけのプルリクは送らない。オープンソースとして見たときに、どんな価値があるのかを常に意識しています。

服部：続いては、OSS貢献活動に取り組む中で得られたことをテーマに、企業の視点と個人の視点から、それぞれお話いただきたいと思います。

瀬尾：積極的にOSS活動に取り組むことは、企業の技術プレゼンスの向上につながると感じています。それと同時に、社内のエンジニアの意識や技術レベルの向上にも寄与しています。

個人としては、著名なエンジニアが書いたコードをたくさん読むことで、技術レベルの向上に役立っていると思います。また、制作物をOSSとして公開するためには、社外の人にも汎用的に使える設計をすることが求められています。こうした汎化能力をOSSを通して身につけたと感じています。

さらに、コミュニティ活動などを通して、個人的なコネクションもできましたね。Rubyコミッターとして、著名なRubyエンジニアと仲良くさせてもらったり、ミートアップなどで技術談義が同じ目線でできたりするのは非常に楽しいことですね。

栗原：個人としては、英語力が上がりましたね（笑）。もともと英語があまり得意ではなかったのですが、開発、そしてより海外のコミッターとスムーズにコミュニケーションをとるために、英語のスキルが大いに身についたと感じています。

また、視野が広がったとも感じています。先程瀬尾さんのお話にもあった通り、修正や機能追加の際に、OSSにとって本当に価値のある修正なのかを考えられるようになりました。

企業として得られたのは、界隈のノウハウをいち早く入手できるようになったことでしょうか。主催したイベントに登壇する企業がどのような課題を抱えていて、どんなニーズがあり、どんな技術を使っているのかなど最新情報を入手しやすくなりました。

武内：企業としては、まずはエンジニアの採用力の向上につながっています。コミュニティへの貢献をブログなどで発信することで、サイボウズの技術力や取り組みをエンジニアに訴求できると思います。

技術者の意識と技術レベル向上に寄与しているのも実感しています。先程栗原さんが話された英語力を例にすると、社内のミドルウェアの開発をする場合、基本的に英語を使用するシチュエーションが少ないんです。ただ、OSS開発となると、英語を使って自分で情報発信したり、交渉したり、修正してコミットログを書かなくてはいけない。

OSS開発をすることで、世界と繋がっているという意識の変化も起きるのではないでしょうか。あと、結構皆さん英語母語話者ではない場合も多いので、あらゆる手段を駆使して意思疎通を図る面白さもありますね。

個人としては、交渉スキルを身につけられたのが大きいですね。様々なバックグラウンドを持った人たちが、いろんな目的で使うのがOSSの特徴でもあるので、説得して自分のやりたいことを実現しつつ、みんなのやりたいことも取り込んでいくことができるようになったかと思います。

瀬尾：確かに。ときどきOSSにプルリクエストを送ってもそのまま放置されてしまうこともあるかと思いますが、そこもマージしてもらうための粘り強さ・交渉能力が鍛えられましたね。

服部：ここからは、お互いに聞いてみたいことをざっくばらんに語り合いたいと思います。

Q1：コミッターを増やすことを考えているか？

栗原：ヤフーではコミッター人材を増やす取り組みが行われています。皆さんもコミッターを増やすことを考えているか、増やす場合はどういう戦略や方法をとっているかを聞いてみたいです。

武内：ここでいうコミッターはコミット権限のある人のことを指しているのでしょうか？

栗原：そうですね。

武内：コミッターを意図的に増やしたいとまではいきませんが、重要なコンポーネントであればコミッターを出すぐらいの意識で取り組むようにしています。例えば、Rookだけでなく、データの安定性を保つために、その本体であるCephのほうにもコミッターレベルの人を出していきたいと思っています。

瀬尾：現状ZOZOはまだ個人の努力に頼っている部分がありますが、もし企業を主体に取り組む場合、業務時間の大半を使っていいというポジションや支援制度をつくるのはいい方法だなと思って聞いていました。

服部：活動するための土台づくりは企業としての重要な役割ではありますね。

栗原：ハードルは高いかもしれませんね。ただ、プルリクを出すコントリビューターから少しずつ増やしていきたいですね。

Q2：OSS活動の中で苦労したことは？

武内：OSSは、通常の社内プロダクトの開発とは違う特有の苦労があると思います。これまでOSS活動の中で苦労したことや、失敗事例、それをどうリカバリしたかについて、お話を伺いたいです。

瀬尾：個人レベルで苦労した話というと、OSS活動を続けていくと、周りからも信頼が得られるようになってきます。すると、いろいろなことを任されるようになり、自分が持つOSSがどんどん増えてくる。1人ではまかないきれないほど多く抱えてしまったこともありました。その際、過程は大変でしたが、後任を探してペアプロで教えたりして、他人に自分のタスクを任せることをしていました。

栗原：OSSと社内で使っているものでバージョンの乖離が出てしまい、どうギャップを埋めるべきか今悩んでいる点ですね。

オープンソースはエンハンスが速いため、社内はそのスピードに追従したいものの、安定性を重視する必要があり、同じ速度で進化するのは難しいです。それで何個もバージョンが違うこともあります。バグが見つかるとその分パッチで取り込むなど、現状ではその運用がなかなか大変だと思っています。

安定性と最新機能のトレードオフ、どちらを重視するか、そのバランス取りが常に難しいと感じています。

武内：私の経験では、どちらかというと、OSSのほうがリリースが遅いことが多いですね。基本的に私のプロジェクトの開発は、必要なものを全部機能に取り込んでもらうし、バグも修正してもらう。それが全部upstreamに取り込まれたらその安定版を使うという仕組みになっています。リリースまでの間は、昔使っていた安定版に将来マージされるパッチを当てて使うようにしています。

逆にupstreamのほうが進んでしまって、バグ修正がネックになりそうな場合は、早めに最新の安定版を使うこともあります。

服部：瀬尾さんのほうで、upstreamと社内で開発速度の違いを感じたことはあるでしょうか？

瀬尾：マネージドサービスの場合、もっと汎化してバージョンを上げる頻度の話になると思いますが、それはZOZOの場合チームによって違いますね。新しいバージョンが出たらすぐに適応するチームもありますが、定期的にバージョンアップする時間を確保して対応しているチームのほうが多いのではないでしょうか。

Q3：OSS活動の可視化、評価をどうしていますか？

瀬尾：ZOZOは許可なくOSS貢献をしてよいというルールがあるため、誰がOSS貢献をしているかが見えにくくなっているという課題があります。皆さんは、社内のOSS活動をどのように可視化していますか。

武内：具体的にどれぐらい関わっているかは、正直把握できていませんね。成果評価のときに自らアピールしてもらう仕組みになっているんじゃないかと思います。

栗原：ヤフーも社員に自らアピールしていただくことが多いですね。評価の際に自身のコントリビュー数を書いてくれる人いますが、今の段階ではまだOSS用に評価制度をつくっていませんね。

Q4：プルリクエストを送る際の交渉術について

栗原：プルリクをマージしてもらうための工夫やコツがあったら教えていただきたいです。

武内：なかなか取り込んでもらえないときは、「状況を整理させてください」と一旦引き、どうすれば取り込んでくれるのかゴールを設定した上で、再度提案していますね。その際のポイントは、自分が出しているプルリクで問題を解決することにこだわらないこと。全然違う形でも目標さえ達成できたらOKとみなして、ワークアラウンドがないかを見つけたりすることも重要ですね。

瀬尾：私自身もプルリクを出してマージされるまで1年かかった経験がありますね。Rubyコミュニティの場合、関数名がMatz（まつもとゆきひろさん）のセンスに沿うか沿わないかのところもあるので（笑）、Rubyの開発者会議でMatzと直接話をしたりしています。権限のある人と直接話してみるのも、一つの方法だと思います。

服部：OSSを活用するだけでなく、OSSに還元する意識をぜひ持っていただきたいですね。OSS活動を通じて、エンジニアの個人としての成長にもつながっていきます。

では、最後に皆さんからOSS活動に取り込みたい、また興味があるエンジニアの方々にひと言メッセージをお願いします。

栗原：OSS活動をハードル高く感じている方も多いのですが、あまり考えすぎず構えすぎず、簡単なプルリクエストから出してみるといいんじゃないかと思います。そのプルリクエストが最終的にマージされるかは別として、コミュニティは常に人手不足。新たな参加メンバーを求めていますので、皆さんもぜひチャレンジしてみてください。

武内：自分が使っている、もしくは興味のあるプロジェクトから始めることをおすすめします。簡単なバグ修正から出してみてもいいと思います。

最初から肯定的な反応を期待せず、プルリクなりイシューを発行しても、無視されたり反対されたりするのは当然のことだという認識を持っていただきたいですね。社内・社外の詳しい人に聞いたり、相談するのもいいのではないでしょうか。

瀬尾：私も普段使っているプロジェクトからやってみるのがいいと思います。特にライブラリなどの新しいバージョンが出たら、ドキュメントを読んだりして差分を追うことから始めていくと、土地勘がついてきます。そういう形で少しずつステップアップしていくことをおすすめします。

文：馬場美由紀