世界に5400万ユーザーを抱える日本発のプロダクト「TimeTree」
──自己紹介をお願いします。
河野洋志氏（以下、河野）：CTOの河野洋志、ニックネームはScottです。TimeTreeの創業メンバーが新卒入社時の同期だった縁で、「TimeTree」がプロダクトとしてリリースされてから半年ほどで入社しました。それまではサーバーサイドやデータベースに携わっていました。2023年からはCTOとなり、エンジニアのマネジメントやスクラム開発導入などを行っています。
金井栄喜氏（以下、金井）：エンジニアの金井、ニックネームはmiuです。前職でインフラを担当していたこともあり、入社後はバックエンドを手伝いながらインフラを担当し、SREチームを立ち上げました。現在ではSREチームのマネージャーをしています。
──TimeTreeはどのようなサービスですか？
河野：カレンダーシェアサービスです。一般的にカレンダーサービスは手帳をベースにしていますが、TimeTreeは壁掛けカレンダーをデジタル化したイメージです。主に家族、パートナー、職場のスケジュール管理でお使いいただいてます。
金井：よく Google カレンダーと比較されることがあるのですが、Googleカレンダーだと、まず個人のカレンダーがあり、他人と共有することもできます。一方、TimeTreeは1つのカレンダーを誰かと共有することがスタート地点にあるのです。
河野：日本だと家族のスケジュール管理に使っていただくことが多いです。ドイツもそうですね。アメリカやイギリスだと友達同士で、韓国や台湾だとパートナーと使うなど、国によりカルチャーの違いが出ていて面白いです。
──最初からグローバル展開を狙っていたのでしょうか？
河野：創業メンバーが当時のYahoo! JAPANとカカオジャパンのジョイントベンチャーに在籍していた多国籍チームだったので、多国語展開は当然の感覚でした。日本語、英語、韓国語から始まり、対応言語を増やしました。かつてはユーザーさんから直接ローカライズ協力の申し出もあり、「なんて優しいんだ」と感激したことを覚えています。
──おすすめの使い方はありますか？
河野：TimeTreeは予定にコメントを付ける機能があります。家族やグループで作成した外出予定にコメントすることで、会話が広がるのがおすすめです。
金井：あと予定にファイルも添付できますので、マンションに掲示されている清掃や防災点検のお知らせなどを撮影しておいて、OCRで予定を自動登録することができます。チェックリストもあるので、買い物にも便利です。
100億レコードを超えるテーブルも！ 日本から世界のデータを扱うには
──プロダクトの技術的な特徴はありますか？
河野：クライアントはiOS、Android、ブラウザで、バックエンドは全部Ruby on Railsで書かれたAPIで動いています。尖っているというよりはシンプルなデザインにしています。とはいえデータ量が多いのが悩みの種です。
金井：もともとインフラ担当が少なかったなかでサービスをスケールしたので、なるべく手がかからないような運用を心がけた設計になっています。キャッシュがあり、入口にロードバランサー、サーバー、データベース、ストレージとシンプルな構成です。
──データ規模はどのくらいですか？
金井：バックアップで7TB、100億レコードを超えるテーブルもあります。日本のデータセンターにデータを置いているので日本国内からのアクセスなら50msec、ヨーロッパだと100〜120msec、地球の裏側だともう少しかかります。できるだけインターネットを通さずメインクラウドのAWSネットワークでアクセスできるように、エッジロケーションを使うような構成にしています。最近は円安なのでコストも気になるところですが、できる対策をしっかり行った結果AWSの方からも「もう、やりきっている」と太鼓判を押していただきました。
河野：よく「なぜサーバーをマルチリージョンにしないのか？」と聞かれますが、1つはシンプルな運用でコストを下げたいのと、もう1つはデータベースなどの通信回数を減らすために、シングルリージョンにしています。
データベース移行プロジェクト始動、技術選定のポイントは？
──アプリケーション側はどのようになっているのでしょう？
河野：1つのAPIは1つのことしかできないような設計にすることで、コードやテストをシンプルに保つようにしています。いろんなことができてしまうエンドポイントで苦労した経験もあるので。ただ、クライアントの実装とのトレードオフもあるので、みんなで話し合いながら全体としてシンプルな構成を目指しています。
金井：私が入社した2018年時点ではユーザー数が1000万人ほどで、それでもデータ量がかなりありましたが、そこからユーザー数やデータ量が増え続けてもパフォーマンスは落ちていません。データが増えても影響が出ないようなAPIになるように考えられているからだと思います。
河野：社風かもしれませんが、シンプルさは常に意識しています。エンジニアは仕様がおりてきたらその通りに開発するのではなく、目的を意識したうえで「それならこうしたほうがよりシンプルにできる」とアイデアを出したりしています。
──技術的な課題はどんなところにありますか？
河野：データ量が大きいにつきます。何か新しいことをやろうとしても5400万のユーザーがアクセスすることを想定し、パフォーマンスを考えた設計にしなくてはなりません。特にデータベースに変更を加えるような機能実装が難しくなってきています。
金井：ストレージ容量が大きくなり、物理的なスケールアップ上限が目前に迫ってきています。以前から課題でしたが、昨年から本格的にデータベース改善プロジェクトとして動いています。移行する際の選択肢としては「Vitess（シャーディングツール）を自前で運用する」「VitessのマネージドサービスとなるPlanetScaleを使う」「Google Cloud Spannerを使う」という3つがありました。その後、コストやサポート、運用負荷などを総合的に考慮した結果、Google Cloud Spannerへの移行を決断し、作業が進んでいます。
河野：大きな決断でしたので、エンジニアだけではなく経営層も巻き込んで決断しました。
金井：エンジニアから声をあげ、プロジェクトとして立ち上げて、最終的にクラウドの移行まで動けた。ボトムアップの会社であるTimeTreeの強みが出た事例だと思います。
──ツール選定はどのように進めていったのでしょうか？
河野：ベタですが、大規模サービス運用をしているサイトの記事からバックエンド構成を調べて、自分たちに合うものを議論しました。Vitessだとデータベース分割のミドルウェアのようなもので、使用するデータベースは問わないのでアプリケーション的に親しみがあり、AWSのままでいいというメリットがありました。しかしシャーディング運用しなくてはいけないので、マネジメントコストがかさんでしまう。VitessのマネージドサービスとなるPlanetScaleでは、我々のデータ量だと予算超過になってしまう。あとまだ日本語のサポートがなくて時差が生じるのも厳しいという判断になりました。
──そのような技術選定を進めるうえでのポイントは？
河野：ありきたりですが必ずメリットとデメリットを列挙して、みんなで議論して決めることです。実は私、最初は「Vitessの自前運用」推しでした。移行コストを過大評価していたのですが、最終的にはGoogle Cloud Spannerで納得しました。
金井：私はGoogle Cloud Spannerを推していました。最初の意見は異なっていましたが、理由を説明したら納得してくれましたね。
河野：新しいことは悪影響が少なければ試そうという雰囲気も大事です。「新しいからやりたいです」だけではダメですけど、ちゃんと理由があればみんな話は聞きます。いつもみんなで決めているので、過去の試行の共通認識も持った上で話を進められます。
──現在データベース移行作業中とのことですが、どんなところが辛いですか？
金井：やはり最も辛いのはデータの大きさです。データが小さければ試行のスパンを短くできますが、データ量が大きいので移行するだけで数カ月かかってしまいます。長い期間をかけて行うプロジェクトですが、期限内に必ずやり遂げなくてはならないプレッシャーはありますね。また、経営層への説明用にプロジェクトのロードマップを作る時には、どの程度の粒度で資料を作るか迷いました。
あとAWSからGoogle Cloudへの移行にあたり、大量のインプットも必要になります。チャレンジングでなかなかしんどいことも多いですが、その分やりがいがあって楽しくもありますね。
河野：プロダクトの特性もあり、昔のデータにもアクセスがあるので、全てのレコードをアクティブにしなくてはならないのが難しさを助長させています。
「誰のために、何をどう作るのか」これからのエンジニアに求められる総合力
──プロダクト開発における課題解決のアプローチや思いについて教えてください。
河野：「ユーザーさんのために」という思いはいつも大切にしています。ありがたいことにTimeTreeはユーザーのみなさんからいつも温かい声をいただいていて、安定稼働させることでその声にお応えしたいと思っています。
金井：ユーザーさんのことはもちろん考えつつ、SRE担当としてはランニングコストへの責任も持っているので、サービスの信頼性を守りながら会社の収益を担保するバランス感は大事にしています。これだけ大規模サービスに携わることはなかったので、すごくいい経験を積むことができています。
──課題解決を進めるうえでの開発体制についても教えてください
河野：基本的には各自テーマを持ち、自由に考えてもらっています。それを各ディビジョン（部署）を統括するCxOと常に話し合いながら進める体制です。チーム間の横串のコミュニケーションはまだ課題がありつつも、プラットフォームごとにチームがあって連携しています。
金井：SREチームは人数が少なく、ディビジョンに直接紐付かないので横串の活動が主軸になっています。例えばiOSエンジニアが仕様を変えるとサービスに影響がありますが、SREがロードバランサーを変更してもサービスに大きな影響はあたえないので、比較的動きやすいと言えますね。
河野：エンドユーザーの課題解決についてはプロダクトディビジョンという部署があり、ここで課題に対してスクラムを回しています。ドッグフーディング的に進めることもあります。TimeTreeでは広告事業が収益の柱になっていますが、広告は闇雲に配信するわけではなくて、ユーザーさんにとって見て良かったと思っていただけるような広告を作ろうとしています。
金井：各ディビジョンがやろうとしていることに対して、SREチームはどういう設計で手伝えばいいかなど提案したりしています。基本的には問題が起きないようにするのがSREチームの考えなんですよね。問題が発生せずにユーザーさんが自然に使えるのが一番で、それを継続することによりユーザさんからの信頼性を高めていくことが目標です。
──エンジニアはTimeTreeでどんな成長が見込めそうですか？
河野：ユーザーさんのためにいいと思うことができる環境がありますし、それは維持していきたいですね。自分で課題を発見して解決していける人なら、すごく成長を感じられると思います。Ruby on Railsひとつ取ってもコードやフレームワークの理解が必要ですので、すごくスキルアップできるんじゃないかな。
金井：私たちが入社したころはまだユーザー数が今ほど多くなくて自由に動けましたが、今はユーザー数が増えて社会的な注目度も高まり、以前よりもサービスに求められることや解決しなければならない課題は大きくなりました。個人的にはそこが魅力だと思っています。課題に自律的に立ち向かうことで達成したら必ず成長があると思います。
河野：それこそ開発環境に生成AIが浸透してきている昨今、エンジニアの生産性は飛躍的に向上することが予想されます。だからこそ、開発の前段階にある「誰のために、何をどう作るのか」にしっかり関われる、総合力が求められると思います。「いまなぜこれが必要なのか。もっとよくするにはどうしたらいいか」を常に考えるのがTimeTreeのエンジニアなので、（入社したら）そういう経験を積んでもらえたらと。
金井：それと、今はCopilotやAIを活用することは自然な流れだと思うので、使用するなかで新機能のアイデアにつなげる経験が積めるかもしれません。いろんな可能性を感じながら使用してもらえるといいのではないでしょうか。
──最後に読者にメッセージをお願いします
河野：TimeTreeでは今クローズドなコミュニティーで使う「共有カレンダー」のほかに、イベント情報をオープンに受発信する「公開カレンダー」の拡大に注力しています。それ以外にも、これからどんどん事業を広げ成長していき、世の中の予定を全てTimeTreeに集めるという大きな野望を持っています。そのためにさまざまな方の期待に応えられる組織を作り、事業を展開していきたいです。
金井：ユーザー数が増えてデータ量の課題があるなかで、サービスも会社も大事ですが、自分の人生も楽しみながらサービスの成長を一緒に手伝ってくれる方がいるとすごくいいなと思います。
TimeTreeでは一緒に働く仲間を募集しています！
バックエンドやSREはもちろん、TimeTreeでは幅広くエンジニアを募集しています。本記事で興味を持たれた方はぜひTimeTree採用サイトからご応募ください。
