予定を共有するアプリから、予定を見つけるプラットフォームへ
──まずはお二人の自己紹介と、それぞれの担当領域を教えてください。
佐藤新悟氏（以下、佐藤）：iOSエンジニアとして、カレンダー本部に所属しています。主に共有カレンダー機能の開発を担当しており、2016年の入社からちょうど10年になります。TimeTreeでのニックネームはSionです。
田邉広樹氏（以下、田邉）：Androidエンジニアとして、カレンダー本部に所属しています。創業した2014年からTimeTreeのAndroidアプリをずっと担当してきました。共有カレンダー機能の開発が主な仕事ですが、ウェブチームに出向した時期もあります。ニックネームはHalです。
──TimeTreeはどのようなプロダクトですか？
田邉：家族やチームなど複数人で予定を共有できるカレンダーアプリです。個人の予定管理というよりも、同じカレンダーを一緒に使うという、家の壁掛けカレンダーを家族みんなで眺めるような体験をコアとして設計されています。ユーザー数は7000万を超えており、毎週リリースを続けています。
佐藤：技術面での特徴は、iOS・Androidともにネイティブで開発していることです。ユーザービリティの細かい調整がしやすいという理由でネイティブを選んでいます。また10年以上続くプロダクトなので、最初はObjective-CやJavaで書かれていたコードを、SwiftやKotlinに段階的に移行しながら、必要な部分だけ新しくするアプローチを続けてきました。
──今回のリニューアルの概要を教えてください。
佐藤：大きく3つの変化があります。まず「ホームカレンダー」の導入です。これまでのTimeTreeはカレンダーを起動するとそのカレンダーの予定が表示される、カレンダー中心の設計でした。今回の刷新ではユーザー個人を軸にして、複数のカレンダーの予定をまとめて俯瞰できる「ホームカレンダー」がトップ画面になりました。個別のカレンダーはその下の階層として開く形です。カレンダーが主役だった設計から、ユーザーが主役の設計に変えたイメージです。
次に「フィルターカレンダー」です。ホームカレンダーの上部にフィルターを設け、表示するカレンダーをオン・オフで切り替えられるようにしました。家族カレンダーだけ、仕事カレンダーだけといった絞り込みが直感的にできます。
そして「見つける」機能です。ユーザーが自分で登録した予定だけでなく、公開カレンダーで公開されている話題のイベントやセール情報、フォロー中の公開カレンダーの更新などを発見できる画面です。気になった予定は「気になる」ボタンを押してカレンダーに表示することもできます。自分で予定を登録するだけでなく、新しい予定を見つけるプラットフォームへという変化です。
──10年続いてきたアプリを、なぜこのタイミングで大規模にリニューアルしようと決断したのですか？
佐藤：「TimeTreeを、未来の予定に出会うためのプラットフォームにしたい」という構想は、実は創業当初からありました。ただ、まずはグループで予定を共有するという価値が評価されてサービスが成長していく中で、プラットフォーム化は後回しになってきた経緯があります。
既存の構造では「新しい機能を入れる場所がない」という課題も以前からありました。例えばハンバーガーメニュー（画面左上の三本線アイコンを押すと開くメニュー）の中にどれだけ新機能を追加しても、ファーストビューに入らないため使ってもらえないという失敗が続いていました。「そろそろやらなければ」というタイミングが今だったのです。
田邉：先ほどの3つの機能に加えて、今後リリースされるAI関連の機能なども「置く場所」をまず作る必要がありました。これまでどれだけ新しい機能を作っても、ハンバーガーメニューの奥に入れてしまうとファーストビューに出てこないので使ってもらえない。その失敗の繰り返しが、今回の判断を後押しした部分は大きいと思います。
1年かけて挑んだ、TimeTree史上最大のUI改修
──プロジェクトの体制を教えてください。
佐藤：「リストラクチャープロジェクト」と呼んでいました。構造改革を直訳した名前で、チーム内では「リストラPJ」と言っていましたが（笑）、もちろん窓際という意味ではありません。タスクフォース形式で、各部署から選りすぐりのメンバーを集めました。iOS・Androidエンジニアが最初2名ずつ、バックエンドエンジニア1名、PdM（プロダクトマネージャー）2名、デザイナーという構成で、最終的にはクライアントエンジニアが1名ずつ追加されました。
──プロジェクトの期間とリリースのスケジュールを教えてください。
佐藤：2025年5月頃から本格的に動き出しました。2025年12月に希望ユーザー向けのベータリリースを行い、2026年1月に「見つける」機能とあわせて本格リリースし、全ユーザーへの完全移行が完了しました。約1年をかけた大規模プロジェクトでした。
田邉：SREチームやCSチーム（カスタマーサポート）、広告チームなど、全社を巻き込んだプロジェクトになりました。
1週間のプロトタイプが証明した設計の正しさ
──新しいUXの設計をどのように検証していきましたか？
佐藤：まず画面構成を再現するプロトタイプを1週間ほどで作り、インタビューに応じてくれるユーザーをオフィスに招いて実際に触ってもらいました。私たちが最も気にしていたのは「ユーザーにこの構造変化を理解してもらえるか」という点でした。
ところが実際に触ってもらうと「何が変わったかわからないくらい、自然と使えている」という反応が多かったんです。チーム全体で「これはいける」という確信が持てた瞬間でした。
田邉：自分も「ユーザーがびっくりするだろう」と思っていたので、あの反応は正直驚きました。今まで1つのカレンダーを見ればよかったのが、その上にさらにカレンダーが開く構造になったので、「今どこを見ているのか混乱しないか」というのがチーム内でも懸念でしたが、ほとんどの方に違和感なく使っていただけました。
一方で「個別カレンダーの閉じ方がわからない」というフィードバックも得られました。ボタンを変えたりハンドルを追加するといったUI修正を行えたのも、プロトタイプ段階で検証できたおかげです。
iOSとAndroid、それぞれが独立して同じ壁にぶつかった先にあったもの
──10年の蓄積があるアーキテクチャに対して、ホームレイヤーを導入することでどのような設計上の課題が生まれましたか？
佐藤：本来なら既存の設計を根本から見直して作り直したかったのですが、スケジュール的に難しかったため「既存の設計はそのままにして、見た目だけ新しいUIに合わせる」という判断をしました。
具体的には、従来の設計では「どのカレンダーを表示しているか」をグローバル変数（アプリ全体から参照できる変数）で管理していました。新しいUIではホームレイヤーと個別カレンダーのレイヤーが重なって存在しますが、設計上は「カレンダーは1つしか開かない」という前提のままです。そのため個別カレンダーを開いているときに、裏のホームレイヤーが誤ってデータを出力してしまわないよう、細心の注意が必要でした。
田邉：iOSとAndroidで席を合わせて相談したわけでもないのに、全く同じ課題が独立して出てきました。ホームレイヤー側のカレンダーのデータを、個別カレンダー画面に誤って出してしまわないようにブロックする実装がそれぞれ必要になったんです。
このプロジェクトを一言で例えるなら「今までのUIが家だったとして、家の形はそのままに、土台を新たに付け加えた」ということです。家をいったん壊して新しく建て直すのではなく、既存の部材をそのまま使いながら基礎をすげ替えるような、そのくらいの大工事でした。
テスト工数は2倍になった。それでもフィーチャーフラグを全面採用した理由
──ベータリリース期間中、一つのアプリの中に新旧のUIを共存させる開発はどのように進めましたか？
田邉：開発期間が長く、コードの差分も非常に大きくなることは最初からわかっていました。そこで「フィーチャーフラグ」という手法を全面的に導入しました。フィーチャーフラグとは、コードの中に「このフラグがオンの場合は新UI、オフの場合は旧UI」という分岐を仕込む仕組みです。これにより既存の動作を変えないまま、新UIのコードを少しずつメインのコードベースにマージしながら開発を進めることができました。
ベータリリースもこのフラグのおかげで非常にスムーズでした。希望ユーザーには設定画面から新UIを試せることをお知らせし、そのフラグをオンにするだけで新UIが使えるようにしました。
──具体的にどのような箇所にフラグが入りましたか？
佐藤：まずアプリの起動時、画面構成を組み立てる処理でいきなり分岐します。新UIユーザーはホームレイヤー＋個別カレンダーの2層構造、旧UIユーザーは従来通りカレンダー画面から始まる構成です。タブのデザインにも分岐が必要でした。旧UIではTimeTreeのテーマカラーである緑のタブが、新UIでは黒ベースのデザインに変わったため、色の切り替えもフラグで管理していました。
田邉：アプリのあらゆる場所に分岐が入り、テストの工数も単純に2倍になりました。フラグのオン・オフ両方で動作確認が必要になるからです。また想定よりも起動時の処理の移植が複雑で、古い実装の仕様を古いドキュメントや実際に当時担当したメンバーに確認しながら進める場面も多く、工数が膨らみました。途中でメンバーを1名追加してもらったことで大きく助かりました。
佐藤：フィーチャーフラグはこれまでも使っていた手法ですが、今回は規模がまったく違います。重要だったのは、プロジェクト外のチームへの丁寧な説明です。他の施策を進めているメンバーも「新UIが存在する」前提で開発してもらう必要があったので、フィーチャーフラグの仕組みと影響範囲を丁寧に共有しました。
KPIは下がらなかった。段階リリースと全社連携が守ったユーザー体験
──大規模なリニューアルだったため、他チームとの連携も多かったのではないですか？
田邉：CSチーム（カスタマーサポート）との連携が特に効果的でした。通常はリリース時に共有するだけのところを、今回はプロジェクト立ち上げ当初からCSのメンバーに専任でチームに参加してもらいました。機能の背景や意図を含めて情報共有し続けることで、CSチームがユーザーの問い合わせに対して「機能が決まった理由」まで含めたコミュニケーションができるようになりました。お問い合わせには専用カテゴリーを設け、リニューアル後の新UIを使っているかどうかが判別できるようタグも付けてもらうなど、フィードバックを体系的に収集する仕組みも作りました。
佐藤：SNSに投稿されたユーザーの声も含めて、社内Slackにリアルタイムで流れる仕組みがもともとあります。そこに「構造改革フィードバック」という専用リアクションを設定し、そのリアクションをつけた投稿が自動的に専用チャンネルに転送されるようにしました。プロジェクトメンバー全員が常にフィードバックを閲覧できる状態を作ったことで、チームとしての方向感を合わせやすくなりました。
──連携で苦労した場面はありましたか？
佐藤：広告チームとの連携では大きな行き違いがありました。新しい画面の広告対応はタスクフォース内ではできないため広告チームにお願いしていたのですが、開発終盤になって「こちらは広告チームに依頼済みのつもりが、向こうはこちらの実装が終わるのを待っていた」という状況に気づき、慌てて仕切り直しました。大規模プロジェクトでは、タスクフォース外のチームとの連携確認を、より早いタイミングから細かく行う重要性を学びました。
田邉：SREチームとは事前に「起動時のデータ取得処理が変わり、サーバー負荷も変化する可能性がある」と共有し、リリース後は継続的に監視をしてもらいました。「このリクエストが急増している」「こちらのリクエストが急減したが問題ないか」といった連携が、安定稼働に大きく貢献しました。
──リニューアル完了後のユーザーの反応や、KPIへの影響はどうでしたか？
佐藤：UIが大きく変わるとネガティブな反応が来ることはチーム全員で覚悟していて、実際に多くのお問い合わせとSNS上の意見をいただきました。ただ、主要なKPI（重要業績評価指標）の数字はまったく下がっていません。大多数のユーザーが違和感なく使い続けてくれていることが数字から見えて、個人的には大きく安心しました。フィルターカレンダー（複数のカレンダーの表示・非表示を素早く切り替えられる機能）は複数カレンダーを利用するユーザーから「使いやすい」という声も届いています。
田邉：共有カレンダーという既存の価値を守りながら、個人に向けたパーソナライズされたカレンダー体験を提供できる場をリリースできたと感じています。
──リリース後にリファクタリングは進めていますか？
佐藤：まさに今進めています。「どの個別カレンダーを開くか」の指定を、グローバル変数ではなく明示的なパラメーターで渡す形に変えつつあります。ユーザーには見えないところで、内部構造を着実に整理しているところです。
田邉：Androidも頑張っています。今後の開発をスムーズに進められるよう、現在は既存のUIに合わせて、UI構造やデータ保持の方法などのリファクタリングを進めています
──今回の経験を通じて、エンジニアがプロダクトの未来を見据えた技術戦略を描く上で最も大事だと感じたことは何ですか？
佐藤：プロトタイプで早めに試すことの重要性を改めて痛感しました。大きな開発をいきなり始めるのではなく、まず動くものを作ってユーザーに触ってもらい、「いける」という確信を持ってから進みます。あの段階で確信を得られたからこそ、その後の長い開発期間も前向きに続けられたと思います。大きな変更でも、準備を怠らず、早い段階での検証をいとわないことが、結果的に最も安全で確実な方法だと感じました。
田邉：大きな変更はユーザーにとっても負担になるので、プロトタイプを作り、ユーザーインタビューで検証し、お知らせなどのコミュニケーションを丁寧に準備してリリースする。一つひとつの段取りが大切だとあらためて感じました。プロジェクトを通じて納得感を持って実装を進められたことが、長いプロジェクトを最後までやり切れた一番の理由だと思っています。
──最後に、エンジニアリングの観点からプロダクト・事業への貢献について、どう考えていますか？
佐藤：エンジニアの役割は、目指す方向性に対して「具体的にどんな形に落とし込むか」を考えることだと思っています。ユーザーにとっての使いやすさ、コードベースの品質、開発工数など、これらを総合的に判断してベストな形に持っていくことが、エンジニアの責任だと感じています。
田邉：既存の仕組みや開発コストを踏まえた提案はもちろんですが、自分もTimeTreeのユーザーであるという視点も大切にしたいと思っています。技術者でありながら使う人間の目を持つこと。そのバランスを意識しながら、今後もプロダクト開発に貢献していきたいです。
TimeTreeでは一緒に働く仲間を募集しています！
モバイルエンジニアをはじめ、TimeTreeでは幅広くエンジニアを募集しています。本記事で興味を持たれた方はぜひTimeTree採用サイトからご応募ください。
