RMP FEATURE

RMP FEATUREサプリ

『スタディサプリENGLISH』成長の裏側には、良いコードがあった。エンジニアが育つ、バックエンドが今アツい!

9月某日、役員の声掛けにより集まった3人のエンジニアたち。 彼らは、2017年8月リリース以降、会員数を増やしている『スタディサプリENGLISH』に携わるエンジニアたちだ。TOEIC®学習者を対象とし、学習者が圧倒的に感じる「忙しくて時間がとれない」課題を解決するサービスには、申込者が殺到。しかし、成長するサービスの裏側では、急激に増えるアカウントや負荷に対応するため、エンジニアたちの大きな功績と活躍があった・・・。スマートな設計をコードで表現する彼らは、どのようにして新たな技術に没頭し、日々の難題を楽しみながらクリアしているのか。3人のエンジニアと1人の役員 (エンジニアのボス)が今のRMP、そして『スタディサプリENGLISH』の裏側について赤裸々に語った――。

2017-10-12

竹迫 良範
独立系ITベンチャー2社を経て、2015年中途入社。内製開発エンジニア組織の体制強化と開発マネジャーを兼務する。2016年4月より専門役員に着任。

釘宮 愼之介
2015年中途入社。ネットビジネス本部にて、『スタディサプリENGLISH』サービスを担当するグループのマネジャーを務める。Androidエンジニアとして活躍する傍ら、バックエンド開発も手がける。

松川 翼
2016年中途入社。ネットビジネス本部にて、『スタディサプリENGLISH』のサーバーサイド開発・インフラを担当。

池田 裕介
2016年中途入社。ネットビジネス本部にて、開発支援グループとして新規サービスのインフラ、サーバーサイド開発など内製開発サービスを横断で担当。10月より『スタディサプリENGLISH』のサーバーサイド開発も担当。

急成長するスタディサプリENGLISH
エンジニアこそスケールの要

竹迫 僕は今専門役員という立場で会社に関わっているんですが、以前他の会社にいた時に、優秀なエンジニアの人がみんな海外に行ってしまうのを見ていて、日本の会社に優れたエンジニアがいなくなっちゃうんじゃないかなという危機感があったんですね。そこで日本の会社でも理想的なエンジニアのキャリアパスを描けるようにしたいという想いがありました。僕がRMPに入社した2年前は20人強の組織だったんですが、今はデザイナー含め70人くらいの組織になりましたよね。

池田 すごい増えましたね。

竹迫 当時は『スタディサプリ英単語』が4月にリリースされていて、無料で使える英単語サプリって名前だったんですけど、無料で結構英語学習ができるアプリっていうのがあって、それを入社する前に見て衝撃を受けて。Androidでは作り込みづらいアニメーションも、すごい頑張ってますよね。

釘宮 Androidだとアニメーションごりごり動かすのが大変で、デフォルトでGIFを動かす機能もない。自分で1コマ、1コマ画像を変えるみたいなことをやって頑張ってました。

釘宮 toCのサービスがあんまり無かった。『受験サプリ(現スタディサプリ)』があったけど、内製で開発したサービスとしては、多分初ですかね。

竹迫 リクルートって、どちらかというとカスタマーを集めて、メディアに出稿したいクライアントから広告費をいただいてマッチングさせるっていうところがあるんですけど、カスタマーに対して直接向き合って提供する価値を出して行けば、すぐ結果が出てフィードバックが早く返ってくるかもしれないですね。池田さんは、前職はどんな事をしていたんですか。

池田 前職はソーシャルゲームと広告関連ですね。その頃はJavaでサーバーサイドのシステムをメンテしてたんですが、ちょうどNode.jsやJavaScriptが流行り始めた頃で、そっちも面倒見てました。Node.jsが出た頃ってそんなにライブラリとかもないので、ソケット通信を生で自分たちの手で実装したり、すごい大変でしたけど面白かったですね。Node.jsは最初マルチサーバー的なものが無かったから、うっかりデータベース触りに行ったら、そこでスレッド止まってプロセス落ちるとかありましたね。1回サーバー止めちゃって大騒ぎしました。(苦笑)

竹迫 そうか。ブロック待ちが発生するとそこで詰まっちゃうんだ。じゃあ、つらい話をしてくれた池田さんには、エンジニアには必須の飲み物をプレゼントします。(笑)

池田 ありがとうございます。

竹迫 これ飲んでるおばちゃんが100歳以上生きてるとか言われている、スゴイ飲み物です。(笑)

池田 マジですか。これで長生きしているって感じですか。

竹迫 釘宮さんは、Androidエンジニアとして入ってきたじゃないですか。非同期的なイベントを掴んでそこで処理するって、結構当たり前な感じなんですか。

釘宮 そこはAndroidの中でもやり方がずっと遷移してきていて、スレッドとハンドラーっていうのを使うっていうのが、多分プリミティブなやり方で、そのあとにイベントバスでやろっかみたいな話があったりとか、でもやっぱりオブザーバーパターンに戻ろうかみたいな話があったりとか。最近はやっぱりRxとかリアクティブ系の話を非同期に投入するのが主流だったりします。

竹迫 なるほど。ここで松川さんに登場していただきたいんですけど。Scalaだと、そういった手続きを宣言的にラップするようなことは結構やります?

松川 そうですね。結構、何か今使ってるPlayフレームワークとかはリクエストからレスポンスまで全て非同期で返す思想で、Futureって呼ばれる非同期特性をもったモナドの型で全てを返す形になっています。ユースケース層は関数型の手続きをきれいに書ける特性をすごい生かしやすいところだと思ってるので、ScalaのライブラリもDBのI/Oを表す型があるんですけれど、それも実行するとFutureになるので、UseCase層でDBのtransactionを全部管理して、最後の最後にDBIOをtransaction実行して、結果をFutureで返すようなことをしてます。

竹迫 松川さんも、『スタディサプリENGLISH』リリースしたあとに途中から入ってきたと思うんですけども、当時って、Scalaのサーバーサイドってまだまだ伸びしろがたくさんあったと思うんですよ。松川さん、その当時DDDをちゃんとやりたいっていうのをすごい言ってたと思うんですけど、実際入ってみてからDDDってのはどんな感じでやられてきました?

松川 最初入ってガツッとアーキテクチャーを変えるってことはやっぱできないなと思っていて、ちょっとずつ直そうみたいな感じでやってたんですけど。ちょうど新しいTOEIC®のアプリを出すタイミングで、もう既存のやつだけのアーキテクチャーをそのまま進めていってもつらいところが見えてきたなってのがあったので、機能分割してマイクロサービス化して、で、新しく作ったり、書き直した小さいサービスから戦術的DDDを入れて・・・といった形でやっています。

松川 クリーンアーキテクチャーを採用しています。レイヤードにDIPとUseCase,Port&Adapterあたりの考えが追加されたようなものです。技術的な関心事を完全に一番外の層に追い出して、ユースケース等は全て手続きだけを書けています。そこに技術的関心事をDIするみたいな感じの書き方をしてるので、Scala書いたことのない人とかでも、for式で全てユースケースを書いているので、for式の変数を読んでいくと業務手順が分かるようになってます。

竹迫 釘宮さんはAndroidエンジニアですけど、Scalaも結構書いてます?

釘宮 Scalaばっかり書いてます。今年入って8万くらい。

竹迫 それすごいですね。

一同 (うなずく)

竹迫 8万行超えたってことで、飲み物をどうぞ。(笑)

松川 本当に釘宮さんには助かりました。まさに、リリースターボエンジンでした。(笑)

竹迫 でも、無事に今年TOEIC®の新規サービスのリリースができて、あれですよね、思ってたよりも想定以上のやっぱり反響があって。

松川 売り上げもすごいですね。

竹迫 申し込みとかやばいっすよ。

釘宮 すごいっすね、何か。

松川 売り上げだけが癒してくれるってやつです。(笑)

竹迫 1カ月の集客目標が、もう何か2日ぐらいで達成したとか聞きましたけど。

池田 何か、リリース直後にもう初速好調とか言ってましたもんね。

竹迫 だからエンジニアで急務なのは、その急激に増えるユーザーに対してちゃんと提供できるように、ちゃんとスケールさせていくっていうところなんですよね。

釘宮 そうですね。その中で、マイクロサービスとかが多分キーワードになってくるのかなと思ってます。新規開発と平行で今回大変でしたが、その中で新機能を追加しやすい、スケールしやすい基盤ができたので、本当に良かったなって感じです。

松川 ガッと変えたので、変えきれないところみたいなのがあったりして。そろそろ回収してかないといけないなって感じですね。

堅実な設計を支える
豊かなScalaの表現力

釘宮 今gRPCを使ってるんですけど、ScalaでgRPCを使ってる例ってあんまり聞かないですよね。

松川 国内開発としては最大規模かもしれない。関数型界隈で有名なメンバーが導入手順とかを公開くれてて、それを触りながら、うちのアーキテクチャーに落とし込めるかなっていうのをチクチクと試して、で、ベンチマーク取ってみたらすごい早くて採用に至りました。最初は普通にPlayのHTTPで内部通信もやっちゃおうかなと思ったんですけど、やり取り用のJSONモデルを手で書くのがすごいつらくて。

竹迫 あとはオーバーヘッド、気になる感じですよね。

松川 そうそう。でも監視のしやすさとか、HTTPはリソースがたくさんあるので、通信の可視化はやりやすいっていうのが悩みどころでした。どっちを採用するか結構迷ったんですけど、パフォーマンスで困るの嫌だなってのと、gRPCだとProtocolBufferていう、これもGoogleが作ったインターフェース共通化できる仕組みがあって、それですごくシュッと導入できたのが決め手でした。

竹迫 シリアライズ・デシリアライズみたいな、あんま気にせずに行けるっていう感じなんですか。

松川 そうそう。まったく気にしなくてよいんです。

釘宮 モデルを共通化で使えるんですよね。あれって、実際は内部通信で使ってるけど、対クライアントとも実はできたりするんですね。

竹迫 じゃあ、それを解析するようなアプリもちゃんと。アプリとかじゃないんですか?

松川 アプリにもProtocolBufferのprotoファイルだけ渡して言語用にライブラリが用意されているので組み込んでコンパイルしてくれれば、勝手にモデルとクライアントが自動で生成されます。

竹迫 スタブコードみたいなってこと。

釘宮 そうそうそう。

松川 実装だけ、インターフェースに則ってサーバーでやっとけば良い感じです。

竹迫 いいですね。結構APIを作る人にとっては割と理想形の感じですね。

松川 すごいきれいだなと思いましたね。Google様様や。

釘宮 RMPではクライアントには採用してないんですが、今は、採用してるとこ多分ありますよね。

竹迫 通信量とかやっぱ減ったりするんですか、それ。

池田 そうですね。やっぱJSONだと大きくなるという。テキストプロトコルだと容量大きくなっちゃうのがあるので、そういう意味ではバイナリはやっぱそこは高速ですし。

釘宮 確かにキュッとなってる。

池田 サイズも小さくていいんじゃないかなって感じですよね。

竹迫 すごい、10年、20年ぐらい前だと、SOAPとか、WDSLとかって時代もあったんですけど、そこはJSONが出る前のXMLだったんですごい狭隘だった。スタブのコードは作れたんだけど、ちょっとね、通信量が。

池田 Scala、特にPlayFrameworkだとSlickっていうデータベースにアクセスするライブラリがあるんですけど、あれが結構癖あるものなので、やっぱちゃんと使いこなさないと変なクエリを投げたりしてデータベースに負荷かかったりだとかして、さっき言ってたスケーラビリティーっていうところにちょっと影響出ちゃうんで、そこは多分ちゃんと設計してかないといけないんじゃないかなっていうところはありますね。

竹迫 ちなみに、コーディング標準みたいなのってあるんですか。

松川 そうですね。層に分けられてるので、この層に従ったものを書いてもらっていて、例外があればレビューで拾うみたいな感じですね。

釘宮 結構簡単、見れば分かるコードなので。

松川 関数型だけだとそうは書けないんですけど、オブジェクト指向とのハイブリッドなので。

釘宮 そうですね。結構設計がしっかりしてるから、誰が見ても割ととっつきやすくはなっていて、Scalaってとっつきづらい感じもあるかもしれないですけど、普通にAndroidやってる新卒エンジニアとかでも全然書けるレベルくらい、可読性はある感じになっていると思っていて、なんで、みんなすんなり入って、普通に書いてくれてますね。

池田 Scalaの良さは、表現力が豊かな所だと思います。

松川 余計なこと書かなくていいとか、何て言うんですかね、こう動いてほしいみたいなのをシャッと書けるみたいなこととか。

釘宮 Javaだとできないことを表現できるというか。

松川 マッチケースとかマジ最高です。

置かれた卓球台は真剣勝負の舞台
快適な開発環境、海外視察制度も充実

竹迫 ノートPCも最近MacBook Proみんな使ってますけど、最近、20万円を超えるものじゃないと、ちゃんとしたスペックも買えなくなっちゃったから。

松川 そうなんですよね。Scalaだと特につらくて。

竹迫 そのために、ちょっと社内の制度もちょっと変えて、30万近い、別にMacBook Proも買ってもいいよみたいな感じにして。生産性を向上させたほうが圧倒的にいいと思います。

釘宮 環境も良くなってきてますよね。

松川 だいぶオフィスが居心地いいですからね。

釘宮 卓球しまくってますからね。

松川 そうそう。あれは本当に嬉しい。

釘宮 ベンチャーあるあるとかで卓球台置くんですけど遊びづらいっていうのがあったりするじゃないですか。でもうちは普通にガンガンやっちゃってる。

松川 ガンガンやってますからね。マイラケット何人買ったんだみたいな。

竹迫 卓球大会もやりましたよね、去年。元卓球部の人とか。

松川 ガチ。半ズボンはいてましたね。

竹迫 中国出身のエンジニアの人とか、すごい動きが俊敏だった。

松川 卓球エリートでしたね。あれは。えぐい回転をしました。

竹迫 えぐい回転なんだ。(笑)釘宮さんは今年からマネジャーっていう立場になって、みんなが働きやすい環境作ってくっていうところで、まだまだやれることって結構ありそうですか。

釘宮 インフォーマルなコミュニケーションで繋がりをもっておくと、仕事上での接点がない人でもいざって時に頼れますよね。人数がすごい増えたので、いろんな課題が出てくるたびに、みんなで解決して行けたらな、みたいな感じです。

竹迫 そうね。だから、少ない人数で始めるときは割と幅広くやれる人は必要なんだけど、やっぱり人数が増えてくると専門的なスキルを持ってる人がすごく必要になってくるよね。

釘宮 とはいえ、スポットで入れる人っていうのもやっぱり重要になってくるなと思ってて、僕もサーバー入ったりとか、逆にクライアントがサーバー入ったりとかしてるのも、補い合いながらやっていくっていうのが要るなって感じですよね。

竹迫 結構ね、映画製作とかに近いなと最近思っていて。最初数人ぐらいで自主製作映画みたいなのを作るってときは、みんなでワイワイ全部ね、監督が編集したりとか、全部やるじゃない? でもハリウッドの映画とかは完全に分業体制らしい。専門の人がめっちゃ多いじゃないですか。やっぱり規模が大きくなればなるほど専門的に分業してやっていく。そこをどうやって統合して開発を進めていくかっていうところが大事になってくるかなと。

釘宮 分業し過ぎると作業者になっちゃわないかみたいなのも、ちょっと課題としてあるというか。

竹迫 でもそういった意味だと、Androidエンジニアの新卒メンバーとかは実際に1エンジニアなんだけど、自分でこういう機能つくったほうがいいとか、勝手に何か提案して入れてくれてますよね。リクルートって、そういう事をすごい求めてる感じがする。

釘宮 求めてるし、提案しやすい環境ですね。

池田 BtoC向けサービスだとユーザーの意見が散逸的になることがあるので、フィードバックに全て目を通しきれないみたいな事がよくあるんですけど。『スタディサプリENGLISH』はちゃんと学習目的で使ってるんで、そういう目的の人が使ってるから意見のコンテキストがずれにくくて意見を聞きやすい気がしますね。

池田 あと、忙しい中でもすごいみんな仲良くやってるなとは思いました。

竹迫 ミドルマネジャーの仕事としては、みんなが働きやすい環境をどうやって作っていくかが大事ですよね。開発ツールとかは何を使ってるんですか、エディターとか。

松川 エディターはIntelliJを会社からサブスクリプションを提供していただいて。感謝してます。

竹迫 高いっすよね。全然普通に買ってるけどさ。PCはMacBook Proが標準?

松川 そうですね。SSD当たり前だし。

松川 そうですね。最近だと入社した人にどれを配ってるんだか分からないですけどね。

釘宮 今は普通にGitHub使って、CircleCIとかJenkins CIとかして、っていうのやってますよね。サーバーがSwaggerを使っているので、APIが更新されたらCI回って、クライアントサイドのJSONモデルを自動でアップデードしたプルリクを送ってくれるってことをやりたいなぁ。

松川 超かっこいい。サーバー的には、レスポンスの型を変えるのにすごい億劫になっちゃうので、そういうのがあると嬉しい。

釘宮 そこら辺はちょっとやってみたいですね。時間あるときに。

竹迫 あとは、釘宮さんが今着てるTシャツはI/O。これ、行ったんですか。

釘宮 行きました。気付いてくれて、ありがとうございます。(笑) 自己起案制度というのがあって、自分でこれ行きたいですって手を挙げると、海外カンファレンスも行かせてくれる。

竹迫 松川さんは、どっか行ったんですか。

松川 re:Inventでラスベガスに。

竹迫 AWSのイベント。

松川 最高でした。

池田 僕も今年行くんで。

松川 楽しんできてください。

釘宮 あとリモートワークは本当に良くて、僕は公園でリモートワークしてたりもしてるんで。

竹迫 いいですね。

釘宮 冬は寒いんで、ScalaのプロジェクトとSwiftのプロジェクトをどっちもビルドして、パソコン温めるまでやってました。

竹迫 CPU。ファンからでも結構熱い。

釘宮 でも、ちょうどいい温かさ。

竹迫 暖房要らないみたいなやつですか。

釘宮 ちょいリフレッシュしたかったんで、そういうとこでやりたいなみたいな。会社の規定である2時間以内に通える範囲なんで。

池田 僕もリモート使ってます。各地に提携のサテライトオフィスがあって、そこに行けば1人で集中してできるっていう。

釘宮 そうですね。朝混む時間をさけて、ちょっとリモートで集中して作業してから、ごはんを食べて12時ぐらいに来ても別にいいし。

松川 みんな11時ぐらいですもんね、出社が。

良いコードが良いエンジニアを育てる
共に楽しみ、共に成長するために

竹迫 今は、まだまだエンジニアほしいって感じですよね。足りないんですよね。

釘宮 足りないです。あと50人ぐらいほしい。(笑)

竹迫 やっぱり一緒に気持ち良く働ける人がいいですよね。

釘宮 多分2タイプあるのかな。技術に完全に振ってる人も来てほしいし、企画側の人にも歩み寄れるエンジニアがいたらいいな、とも思ってますね。

竹迫 エンジニアはやっぱり内発的動機を持って、自分たちでプロダクトを作ってるっていう意識を持つのが大事だから、そういうことは結構やれてる人はいるけど、もっともっとそういう人が集まってくるといいサービスになるのかって感じですね。

釘宮 そうですね。どっちかだけだと良くならない。ていうかビズ側寄りなエンジニアだけがそろっても多分大規模では作れないと思うし、とはいえ技術志向が固まっちゃったら、企画側と亀裂が入っちゃったりして、うまく回らない気もするので、バランスが大事ですよね。

池田 今後多分、いろんなサービスからDB見られるはずなので、データベースをいかにスケーラビリティ高くする設計をしていくことが、これからすごく大事になってくると思う。ビジネス的にも今ちょうど伸びてるところなので、そういうのに関わりたいって思ってる人は、すごくいいタイミングというかいいチャンスじゃないかなって、そう思いますね。

竹迫 今はあれですねAWSのRDSをそのまま使ってる感じですか?

池田 そうですね。MySQL。でも、さっき言ってたマイクロサービス化が進んで、ユーザーの認証機能を切り出してたりするんで、キーバリューストアとかを使う機会もありそうですね。バックエンドでいろいろチャレンジする余地はすごくある気がしますね。

竹迫 そうか。キーバリューストア入れてないんだ。結構まだまだ改善の余地はかなりありそうですね。

松川 インフラもサーバーもできる人が求められます。

釘宮 Scalaじゃなくてもいいっすよね、それでいうと。Javaとかでも全然いいんで。

松川 HaskellとかJavaとか触ってましたみたいな人でもいいっすね。

竹迫 だから、小っちゃいトイプログラミングとかじゃなくて、実用的な大規模なプロダクトをどうやって型で作ってくかみたいなの。

釘宮 設計がちゃんとしてると若手が育つんですよね、何か。

松川 名言が出ましたね。素晴らしい。

竹迫 でも、いいものに常に毎日触れるって大事だよね。

釘宮 イケてないコードとずっと戦ってても、それを対処する方法しか身につかないんで。

池田 本当に伸びてるサービスに関われるって、エンジニアとしては成長のチャンスだと思うんで、それが本当にいいタイミングじゃないかなって気がしますね。

釘宮 コード書いてるだけで学びがたくさんあるんで、ぜひって感じですね。

竹迫 これから勉強したいっていう人でもいいので、一緒に成長をしていける人募集中!って感じですかね。本日はありがとうございました!

より技術的な側面からもっと知りたい方はこちらの番外編をご覧ください♪
「スタディサプリEnglish大規模改修の裏側」

採用情報

  • 営業総合社員(新卒・中途)はこちら

  • 企画スタッフ職はこちら

  • エンジニア・デザイナー職はこちら

同じカテゴリの特集