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

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

▼サーバーサイドエンジニアが挑戦するフロントエンド

ー【質問】求められる技術力を知りたいです。

長永：いまのQuipperだと、ちょっとハードルは高めになりつつあるかなと思います。1 つはサーバーサイドのRubyとかRailsの開発経験。ただサーバーサイドは、ぶっちゃけRubyであるかどうかはあまり重要じゃないと思っていて、RubyっぽくRailsっぽく書ければ良しなんです。実際、仕事とか趣味でRubyはほぼ使ったことがなくてずっとPythonだった、とか。そういう人がいま、大活躍してたりするのでそこは大丈夫です。サーバーサイドの言語で何かしらweb開発したことがあれば大丈夫かなと。フロントエンドのほうは、サーバーサイドをずっと専門でやってきた人にとってはすごくハードルが高いものだと思いますね。ぼくが長年サーバーサイドだったので、フロントエンドSPAとかってほぼ仕事で触ったことがなかったりして、そこがやっぱり難しかったです。キャッチアップするのに苦労するところかな、と思いますね。でも、いまだとReact.jsとかAngularJSとか有名なフレームワークは情報も多くなって、昔よりもいろいろ豊富になってますし、触るきっかけになりやすいですよね。「React.jsだったら、ちょっとやってみようかな」とか。なので、とっつきやすくなってるかもしれませんね。
金谷：フロントエンド専門のエンジニアっているんですか？
長永：いないですね。
金谷：サーバーサイドの人がやってるんですか？
長永：そうなんです、そこがチームとしては微妙なイシューにはなっていて。フロントエンド専門の人が欲しいんですけど、とはいえハイブリットでみんなどっちもやってるので、本当に「フロントエンドだけしかしません、できません」っていう人だと、活躍の幅が狭まっちゃって、チームとしてそれを受け入れるだけの余裕がまだ組織にない、という感じになってしまってるんです。
金谷：ちなみに、私フロントエンドが得意でサーバーサイドもできますよ。
長永：じゃあちょっとこのあとで、詳しくお話しましょう！（笑）

▼デザイナーを介さずリリースできる仕組みづくり

ー【質問】 1つの機能をリリースするまでに、エンジニアとデザイナーがどういう関わり方ですすめるか知りたいです。

長永：ネイティブアプリの進め方に関しては詳しくわかってないんですけど、webのほうで言うと、プロダクトマネージャーみたいな人が「こういう機能が欲しい」って言ってスペックとかをデザイナーと相談します。デザイナーが既存のサイトのものと整合性が取れるよう、Quipperだと内製のBootstrapにかぶせた「Qstrap」っていうCSSフレームワークみたいなのがあるので、既存のコンポーネントとかを使いつつ、「こういうのじゃない？」という完成形に近いデザインモックみたいなものをつくります。ただ、細かいpx指定とかの書き込みまではしてないですね。完成形で「こういうビジュアルになるよ」ってものをもらって、それを見ながらエンジニアがどんどん実装していくって感じですね。だいたいそのコンポーネント集はあるので概ね上手くいくんですけど、CSSが不得意なエンジニアがつくると細部に神が宿れなくて、途中途中でスクリーンショットを貼って「こんなんでどう？」みたいに言ったり（笑）あとは、ステージング用のアプリURLみたいなものができて、そこにアクセスするとそのブランチのコードが走ってるみたいな状態のやつを持っています。そのURLを貼って「これで見てみて」と。そうすると、開発中のものを実際に動かしながら見てもらえるので、「ちょっとここのマージンが狭すぎるから空けて」とか「ここのコンポーネントのコントロールの色は、こっちのほうがいい」とか。いろんなやり取りをしながら仕上げていく、って感じですかね。
金谷：うちは、フロントエンドを専門にやってくれてる方がたまたまチームにいるので、デザイナーさんが書いてくれたものを彼らがビューに落として、リリースしていくってのがありますね。なので、細部に神が宿るみたいな話もありましたけど、普通に彼らにそのへんは心配なく任せられる感じです。ただ、「Qstrap」みたいな話もありましたが、今後それに近い話でコンポーネントとかをちゃんと設計して、トンマナも全部決めちゃって、ある程度の機能だったらデザイナーを介さずにエンジニアだけでもガンガンリリースしていけるという状態をつくっていこうってことで、今その設計をデザイナーさんと一緒にエンジニアが入り込んでゴリゴリつくってますね。それこそ「RMPstrap」をつくっていこう、という話に近いと思うんですけど。それを使って開発スピードを早めていこうとしています。そうなれば、デザイナーさんはもっと高い視座で、サイト全体・プロダクト全体をデザインしていくっていうところに集中できる。そういう流れを検討している状態にありますね。

▼負荷対策はスケールアップで

ー【質問】負荷に関して、対応されていることを教えて下さい。

金谷：まずRMPで言うと、残念ながらすごく負荷が高いサービスってまだないんですよ（笑）もともと「ゼクシィ」とか「カーセンサー」という大きいプロダクトは持ってるわけですけど、実はそっちのほうは私達のグループは携わっていなくて。新規事業系で出てきたものに関して、我々がアサインされている状態です。なので、うちのエンジニアが関わってるようなプロダクトは、むしろ（負荷、トラフィックを）増やすために頑張っていこうというフェーズなんですね。なので、そういった工夫はまだまだこれから、ところです。
長永：ぼくはインフラ側のチームではなくてwebのほうなので、そこに対する知見はあまりなんですが、「Quipper」のグローバルのプロダクションは全部Herokuで動いてるんですね。メインのDBはMongoDBなんですけど、mLabっていうMongoDBのサービスのものを使ってるんですね。なので、あまりコントロールできないのを逆手に取って、とにかくスケールアップする（笑）今は、お金で解決できることはお金で解決するようにしています。スタートアップのキーワード：「金」「人件費」「時間」みたいなところで。インフラエンジニアを雇うより安くつく、ってぐらいまではガンガン上げてきたって感じですね。とはいえ地道にqueryの改修とかはやっていたり。MongoDBなんで「ジョインができない」とかはインフラに強いチームの人とかがNew Relicのグラフを見て「お前、これ酷すぎるだろ」みたいなのを指摘くれてGitHubで「すみません」って直すとか。もうすこしテクニカルなことで言うと、インフラに強い人たちがパフォーマンステストとかを組んでいて、MongoDBのレプリカというか、MongoDBとそのアプリケーションサーバーとをクラウドのDockerのうえでバーっと作って、オートメーションのリクエストを飛ばせるやつがあって。それが並列で流せて負荷テストに使えるんですね。負荷テストのシナリオで「1,000 ユーザが同時にアクセスして問題を 1,000 回連続で解きまくる」みたいなシナリオを 1 時間流すみたいな。そういうシナリオを書いて、流して、それを見る。それをDBのスペックを変えながらやって、「ここまでは耐えられる。プロダクションでこの半分ぐらいまで来たらやばいから、次のスケールアップ検討しよう」とか。そういうベンチマークと、中長期のスケールアッププランみたいなものを考えたりしていますね。

▼MongoDBで課金サービス？

ー【質問】RailsとMongoDBですか？

長永：はい、そうです。昔は全部無料サービスだったので。あとは「Quipper」のクイズコンテンツとかの構想が結構自由度を持たせたかったみたいな理由と、開発スピードとかの問題からMongoDBでやっているんです。ただ、有料サービスをやりはじめるとトランザクションがないので、結局そこに苦労しているところで…。いまは、PostgreSQLにつながってる決済ゲートウェイとのやり取りを行ったり来たりするだけのアプリケーションが別にあって、そのサブシステムに飛んで、シングルサインオン的なことになっていて…みたいな実装にしていますね。
金谷：私も前職で 4 年ぐらいMongoDBのサービスを運用していたんで、完全に同じことをしていました（笑）
長永：なんか、結局そうなっちゃいますよね。ぼくがやってたサービスじゃないんですけど、前の会社でMongoDBの中で決済データ全部持ってたサービスがあったんです。MongoDBにembedded documentってあるんですけど、あれってコレクションの 1 個のドキュメントの中に埋め込みでデータ構造を入れられるので、embedded documentの中に入れていくとその 1 オブジェクトに対する書き込みはアトミックなんですよ。
金谷：たしかに。
長永：そういうふうにして、トランザクションを担保して。あとは管理画面とかで内部で見るための「ある月に、何人が買ったか」みたいな台帳的なものを出すのが…。
金谷：難しいなそれ！（笑）
長永：なので「MongoDBで課金はやめたほうがいい」っていう与太話でした（笑）

▼求めるのはRailsのスペシャリストとグロースハックエンジニア（RMP）

ー人材募集をしてると思いますが、いまの時点でどういう人材を求めていますか？

金谷：いま、「料理サプリ」と「ゼクシィキッチン」っていうプロダクトをやってますが、何百万UU達成しようみたいな高い目標を掲げてやっています。そういった中で、どんどんスピードアップしていきたいっていう文脈があって、サーバーサイドはRailsで動いてるんで、Railsをもうゴリゴリ書ける人がいいですね。私自身、Railsで 4 年間ぐらい開発してたんですけど、いまチームに居るメンバーでRailsを昔からやってましたっていうメンバーは少なくて。新卒でRMPに入社してからRailsを勉強しながら頑張ってやってくれている人とかが多いんですね。私もマネジメント中心になっちゃって、ガッツリとコードを見れる立場でなくなってしまったこともあり、「Railsちゃんと開発してました！」「教えることができます！」という人。例えばルーティングの設計ひとつ取っても、「しっかり議論する」のはすごく良いことだと思うんですけど、ただその中にはある程度答えがある話もあるじゃないですか、セオリーがあるというか。特にRailsには、そういうものがたくさんあると思ってて。そういう話をスパっと言ってくれて、無駄な議論はせずに済むようなところを目指したいなと思ってるので。議論できること自体はすごく良い文化だと思うんですけど、どうしてもスピードとのトレードオフにもなると思うので。そこはスパスパと進めてくれるような人が欲しい思ってますね。もう 1 つちがう観点で、単純に事業的な目線で達成したい目標があって「こういうプロダクトを自分はつくりたい！」という強い思いがあってやっていける、いわゆるグロースハックエンジニア。そういう人も欲してますね。

▼新たな視座で「ぶっ込める」エンジニア（Quipper）

長永：Quipperは、中途で何社か経験されてきてそれなりに経験のあるシニアの人ばかりなんですね。そのせいか、あるいは単にそういう性格の人が集まったのかわからないんですけど、みんな非常に現実的なので、技術的なことであんまり議論しないんです（笑）揉めずに進められるので、そこは非常にやりやすくて楽なんですけど。ただ、端的に言うとオッサンばかりなので「Elixirでやりましょうよ」みたいにいう人がいないというか。「あの会社でElixirでやってるらしいね」みたいに言っても「ふーん」みたいな（笑）誰もそこにくいつかないんですよね（笑）事業って観点だと、すごく良く馴染むんですけど、個人的には価値観が均一になりすぎてしまうと、チームとか会社で長くやっていくときにあまり良くないなと感じているので、ちょっと「ぶっ込む」感じの人の力は欲してます。むしろそれが足りない部分なので。
金谷：交換すればいいんじゃないですか、うちはそんな感じが多いですよ（笑）
長永：今日話してて思いました（笑）まあ、ぼくらも事業を成功させて、その先にある目標のためにやっていることなので、いたずらに技術の良し悪しを追うことだけには時間を費やしませんが、「とはいえ」という部分がありますね。たとえば直近で来て欲しいのは、Marionette.jsに「うぇっ」ってならない人ですが、そこで黙々とMarionette.jsでやっているようでは良くないなと自分を含め思っています。いまはシニアで経験がある人がリードして「React.jsにやっぱチャレンジしようよ」って置き換えのプロジェクトがキックオフしたりしていているんですが、むしろ新しく入った人が「なんか変だよ」って、ある意味ぶち破ってくれるっていうのはちょっと欲しいなというところ。あとは、Railsが書けなくても何か 1 個スペシャルな感じの「何か」があるとか。「何か」はわかんないですけど、スペシャルな感じがあるっていう人とは会ってみたいなって言う気がしますね。それがフロントエンドなのかもしれないし、まったく違うかもしれない。もしかしたら、Elixirが超上手いみたいな感じかもしれないですけど、そういうダイバーシティというか、多様性を強化する方向っていうのが 1 個あるかなと思いますね。あとはグローバルな会社なので、現時点で英語ができる必要はたぶんないですが、英語に対して抵抗感がないというのは必須ですね。むしろ、英語を仕事とかで積極的に使っていきたい！っていう意気込みのある人が、早くキャッチアップできるし活躍できるんじゃないかなと思いますね。

▼「フリーロケーション制度」でロンドン勤務

金谷：ちなみにどの国に配属されるかはわかるんですか？

長永：オフィスごとに採用してるので、日本で採用されたら日本配属になりますね。直近だとしばらくは「スタディサプリ」の開発が多くなると思います。ただ、社内でも「せっかくグローバルの会社なのに、日本だけで働く」というのは勿体ないね、という議論はあるんで、最近制度化されたものとして「フリーロケーション」という制度があります。年間 3 ヶ月までは、どのオフィスでも働けるんです。実際、いま 1 ヶ月ぐらい旅行がてらでロンドンの開発者が 1 人日本に来ていて、ぼくの 4 つの隣ぐらいの席で働いてます。彼はプロの小説家を目指していて、小説を書きながらプログラムを学んでますね。来月には、日本のAndroidエンジニアが避暑のために家族でロンドンで仕事してくると。こういうのも元々制度があったわけではなくて、ロンドンのそのエンジニアが旅行でしばらく日本に来たいっていうときに「じゃあ、それを制度として認めてあげようよ」っていう動きになったので、まだまだ会社として若いので制度も柔軟にやってる感じがありますね。