Sider Blog

コードレビュー自動化サービス「Sider」を運営するSider株式会社のコーポレートブログです。

エンジニアが作りたいものを本気で作るための起業という選択肢。起業、Pivot、レビュー支援サービスSiderの着想から現在、未来

第一回:起業、Pivot、そしてコードレビュー支援サービスが生まれるまで

作りたいサービスに全力を投球したいとき、起業は一つの選択肢です。その選択肢をとった開発者として、起業に至るまでのプロセスから現在、そして今後について語りながら、私の経験談・失敗談をお伝えします。起業に興味がある開発者の方や、「社長」という役職の人について知りたい方、技術的な話に疲れてちょっと休憩したい方などのお役に立てればと思い書きました。この秋、Siderが初めてGitHub Universeにスポンサーとして参加することをきっかけとして、私が1人だけでコードを書いていたところから、書かなくなり、CEOとして会社という組織を引っ張っていくようになるまでの物語を、3週に渡りお伝えしていきます。本記事では起業からコードレビューサービスの立ち上げまでを、中編ではSiderの歴史、そして後編では私が成功と失敗から学んだことなどに触れていきます。

はじめに

まずは私を知らない方に向けて、簡単な経歴を含めた自身の自己紹介をさせていただきます。

私は、『Sider』というコードレビュー自動化サービスを提供しているSider株式会社の代表取締役です。TwitterGitHubではsumyapp というハンドルネームで活動しています。元々はプログラマーで、iPhone 3G時代(2009年)にiOSアプリの開発を始めたのがコードを書く始まりでした。Railsは2010年頃にiOSアプリのサーバサイドアプリケーションの開発と、卒業論文用のソフトウェアの開発で触り始めました。初めて触ったRuby on Railsのバージョンは2.3だったと記憶しています。

経歴としては、学生だった2009年から、フリーランスとしてたくさんのiOS/Android/Webアプリを提供してきました。
翌2010年には、Matzさん(まつもとゆきひろ氏)が技術顧問を勤める(楽天ではフェローと呼ばれる)楽天株式会社に入社し、社会人としてのスタートを切りました。2011年からはCyberAgent(Applibot)、 デジタルアドバタイジングコンソーシアム(DAC)などで新規事業立ち上げに携わり、それぞれ企画〜開発〜サーバ保守運用までワンストップで行いました。
その後、株式会社アクトキャットを創業しました。アクトキャットは2度の社名変更を経て、現在はSider株式会社として事業を続けています。

Siderとは何か

Siderはコードレビューを支援する、開発者向けのWebサービスです。GitHubと連携し、Pull Requestが作成されたタイミングでコードを解析、様々な問題を発見し、GitHubに通知します。結果、人がレビューをする前にSiderが問題を見つける(レビューをする)ことで、人のレビューの時間を節約することができます。

Siderは日本発の開発者向けサービスですが、弊社サイトを通じた直接販売だけでなくGitHub Marketplaceでも販売しており、アメリカ、インド、スイス、アイスランド、ベトナムなどをはじめとした世界中の国々で、コードレビューを楽に、より良くするためのサービスとしてご活用いただいています。海外への進出といえば、先日GitHub Satelliteが東京でありましたが、SIder株式会社は10月にサンフランシスコで開催されるGitHub Universeへもスポンサーとしてブースを出しています。GitHub Universeに参加される方は、ぜひSiderブースに遊びに来てください!

SiderとRuby on Rails

SiderはRuby on Railsで作られています。ファーストコミットでは4.0.1rc3が使われていました。
そのため、RubyKaigiには2016年、 2017年、 2018年と3年連続でスポンサー参加しており、メンバーも登壇(2017・2018)するなど、Rubyコミュニティと比較的近い位置で活動しています。また、Siderのお客様に最も人気のあるフレームワークもRuby on Railsです。
Siderは今後もRails開発者の皆様のお力になれるサービスを提供できればと考えています。

f:id:sideci:20180910163048p:plain
Gemfile(Git first commit)

読者の皆さんへ

今回私がこの記事を書くに至ったのは、2014年にSider(元SideCI)の提供を始めて4年間が経過しており、多少は話せることもあるだろうと思ったことがきっかけです。開発者っぽい仕事から、代表っぽい仕事に自分の職務が移り変わってきていて、それはそれで嬉しいような、悲しいようなですが、だからこそ話せることもあるだろうと思っています。恥ずかしながら、いくつかの成功と、それ以上の失敗がありました。それらを経ての振り返りをしつつ、今後、もっと世界中で使われるサービスを目指していきます。
おそらく、ずっと開発者でいたい、かつ開発者でいる予定である方には、多くの学びはないかもしれません。その方々には単に面白さを感じてもらえればと思います。
もしあなたが起業したい方であれば、開発者が起業する場合に役に立つ話になっていると思う(願う)ので、ぜひ役立ててください。何か質問があればお気軽にご連絡ください。
なかには自社の社長が嫌いな方もいらっしゃるかと思います。そういった方々が、少しだけ、社長という役職の人の人生みたいなものを知って、今後ちょっと優しい目で接してあげられるようになってくれると良いな、という気もします。
それでは、起業の話を始めましょう。

起業への道

ソフトウェア開発者であった私が起業に至ったプロセス、起業してから起こったことなどを時系列で紹介します。

そもそも、なぜ起業?

そもそもなぜ私が起業したかについて触れます。起業のメリットは「会社に縛られない」ことだと思います。
私は自分の手でなにか新しいものを作るのが好きです。「プログラミング」よりも「モノを作ること」が好きです。それを育てることが好きです。
会社で新規事業の立ち上げをしていた際には、自分ではどうしようもないように思える制約条件が多いように感じました。予算の制約、人の縛り(社内のこの人とやる必要がある、発注するならこの会社に、など)、テーマの縛り、時期の縛り(新規事業をするタイミングは上から降ってくる)。どれも新規事業を成功させるためには、1つでもあったら失敗するのでは、ぐらいの大きな制約条件です。
その制約条件を限りなく少なくして、作りたいものを作るためには、自分でより多くをコントロールできる、起業という選択肢が良いと考えました。

Pivot,Pivot,Pivot

リリースしたプロダクトは以下のようなものがあります。順番にお話していきます。

  1. お願いカンパニー 2012年(事業譲渡済み)
  2. カットモデルマッチングアプリ 2012年(事業譲渡済み)
  3. プロトタイプを開発しては捨てるの繰り返し & 受託開発
  4. StudyTech / Spath School 2013年
お願いカンパニー 2012年(事業譲渡済み)

起業自体は「なにか新しいものを自分の手で制約なくいい感じに作りたい、育てたい」という動機で始めたことなので、実は当初は、特に「これをやりたい」というものは決まっていませんでした。
なので、1つ目のサービスは、ヤフー知恵袋にポイントが付いたようなものを提供していました。これは自分的にはアプリ名が完全に黒歴史なんですが、「質問に答えてポイントが貰えるQ&Aアプリ、お願いカンパニー」というアプリです。

「質問に答えてポイントが貰えるQ&Aアプリ、お願いカンパニー」
助けて稼ぐ!お願いカンパニー:招待、恋愛相談、質問・疑問へ回答で簡単にこづかい・ポイントが稼げるアプリ - Appliv

ちなみにこれもRuby on Railsで開発しました。
iOSとAndroidは「ガワだけネイティブ」というやつで、Push通知の機構以外は完全にWebViewでした。技術的には何も難しいことはしておらず、技術スタックは言語系はRuby on Rails、 HTML、CSS、jQuery、Objective-C、Android Javaなど。サーバサイドはHerokuとMySQL(Herokuアドオン)でシンプルな構成でした。
2012年当時はたくさんのポイントサイトやアプリがありましたが、どれも広告主が同じで、ポイントを貯めることが難しい時代でした。ポイントという通貨を増やすためには広告主を増やさなければならない、でも広告を出す法人は限られている。であれば個人が出せるようにして、ポイントという通貨の流通量を上げていこう、という目論見で始めました。
一般的にはweb上で何か質問すると、ヤフー知恵袋などの大きなサイトだと回答がつくまでに結構時間がかかりますし、回答も数件程度です。しかし「お願いカンパニー」では質問にポイントを付与したことにより、1時間で数百件の回答が付くようなアプリに仕上がりました。
私は開発当初、以下のような方々がこのアプリを使ってくれると想定していました。

  • ポイントが欲しい、稼ぎたい人
  • 質問に答えてほしい人
  • ネット上で他者と交流したい人

事前の広告費を300万円ほど投下し、「お願いカンパニー」はサービス開始1週間ほどでユーザを数万人獲得することに成功しました。しかしアクティブユーザーは1000人程度にすぐ低下し、その後もどんなに新規登録があってもなぜかアクティブユーザーは1000人程度に戻ってしまう、けれど1000人程度より著しく下がることもない、という謎の現象が続き、結局「お願いカンパニー」を事業譲渡することに決めました。
結果としては、こういうことだったんだと理解しています。 f:id:sideci:20180910163754p:plain

カットモデルマッチングアプリ 2012年(事業譲渡済み)

http://www.cutty.jp/

こちらは今も継続してサービスが提供されています。
どんなアプリかというと、カットモデルを探している美容師と、無料で髪を切りたい人のマッチングサービスです。mixi社が提供している「minimo」に似たサービスです。

「課題解決型のスタートアップがしたい」と思って始めたビジネスで、美容師さんのカットモデルを探す労力は本当に大変そうだな、と思ったのがきっかけです。東京では、カットの練習をさせてくれるカットモデルを探している美容師さんを沢山見かけます。無料で髪をカットしたい人は沢山いるはずなので、マッチングさせようと考えカットモデルを探されている美容師さんにヒアリングを行うと、100名カットがノルマ、200名がノルマ、終電までカットモデルを探している、などの苦労を耳にしました。この課題は非常に大きいと考え、サービス提供を始めました。リリースに併せて、TechCrunch Tokyo Startup Battleにも出場するなどしました。 https://jp.techcrunch.com/2013/11/15/tc-tokyo-2013-startup-battle/

さて、これはリリース後に発覚したのですが、実はカットモデルを探す文化は、東京とそのほか一部の都市に限定されるものでした。私の義姉の美容師に聞いたところ、地方都市ではこの文化はないそうです。
カットモデルのマッチングは東京のみの文化であるため市場が大きくなく、マネタイズが難しい。また、競合企業・サービスも多く、当社で継続してこのサービスに注力するのは難しい。このように判断し、こちらも事業譲渡に至りました。

プロトタイプを開発しては捨てるの繰り返し & 受託開発 2012年〜2013年

この期間はいろいろなアイデアを考え、ヒアリングをし、物によってはプロトタイプを作りました。しかしそれらは、市場がちゃんとありそうか、課題が明確にあるものか、自分がそれに取り組みたいかなどによって、すべて廃案になりました。
この間の売上は受託開発によって上げておりました。当時ご依頼いただいた方々には大変感謝しております。

ここで廃案になったプロトタイプの一つをご紹介します。効果計測が可能なデジタルサイネージアドネットワークのプロトタイプです。iPhoneとディスプレイを接続し、ディスプレイに動画広告などを表示し、同時にiPhoneのカメラから広告を閲覧した人数や時間を、顔認識によって算出します。従来のサイネージ広告では効果計測が出来なかったり、広告の変更に時間がかかったりする(張り直し)といった課題があったところを、iPhoneとディスプレイのみで効果計測・リアルタイムの広告配信・サイネージ広告のアドネットワーク化を実現しようとしたものでした。

f:id:sideci:20180910163903j:plain
顔認識技術を用いたデジタルサイネージアドネットワークのプロトタイプ

これは今考えると悪くないアイデアですが、検討当時いくつかのヒアリングを行ったところ、サイネージを設置する場所の方や広告キャンペーンを企画する人たちの間にそもそも効果計測に関するニーズがないことがわかり、プロダクト化を断念しました。

StudyTech / Spath School 2013年

コンシューマー向けのアプリの博打性の高さが辛くなったのと、ちゃんと人の役に立つことをしたいという思いから、次はオンラインプログラミングスクールをはじめました。2013年のことです。
これらはOnlabの6期DemoDayでも発表させていただいたプロダクトです。

参加企業は2倍の成長を遂げるOnlabシードアクセラレータープログラム・第6期Demo Dayを行いました! - Open Network Lab (オープンネットワークラボ) 次世代の起業家育成を行うOpen Network Labでは、2013年5月14日(火)に第6期シードアクセラレータープログラムの集大成として、Onlab Demo Day Spring 2013を行いました。…onlab.jp

当時はProgateはなくて、CodecademyがSeries Bの調達(累計125万ドル、1.4億円程)といった時期です。日本のプログラミングスクールとしては、比較的早い参入タイミングでした。
当時の既存のプログラミングスクールは次のような課題を抱えていました。それは「プログラミングスクールはたくさんあるけれど教材ありきで、エンジニアの方が生きたプログラミングを教えてくれるスクールは少ない」ということと、「スクールに通ってもプログラミングを教科書通り教わるだけで、実際にモノを作れるスクールがない」ということです。

これに対し、私は「エンジニアが教える」「モノを作れる」ことを目指して事業を始めました。 実際にサービスを提供した結果、次のような課題を感じました。

  • 教材を買っても勉強を開始しない人が9割である
  • 残りの1割の方は初めてのモノ(Webサイト、アプリなど)を作れるレベルまで到達できるが、手間暇がかかり、スケールしづらい
  • 毎日ずっとコードレビューするのがつらい

結局、「教材を買っても勉強を開始しない人から得た売上を顧客獲得コストとして使う」、といったマーケティング主体のビジネスモデルであり、このビジネスモデルが個人的にあまり好きではなかったため、上記の課題と合わせて、事業撤退を決めました。
もちろん、広告ではなく口コミによってユーザを獲得できるようにする道もありました。しかしそれには非常に多くの時間がかかるであろうことが見込まれ、、また、教材を買っても勉強しない人の割合を変えることはほとんどできないだろうと考え、やはり事業撤退をすることにしました。

人生の迷子と転機

ここまで何回もプロダクトを作って、譲渡なり撤退なりをしてきて、次は何をするべきか、会社を閉じる選択肢も含めて検討をする中で、自分を見つめ直しました。2013年11月頃のことでした。しかし1人で考えても結論が出ないので、先輩起業家の方々に相談することにしました。

5人ほどに相談してみたところ(アルファベットは仮のものです)、不思議なことに全員が、旅を勧めてくれました。
そこで、ふらっとサンフランシスコに1人、人生探しの旅に出ることにしました。

旅の中で見つめ直した自分

2013年12月、サンフランシスコを旅しながら、自分はいったい何をしたいと思っているのかを考え直しました。また、課題解決型のスタートアップとして、自分が想像できる、解決したい、身近な課題を見つけるために、自分が今まで何に時間を使っていたのかも見直しました。

その結果、自分がこれまで何をしたいと思って、色々なことに取り組んできたかというと、その根底にあったのは「人の成長に貢献したい」という思いでした。学生時代には講師の仕事をしていましたし、Spath Schoolの事業もプログラミング教室でした。そして、これまで自分がどのようなことに時間を使ってきたのかを振り返ったとき、毎日1時間はコードレビューをしていたことや、そのなかで、コードミスには設計上の問題もあるが、インデントのずれやブラケットの閉じ忘れなどの初歩的なものも多くあったことを思い出しました。

コードレビューを通じて、人の成長に貢献できるもの。それが答えのように見えました。そこで私は、「コードレビューを支援する事業を作ることはできないか」と考えました。

渡米中にSideCIの元になるアイデアを思いつく

当初思いついたアイデア発議は次のようなものです。
「『こう書いたほうが良いよ』とコードに対して自動的にサジェストしてくれる、ルール(辞書)のようなものを作り、それをレビューに活かす、もしくはレビュー前に機械的に修正もしくは修正提案をする」

このアイデアは起業家向けのイベント、Incubate Campで「コードキャット」として発表されました。
http://thebridge.jp/2013/12/incubate-camp-6th-2nd-day

裏話としては、当初このサービスは「CodeMagica」という名前になる予定でした。しかし、とある有名な魔法少女アニメを連想させるとの意見がありボツ案となり、結局その時点での社名だったアクトキャットにちなんで、「コードキャット」と名付けられました。

ただしコードキャットはドメイン名などが取れなかったことから、.comドメインが取得可能で、短く覚えやすい名前として、すぐに「SideCI」という名前に変更を行いました。SideCIのネーミングの由来として、過去の社内ドキュメントで次のように記載しています。

SideCIの "Side" の意味

Sideはいつも開発者さんの隣でお力になれるよう見守ってます。何か間違ったことをしそうになったらそっとそれに気づかせたり、教えたり。逆に、皆さんから教わることも多々あります。Sideは教えてもらったことをずっと忘れずにいて、それを活かせる機会が訪れたら、また私はそれを開発者さんに気づいてもらうために使うのです。

CircleCIやWerckerCIさんなどは「開発者の代わりに」仕事をするために産まれたのかもしれません。SideCIは他の方とは違って、開発者の隣でお役に立てる、メンターのような、パートナーのような、同僚のような、そんな存在になるために産まれたのだと考えています。

その後、2018年6月にSideCIから「Sider」へと名前を変えることになりました。これらが2013年12月頃の、コードレビュー自動化ツール『Sider』の始まりの物語です。
2014年1月からはプロトタイプをともに、ユーザヒアリングに明け暮れました。

Siderが始まった後、どのようにコードレビューサービスのプロダクトを育ててきたかについては、次週9月20日に公開する中編でお話していきます。


あなたのチームの開発効率向上に!
Siderの自動コードレビューを14日間の無料トライアルでお試しください!

Sider スペシャルインタビュー ー RuboCopの生みの親Batsov氏に、RuboCopとRuby Style Guideについて直接聞いてみました

f:id:sideci:20180601192336j:plain (編集者より:この記事は、SiderのMediumに2018年6月28日に公開された英語記事を翻訳し、加筆したものです。)

Siderは、2018年8月よりRuboCopのスポンサーになりました。コードレビュー自動化サービスであるSiderを利用すると、さまざまなプログラミング言語や環境で、色々な種類の解析器をご利用いただけます。Siderではさまざまなオープンソースプロジェクトを活用しながらプロダクト開発を進めており、コミュニティへの貢献を大切にしています。このスポンサー活動を通して、RuboCopのさらなる発展に協力できれば幸いです。

今回はこれを記念して、RubyKaigi 2018にて実現した、RuboCopの生みの親である@bbatsovことBozhidar Batsov氏への独占インタビューの日本語版を公開いたします。SiderのCTOである松本宗太郎 (@soutaro) とRuboCopコミッターでありSirderの技術顧問のpocke (@pocke) の前で、Batsov氏はRuboCopやRubyスタイルガイドに関するご本人の考えを、とても気さくに語ってくれました。 

RubyスタイルガイドからRuboCopができるまで

Soutaro:
最初に、RuboCopの開発に至るまでの動機について聞かせてください。RuboCopを通じて、どんな問題を解決しようと思われたんですか?

Bozhidar Batsov:
私は、Rubyで開発するようになる前はJavaで開発をしていました。Javaも色々な問題があるものの、Java用の良いLintツールが沢山あります。以前わたしの勤めていたのはコンサルティング会社で、様々なプロジェクトに取り組んでいました。チームメンバーはプロジェクト間を行ったり来たりする必要があり、全てのプロジェクトに対して統一されたコーディングスタイルを持つことが非常に重要でした。そうしないと、プロジェクトを異動した際に「あれ、このチームではこのやり方だけど、あっちのチームでは別のやり方だったぞ」というように、混乱してしまいます。

仕事でRubyを扱うようになって最初に取り組んだ問題は、統一されたコーディング規約を作ることでした。Javaではこういう問題はありませんでした。Sun公式のコーディング規約や、非公式だけど人気があるGoogleによる規約などがあり、皆がそのどちらかを利用していたからです。コードベースも一貫していたので、プロジェクトの移動もとても簡単でした。「タブとスペースどっちにする?どこに括弧つけるんだっけ?」みたいな話は滅多にしなくてよかったので、楽でしたね。

それから、ある企業でRubyの開発者として新しい仕事を始めたのですが、Rubyが分かるのは私一人だけでした。その会社は、ブルガリアで二番目にRubyを企業として利用した会社で、沢山のプロジェクトを作ろうとしていましたが、その頃はまだRubyは広く使われているプログラミング言語ではなく、開発者はそれぞれが違う言語のバックグラウンドを持っていました。10年以上前の話ですね。チームのメンバーは優秀でしたが、みんなPHPやPython、Javaの開発者でした。なので、コードレビューの半分は、Rubyの基本的なスタイルの問題の指摘でした。

そこで、まず私は社内用に、Matzの本やピッケル本などを参考にしてRubyのスタイルガイドを書きました。良いとされているものを全て盛り込みました。本によっては違うスタイルを推奨していたので、自分で判断をする必要もありました。いくつかの有名なプロジェクトのコードも参考にしました。Railsのコーディング規約は参考にしませんでした。かなり独特で、Rails開発者ですらRails以外ではそのスタイルを採用しないことがあるからです。

その後、Ruby Style Guideの最初のバージョンが出来上がり、公開を決めました。そうしたら人気が出て、フィードバックを色々もらうようになりました。あるチケットには「これ、すごく良いんだけど内容が多すぎて全部のルールを覚えられないから、PythonのPEP8みたいにスタイルガイド文書とそれを検査できる公式ツールがあったらいいのに。」というコメントがありました。そこで、やってみようと思ってRuboCopの開発を始めて、今に至ります。これが動機でした。

Soutaro:
スタイルガイドが長すぎて、自動でチェックできるツールが必要だったんですね。

Bozhidar Batsov:
そうです。RubyのコミュニティにはそうしたガイドやLinterがないことにびっくりしました。こういうことをやりたかった、というより、やらざるを得なかった。その頃にもスタイルガイドは不完全ながらいくつかありましたが、Linterは非常に原始的なものばかりでした。

Ruby 1.8から1.9への移行を覚えている人がどれくらいいるかわかりませんが、ほとんどのLintツールが構文解析にSeattle.rbのruby_parserを使っていました。そして、ruby_parserの1.9対応には時間がかかっていました。これが、初期のRuboCopがRipperを使っていた理由です。Ripperも大変でしたが、1.9で動くのは本当にそれしかなくて、ものすごく辛かったです。1.8から1.9への移行は、当時いくつかあったRubyのLintツールにとって逆風になったと私は考えています。

コミュニティがRuboCopを育てた

Soutaro:
今、RuboCopはとても人気ですよね。最も使われているRubyのLintツールの一つだと思うのですが、RuboCopが人気になったマイルストンはありましたか?

Bozhidar Batsov:
まあ、私がとてもチャーミングだから皆が信じてくれたのかな、と(笑)。冗談はさておき、(RuboCopができる以前はこういうツールが存在せず)皆が必要としていたので、最初にツールを作った人が人気になるような、言わば真空状態のような状況だったんだと思います。当時はここまではっきり思いませんでしたが、今はそう確信しています。沢山の人が全然機能がない初期のリリースを熱烈に歓迎してくれましたし、リリースの度に発生する破壊的な変更を受け入れてくれました。新しい機能を追加するたびに、誰かのビルドが壊れていました。おそらくご存知だと思うんですけど。とにかく、誰かが埋めなきゃいけない穴があったんです。そして、RuboCopがその穴を埋めた。もしそうでなくても、次に出てきた別のLintツールがその穴を埋めていたと思います。だから私たちが特別な何かを作ったとは思っていません。もし何か特別なことがあったとしたら、わたしがコミュニティからのフィードバックを積極的に受け入れたことだったのかなと思います。

私はRuboCopをそこまで柔軟なものにするつもりは全然ありませんでした。Rubyスタイルガイドが守られるような何かが欲しい、とは思っていました。皆さんが抱えているユースケースの多くは私が当初は想像しなかったものでした。プラガブルなアーキテクチャを設計したり、設定を継承できるようにすることなんて考えてもいませんでした。初期バージョンはスタイルガイドを守るためのものだったので、設定は存在しませんでした。

コミュニティと連携したことと、たくさんの人が助けてくれたことが、私たちの成功の秘伝のタレなんだと思います。一人で大きなことをやり遂げることはできません。RuboCopの成功に大きく貢献してくれた人は、少なくとも10名はいます。これは本当に重要なことです。チームが無くては、そしてコミュニティが無くては、どんなことでも絶対に成功できないからです。

bbatsov自身のRuboCopの設定とは?一貫性は個人の嗜好よりも大切

Soutaro:
ありがとうございます。次の質問に移ります。 ご自身のチームでもRuboCopを使ってらっしゃるんですよね?

Bozhidar Batsov:
もちろん。

Soutaro:
チームでのRuboCopの設定はどんな風にされてますか?デフォルト?

Bozhidar Batsov:
いや、デフォルトではないです。全然違います。

私はToptalのVP of engineeringなのでデフォルトを使うよう指示することもできますが、民主主義を重んじる上司として、チームの皆に投票をしてもらって決定を委ねています。ただ、色々な困難もありました。

うちの会社では、Ruby開発者が「スタイルガイド更新会議」なるものを6か月ごとに開催して、そこでオフィシャルのRubyとRailsのスタイルガイドからフォークする作業を行っています。チームが小さかった初めの頃は私も会議に参加していたんですが、議論がとても白熱していてたので、干渉しない方が良いなと思い直しました。この会議では、どのルールを見直したいかアジェンダを作って投票をするのですが、一部の開発者は熱が入るあまり偽のアカウントまで作ってチートしようとした人もいましたね。40名が参加した会議に、60票の合計票が集まってびっくりしたことがありました(笑)。

たくさんの方がRuby Style Guideが私個人の嗜好を表していると思っているようなのですが、これは事実とはかけ離れている、ということを胸を張ってお伝えします。私個人としては真逆の意見を持っていて、一方で大勢の方が良いアイデアだと考えていてRubyのコミュニティで広く使われているような、そういう項目もあります。私はそれで構いません。

このインタビューの前に、 SiderのMatz氏松田明氏とのインタビュー記事を読んだのですが、Matz氏もRubyのスタイルガイドの中の多くの部分に同意してはいないと言っていたのが興味深いなと思いました。具体的にはどの部分なのか、ぜひ聞いてみたいですね。皆が喜ぶようなものは作るのは不可能だし、どこかで妥協をしなければいけない、と私は思います。最終的には、自分自身が何に同意するかよりも、何かに同意したら一貫してそれに従うことのほうがずっと重要なことでしょう。

一貫性というのはスタイルです。主観的には、良いスタイルとひどいスタイルがありますが、スタイルというものに意識を向けて、一貫した形の中で作業することの方がもっと大切なことだと思います。この考えに同意しない人がいることは知っています。「インタプリタがコードを受け付けるのであれば、もうそれで十分。コードの挙動だけ気にすれば良い」と考える人もいます。ですが、このことで誰かが行った仕事やオンボーディングプロセスなどが妨げられているのを日々見ていると、やっぱりそれは想像上の問題ではないことが明らかだと思います。これは実際に起こっている問題なのです。現状、Rubyの内部コードはぐちゃぐちゃなので、新しくコミッターになりたい人が貢献しにくくなっていると思います。「こっちのファイルみたいに書いたらいいのかな?それともこっちかな?どうしたらいいんだろう?」みたいに、結構な時間をかけて悩んでしまうと思うんですよね。 この定まらない部分を無くしていくことで、皆がやらなければいけないことに集中できて、魔法が起きるんじゃないでしょうか。

f:id:sideci:20180601190758j:plain

RuboCop 1.0 のロードマップ、そして新しいオーガニゼーションのゴールとは

ここで、同席していたSiderの技術顧問でありRuboCopコミッターであるPocke氏が、RuboCop 1.0についてBatsov氏について質問しました。

Pocke:
昨日(編集注:2018年5月31日)のRubyKaigiの発表で RuboCop 1.0について話してらっしゃいましたが、私は最後までお話を聞けなかったので、 RuboCop 1.0のロードマップについて詳しく聞かせてくれませんか?

Bozhidar Batsov:
ロードマップはまだ確定したわけではないのですが、RuboCop 1.0の一番大きなマイルストンは、Railsの機能を別のgemに抽出してrubocop-railsと命名することになるでしょう。まだ考えているところですが、おそらくパフォーマンスの機能も、MRIのバージョンに強く依存するので、別のgemに抽出することになります。正確に問題を検出できれば価値のあることだと思うのですが、人々を誤解させるようであれば、価値あるものとは言えないでしょう。Performance copについては、適用されるMRIのバージョンを指定できるようにするつもりです。それぞれのCopがMRIのどのバージョンで有効で、または無効なのかを指定できるようにして、一目で理解できるようにする。つまり、RuboCopのスコープを減らし、よりモジュラーにする必要があります。

拡張機能を作りやすくするために、より良いAPIを作る必要があります。今はちゃんと定義されたAPIが存在しないのですが、これは大問題です。RuboCop拡張のgemを持っている人が皆「これは多分publicで、これはprivate」と推測しなければいけないような状況はまずいですね。なので、良いAPIを作って、コミットしメンテナンスしなくてはいけません。そうすれば、RuboCopがあんまり壊れなくなっていくのではないでしょうか。

もう一つの1.0に関する問題は、安定してアップデートができるようなメカニズムです。RubyKaigiでも話した私の簡単なアイディアは、それぞれのCopに対して有効・無効の他に、もう一つステータスを追加することです。ここでは仮に“new”と呼びましょう。新しいバージョンのRuboCopを使い始めたときに、ステータスが“new”のCopが存在する場合には警告を出します。つまり、「ステータスがnewのCopが10個あります」というメッセージが表示されます。。そして、有効にするか無効にするかを決めるとこれらの警告が消えるようにするのです。すごく単純な機能ですが、アップグレードの煩雑さをぐっと減らしてくれると思います。それから、breaking changeが何かという定義をする必要がありますね。例えば、あるCopのデフォルトを変更することはbreaking changeなのか、non-breaking changeなのか。おそらくこれはbreaking changeだとは思います。breaking changeはメジャーバージョンアップでしか起きないようにしないといけません。

もう一つ1.0に期待することには、node matcherエンジンをRuboCopから抽出しプラガブルにすることがあります。Stripeの人が、C++でマッチャーを実装するアイディアを教えてくれたんですが、むちゃくちゃ速くなりそうです。彼らはRuboCopをprofileして、node matcherをC++で実装したらRuboCopが10倍速くなると言っています。これが本当かどうかは検証する必要がありますけど、教えてくれた方達のバックグラウンドを考えても、多分本当だと思います。これは、そこまでではないけど、重要なことですね。

そして、今後の全体的な一貫性を保証するために、私たちは、既存のCopの名前や設定を慎重に見直さなければいけません。全体のコードベースを通して名前に一貫性をもたせて、後になって名前を変更して回るような必要が生じないようにしたいのです。

また、デフォルトの設定についても、実際に皆さんに役立つものであり、変更しなくて済むようにしていく必要があります。GitHubのBigQuery APIを使ってRubyプロジェクトを検索するとか、昨日(RubyKaigi 2018のトーク)でお見せしたGemを使うとか、そういうことをやろうと考えています。正直に言って、私はどういうデフォルト設定が良いのか判断ができないので、こんな方法でやるのがいいでしょう。今のデフォルト設定は私にとっては理にかなったものですが、明らかに私の判断は偏っています。

今お話したようなことが主要ポイントになるかと思います。巨大なロードマップを1.0には持たせたくはないですね。数ヶ月内に実際に達成できるような何かを提示したいです。現実的には、Railsとパフォーマンスの分離だけが厄介な点だと思います。それでも、rubocop-rspec みたいな gemが既にあるわけで、似たようなことができるでしょうから、ものすごく面倒というわけではありません。

プロジェクトへの導入を補助するような機能があってもいいですね。初期設定時に、より賢い設定を生成するとか。これで、現行のものを置き換えられるかもしれません。

それから、マイナーなバージョン間で設定のmigrationが必要なくなるといいなと思っています。つまり、メジャーバージョンアップでのみ設定ファイルの修正が必要になるような形です。そのためには、より安定した開発サイクルにコミットすることになります。1.0の大事な部分はこんなところだと思います。

Pocke:
ありがとうございます。もう一つだけ質問があります。昨日、RuboCopのレポジトリーをbbatosvからrubocop-hqに移動しましたよね。このオーガニゼーション (rubocop-hq) は、rubocop-jp/issuesを移動するとか(編集中:2018年6月に移動済)、いくつかの目的があると思うのですが、オーガニゼーションの運用計画など、他にもあれば教えてください。

Bozhidar Batsov:
このオーガニゼーションのゴールは、コアのRuboCopに関連する活動全ての中心になることです。より大きなチームを私たちが作りあげていけたらと思っています。できれば、異なるプロジェクト間でより大きな同期ができるようにしたいですね。なぜかというと、現在RuboCopの拡張を書いてくれている人のことを、私はほとんど把握できていないからです。rubocop-rspecの人のことは多少知っています。一番大きくて複雑な拡張だから。でもRuboCop用のRuby gemを検索したら189個もあって、本当にびっくりしました。PockeさんのMryGryなどのgemも実際こうして見つけたんですけどね。RuboCopで一緒に仕事をしていても、これらのGemのことは知らなかった。古いgemの中にも、便利だけどメンテナンスされていないものがありますよね。

なので、情報の中心となるものがあれば素敵ですね。例えば、guard-rubocopのアップデートについて尋ねる人をよく見かけます。開発者であるYuji Nakayamaさんは忙しくて時間がないそうですが、でも彼がこのプロジェクトを移管してくれたら、rubocop-hqの中でメンテナンスしていけるかなと思います。私は皆さんにRuboCopはRubyコミュニティー全体のものだし、スタイルガイドも然り、ということを分かってもらいたいんです。これは既にわたしの個人的なプロジェクトではありませんし、もう長いこと、そういう状況だったと思います。これほど多くの方が使っていて、たくさんのことを行う必要があるならば、これはやはりコミュニティのものでしょう。

f:id:sideci:20180601191145j:plain
左 Bozhidar Batsov氏 右 Pocke氏

Siderの可能性

Soutaro:
弊社のサービスSiderをご存知だといいんですけど。Siderやコードレビューを行う他の同様のサービスが、RuboCopを使用する事でどうコードレビューを改善していけるか、Batsovさんの意見を聞かせてくれませんか?

Bozhidar Batsov:
この質問は「RuboCopがSiderなどのサービスに対して何ができるか」という意味でしょうか。Siderのようなサービスの価値は疑いようがないですが、エンドユーザーの役に立つにはその土台となるツールが必要です。

初めの頃は、重複した作業がたくさんありました。解析となると皆が自分のやり方でやっていて。でもここ数年は、RuboCopなどのツールやライブラリを内部で活用することに皆さんが賛成してくれるので、私は満足しています。つまり、サービスはエンドユーザーエクスペリエンスに注力するようになり、車輪を毎回再発明することをしなくなりました。

私の働く会社では、たくさんの同様のツールを使用しています。RuboCopに関しては、実はGitHubとの独自のインテグレーションが存在します。巨大なコードベースがあるので、我々の望むほどには簡単に移行ができないのです。実際、私たちが一緒に作業するようになるまで(※PockeがRuboCopコミッターになるまで)は、Siderについては知りませんでした。

ある意味では、RuboCopが必要な物を全て兼ね備えた良質なCIを提供できるようなところまで行くといいなと思っています。Siderにとっても、これをどうやって見せていくかというだけの問題になっていくでしょう。Siderのようなサービスに対して、RuboCopがプロファイルのサポートを提供していたら良いだろうなって考えていました。

デフォルトのスタイルが好きじゃなくてカスタムしたものを使いたければ、「GitHubのプロファイル」や「Stripeのプロファイル」を実行したい、というように設定するんです。これはそんなに手間がかかるものではない、数時間でできるんじゃないかな。エンドユーザーにとってすごくありがたいと思いますよ。設定の中にドロップダウンメニューがあって、魔法が起きる。たくさんの人に設定を色々いじる必要があって始めにくいとよく文句を言われますが、こちらがたくさんの設定を予め用意しておいてあげられたら、素晴らしいでしょうね。私は、これはSiderのようなサービスがやるべきことだと思っています。RuboCopではなくて。RuboCopはプロファイルの読み込みに対応する機能を提供し、各サービスがプロファイルを提供する。

それから、誰かが設定のヒエラルキーやオーバーライドを使用している場合、CIやUIがこれを表示してくれるようになると良いですね。いろんな人が違う.rubocop.ymlを別のフォルダに入れては忘れてしまうので、あのフォルダではこのオフェンスが検出されるのにこっちでは検出されない、なんてことが起きたりすることがよくあります。バグの報告を見て、「いくつ.rubocop.ymlがあるんだろう?」なんてこともあります。

inclusionexclusionsも同じです。ユーザーが何かを間違えた際に、「このinclusionで合っていますか?」なんて聞いてくれるUIを表示できたらすごく良いなと思います。exclusionsでも良いんですけど。最近、「RuboCopが.rb ファイルの処理を止めてしまった」というチケットがありました。これはまあ、file includesの中に*.rbがないからなんですね。RuboCopはこの警告をすべきなのかもしれませんが、ただの設定だし、ユーザーが設定を間違えただけなので、しないほうがいいでしょうね。

でも、Siderは、そうした部分を手助けできるのではないでしょうか。

わたしはそんな風に我々の関係を見ています。Siderのようなサービスには、ユーザーを喜ばせるために必要なものを教えてもらう。私たちがその基礎を一緒に作る。そして、Siderは、それを活用するための方法を共有し、Rubyの精神に乗っ取り、人々を喜ばせ、生産性を上げていく。

f:id:sideci:20180601190426j:plain

RuboCop 初心者へのアドバイス

Soutaro:
RuboCop ユーザーや、これからRuboCopを使おうとしている人たちに、コメントやアドバイスをお願いできますか?

Bozhidar Batsov:
マニュアルを読んでください (一同笑) 。私に寄せられる質問の多くや、バグレポートの多くはだいたいマニュアルの中に記載されているんですけど、誰も読んでないんです。

Copについての説明や、何が設定できるのかなど、もっと皆さんに読んでもらいたいですね。設定をいじれるCopがただ無効にされていて、使い方をわかってないんだろうな、という状況をしょっちゅう見かけます。様々なスタイルが設定できるCopなのに、単に無効にしておいて「これの一貫性には気を配らないのか」と言う。非常に問題だと思います。もし、個人や企業でRuboCopを使っていてCopを無効にする際には、.rubocop.ymlの中に説明を残しておいてもらえるとすごく助かります。私や他のRuboCop開発者は、GitHubを検索して何を改善すべきか洞察を得ているので。何も説明が残っていなければ、それが報告されていないバグなのか、何かよくわからないことがあって手助けが必要だったのか、私たちにはわかりません。ドキュメンテーションは完璧からは程遠いですが、そこまでひどくはないと思います。皆さんが少しだけ時間を投資してくださると、ものすごく助かります。

もう一つ、もっと多くの方に提案したいのは、「プロジェクトがそんなに大きくないのなら一気に直してしまう」ということです。警告を一度に全部修正してしまって、「この場合は警告だけどこっちの場合は出さない」というふうな複雑な設定をすることに時間をかけないほうが良いと思います。私の意見では、チーム自体にとっても、コードベースを一度にまとめて綺麗にするほうが良いと思います。コードが10万行以下のコードベースなら、みんなで集中すれば一日か二日で修正することができます。私たちToptalのようにたくさんのRubyプロジェクトとレガシーコードを残念ながら抱えている場合は、もう少し時間がかかると思います。でもそれですら、私たちも最後にはきれいに片付けることができました。違うコードスタイルをずっと切り込み続けることはできないと思います。いずれ、どこかで線を引いて「これはやめた」と言わなくてはならなくなるでしょう。私からのアドバイスは以上です。

Soutaro:
ありがとうございます。最後に、日本のユーザーに向けて、コメントをいただけないでしょうか。

Bozhidar Batsov:
そうですね。日本のユーザーのからの応援は、本当に嬉しいです。最も活発なコミッターの何人かは日本人ですし、もっとたくさんの日本のプロジェクトとか、オーガニゼーションなどに繁に参加してほしいです。日本はRubyコミュニティの中心ですし、RuboCopコミュニティの中心にだってなり得ると思います。

どんな形でもいいので手伝ってもらえることは本当に大歓迎です。日本ではシャイな人が多いようですが、私たち皆、気さくな人の集まりです。Genadi氏が言ったように、ブルガリア人はスラブの楽園に住んでいるので、ハッピーで、ウェルカムな人たちばかりですよ。

Soutaro:
あらためて、あたたかいコメントどうもありがとうございます。

Bozhidar Batsov:
嬉しいです。ありがとうございました。

f:id:sideci:20180601193344j:plain

インタビューのあとで、RuboCopコミッターでありRubyKaigiに登壇もしている伊藤 浩一氏も交え、夕食を一緒にとりました。おいしいお酒とともにRuboCopの話をできて、楽しい夜になりました。

f:id:sideci:20180905174440j:plain

Batsovさん、どうもありがとうございました。また日本でお会いできることをSiderメンバー一同楽しみにしております!


あなたのチームの開発効率向上に!
Siderの自動コードレビューを14日間の無料トライアルでお試しください!

8月分の解析ツール更新を行いました

Siderは毎月解析ツールのバージョンを見直しております。このたび、8月分のバージョンアップデートを行いましたのでお知らせいたします。

現在のバージョンについてはドキュメントもあわせてご確認ください。

なお、RuboCop, ESLint, stylelintに関しては、それぞれ任意のバージョンをSider上で動作させることが可能なため、上記のアップデートはデフォルトバージョンの更新になります。詳しくはドキュメントの各解析ツールの設定をご覧ください。

何かご不明点がございましたら、お気軽にSiderの右下のチャットからお問い合わせください。

SFにSiderのUSオフィスが設立されました!

f:id:sideci:20180808110649j:plain
(左: CEOの角幸一郎 右: Head of Business Developmentの笠原太一)

このたび、SiderはUS内の拠点をサンフランシスコに立ち上げました。コードレビューが開発にとって重要だと考えるSiderは、2014年にコードレビュー自動化サービスをリリースして以来、「コードレビューの時間を削減することで開発者の皆さんに貢献していく」という考えのもと、日々尽力してきました。この4年間で、弊社の理念に共感してくださった国内のIT企業さまにご利用いただく機会も増えてまいりました。 そして、今年。満を辞してSiderは、世界のIT業界の中心地とも言えるサンフランシスコに進出いたします!

オフィスとメンバーについて

Siderの拠点は、SOMA(South of Marketの略)地区と呼ばれるエリアにあるWeWorkの一角をお借りしました。こちらは、数あるWeWorkのスペースの中でも一番歴史ある施設だそうです。 2018年7月末、SF拠点のメンバーとして、笠原太一がHead of Business Developmentとして加わりました。笠原は今後、現地SFの開発者コミュニティへ向け、弊社のコードレビューツールを広めたり、使用法などを伝えたりする広報活動を担当します。これにともない、SiderではUS国内での開発者ミートアップの参加や主催、スポンサー提供なども行う予定です。

そしてGitHub Universe 2018へ!

Siderは、今年の10月16日・17日に開催されるGitHub Universeのスポンサーをすることになりました!これはSiderにとってUSでの初のスポンサー活動でもあります。現在、GHUの弊社ブースを飾るいろんな仕掛け(どんな仕掛けかはお楽しみに!)を鋭意準備中ですので、今年のGHUへ参加を予定している皆さんも、参加を検討中の皆さんも、ぜひ弊社ブースへお立ち寄りください。皆さんにUSでもお目にかかれることを、Siderメンバー一同楽しみにしております!

f:id:sideci:20180814083746j:plain
(皆さまのお越しをSFでお待ちしております!)

Sider 特別インタビュー GitHub アーロン・パターソン氏  コードレビューにとって大切なことは

2018年6月12日、13日の2日間にわたり、GitHub Satellite Tokyoが開催されました。 Siderでは、これにあわせて来日していたGitHub社のAaron Patterson(アーロン・パターソン)氏に、特別インタビューをお願いしました!気さくで日本語が堪能なアーロンさんは、終始笑顔で弊社CTOのSoutaroの色んな質問に日本語で答えてくれました。どうぞお楽しみください!

f:id:sideci:20180611122905j:plain  

GitHubでの日常 - RailsのアップグレードからGCの改善まで

Soutaro:
今GitHubでどんなことされてるのかをちょっと聞かせてもらえないかな、と思っています。

Aaron:
実はGitHubでは私は普通の開発者です。

Soutaro:
えっ??プロダクションのコードをバリバリ書いてるんですか!?

Aaron:
それは冗談。ジョーク(笑)。

GitHubでは私はメモリー使用量とウェブサイトの速度を改善しています。つまりパフォーマンスを中心に頑張っています。Rubyの開発だけをやるフルタイムコミッタではなくて、アプリケーションとRubyの両方を開発しています。

Soutaro:
RubyKaigiとかRubyConfとかで話していた、GCのやつとかですね。あれはGitHubで必要だったってことですか?

Aaron:
はい。GitHubのアプリケーションはすごくメモリを使うので、最近はRubyのメモリの使用量を減らす方法を考えています。

大体1年くらい前に、GitHub Enterpriseのサポートの人たちから「私たちのアプリケーションのメモリー使用量がだんだん増えてきた」と聞いて、それから調べ始めました。GHEとGitHub.comでは共有されているコードがありますが、GHEはお客様のハードウェアにインストールするものです。お客様のコンピューターのメモリはGitHub.comよりも少ないので、制約が厳しいんです。

Soutaro:
わかります。我々のSiderのオンプレ版も将来的にリソースが問題になると思っています。

Aaron:
私たちと同じ問題ですね。

Soutaro:
なんで最近あんなにメモリのことをずっとやってるのかなと思っていたんですよ。

RubyConf 2017で話されてたCompacting GCを僕はとてもすごいと思っていて、それまで「RubyでCompacting GCやってもほとんど意味ないんじゃ」って思っていたので、「あ、実際にできるんだ、効果あるんだ!」と思って。

Aaron:
ありがとうございます。開発は進んでいて、プロダクションにも入れてみたんですが、まだリリースしていません。バグがあるのでまだRubyコアにサブミットしてないんです。GitHubのプロダクションの一部で試したらバグが見つかったので、revertして。

GCの仕事はすごく楽しいけど、私の業務の割合としては20%くらいですね。普段はRailsの問題を修正しています。GitHubの開発で見つかったRailsの問題を直しています。

Soutaro:
同時にGitHubのコードも直していくっていう?

Aaron:
そうです。今のGitHubのRailsのバージョンは4.2ですが、1年前は3.2でした。今、5.2にアップグレードしている最中です。いろいろと問題が見つかってます。

Soutaro:
なるほど。入社されたときには3.2だったのを、これはアップグレードしないと駄目だって思って……

Aaron:
そうそう。プロダクションでRailsのmasterとRubyのtrunkを試したかったから、最初にアップグレードをしなくちゃならなかったんです。Railsのmasterを使えばアップグレードも簡単になると思います。いつもアップグレードしてくれるし、誰かがRailsにバグを入れたらすぐにわかるから(笑)。

Soutaro:
なるほど。それにしてもGitHubはすごいですね。RailsもRubyもわかってる人がチームにいて、直したRubyとRailsをすぐにプロダクションにデプロイできるっていうのは、すごく強いなと思います。

Aaron:
うん、強いと思います。

おそらくRubyだけを速くしても、Railsのことをわかっていないと結果はそこまで出ないと思うんです。今、WebアプリケーションのボトムラインはRubyというよりかはRailsなので。RubyとRailsの両方が理解できていると、もっと良い結果が出せるはずです。

Soutaro:
GitHubにジョインされることになったきっかけはどんな感じだったんですか?

Aaron:
GitHubは3回も入社を誘ってくれたんですよ。そのとき私はRubyのフルタイムコミッターになりたかったんですけど、GitHubは面接で「うちでそれができる」って言ってくれたんです。それが3回目の誘いだったので、もう4回目はないだろうと思って、入社しなくちゃならないと思いました。それが理由でした。

それから、入社を決めたもう一つの理由に、「GitHub.comのコードを見たかったから」というのもありました。

Soutaro:
GitHubのコードはどうでした?

Aaron:
結構問題あるけど……。今までにもっと悪いコードも沢山見たことあるから、実際はにはそんなに悪くないと思います。でも、もちろん問題ではあります(笑)。

面白かったのは、defunkt*1のバグを直したときですね(笑)。defunktが書いたバグを私が直したんです!つまらないバグでしたが、結構古いコードで、誰が書いたか知りたかったのでgit blameしたら、defunktが書いたのがわかった。

 
 

RubyとRails、スタイルに関して

Soutaro:
先日、Siderで松田明さんにインタビューをしたときにRubyとかRailsでのコードレビューとかコーディングスタイルについての話を聞いたんですが、何か補足とか、意見とか、これはウソでしょうみたいなことってありますか?

Aaron:
あの記事は面白かった。

コーディングスタイルはRailsとRubyは全然違いますね。例えばRailsではスペースだけを使っているけれど、Rubyの中ではスペースとタブを共に使ってます。

Soutaro:
あの記事を見て、Rubyコミッターの卜部(うらべ)さんが「Rubyも最近はスペースに統一することになってる」ってツイッターで言ってて。

Aaron:
本当!?

Soutaro:
えっ??

Aaron:
Wow! 知らなかった。

Soutaro:
この話をコミッター3人として、そのうち2人が知らないっていうのはどういうことだ……

Aaron:
スペースかタブかは私にはどっちでもいいので、その話自体を見てなかったです(笑)。Vimで自動でスタイルを合わせてくれるから、私には全然問題がない。

Vimは、設定すれば自動的にスペースかタブを選んでくれるんですよ。このVimの設定は特別な設定ですが、おそらくみんな同じファイルの中でスペースとタブをあんまり使ったりしないから、ほとんど知られていないんだと思います。 *2

Soutaro:
Railsはもう最初からスペースは2つなんですね。

Aaron:
スペース2つ。

でも好きじゃないところはprivateのキーワード。privateと書いた下にはさらに2つスペースを入れます。それは変だと思います。GitHubでは使わない。他のプロジェクトで見たこともあるけど、その開発者はもともとRailsの開発者でした。

Soutaro:
ちなみにDHHインデンテーションのメリットは何だと思いますか。

Aaron:
……分からない。

彼の主張では、「何がプライベートのメソッドか簡単に分かる」という点ですね。でもそのインデントがなくても、privateのキーワードを見たらすぐ分かると思います。その下はプライベートだから、これは意味がないと思う。

Soutaro:
ですよねえ。

Aaron:
スタイルの話で言えば、Seattle.rbのスタイルは括弧を使わない。

メソッドの宣言では引数に括弧を入れないんです。このスタイルはみんな嫌いなんですけど、私は好きです。なんでみんな嫌いなのかわからない。

Soutaro:
えっと、僕も嫌いです(笑)。

Aaron:
なんで嫌いなんですか?

Soutaro:
Cみたいな感じかな……うまく説明できないけど。

Aaron:
私が括弧を使わない理由は、RubyはLispみたいな言語ですが、括弧を使わないLispがかっこいいと思っているからです。Lispは括弧は多すぎるから。

Soutaro:
僕はOCamlも書くので、そのときの感じで書いちゃうのかも。OCamlは複数の引数をタプルで渡すか高階関数にするかの2通りがあって、型が違うんですよ。(int * int) -> intint -> int -> intの違いで。

Aaron:
ああ、なるほど。ここでは括弧の意味があるから。

Soutaro:
そうですね。あとは、Rubyだと「ここの括弧がなくても絶対に曖昧にはならないんだから書かなくていい」って聞いたことがあって、それはちょっと納得しました。

Aaron:
多分、みんなはC言語みたいななものに慣れているから、括弧がないと気持ち悪いんだと思います。

いずれにしても、一番重要なことはそのチームのスタイルを使うことです。Railsを開発するときはRailsのスタイル、GitHubを開発するときにはGitHubのスタイルを使っています。私の好きなスタイルはあるけど、それに対する私の個人的思い入れはそんなに強くないですね。

「もしも自分のスタイルを使いたいなら、自分のプロジェクトを開発したほうがいいですよ」と言いたい。

Soutaro:
プロジェクトによってスタイルが違うと、何か混乱したりとかしませんか?

Aaron:
あんまりない。だいたいのプロジェクトにはRuboCopとかがあるし、間違えたら誰かが教えてくれる。大丈夫です。

Soutaro:
RuboCopは好きですか?

Aaron:
実は、RuboCopは初めは嫌いだった(笑)。でも今は慣れました。

最初は「何で私にスタイルを押し付けてくるんだ」と思って嫌でした。でも考えてみれば、一番いいことは、同じチームのみんなが同じスタイルを使うことです。だから今はもう嫌いではないです。RuboCopを使うべき理由を分かっているから。RuboCopによってチームのスタイルが統一されることが大切。

Soutaro:
そうですよね。 Railsのレビューの話も聞かせてもらえますか?

Aaron:
ああ、いいよ。Railsのレビュープロセスは、私は簡単だと思う。レビューされていないから(笑)。

直接masterにプッシュしちゃうからレビューされない。もし間違えても、他の人が直してくれるから問題ないです。多分悪いことだけど…。

Soutaro:
Rubyみたいになってますね。

Aaron:
そう。最近PRを作るようになったけど、前は全然使わなかった。なんでかって言うと、PRを作るのが面倒くさいから。

でも、直接pushしてCIが落ちちゃったときにCIを直す方がすっごく面倒くさいことに気づいたので、今ではPRを作るようになりました。

 
 

GitHubの開発プロセス

Soutaro:
ここまでRailsとかRubyの話を聞いたんですけど、GitHub社内ではどんな感じでコードレビューをしてるんですか?

Aaron:
みんなとだいたい同じだと思います。普通はバグとフィーチャーを作るときにブランチを切って、変えて、開発をして、レビューをして、直して。

そのブランチは、プロダクションにデプロイして、問題がなければマージします。つまりmasterはいつもステイブルのブランチです。

Soutaro:
GitHubではPRをマージする前にデプロイする。

Aaron:
開発者がそれぞれフィーチャーブランチを切るんですけど、PRを出して、アプルーブされたらプロダクションにデプロイします。何も問題がなければそのままmasterにマージします。もしもエラーが増えるとかの問題があったら、masterをプロダクションにデプロイします。

デプロイのときは、まずは3%のマシンにデプロイされます。それでエラーの状況を見て、エラーが増えてなければ全部にデプロイ。その後でmasterにマージします。3%はトラフィックの絶対量としては多いけど、お客さんの割合としてはあんまり多くありません。なのでもし問題があったら簡単にロールバックできる。

つまり、masterは常に安定版になっていて、いつでもロールバックできるようにするための存在です。この辺は他の会社と違うと思います。

Soutaro:
はい。われわれは違いますね。PRをレビューして、マージしてからデプロイしています。ロールバックしたいときには、GitHubの画面からRevertしています。

Aaron:
なるほど。

Soutaro:
ちなみに、PRがアプルーブされてからデプロイ完了までってどのくらいの時間が掛かるんですか?

Aaron:
今、それは会社の中で大問題になっています。デプロイ自体は10分か20分で終わるんです。でも問題は、デプロイ待ちのキューで、キューで待たなくちゃならないということです。キューにはいつも10人とか5人くらいの人が入っていて、それぞれ10分か20分かかるから、1時間〜2時間待たないといけない。

でも私は今日本にいるから、時差のおかげでキューには誰もいない。みんな西海岸にいるから。今だったらデプロイは10分で終わります。

Soutaro:
すごい。デプロイし放題だ。

Aaron:
そう、そうです。デプロイの時間があまりかからないから。私はSlackで「みんな日本に引っ越したらいいよ」と言っています(笑)。

今、この問題を解決する方法をみんなで考えています。多分マイクロサービスとか何かを使うことになるのかと。アプリケーションが分かれれば、キューがたくさんになるから、待ち時間が短くなるはず。

Soutaro:
そうですね。今のはデプロイの話でしたが、レビュー自体は普通にやるって感じですか?

Aaron:
はい。RuboCopも使ってます。デフォルト設定は使ってないけど。公開されているGitHubのスタイルがあるので、そのスタイルを使っています。

でもGitHubのスタイルは、いつもダブルクォートを使うんです。私はいつもシングルクォートを使っていたから、入社したてのときにこれは面倒くさいと思った。RuboCopはいつも怒ってました。

Soutaro:
あれ?ダブルクォートはRailsも一緒じゃないですか?

Aaron:
Railsは、ダブルとかシングルのどっちでもいいと思います。

Soutaro:
そうだったっけ……?

Aaron:
そうかな?間違ってるかな……。

(この間Soutaroにhttps://github.com/rails/rails/blob/v5.2.0/.rubocop.yml#L120-L123 を見せられているAaron)

f:id:sideci:20180611121052j:plain

Aaron:
Oh, No!(笑)

Soutaro:
えー。何で気付かないんだろう……文字列リテラルをあんまり書かないんですかね。

Aaron:
あんまり書かないのかな……。

ダブルクォートと言えば、一般的なキーボードでダブルクォートを打つ時にシフトとクォートを押さなくちゃいけないのが面倒なので、私のキーボードで1つのキーを押したらダブルクォートが出せるようになってます。自分のキーボードで。

Soutaro:
えっ、すごい!

Aaron:
あと、私のキーボードだとホームポジションで括弧を書けるんです。このボタンを押して、DとFで括弧が出ます。これは括弧のオープニングとクロージング。

編集注:気になったので、後日アーロンさんのInstagramを覗きにいったら、自作キーボードの写真が色々載ってました。興味のある方はぜひどうぞ!

コードレビューで大切なこととは

Soutaro:
GitHubでの仕事のコードとRailsとかのオープンソースのコードでは、レビューに関してなにか違いはありますか?

Aaron:
私からすると違いはないですね。だけど、オープンソースのほうが良いレビューをしようとする気がします。ちゃんとコメントを書いて、フィードバックをあげる。企業での開発ではそうはいきません。みんな、コメントも短いし、レビューもあまりされなかったりする。

なので、私はオープンソースでレビューをするように、会社でも質の良い、丁寧なレビューをしようと心がけています。みんながそうしているかはわかりませんけど。私にとっての違いはその辺でしょうか。

Soutaro:
コメントの質が違ってくる理由は何だと思いますか?

Aaron:
会社だと同僚同士でお互いを知る機会があるので、もっと手っ取り早くレビューができてしまうんじゃないでしょうか。OSSでは、知り合いではなかったり違う企業で働くもの同士が協力しあうので、そうはいきません。もっとコミュニケーションを取る必要が出てくる。

でも私は、それは良いことだと思っています。なので、会社でも同じようにレビューしようと心がけています。新しく入ってくるメンバーに読んでもらいたい状況が出てくるかもしれないですし、後から見直したくなることだってあるかもしれない。自分でも忘れてしまうことがあるんだから、記録が残ってるほうが良いと思います。

あとは、企業とOSSの開発速度が違うのも関係するのではないでしょうか。会社での開発はOSSと違って時間があんまりないので、それがコメントのスタイルにも影響しているんだと思います。

Soutaro:
コードレビューをやっていく中で大事なことは何だと思いますか?

Aaron:
レビューで大事なことは、コードの変化を理解することです。そのコードがプログラムの挙動をどう変えているのか、何をしているのかが分かること、これが一番大切だと思います。でもdiffだけで見ていたら、そのことがわからない時もあります。そのあたりがPRでレビューをするうえでの難しい点だと思います。つまり、どうやって全容の理解に取り組むか、が大事です。

Soutaro:
僕はGitHubのPRはレビューの効率をすごく改善したと思うんですけど、まだ十分ではない?

Aaron:
レビューのコメントを書くことができたりとか、PRはすごく便利だと思います。

でもdiffだけ見ていると、どうやってプログラムが動くのかわからないときもある。diffを見たらコードの何が変わったかは分かりますけど、その変更が全体のシステムにどう影響するかがわからないことがあります。他のコードがどう影響するかがわからないから。それが自動でわかるようになるといいと思います。

Soutaro:
クラスの定義を変更したときに、他のコードから参照されているところで何かがおかしくなっていた、みたいな話?

Aaron:
そう。それが自動的で分かるとすごく便利。

Rubyで、なにかコードを解析してくれるものがあると、大きなプロジェクトですごく便利だと思う。

Soutaro:
型検査ツールとか?(笑)*3

Aaron:
そう。

でも……実は型を書きたくない(笑)。


f:id:sideci:20180611112743j:plain Aaronさん、お忙しいなかありがとうございました!

*1:編集者注: GitHubの共同創業者でありCEO

*2:編集注: 以下がその設定。https://github.com/tenderlove/dot_vim/blob/c5e3c7c1bb5273c9b4be4d1a6eb5f1312bd3915a/vimrc#L129-L133

*3:編集注:Soutaroが開発中の型検査ツールの話をしています