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が存在する」前提で開発してもらう必要があったので、フィーチャーフラグの仕組みと影響範囲を丁寧に共有しました。
