Sider Blog

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

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

第二回 コードレビュー支援サービスSiderの歴史

この秋、Sider株式会社が初めてGitHub Universeにスポンサーとして参加することを記念して、事業立ち上げから、コードレビューサービスであるSiderを提供する現在にいたるまでを振り返るシリーズ記事を三週続けてお届けしています。
先週公開した前編では、CEOである私がどのように起業を志し、最終的にSiderというサービスを立ち上げていったのかをお伝えしました。今回は、Siderの歴史について書いていきたいと思います。

先週までのあらすじ

学生時代からのアプリ開発経験、そして会社員時代にはプロジェクト立ち上げなどを経て、課題解決型のスタートアップを起業することに決めた私は、コードレビューを支援する事業を立ち上げることを決めました。以前の名前のSideCI、そして現在のプロダクト・社名のSiderにも含まれる「side」というのは、いつも開発者さんの隣でお力になれるよう見守る、開発者の隣でお役に立てる、メンターのような、パートナーのような、同僚のような、そんな存在になれるように名付けました。

SideCI プロトタイプ 開発スタート 2014/1

紆余曲折を経て2013年12月頃にアイデアを発議したコードレビュー自動化ツール『SideCI』(現在のSider。前編参照)は、2014年1月から実際の開発に進みました。CTOの友人たちへのヒアリングのおかげでコードレビューのプロセスに課題があることが明らかになってきたため、課題を解決するプロトタイプの開発に乗り出しました。
ちなみにこの時のメンバー構成は、自分を含めた計3名の開発者がいるだけで、開発以外の業務は全て自分のみでカバーしていました。

プロトタイプの機能は、ユーザーがZipでアップロードしたソースコードをSideCIがサーバサイドで解凍し、rails_best_practices gemで解析した結果をHTMLで表示する、というものでした。今思い返すと、当時の自分はなぜこれがMVP(Minimum Variable Product)だと思っていたのか全く理解ができません。明らかに手元のPCのコマンドラインでgemを実行するのとほとんど変わらない、もしくはコマンドライン実行の方が便利そうです。

f:id:sideci:20180910165443p:plain
(プロトタイプの画面)

しかし開発当初は、このプロトタイプをもってユーザヒアリングを進めていました。

SideCIベータ版リリース 2014/4

コードレビューをどのようにしているのか、このMVPでコードレビューが楽になるかといったことをヒアリングさせて頂いたところ、多くの方がGitHub Pull Request上でコードレビューをしている、Zipでアップロードするのは面倒でやらないだろう、といった意見が多く、GitHub Pull Requestと連携するのがシームレスだろうと考えました。そのため、GitHubと統合した形でSideCIベータ版の開発を行いました。
ベータ版は、『コードレビューの自動化』をコンセプトとしてすべてのコミットを静的解析器で解析し、結果をGitHub Commit Comment APIでコメントするものでした。解析部分の実装はHeroku上でgit cloneを行い、rails_best_practices gemなどの解析器をKernel.#systemで呼び出す形です。

しかしこのベータ版は大きな2つの問題を抱えていました。一つは、Herokuでのコードの解析には当時のHerokuの最大スペックのPX Dyno(8コアマシン)でもメモリが足りないということ。もう一つの問題はrails_best_practicesが親プロセス(Railsアプリケーション層)ごと巻き込んで死ぬことがたびたびあるということ。つまり、本当にシステムが安定しなくてダメでした。

そのほか、密結合なマイクロサービスアーキテクチャを取っていたため、最小のサーバ構成がHerokuのPX Dynoが4台であり、毎月$2000が必要でした。売上がないベータ版の状態でこの費用は大きすぎました。
またプロダクトの機能面でも、すべてのコミットを解析してコメントしてしまうため、非常にうるさいサービスでした。そこでベータ版リリース後、Pull Requestの作成と更新のタイミングでのみコメントを行うように仕様を変更しました。 f:id:sideci:20180910165538p:plain https://web.archive.org/web/20140812205202/https://www.sideci.com/

f:id:sideci:20180910165625p:plain
(ベータ版のリリース記事)

https://jp.techcrunch.com/2014/04/30/%E3%82%A2%E3%82%AF%E3%83%88%E3%82%AD%E3%83%A3%E3%83%83%E3%83%88%E3%81%AE%E3%80%8Csideci%E3%80%8D%E3%81%AF%E3%80%81%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC%E3%82%92%E8%87%AA/

Dockerベースに移行 2014/9

SideCIベータ版の「HerokuでKernel.#systemを呼び出して実行する」という形は不安定であり、また、並列実行する際にはセキュリティ上の懸念がありました。そのため、アーキテクチャをDockerベースに変更しました。具体的にはHerokuからAWSにシステムを移行し、EC2上にDockerコンテナを起動し、そのコンテナにSSH接続を行ってコンテナの中でgit cloneや解析器の実行をするという形です。
この形を採ることで、Herokuで動かしていたベータ版よりは動作がマシになりました。ただし、時折Dockerのインスタンスが残ってしまったり、コンテナ内で暴走したプロセスをきちんと終了できなかったりといういくつかの問題があり、残念ながら不安定な状態が続いていました。

f:id:sideci:20180910165834p:plain

https://web.archive.org/web/20141230072517/https://www.sideci.com/

最初の危機 2014/11

f:id:sideci:20180910170305j:plain
(Paul Graham氏の提唱するスタートアップ曲線。出典:http://www.fastcompany.com/1825877/5-things-i-learned-about-entrepreneurship-y-combinators-paul-graham

スタートアップ企業は往々にして、「愚かさがクラッシュ」(Paul Graham氏の提唱するスタートアップ曲線の中での、The Crash of ineptitudeと呼ばれる停滞期の後にくる事業が落ち込む時期のことを指す)するタイミングがあります。Siderは2014年の11月、この「愚かさのクラッシュ」、つまり最初の危機を迎えました。

不安定なシステムと合わせてメンバー間の仲も不安定になりました。結果、一度チームは崩壊を迎え、私がCEOとCTOとそのほか全部を兼任する、1人体制になりました。

設計をゼロからやり直し。再リリース 2015/2

チームが崩壊した後、メンバー構成は 暫定的に、私とフリーランス1人の2人体制になりました。そこでまずはシステムの不安定さを根本的に解決するため、アーキテクチャの根本的な見直しをはかりました。具体的にはSSHでDockerコンテナに接続する形を廃止して、docker exec rubocop –R dirname といったコマンドをSidekiqのWorkerプロセスから呼び出す形に変更し、WorkerプロセスやDockerコンテナが暴走した場合にはKill、そこにRailsアプリケーションと、解析器の間に中間層のような構造を導入しました。それに合わせて各静的解析器の解析結果を共通の形式に変換し、GitHub APIに送信する形にも変更しました。
その後、SideCIに一瞬テスト&デプロイ機能が付いたこともありました。 2015年3月のことですが、文字通り、Side「CI」に一瞬なったわけです。この変更により、コードレビューの自動化サービスから統合的なCIのサービスに進化(?)しようとしたのですが、「TravisCIやCircleCIでやるからその機能は要らない」という意見が多く、すぐに撤退することになりました。

f:id:sideci:20180910170431p:plain f:id:sideci:20180910170518p:plain https://web.archive.org/web/20150322061315/https://sideci.com

Ruby以外の言語のサポートを開始 2015/7

結局SideCIがCIであったのは短い間でしたが、Dockerコンテナをベースとし、解析器の出力結果の取り扱いを共通形式に変更したことによって、新しい解析器のサポートが容易になる、といういい面もありました。新しい解析器の追加によって、様々なプログラミング言語をサポートすることも可能になったため、2015年夏頃からはRuby以外の言語のサポートを開始しました。SideCIから名称を変更した現在のSiderは20以上の解析ツールに対応していますが、これはその第一歩とも言えます。また、テスト機能を廃止したことで、レビューのみに再度フォーカスしようということになりました。レビューの自動化を集中して扱うサービスにしようという動きが本格化したのもこの時期です。

f:id:sideci:20180910170535p:plain f:id:sideci:20180910170706p:plain

https://web.archive.org/web/20160207112639/https://www.sideci.com/

1人→3人に 2015/11

新しい道を歩みだしたSideCIの元に、少しずつ新しいメンバーも集ってくれました。一人目はPockeです。SideCIについてエゴサーチしていた際に、TwitterでPockeのつぶやきを発見したことが縁となり、2015年10月、学生アルバイトとして迎えることになりました。PockeはSideCIを作っていく中でOSSのRuboCopにコミットを続け、RuboCopのコアコミッターとなり、2018年4月には当社の技術顧問に就任しています。さらにその後、2015年11月にはVPoE・取締役に就任する開発者も入社し、株式会社アクトキャットは3人体制になりました。

資金調達(4度目) 2016/3

その後順調にメンバーも増え、プロダクトも安定して動作するようになったので、事業拡大のために4度目の資金調達を実施しました。この頃はSideCIには指摘を修正するPullRequestを自動的に作成する機能も提供されていました(現在は廃止)。そして2016年4月、SideCIはついに「正式版」としてローンチします。

負債カンバン機能をリリース 2016/8

続いて、技術的負債を可視化する『負債カンバン』という機能をリリースしました。これは「技術的負債を返したい、けれど返せていない」という課題を解決する機能です。スタートアップのフェーズなどでは、コードの善し悪しは気にせずとにかく機能をリリースして、「技術的負債」の名前の通り、先に作った負債を後で返済する(リファクタリング)、といったことが多くあります。負債カンバンは、その「後に返済する」ことを支援するために作られました。裏側は静的解析器を使っており、解析結果にファイルの修正頻度などを加味してSider側で優先度付けをし、それをトヨタ生産方式やアジャイル開発で有名なカンバン形式で表示したものでした。

f:id:sideci:20180910170813p:plain
(出典:TechCrunchで紹介された際の記事https://jp.techcrunch.com/2016/08/31/sideci-introduces-technical-debt-kamban/

受賞 & 再度、愚かさがクラッシュ 2016/12

こうして軌道に乗り始めたSideCIは、2016年の末には、「コードレビューの支援」という製品の性質や製品自体、Rubyコミュニティへの貢献などを評価され、Ruby biz grand prix 2016 special prizeを授与していただきました。

f:id:sideci:20180910170914j:plain
(Ruby biz grand prix 2016 授賞式)

しかしここで「愚かさのクラッシュ」が再来しました。Ruby biz grand prix 2016授賞式のわずか数日後、VPoEから退社したい旨の相談を受け、実際に退社することとなりました。この頃は資金調達の活動中であり、また、VPoEが取締役に就任してからまだ4ヶ月という時期でした。突然の事態に私やチームは驚きでいっぱいになり、開発チームに再び混沌が訪れてしまいました。
VPoE退社への応急処置として、翌2017年の1月から新人事とスクラム制の導入を行いました。当時、前職でもCTOを長く務めていたsoutaroが社内にいたため、VPoEに代わり、急遽CTOに就任してもらうことにしました。また、VPoEが抜け、かつCEOは資金調達で忙しいことからプロダクトマネージャーが不在がちになってしまうという問題に対しては、スクラム制を導入しました。こうしてなんとかCEOが製品開発の優先度付けだけはできるように体制を整え、SideCIの2017年が幕を開けました。

SideCIのレビューフローを「コメント」からWebUIへ変更 2017/1

それまでのSideCIは発見したコードの問題をGitHubのPull Requestにコメントしていました。これには指摘が読みやすく、GitHub上で完結するというメリットがある一方で、指摘が多くなるとPull Requestのページが開けなくなることや、開くのに時間がかかること、SlackとGitHubが連携している場合にSlackがNoisyになること、などの様々な問題がありました。この問題を解決したいと考え、ユーザ体験の変更に着手しました。
ここでSideCIは、WebUIで指摘を表示する形に変更されました。さらに、SideCIが提示した指摘を無視することもできるようにしました。この変更にはSideCIの指摘が有用なのかどうかや、ユーザが指摘をどう判断しているのかを知りたいという意図もありました。それが判れば、SideCIが提供した指摘が「誰にとっても有益な指摘」「そのプロジェクトでだけ有益な指摘」「誰にとっても無益な指摘」のどれだったのかを知ることができます。この非常に有益な情報を元に、レビューの品質や量、誤検知率などの改善を繰り返してきました。

f:id:sideci:20180910171444p:plain

https://blog-ja.sideci.com/entry/abyssinian_beta_release

資金調達(5回目。累計調達は3億円超に) 2017/4

この時点でエクイティファイナンス及び長期のデットファイナンスの累計額は、3億円を超えました。この頃にはお客様の解約率も低く、また新しいお客様も日々オーガニックに入ってくるようになっていました。SideCIはプロダクトマーケットフィットに到達したと考え、継続的な製品開発並びに販売拡充のために新たに資金の調達を行いました。会社としても新たなフェイズを迎えるための準備が再び始まりました。

人事についても見直しました。2016年12月のVPoE退職から、開発体制は私をプロダクトオーナー(PO)としたスクラム開発になったままでしたが、この機会に自分をCEOとしてセールスやマーケティング、採用の核となるため、POをSoutaroに委譲しました。Soutaroはプログラムの解析の有識者で、プログラミング言語の型解析の論文などによりPh.Dを取得しており、Ruby3x3プロジェクトの一つである静的型推論の実装steepの開発者でもあります。
元からSideCIは静的解析を用いたコードレビューの自動化や支援に集中していたため、RuboCopやReekのコアコミッター、コミッターがメンバーとして在籍しておりました。SoutaroのPOへの就任はこの方針をより強化しました。結果、SideCI株式会社はレビューできる範囲を広げるための新しい解析器やQuerly(Ruby)、Goodcheck(全言語)の提供や、それに合わせたWebUIの提供などに集中できるようになりました。

参考: 誤検知を増やしても良い、増やせるようにし、レビュー範囲を広げる
https://blog-ja.sideci.com/entry/2017/04/07/161025

合わせて、機能を取捨選択し、ユーザにとってより使いやすいサービスにするため、「負債カンバン」などのコードレビューに直接的な関連性の薄い機能は廃止されることになりました。

参考: クラシックモードを廃止し、開発リソースをコードレビュー自動化カバレッジの向上により集中
https://blog-ja.sideci.com/entry/2017/09/06/160514 Styleint, Java, Misspell, Flake8プラグインサポートなどを追加したのもこの時期です。より多くの人に、より充実した内容のコードレビューを提供できるSideCIになれるよう製品改善を進める姿勢は、現在も大切にしています。

マーケティング & セールスへの集中

製品の質を高める一方で、より多くの方にSideCIを使っていただきたいという思いが大きくなりました。そこで2017年からは製品を世界中へ拡大させるために、イベントへのブース出展や登壇による認知度の拡大を図っています。以下はその一例です。

  • RubyBusiness User Conference
  • RubyKaigi2018
  • RubyConf Taiwan
  • Rails Developers Meetup
  • GitHub Satellite 2018 Tokyo
  • Code Review Meetup(自社にて4回開催)

SideCIからSiderに名称変更 2018/6/13

2014年リリース当初から約4年間ほど「SideCI」という名称でサービスを提供してきました。おかげさまで新規のお客様も途切れることなく、日本の開発者の方々の中では「SideCI」の知名度は高いと考えています。
一方、アメリカや台湾などの海外では、SideCIの話をするたびに、「テスト&デリバリー(CI)のためのサービスと何が違うのか」「テスト&デリバリー(CI)はもう使ってるからSIdeCIは必要ではない」といった話を聞く機会が多くあり、「CI」がサービス名に含まれていることの弊害を感じることも多々ありました。「SideCI」という名称のままでは今後も同様の状態が続くだろうと考え、製品名の変更を決定しました。GitHub Satellite 2018に登壇した際にアナウンスを行って以降、「Sider」として製品の提供を続けています。また、2018年8月31日時点ではまだ当社からのアナウンスは行われておりませんが、GitHub Enterpriseに対応したSiderの提供を開始しました。結果、様々な大手企業にもSiderの導入が進むようになりました。

参考: https://githubsatellite.com/

Siderはこのように着想から色々な困難を乗り越えてリリースされ、約4年間皆さまからいただいたフィードバックとともに歩みながら、いまお届けしているSiderになりました。Siderは、これからも皆さまの隣に寄り添う「Sider」であり続けます。

これから

今後Siderをより多くの人々に広めていくため、2018年10月16日、17日にサンフランシスコで開催されるGitHub Universeという大型イベントのスポンサーやブース出展を行います。もし機会がございましたら、ぜひブースに遊びに来てください。様々なノベルティをご用意して、皆さまのご来場をお待ちしています。

f:id:sideci:20180910171759p:plain https://githubuniverse.com/


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