Androidエンジニアの平野です。

先日の社内LT大会で社内エンジニア向けに「オープンソース公開しようぜ！」という話をしたのですが、「実際のところどうなのよ？」といったあたりをもうちょっと突っ込んで解説します。

はじめに

リクルートマーケティングパートナーズでは2015年4月現在、iOS/AndroidのライブラリをGithubにオープンソースとして公開しています。本記事では下記について述べます。

• 現在公開しているオープンソースのライブラリについてかんたんに解説
• 組織としてオープンソースを公開する目的
• オープンソース公開する際の社内での手続き
• 公開してどうだっかと今後について

本記事の読者対象

本記事は組織としてオープンソースの公開をしたいがどこから手を付けたらいいのか悩んでいるエンジニアの方々に参考にしていただけたらと思っています。その上で組織としてオープンソースを公開する際の参考にしていただければ嬉しいです。また、すでに組織としてオープンソースを公開している場合でも、本記事を一つの事例としても読めると思います。

現在弊社で公開しているオープンソース

2015年4月現在、下記の4つのオープンソースを公開しています。

android-HeaderFooterGridView

AndroidのGridViewにヘッダーとフッターを追加できるライブラリです。料理サプリAndroidアプリの各種画面で使用しています。

• 【Android】ヘッダー/フッタービューつきのAndroid GridViewをオープンソースとして公開します
• recruit-mp/android-HeaderFooterGridView

RMPScrollingMenuBarController

iOSでSmartNewsやGunosyアプリのような1画面でタブメニューと画面の切替ができるライブラリです。タブ内の1つ1つの画面はUIViewControllerとして実装できるというイケてる設計です。料理サプリiOSアプリのトップ画面で使用しています。

• 【iOS】スクロール可能なメニューバーを持つViewControllerをオープンソースとして公開しました
• recruit-mp/RMPScrollingMenuBarController

android-RMP-Appirater

Androidでストアレビューをお願いするダイアログです。似たようなライブラリはすでに他のオープンソースでもありますが、それらでは料理サプリAndroidアプリで使う上での仕様を満たすことができなかったのでフルスクラッチで作ることになったのがこのライブラリです。

実際のところは仕様が変わってしまったのでフルスクラッチで作るだけの理由がなくなってしまったのですが、仕様が変わる頃にはライブラリとして出来上がってしまっていたので公開しました。

• 【Android】Android用のレビューダイアログライブラリをオープンソースとして公開します
• recruit-mp/android-RMP-Appirater

RMPZoomTransitionAnimator

iOSでPinterestのようなズームするアニメーションにするライブラリです。先日リリースしたばかりである料理サプリiOSアプリ 3.3.0で使用しています。

• 【iOS】Pinterest風な遷移アニメーションをオープンソースとして公開しました
• recruit-mp/RMPZoomTransitionAnimator

なぜ組織としてオープンソースを公開するのか

表向きの理由

ないしはマネジメント層にオープンソース公開を説得する際の理由ですね。

会社のリソースを使って作成した成果物をオープンソースとして公開する以上、マネジメントの人たちにオープンソース公開のメリットを説明して納得してもらう必要があります。そのための説得材料として

• リクルートマーケティングパートナーズのIT分野におけるプレゼンスの向上
• エンジニアの技術力向上、モチベーション向上

というのを主に上げました。また、ネット企業では国内海外を問わず自社ライブラリをオープンソースとして公開している組織も多いこともあわせて解説しました。

リクルートマーケティングパートナーズは分類上は大企業になりますが、「え？ リクルートってエンジニアいるの？」みたいなイメージが今のところ一般的です。本ブログやオープンソースを公開することで「内製開発やってんだぜ！」とか「オープンソースも公開しちゃうくらいイケイケなんだぜ！」ということをアピールすることで、IT分野におけるプレゼンスの向上を図るということになっています¹⁾実際これはウソではない。

加えて、在籍しているエンジニア達に対しても、オープンソースの公開を通じて技術力とモチベーションの向上につながるということも説得材料の1つにしました。

エンジニア向けの理由

とはいえ上記の理由だけではエンジニア達にとってオープンソースを公開するきっかけとしては弱いので、彼らに対してはオープンソースとして公開すると業務で開発したコードをプライベートでも使えるということを一応前面に推しています。

といいつつも、経験のあるエンジニアならばソースを公開することの意義と利点は自ずと分かっているため、「業務で開発したものをオープンソースで公開することができる」というスキームが存在することそのものがソースコード公開の理由になっているようです。

どのようなものを公開するのか

オープンソースとして公開する社内スキームを定めるにあたり、今のところ下記のようなものをオープンソースとして公開してもよいということにしています。このあたりは組織として公開する以上、しっかり決めておく必要がありそうです。

• 公共性の高い一部の機能をライブラリとして切り出したもの
• リクルートマーケティングパートナーズのサービスを利用してもらうために、有用と思われるツール
• ブログ記事で解説した技術のサンプルコード

オープンソースを公開するまでの社内フロー

組織としてオープンソースを公開する以上、公開までの社内フローは定めておくとよいでしょう。リクルートマーケティングパートナーズでのオープンソース公開のための社内フローは下記の通りです。

1. 事業側への確認
2. 起案
3. 採択
4. レビュー
5. 公開
6. ブログに記事を書く

1. 事業側への確認

公開するソースコードを利用しているサービスの責任者（具体的にはプロダクトオーナーと事業の責任者）に公開したい旨を共有し、承認を得ます。この承認については口頭による承認でもかまわない、としています。

2. 起案

公開するソースコードとライセンス形態を決め、上長に起案します。実際のところは、以下の二点を併せてメール一本投げる程度です。

1. 事業側への確認
2. 起案

なお、公開時のライセンス形態はプラットフォームの慣習になるべく沿った形のオープンなライセンス²⁾iOSならMIT、AndroidならApatch Licenseでしょうかを推奨しています。

3. 採択

社内の定例MTGで起案内容を確認し、エンジニア達の採択を得ます。変なものでなければ反対されるようなことはないです。実際は他のサービスに関わっているエンジニアに対するアナウンスといった感じです。

4. レビュー

公開するソースコードのレビューをします。公開するものは実際のサービスで使用しているコードが多いため、開発中にもレビューはしています。そのため公開の際に改めてレビューすることは少ないです。

5. 公開

Githubにリポジトリをプッシュします。公開内容はドキュメントやコメントを含め英語を推奨しています。また、CocoaPodsやMaven Central、Gemといった利用者にとって扱いやすい形で公開することも推奨しています。

6. ブログに記事を書く

公開したらブログの記事を書くことを推奨しています。必須ではありません。コードの作者とは別の人がブログ記事を書くこともあります。

実運用は

こうして見ると手間がかかるように見えますが、実運用としては

1. チームのメンバーに合意を取って
2. 関係者にメール一本出して許可もらって
3. 定例MTGでアナウンスし
4. 公開してブログ書く

だけという軽めのものになっています。許可を取る相手も必要十分に抑えているので、このフローを回すのに時間がかからないようにしています。

また、オープンソースを公開する際のサポートやフローの1〜3を代行する担当者も立てており、開発者が公開する際にリポジトリにプッシュするだけでいいようにもしています。

公開後の運用

公開後の不具合修正等のメンテナンスについては特に定めを作らず、必須とはしていません。現状公開しているものは弊社アプリにて実際に使っているコードでもあるため、メンテナンスは随時しています。ただし、アプリ開発時にもCocoaPodsやMaven Centralからこれらソースを取得しているので、不具合や機能拡張が生じた場合には公開しているソース側を修正しないといけない感じにはなっています。

また、プルリク等の対応をどうするかについては、「業務時間中に対応する場合は上長の許可を取ること」くらいの定めしかしていません。プルリク対応の義務はありませんが、業務で実際に使っているコードということもあってかエンジニア個人の判断で対応したりしています。

公開してどうなったか

公開したソースコードの品質が上がります

不具合報告やプルリクが来るライブラリもあるので、自分たちのアプリで使う場合には発生しない不具合の発見・修正ができています。ソースコードというのはその利用者の数に対し（ある程度までだとは思いますが）品質が比例する性質があるため、社内だけで利用するよりもいい感じに発展していきそうです。

いくつかのアプリに採用されているようです

こちらで捕捉している限りですが、いくつかのアプリにこれらのオープンソースが組み込まれているようです。うれしいですね。

はてブ100を超える記事も出てきました

本ブログのオープンソース記事で100ブクマを超える記事がでました！

• はてなブックマーク - 【iOS】スクロール可能なメニューバーを持つViewControllerをオープンソースとして公開しました

海外のiOSオープンソースライブラリ紹介サイトでも紹介されました

海外のiOSオープンソースライブラリ紹介サイトでも紹介されるライブラリがでました！

• Open Source iOS Component For Easily Adding A Neat Zoom In Animations To Your Views

インターンに来た学生にはウケます

インターンに来た学生にはウケます。

今のところリクルートグループの新卒エンジニア採用は、親会社であるリクルートホールディングスの採用でそこから研修後にグループ会社に配属という形になっています³⁾ちなみに新卒でも業務に耐えうる技術力を持っていると判断された場合は研修なしで即配属です。今年も4月付けで開発部に配属になっている人もいます。。

そのため、配属先になり得るリクルートのグループ会社の中でエンジニアには「リクルートマーケティングパートナーズに行きたい！」と思ってもらえることで、こちらとしてもいいエンジニアに来て頂けるというメリットがあります。

エンジニア個人のプレゼンスが増す

リクルートマーケティングパートナーズのエンジニアが個人でGithubにオープンソースを公開しているというケースも多いのですが、中には技量を持ちながらも「メンテナンスが継続できなくなるかもしれない」とか「飽きるかもしれない」といった理由などで個人での公開に踏み切らない人もいます。

そういう人にも組織のリポジトリでオープンソースやるとなると、個人でやるよりもメンテナンスが継続できる可能性が高まるといったこともあってか公開までの心理ハードルが下がるというメリットもあります。そうなると開発者の個人的なプレゼンスが増しますし、ついでに組織のプレゼンスも増すというWin-Winの関係になります。

今後について

ゆるゆるとやっていきたい

組織としてオープンソース公開に対する数値目標等は一切なく、エンジニアのやりたいようにやっているというのが現状です。
今後もこの状況を維持していきつつ、今後組織が大きくなっていった場合でも公開までのフローをこれ以上重いものにはしないようにしながら、今後もゆるゆると積極的にやっていけたらと思っています。

エンジニアの採用につながっていけば…と思っています

前述の通り「え？ リクルートってエンジニアいるの？」というのが一般的なイメージかと思います。
リクルートマーケティングパートナーズではいくつかのサービスを内製開発していますし、開発部隊も「オープンソース公開しちゃおうぜ！」と思い立ったら公開もできちゃうくらいにはイケイケではあります。本ブログや公開しているソースコードを通じて実際の雰囲気を感じていただければと思います。

• エンジニア採用サイト

ちなみにエンジニアの中途採用についてですが、一次面接は現場で開発しているエンジニアが対応いたします。ご自分のGithubで公開しているソースコードや技術ブログ等をお持ちであれば、応募書類に是非記載ください。記載いただければ、Githubのソースコードやブログ記事を現場のエンジニアが見ます。

開発者の皆様へ

ライセンス内での利用でしたらどんどん使ってください。そして気軽にIssueとかプルリクいただけたらと思います。日本語でおK。

さいごに

見ていただいたとおり、社内の決めごと自体はしっかりとやっていますが実運用としてはゆるゆるとやっています。
組織としてのオープンソース公開というといかにも重いものを想定しがちですが、その重さの前にオープンソースを公開できないよりも「それなりにでもいいからオープンソース公開してしまおうぜ」みたいな心持ちでやってしまうのがいいように思います。

この記事が組織でオープンソースをやりたいエンジニアの一助になってくれればと思うとともに、オープンソースを公開する組織が1つでも増えてくれたらうれしいです。