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

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

▼「料理サプリ」と「Quipper」

ー自己紹介からお願いします。

金谷：こんばんは。RMPの金谷と申します。経歴から説明しますと、もともと「ジモティー」というサービスを立ち上げからつくっていて。そのあと、SonicGardenという会社とちょっとだけ仕事をして、RMPに入社しました。もともとエンジニアとして入社したんですけれども、RMPのエンジニア組織自体がまだできて3年ぐらいしか経っていないので、まだまだ改善していかなければいけない点が多数あります。今は、それを改善していくグループマネージャーという立場でやっています。コード書くところから少し離れてしまっていますが、組織活性をしていくというポジションで頑張っています。関わっているプロダクトとしては、「料理サプリ」「ゼクシィキッチン」という 2 つの料理レシピサービスですが、最近はさっき話したようなマネジメントや仕組みづくりを最近は中心にやっているかな、というところです。レシピ系のサービスをつくっていることもあり、最近はすごく料理を作ったり、家で食べたりするようになって太っちゃって。このサービスにジョインしてから 5 キロぐらい太ってるんじゃないかなというぐらい。それが今の悩み事ですね。

金谷：「料理サプリ」はどういうサービスかと言うと、” プロのレシピ動画が無料で見られる “ サービスで、プロの料理人や料理研究家の方々のレシピしか掲載していません。100名以上の料理人のレシピが3,000件ぐらい載っています。試しに料理サプリを使って「バターチキンカレー」を作ってもらえると分かると思うんですが、「家でこんな美味しいバターチキンカレーを食べれるのか！」「もう店に行かなくていいのでは！」ってぐらい美味い料理がレシピ動画を見ながら作れます。これは「動画」っていうのが結構良くて、「にんじんのミジン切りっていうのは、こういう技があるんだ！」みたいな気づきもある良いサービスになっています。

ー Quipperの長永さんお願いします。

長永：こんばんは。Quipperの長永健介といいます。インターネット上では @kyanny というハンドルネームで、古（いにしえ）のニックネームは @刺身です。経歴としては、小さいweb制作会社にアルバイトで入ったあとにlivedoorに転職、そのあとPaperboy & Co.（現・GMOペパボ）に転職して、そのあと今のQuipperに転職しました。仕事のポジションとしてはwebのエンジニアなので、いわゆるフロントエンドのJavascriptのSPA(Single Page Application)から、サーバーサイド・バックエンドのAPI書く、ということを主にやってますね。実際に何をやってる会社なのかと言うと、Quipperは「Quipper School」「Quipper Video」というサービスを東南アジアとかメキシコで提供してます。それと機能はほとんど同じなんですけど日本ブランドとして「スタディサプリ」というサービスもやっていて、高校生・大学受験生版を運営してます。今は、「スタディサプリ」の仕事を中心にやっています。

今日お話できそうなことで言いますと、「グローバル企業」って言うとちょっと格好つけすぎなんですけど、Quipperは本社がロンドンにあって、開発部がロンドンと東京とマニラ、営業の拠点がロンドン、東京、マニラ、インドネシア、メキシコにあります。世界の複数カ国で企業活動をしているし、サービスも提供してます。数カ国で使われるサービスを、数カ国のエンジニアたちが、数カ国で開発してリリースしている。そのうえでの苦労話とかノウハウっていう「Quipperならでは」の話ができるかなと思っています。あとは、外資というか海外の会社ですので、自分自身も入社するまではものすごく高いハードルだと感じていたんですけど、実際はそうでもないなと思うところがあって。今は正直そう感じているので、実際のヨーロッパや東南アジアのエンジニアの技術力が高いのか低いのかみたいなことまで、ぶっちゃけてお話しできるといいなと思ってます。

https://studysapuri.jp/

長永：「Quipper School」「Quipper Video」「スタディサプリ」の説明ですが、「スタディサプリ」っていうのは、有名講師の授業を動画で受けられるサービスで、英語や数学など 5 教科が月額980円で見放題という教育サービスです。演習問題を解くこともできます。そういったところがコアのサービスですね。それの海外版・インドネシア版・フィリピン版・メキシコ版みたいなものを「Quipper Video」としてやっていると。モデルとしては「スタディサプリ」とまったく同じで、それぞれの国の超有名講師の動画が月額・定額で見放題であると。ただ「Quipper School」は毛色がすこし違っていて、どちらかと言うと生徒さんではなく先生のほうに重きを置いています。先生がオンライン上で宿題を出せるんです。生徒は、そのバーチャルクラスルームに参加していてその中で宿題を解く、と。そうすると、先生はどの生徒がいつ宿題を回答して、そのスコアが何点だったのかという情報を見ることができる。今まで紙でやっていたものを、オンラインで改善しようとしているプロダクトです。日本の「スタディサプリ」も学校に導入していることがあって、そっちでは「Quipper School」の機能も内蔵しているようなかたちになっています。

▼技術トレンドと「Marionette.js」

ー最初のトピックスですが、それぞれ「料理サプリ」と「Quipper」ではどういった技術を使っているか、というところをお話いただければと思います。

長永：Quipperは、オンラインのeラーニングのサービスをいくつか提供している会社ではあるんですが、自分たちの中ではeラーニングのプラットフォームとして捉えていて、その上にいろんなサービスが乗っかっていくような世界観でつくっているんですね。なので、「Quipperプラットフォーム」の上にある、「Quipper School」「Quipper Video」「スタディサプリ」というサービスを、自分たちでプラットフォーム上につくっているような感じなんです。そういう構想だからこそ、先生が宿題を出す方と、生徒が実際に動画見たり宿題を説いたりする方は、別のアプリケーションとして実行されています。
金谷：DBは一緒のを見に行くってことですか？
長永：DBは同じで、ほとんどのアプリケーションはJSONのAPIがバックエンドにいて、その前のところはJavascriptのフレームワークでつくったSPAになっている。主要のアプリケーション3つすべて、そういうモデルになっています。ただ歴史的経緯があるんですが。
金谷：バージョンが、ばらけそうですね。
長永：バージョンというか、実はそもそも使ってるフレームワークがばらけていて。最初、APIはRailsじゃなかったんですよ。Rubyなんですけど、RubyでAPIを書く専用のDSLが使用できる「Grape」でやっていたんですけど、Sinatraの上でいろいろなアプリケーションをつくっていくと、アドインでいろんなものを足していっちゃうので、結局Railsみたいなものをつくりだす、っていうあるあるな話があるんですけど（笑）ぼくらのGrapeでのAPIがまさにそんな感じになっていって、あるタイミングで「Railsそのまま使ったほうが良いよね」っていう話になって。マイグレーションというか、実際Grapeで実装してたほうも技術的に上手くいって全部再利用できたんで。最初のコア部分はRailsが動いていて、その中でGrapeのAPIの部分が活きてるって感じなんですね。

金谷：認証系とか、そういう部分はRailsが良かったり？
長永：そうですね。あとは、Rubyなんでgemとか便利なものいろいろ入れたりして使うんですけど、New Relicっていう監視のやつあるじゃないですか？ New Relicは、Railsだと本当gemをデプロイすれば勝手に動いてくれるんですけど。
金谷：ほぼやることないですよね。
長永：本来やることないんですけど、Grapeだとやっぱりそれが上手くいかなくて。ちょっとしたアダプターみたいになるものを入れないといけなかったり、そのアダプターのgemが本体のgemとバージョンがずれるので…。
金谷：たしかに、New RelicってRailsだと凄く使いやすいから。どの処理でどのコントローラー通ったかとか、どこがいちばん負荷高いかとかを出してくれるので、Rails以外だと大変かもしれないですね。
長永：そこでずれたりとか、細々とした問題があって。
金谷：ありそう…。　
長永：イニシャライザーってRailsのアプリケーションが起動する前に諸々を書く場所が用意されてるんですけど、Grapeだとイニシャライザーの仕組みとかデフォルトにはないので、ブートされるときにキックされるファイルの中からー、みたいな話になって「もうRailsでいいんじゃない？」と。サーバーファイルはそんな感じで。フロントエンドは一世代前ですが、Backbone.jsをベースとしたMarionette.jsっていうフレームワークがあるんですけど、Marionette.jsでだいたいのアプリケーションがつくられています。
金谷：Marionette.jsは知らなかったですね。使ったことがないです。
長永：すごくマイナーですね。
金谷：そこのリプレイスするのが大変そうですもんね。
長永：大変なんですけど、今ちょっとずつやろうとはしていて。
金谷：やっぱり乗り換えたほうが良いみたいな話はあるんですね。
長永：実際、機運は高まってきていますね。現状が厳しいということもあるんですけど、Backbone.jsとかMarionette.jsのコミュニティの問題ですね。
金谷：なるほどそうですね、ちょっと世代前っていう認識があるかもですね。
長永：実際アプリケーション群は、いい意味で枯れてるので安定してはいるんですけど。じゃあずっとこのまま枯れてて良いんだっけ、みたいな。それこそ対外的なことで言うと、「Marionette.jsでやってます、キリッ」みたいなのって、エンジニアからすると「えっ」てなるじゃないですか（笑）そういうところは、内部のエンジニアでよく話題になっていて。
金谷：今だとReact.jsって言うと多少「キリッと感」出ますかね（笑）
長永：これで「社内にMarionette.jsのメンテナーが居ます」とかだと話は違ってくるんですけど、そこまでコミットしてないなってところがあって（笑）なので、ちょっとずつ進めてるって感じですけどね。RMPではどうですか？

▼若手エンジニアはRubyに興味がない？

金谷：長永さんの話と比べると面白い話はできないんですけど、「料理サプリ」はRailsで動かしてます。フロントエンドも別にフレームワークは入れてなくて、それこそReact.js入れようかとか、社内でAngularJSを使ってるところがあるのでAngularJSを入れようか、みたいな話は出てきていますね。でも、次選ぶならReact.jsかな。React.jsに置き換えていこう、って機運は多少はありますけど、基本はただ単にjQueryで書いてるっていう。そんなに要求されてることも実は厳しくないのでjQueryでかいてます、ってだけですね。ただ、他のプロダクトだとScalaで動いてたりします。
長永：おしゃれですねえ（笑）
金谷：おしゃれですよね（笑）うちのエンジニア組織は新卒で採用することも多いんで若い人が多いんですけど、彼らはもうRubyとかあんまり興味ないみたいなんですよ。なんか “ オジサンの言語 “ みたいになっちゃってる気がしてきて「あ、辛い！」って（笑）「じゃあ最近は、何やるの？」って聞いたら、GoとかScalaとかHaskellとかって名前が出てきちゃうから（笑）
長永：辛いよ、おじさん。
金谷：辛いですよね（笑）なので、Scala採用してるプロダクトがあるのと、AngularJSでSPAつくってるところがあったりしますね。基本的に、エンジニアに限らずリクルートの文化として「やりたい」って手を挙げたらやらせてもらえる環境だと思うので、「こういう技術を使いたい」と言えばやらせてもらえます。Scalaが採用された経緯も、別に、「みんなができるからScalaにしよう」というわけじゃなくて、「やりたい」っていう人がいたから、責任もってやっていこうよ、っていう付き合い方になってますね。
長永：なるほど、いいですね。