AWS Startup ブログ
【前編】Amazon ECS と Spot インスタンスを使いこなす Repro 株式会社 CTO 橋立さん に、開発体制や Repro ならではのシステム要求、AWS の活用方法をお伺いしました
みなさんこんにちは、Startup Solutions Architect の塚田（@akitsukada）です。
今日は、パーフェクト Ruby の著者の一人であり、2016年の CTO Night powered by AWS にて CTO of the year 2016 を受賞された Repro 株式会社の CTO、ジョーカーさんこと橋立友宏さん（@joker1007）に、Repro というスタートアップのこと、開発に関すること、AWSの活用方法、今後のチャレンジなどを伺ってきました。前後編に分けてお送りします。
目次
-
前編（この記事）
- Repro と開発体制について
- Repro における CTO としての橋立さん
- Repro が求められる技術要件、課題と AWS の活用（続く）
-
後編
- （続き）Repro が求められる技術要件、課題と AWS の活用
- Docker コンテナオーケストレーションサービスと Serverless について
- マネージドサービスの恩恵
- 今後のチャレンジ
- 読者・Startup エンジニアへメッセージ
Repro と開発体制について
—- Repro という会社、サービスについて簡単にご紹介いただけますか？
Repro というサービスは、モバイルおよび Web アプリ向けの、ユーザー行動分析およびマーケティングオートメーションサービスです。ユーザーの属性情報や行動履歴を収集、可視化できる他、それらの情報を元にユーザーをセグメンテーションし、任意の条件を満たしたユーザー集団に通知を送ることができます。
会社としては2014年の設立以来成長が続いていて、2017年11月に代々木の新オフィスに移転していますが、その後も増床しています。
—- 現在、どんな開発体制を取っていますか？
エンジニアとしては 30 人前後です。ちょうど今月くらいから開発のやり方をけっこう変えて、大規模 Scrum いわゆる LeSS（Large Scale Scrum ）というのをやってみています。
チーム構成は、主にサービス開発を行うチームが 4 つあります。各チームが Sprint でやることをフィーチャー単位でアサインされ、開発にあたります。またそれ以外にも、データを活用して AI を交えた研究開発を担うチームとして Repro AI Labs が存在します。
— Repro の機能開発を行うチームとしては、基本的にはクロスファンクションなチームが４つあって、それぞれのチーム内で開発タスクが完結するようになっているのでしょうか。
基本的にはそうですね。その中でも、インフラが得意なチーム、モバイルアプリが得意なチームなどの “色” はありますが、基本的には各チームがオーナーシップを持ってフィーチャーの開発に当たります。
— Amazon、AWS の開発思想にも似た部分があると思います。Amazon に Two Pizza Rule という考え方があるのですが、それが開発チームにも適用されているんです。各開発チームは「二枚のピザでちょうどいいくらいの人数」で、自分たちのプロダクトに関する全面的なオーナーシップを持って取り組んでいるんですよ。
面白いですね。中にはインフラ系のタスクなど、チーム横断的に作用するものももちろんあります。
Repro における CTO としての橋立さんとは？
— ジョーカーさんといえばパーフェクトRuby の著者だったり、最近では RubyKaigi で発表されるなど Rubyist としてのイメージも強いんですが、2016年の Tech Crunch CTO Night では CTO of the Year を受賞されるなど “CTOキャラ” でもあります。Repro ではどんな CTO なんですか？
どんな CTO か ですか、難しいですね（笑）。
— これはぜひ今日聞いてみたくて。AWS がオーガナイズしている CTO コミュニティイベント CTO Night & Day でも、参加している CTO 間で「CTO 像」のような話題がよく上がるんですが、CTO のキャラって会社やフェーズ、人によってそれぞれだと思うんです。ぜひ、ジョーカーさんがどんな CTO なのか教えてください。
そうですね。自分の場合は、プロダクト開発もするし、最近はチーフアーキテクトに近いところもあると思います。人が増えてくるに連れて、自分の仕事を抱え込まずできるだけ減らそうと心がけていますね。
会社全体で設計に悩むことがあったようなとき、最終的な相談先になるような役割です。筋の良し悪しを見極めて、技術的な意思決定をしています。または、ある程度長期的に、サービス・システム視点を持った上で根本的な設計指針を考えておくようなこともします。
例えば、Repro のサービスってとてもデータ量バウンドな面があるんですが、これがいつか 10 倍、またはそれ以上になっても耐えられるように、という見込みで作っておく必要があるんです。または、ビジネス面での要求としてリアルタイム性をもっと高めていく必要があったりもします。これらを実現できる構成を基盤レベルから考え、実現可能であることを検証し、最初の作り込み部分まではある程度やっておく、といったこともしています。
— 以前は SNS 上でもよくコードのリファクタリングをされているような姿が見えていたのですが、最近はよりシステムアーキテクチャやグランドデザイン寄りの仕事が多いのでしょうか。
今でもどちらもありますが、後者の割合は増えましたね。これまでにだいぶたくさんのコードを殺してきましたので（笑）。それと、やはりシステムには様々な会社の局面での事情や歴史が現れていて、それらを広く把握して横断的に見られるのは自分だったりするので、そういう面もあると思います。
— なるほど。一方 CTO とは、技術面から会社を運営する経営メンバーの一員でもあります。ジョーカーさんはどんな形で経営に関わられているのですか？
これも正に会社によって異なると思いますが、僕はビジネスサイドの ー 例えばマネタイズの施策みたいなことより、やはり技術面からのコミットをしています。例えば、ボードメンバーで新しい方針を議論するとき、実現に必要な金銭コストや人的コスト感、実現可能性などを責任をもって発言し、会社の方針策定を支えます。やはり、今 Repro が持っているエンジニアのリソースや能力、可能性を把握しているのは自分なので。
— Repro といえば、VPoE (VP of Engineering ) の三木さんもいらっしゃいますよね。CTO と VPoE で、どういった役割分担やコラボレーションをされていますか？これも CTO Night & Day でよく議論されるトピックでもあり、このブログの読者の皆さんも聞きたい人が多いんじゃないかなと。
三木は今、HR（Human Resources）面やビジネス面を含め、広く組織のテコ入れをしてくれています。また、社内外で人をグイグイグリップしてくれるのも彼ですね。彼は僕よりそういう適正があると思います（笑）。対して、僕は社内の技術者全般からの技術的な相談役の面が大きいかなと。例えば、各チームが仕事の優先順位を決めるときに相談を受け、技術的見地から支援をしたりですね。
あと、人のマネジメントは当初やっていたのですが、精神的にも自分向きではない面があって、基本的には各チームのマネージャーに移譲しています。また、プロダクトマネジメントは執行役員の林が非常に優秀で、彼がリードしてくれています。
Repro が求められる技術要件、課題とAWSの活用
— Repro では、どんなシステム要件や機能要件があるんでしょうか？何か Repro ならではの特性などあるんでしょうか？
まず先程少し話した点ですが、蓄積されるデータ量がとても多く、且つそれが重要であることがあります。これが将来的に 10 倍 20 倍になっても耐えられるようにシステムのスケーラビリティを確保しておく必要があります。
次にリアルタイム性のニーズです。ここでいうリアルタイム性とは具体的には、エンドユーザー（Repro が組み込まれた Web・モバイルアプリのユーザー）が Repro に属性やイベント情報を送信してから、Repro ユーザーがそのデータを確認できセグメンテーション条件として利用できるまで、セグメンテーションプッシュ通知の送信を登録してから実際に通知が送信され始めるまで、さらに送信され始めてから送信し終えるまで、といった各所にかかる所要時間をできるだけ短くしていく必要があります。これらを実現するデータ処理パイプラインは、Repro のサービスにおいて非常に重要です。
また、「大きなクライアントさんが Repro を導入してくれると一気に Repro に流れ込むトラフィックが増える」というのがあります。例えば、Repro から見ると一社さんが Repro を導入してくれたに過ぎなかったとしても、実はそのアプリのユーザー数はめちゃくちゃ多かったりして…。これは営業活動なども絡むので、事前に把握することは不可能ではなく、できるだけ把握しておきたいところです。
ところが、より Repro らしい難しさとして、「どうしても事前の把握が難しい急激なスパイクアクセス」というものがあります。これは、大きなクライアントさんが大規模な一斉プッシュ通知を配信したとき、短時間中に多数のアクセスが Repro のバックエンドシステムにも押し寄せるというものです。仮に通知を配信するのが自分たちであれば、大量の通知を配信する前にアクセス増に備えてバックエンドサーバーを増強しておくなどの対策が取れるんですが、普通自社サービスのユーザーに通知する前に第三者の Repro に事前に教えてくれたりしないですからね（笑）。自分たちでコントロールできないタイミングで突発的なトラフィックが生まれる。これは本当に難しいです。
— それは確かに難しい要件ですね…。しかも Repro へのアクセスって、Cachable な Read アクセスではなく、ユーザー属性やイベント情報などの Write Heavy な類のものですよね。実際のところ、どうやってその 段差 のあるアクセス増に対応されているんですか？
（後編に続く）
ここまでが前編となります。いかがでしたか？Repro という会社における開発チーム体制や CTO としての橋立さんについて伝わったでしょうか。後編では、Repro ならではの技術課題とそれに対していかに対応しているかなど、技術的なトピックを多めにお届けする予定です。
後編は数日後に公開予定です。Stay tuned でお願いしますmm
このブログの著者
塚田 朗弘（Akihiro Tsukada）@akitsukada
Serverless, Mobile, Blockchain, FinTech Security あたりをよく触っているスタートアップ ソリューションアーキテクトです。