1. クローズドソースから始
めるオープンソース
2017-05-23
Speee Cafe Meetup #07
大仲 能史 a.k.a. @onk

2. 自己紹介
• 大仲 能史 a.k.a. @onk
• 株式会社ドリコム スペシャリスト
• Railsエンジニア歴8年ぐらい
• ドリコムには開発ラインが十数本あるので
それらから共通化可能な部分をくくりだして
社内gemにする仕事をしています

3. 今日の話
• タイトル「クローズドソースから始めるオープンソース」
• すとうさんに怒られそうなタイトルなのであまりこの順番で話
したくないんですが（
• どのようにオープンソースの「障壁」を取っ払う文化を作って
きたかという話をします。

4. 前回のあらすじ！
• RubyKaigi2014でも似たような話をしました(by mitaku)
http://rubykaigi.org/2014/presentation/S-TakumiMiura

5. 前回のあらすじ！
• プロジェクトがいっぱいあると
https://speakerdeck.com/mitaku/rubykaigi-2014-gem-of-this-week

6. 前回のあらすじ！
• チェリーピック(orコピペ)が生まれる

7. 前回のあらすじ！
• 僕らはweb/ゲームという競争の激しい市場で戦っているので

8. 前回のあらすじ！
• 俊敏さを維持する必要がある！ (コピペはAgilityが足りない)

9. 社内gemという文化を作った

10. 社内gem
• geminabox gemを利用して社内gemサーバを立てている

11. 社内gem
• 5/23時点で173個
• aからzまで大体埋まるぐらい
• ドリコムの「d」から始まるgemだらけでキツい
• タブ補完を利かせるためには1文字目を変える方が望ましいという教訓

12. 社内gemが文化になるまでのアジェンダ
• 共通コードをgemにする
• gemを作る、アップデートすることが日常であることを伝える
• 誰もがgemを作れる、更新できる雰囲気を醸成する

13. 社内gemが文化になるまでのアジェンダ
• 共通コードをgemにする
• gemを作る、アップデートすることが日常であることを伝える
• 誰もがgemを作れる、更新できる雰囲気を醸成する

14. 共通コードをgemにする
• こんなのをgemにしました紹介
• komachi_heartbeat
• Speeeさんでも使われてるみたい？
• ヘルスチェックを行うMountable Engine
• dpoint
• 30分で導入できる仮想通貨システム
• client_app
• User-Agentをパースして、必要だったらApp Storeに飛ばすヤツ
• game_date
• ゲーム内では午前4時が日付変更線になってる的なヤツ

15. 共通コードをgemにする
• こんなのをgemにしました紹介
• gstb
• gistub(社内gist)に投稿するためのCLIツール
• 設定レスでgem installするだけで使えるよう、公開せず社内gemに
• capistrano-drecom-deploy
• ドリコムのインフラ事情に合わせたcapレシピ集
• drecomssh
• ec2ssh gem(mirakuiware)の社内版
• ホスト名が補完できるようになる
• komachi_foundation-drecom
• 社内標準のrails app template

16. 共通コードをgemにする
• 僕らの開発組織体制
• プロダクトと別に開発基盤部が存在
• 開発基盤メンバーがプロダクトに
アサインされることもある
• 横のつながりが担保され、共通部分に
気づきやすい
• 外でgemを作ってるメンバーが居た、
共通化して加速するのが当然だよねという
空気が先に存在した影響は大きい

17. 社内gemが文化になるまでのアジェンダ
• 共通コードをgemにする
• gemを作る、アップデートすることが日常であることを伝える
• 誰もがgemを作れる、更新できる雰囲気を醸成する

18. gemを作る、アップデートすることが日
常であることを伝える
• 毎週、全プロダクトのリードエンジニアを集めた共有会を開催
している
• 今後追加しようと思っている機能の報告や、トラブル共有等を
行っている
• 目的は車輪の再発明の防止と、人の振り見て我が振り直せ
• 事実・負債・挑戦＆見える化、横展開
• ツラみやドヤりの共有

19. gemを作る、アップデートすることが日
常であることを伝える
• 共有会のコンテンツに「今週のgem」というコーナーを作った
• 1週間の間に作ったgem、バージョンアップしたgemと
そのREADME、CHANGELOGを報告する
• 作者の顔が見えるし、作者が「めっちゃ便利なので入れてくだ
さい」とアピールする場になる
• 便利gemがプロダクトに取り入れられ、要望が上がってきて
バージョンアップして、バージョンアップ内容が次の共有会で
報告され、便利になったので別のプロダクトに取り入れられ
……という非常に良いループが回った

20. gemを作る、アップデートすることが日
常であることを伝える
• 量が増えたので、社内gemが偏在する
ようになった
• 社内gemのある風景こそが日常
• 普通に作るし普通に使う
• Gemfileがこうなっている→
source "http://gem.drecom.co.jp" do
gem "acts_as_mysql_partition"
gem "blue_pencil"
gem "client_app"
gem "client_version"
gem "compression_serializer-msgpack"
gem "dmaster"
gem "dpoint"
gem "dpoint_web"
gem "drecom-unicorn", require: "unicorn"
gem "drecom-unicorn-worker-killer"
gem "drecom_ldap"
gem "dsearch"
gem "egg"
gem "game_date"
gem "kpi-logger"
gem "lock_with_user"
gem "retryable_action"
gem "scatter_swappable"
gem "taboo"
gem "un_resource_list_info"
gem "una10_controller"
gem "unavro"
gem "unicorn-timeout_logging"
gem "unicorn_manager"
gem "user_id_tagged_logger"
end

21. 社内gemが文化になるまでのアジェンダ
• 共通コードをgemにする
• gemを作る、アップデートすることが日常であることを伝える
• 誰もがgemを作れる、更新できる雰囲気を醸成する

22. 誰もがgemを作れる、更新できる雰囲気
を醸成する
• drecom_gemというgemを作った
• drecom_gem gem [gem_name]で雛型作成
• rake drecom:releaseで社内gemサーバにリリースできる
• drecom_gemdiffというgemを作った
• gemdiffの社内版
• CHANGELOGに対して気軽にアクセスできる

23. 誰もがgemを作れる、更新できる雰囲気
を醸成する
• dcmdというgemを作った
• 社内gemに関するgemをまとめて入れられる
• コマンド体系を変更して覚える量を減らし、タブ補完が効くように
• drecom_gem gem -> dcmd gem generate
• drecomssh update -> dcmd ssh update
• drecom_gemdiff compare -> dcmd gemdiff compare
• awesome_releaseというgemを作った
• コントリビュータに感謝を伝えることができるgem
• octorelease gem(mizzyware)の社内版
• Issue/PRからCHANGELOGを自動生成できる
• Issue/PRに「vX.Y.Zでリリースしたよ、ありがとう！」とコメント

24. 誰もがgemを作れる、更新できる雰囲気
を醸成する
• drecom_gemを使ってgemをリリースするとリリース情報が全体
チャットに流れる
• 初めてのgemリリースのときはみんなで祝福する
• gemを作ってorアップデートして初めて一人前な空気になる
• 共通化チャンスを見つけたら新入社員に優先的に割り振る

25. 誰もがgemを作れる、更新できる雰囲気
を醸成する
• 更新したら使って欲しい
• gemはなるべく最新を使い続けるよう心掛ける

26. 誰もがgemを作れる、更新できる雰囲気
を醸成する
• gemicomという社内サービスがある
• gemnasiumクローン？
• どのプロジェクトが、どのバージョンのgemを使っているかを管理
• 最新バージョンじゃなかったら警告される

27. 社内gemが文化になるまでのアジェンダ
• 共通コードをgemにする
• gemを作る、アップデートすることが日常であることを伝える
• 誰もがgemを作れる、更新できる雰囲気を醸成する

28. 社内gemが文化になるまでのアジェンダ
• 共通コードをgemにする
• gemを作る、アップデートすることが日常であることを伝える
• 誰もがgemを作れる、更新できる雰囲気を醸成する
• これらを練習に適した場所で行いたい
社内のイメージ OSS界のイメージ

29. クローズドソースから始める理由
• ライブラリとして成立するまでの抽象化の壁
• ライブラリとして体裁が整っているかの心理的な壁
• これらの障壁をできるかぎり下げて、「ライブラリを作るって
難しそう」から「やったことがある」に遷移させる

30. これを許容する
• 社内のアウトプット量を最大化させるが、世界のアウトプット
量は最大化していない。まずはそれで良いんです
ベルセルク 24巻 三浦建太郎／白泉社
そ
れ
と
も
お
前
何
十
年
も
修
行
し
て
達
人
に
で
も
な
る
の
を
待
っ
て
か
ら
戦
場
に
出
る
つ
も
り
か
？
気
の
長
げ
ェ
話
だ
な

31. クローズドソースをオープンにする
• とはいえクローズドのままじゃなく、隙あれば公開したい
• 公開するキッカケ
• 辞めた人から「あれ欲しい」って言われる
• 社内gemを社外の自分のプロダクトで使いたい
• 懇親会等で「こんなのあればなぁ」という声を聞く
• Tech Blogのネタが尽きる
• これだけ（173個）あると、「月に1個必ずオープンにする
ぞ！」という上意下達もアリですね

32. 自分の管理対象のコードを広げていく
• 社内gemにPRを投げることに慣れたら、外のgemも社内gemと同
じように扱えるようになる
• Gemfileに加えた瞬間からフィードバックする義務を負う
• 覚悟を持ってOSSと相対していく

33. 外に出ていく障壁もできるだけ下げる
• 社内gemとはいえ、PRのdescriptionはしっかり書く
• 社内gemとはいえ、READMEやCHANGELOG、CIを完備する
• 普段からIssue/PR駆動の開発フローに親しむ
• 普段からGitHubのUIに親しむ
• OSSパッチ会の開催 (Inspired by OSS Gate)

34. OSSパッチ会 檄文
一般にスタートアップ企業はOSSの利用者であることが多く、積
極的に貢献することは少ないですが、営利団体が「使うだけ使っ
て何の貢献もフィードバックもしないフリーライダー」というの
は倫理観が少し欠如しているとみなされても文句を言えない状態
です。
実際、僕らは問題を見つけてバージョンを固定して凌いだり、モ
ンキーパッチを書いたりをしながらサービスを運営しているので、
フィードバックを「できるのにやらない」という、コミュニティ
に還元しない選択をしてしまっています。
この理由を解消し、ふつうの会社にしたいなと思ってこの会を企
画しました。

35. まとめ

36. まとめ
• ライブラリを作ったり貢献したりするまでの障壁は「ある」
• 障壁を下げるために手を尽くす。そのためのクローズドソース
• とはいえ、OSSが実は怖くないのも事実なので積極的に参加し
ていく
• 「この修正でとりあえず動くけど、正しいかどうか分からない
のでupstreamに投げるのが怖い」←正しくなかったら指摘して
くれるからええんやで
• 男は度胸！何でもためしてみるのさ きっといい気持ちだぜ