「料理サプリ」「Quipper」の技術者が語る、プロダクト開発を加速させる組織づくり【２】

2016年6月28日、リクルートマーケティングパートナーズ（以下、RMP）×Quipperの技術対談を聞きながら、おいしいご飯やお酒を楽しむことができるイベント「【RMP×Quipper】Food&Drink meetup #2」が開催されました。トークセッションでは、RMPでマネジメントを担当されている金谷祐季さん(@soplana)とQuipperの開発者である長永健介さん(@kyanny)に、導入している技術の意図や課題、開発組織における職種間の関わり方やスピードに関する課題などを語っていただきました。

（vol.1 はこちら）

▼「テスト」の慎重さはスピードとトレードオフ

ー【質問】リリースサイクル、というかどういうふうにリリースされてますか？

長永：Quipperでいうと、今は正直リリースサイクルが落ちてきちゃっています。リリース間隔が伸びてきてしまっていて週に1回ですね。ちょっと前は週に4回ぐらいやってたんですよ。その前は、マスターブランチにマージされてたら勝手にデプロイされるようになってたんですけど。結構、テストを書いていて、高いものだとカバレッジ90%くらい、低いものでも60%以上は。フロントエンドのMarionette.jsのテストもそのぐらいしてるんですよ。相当しっかりテストは書いている自信があるんですけど、複数のアプリケーションが1個のデータベースを介して時間差で連動する、例えば「先生が宿題を出したら、そのクラスに所属している生徒のダッシュボードに宿題が自動で配信される機能」に対して、それをテストするには単体のアプリケーションだとどうしても難しいんですよね。そうすると、やっぱり横断してテストをやらないといけないんですけど、まだ今のQuipperでは、テストやQAに関してエンジニアリソースをたっぷり割ける組織になっていなくて。マニュアルのテストでどうしてもカバーしないといけない。実際どんどんデプロイしていって、そこで事故っちゃったことが過去にあったので、「それは絶対だめだろう」と、「ちゃんとテストしましょう」となったんですね。ただ、アプリケーションがだんだん複雑になってきたり、「スタディサプリ」だと日本での決済システムとつながってますが、「Quipper Video」だとインドネシアとかフィリピンとかローカルの決済システムとつながっていたりするので、テストのケース・パターンがすごく増える。どんどん大変になってきてしまっていて、ちょっとリリース間隔を空けざるをえないって感じになっているのが今ですね。

金谷：ちなみに、フロントエンドのテストも書いてるって話だったんですけど、コスト面とのバランスはどう考えてますか？
長永：そうですね、正直コストはかかってると思うんですけど、ただフロントエンドのものにしても 1 回書き方が決まっちゃうと、あとは同じように書くというか。そこまできつくないんですね。「Quipper」のサービス自体が学習のサービスなんで、ゲームみたいにダイナミックに画面が変わることがありませんから、そこまで難しくない。でも書いているとどうしても、あんまり「効率的なテストにはなってないかな」って時がありますね。
金谷：テストを書きすぎてスピードすごい落ちているように感じる時があって。うちもすごい書いてるんですよ。そのへんの付き合い方って難しいですよね。ザッカーバーグ（マーク・ザッカーバーグ）じゃないですけど、「たぶん動くと思うから、リリースしようぜ！」みたいな考え方もあるのかなと（笑）どこまで書こうか、って話はチーム内ですごく話し合いますね。たとえば、「コントローラーのテストは書かなくていい」とか「モデルのテストはしっかり書きましょう」みたいな。フロントエンドのテストは、メインとなる導線があるじゃないですか。「最悪、そこだけは書いとこうぜ」「そこだけ動けばあとはいいでしょ」ぐらいの気持ちとか。その塩梅ってすごく難しいですよね。それを全部書いていて、しっかり運用できてるって話は珍しいなと思いました。

ー【質問】テストの実行時間が長くて悩んだりするのですが、そのへんはどうですか？

金谷：うちは現状そんなにアプリケーション自体が大きくないので、「すごく時間がかかる」ってことはないんですけど、フロントエンドの話だけでいうと、やっぱり書き過ぎないようには注意をしてますね。さっきも言ったように「メインとなるストーリーの正常系と失敗系を5つずつ書こうか」ぐらいの気持ちで。他のやつがこけてても良いわけじゃないですけど、そこが正常であれば許容しようか、っていう塩梅ですかね、
長永：ちなみに裏のCIはCircle CI ですか？
金谷：JenkinsとCircle CIの両方が動いています。

▼コードレビューのルールは「全員で」

ー【質問】コードレビューってどんな感じでやられてるんですか？

金谷：うちのチームで言うと、サーバーサイドの人間が 4 名、アプリはそれぞれiOS、Andoroidが 2名ずつぐらいなので、それぞれのコンポーネントでそれぞれにコードレビューしてるって感じですね。基本的にどこも似たような感じかと思うんですけど、「◯◯さん、レビュアーしてください」というのは無いですね。1 人がPull Requestをあげたら、基本的には全員で見に行って、指摘したりします。ちょうど今、「料理サプリ」が全体的にリプレイスしようとしている動きがあって、大きいリリースは控えてるんです。まずはそれをリリース日に間に合わせようとしているので、レビューはするんですけど、それに対応するよりも、とにかく前にすすめることを今は優先してるんですよ。レビューでついたコメントや後回しでも良いようなTODOは、イシューとかに残しておいて。いつか対応するっていうステータスで、今はどんどん進めてます。普段だと、必ずついたコメントに関しては納得いくところまでしっかり議論したうえで、修正していこうっていう感じですね。
長永：うちも、まったく同じですね。規模がちょっと違うくらいですかね。「Quipper」の場合はwebのサーバーサイドのエンジニアがグローバル全体で 20 名ぐらい居るんですね。基本的に全員で見ることになってるんですけど、とは言え日本の「スタディサプリ」特有のちょっとした機能とか、「スタディサプリではこういうふうに振る舞うよ」みたいな実装部分に関しては、日本でやってるエンジニアじゃないと難しいんですよね。逆にインドネシアのペイメントゲートウェイのつなぎ込みとかだと、日本で「スタディサプリ」ばっかりやってる人には背景がわからないので。そこは経験が多い人達がメインでやるって感じですかね。ものに応じて、どのへんの人たちに見てもらうかっていうのはメンション飛ばしてますね。

長永：Quipperの場合だとレビューもそうですけど、誰がマージするのかでいうと、「レビュアーがマージする」っていうはっきりとしたルールがあります。コードを書いた本人はマージしない、必ず誰か別の人がマージする。これ、結構、企業という組織によって違うところですね。逆に書いた人が責任持ってマージするところもあるでしょうし。よくレビューする人、そうでもない人、みたいなのが出てきますけど（笑）よくレビューする人はあらゆるアプリ見てるな、っことで必然的に呼ばれちゃう（笑）
金谷：マージ係みたいになっちゃうんですね（笑）
長永：2週間に1回開発者のチャット会議があるんですけど、この前ロンドンの一番古株のエンジニアに「お前ら、もう少しメンションを賢く使え」って言われましたね（笑）「俺はあらゆるものに呼ばれて、レビューをしてるだけで自分の仕事がすすまない」と。
金谷：それありますよねえ（笑）
長永：それは辛いので、改めようと（笑）
金谷：なるほどなるほど。たしかにレビューしすぎて自分の手が動かないみたいな話はあったりしますよね。かと言って、見て見ぬふりもできない。
長永：全体の速度が出ないと意味が無いですよね。
金谷：うちは、昼と夕方に定期でslackに「このレビュー溜まってるよ」って知らせてくれるbotを作っちゃいました。それで無理やり見に行くようにはしてますね。