「N予備校」を「ZEN Study」に変えてみた件〜サービス名称変更の経験

こんにちは。ドワンゴの教育事業でAndroidエンジニアをしている崔です。

開発を担当している「N予備校」が8月28日、「ZEN Study」へと生まれ変わりました！🎉

www.nnn.ed.nico

今回のサービス名称変更において私は、フロントエンド(Web・iOS・Android)対応を取りまとめる役割を担っておりました。

この記事では、その対応内容と今回の経験で得られた知見や感想についてお話したいと思います。

プロジェクトについて

背景

zen-univ.jp

現在、ドワンゴの教育事業では「ZEN大学（仮称、設置認可申請中）」に関連してさまざまなプロジェクトが動いています。その中でまず、オンライン大学として学習システムをどうするかの検討がなされました。

そこで以前からN高等学校・S高等学校で学習システムとして使っている「N予備校」にZEN大学向けの機能拡充を行いつつ、ブランドに一貫性を持たせるため「N予備校」をリニューアルすることになりました。それによってあらゆるユーザーにとってより学びやすく、使いやすいシステムにすることを目指しています。

リニューアル内容は、予定のものも含めて多岐に渡りますが、最初のリリースでは第一印象に関わる部分がメインになりました。毎回ユーザーに使ってもらうホーム画面のリニューアル（リリース内容）と併せて、ユーザー層を大学受験生だけのように連想させないサービス名称とロゴへの変更などの面でリニューアルを行いました。この記事は後者の対応に関するものになります。

ゴール

まず、プロジェクトとしては下記のゴールがありました。

旧名称「N予備校」が使われている箇所を全て無くす（基本、「ZEN Study」に置き換える）
旧ロゴを全て新しいロゴに置き換える
一部の共通カラーを新しいものに変える
ナビゲーションメニューなどの共通デザインや初期画面群の刷新

フロントエンドを取りまとめる立場として私は、上の対応を漏れなく行うことに加えてもう1つ、「フロントエンドの管轄外でも各クライアントから表示され得るあらゆるコンテンツも漏れなく対応されるようにする」というゴールを自主的に定めました。それは、ユーザーからしたら組織内の責任範囲に関係なく全てのコンテンツはフロントエンドを通じて見られる訳で、正しい内容をクライアントを通じて送り届ける責務がフロントエンドにあると考えたためです。

進行

計画

アプリ内の変更においては、単純に名称とロゴを置き換えること以外は主に「リニューアル後の新ブランドをいかに認知してもらうか」の観点で各部門が参加し、検討と計画が進められました。例えば、下記のような対応です。

アプリ起動 ~ 初期画面群 + ガイド類のデザイン変更
スプラッシュ画面とウォークスルー画面の刷新（モバイルアプリのみ）
ホーム画面にリニューアル周知用の期間限定バナー設置
「N予備校」というコンテキスト上で定められていたサービス内用語・表現の見直し

そしてフロントエンドとしては計画段階で下記を行いました。

デザインが別途作成されない変更箇所（単純置き換え箇所等）の洗い出し
クライアント外部でサービス名称・ロゴが確認できる箇所のリストアップ
リリースまでの開発の段階的なフェーズ設定

変更箇所の洗い出しにおいては、まず、各クライアントチームの協力のもと、共有されているレポジトリも確認しながら網羅的に洗い出しを行いました。そのあと、作業管理や品証計画がしやすいような粒度（画面や機能単位）にまとめました。ソースコードベースの情報だと開発メンバー以外はアクセスできない、どこのことか分からないこともあると思ったので共通認識のある名称の見出しにする、適宜スクリーンショットやデザインへのリンクを添付するようにしました。

開発

開発は基本的に計画に沿って進めました。不変なスコープである名称とロゴの置き換えから始まり、デザイン刷新・機能面での変更を段階的に行っていきました。そしてこれとは別にリリースまでの期間が長かったこともあり、リニューアルに関して多方面で企画・検討がなされたことで当初計画から追加された施策、考慮漏れだった部分の対応も行いました。

一連の開発対応は以下の点に注意しながら進めました。

開発時期とリリース時期の乖離：定常対応や別案件対応が先にリリースされることが分かっていたのでお互いに干渉して誤った内容がリリースされないようにブランチ戦略やデグレ確認に気をつけました。
バックエンド対応と合わせての品証：バックエンドの開発は別トラックで進められたのですが、進め方に自由度を確保させつつ、品証はフロントエンドと合わせて効率的に行えるように品証スコープと期間を調整しました。
プロジェクトとしてのスコープ管理：リリースまで期間が長かった分、計画時になかった変更なども多数発生しましたが、開発に無理が生じないようにプロジェクトのスコープを明確にした上で極力柔軟に対応するように努めました。

延期

既知の方も多いと思いますが、リリースを目前に当社へのサイバー攻撃（プレスリリース）がありました。その影響でリリース作業自体が行えなくなったことに加え、サービス外部の要因も重なってリリースを延期しました。

フロントエンドの開発は幸い、ひととおり終わっていたので対応としてはリリース作業の手を止めるくらいでしたが、開発途中のこのようなインシデントに備えて日頃、前後リリース間のブランチ戦略が練っておいた方が良いとあらためて考えました。

そしてプロジェクトマネジメントのレベルでは、改めていつリリースできる・すべきか把握できるように、リリースに必要な戦略的・技術的前提条件を把握しておくと良いという学びを得ました。

リリース

まずは、リリース前に部門横断で事前ミーティングを重ねました。通常は各クライアント、バックエンドチームで比較的に自由度を持ってリリース作業を行なっているのですが、今回のリリースは大規模な変更を含んでおり、戦略的なアプローチも大事であったためです。

ミーティングでは、ホームページ(LP)・各クライアント・バックエンドのリリース作業の段取りをはじめ、告知スケジュール、当日の立ち会い・連絡体制、最終チェックのフローとロールバック時の対応内容などを話し合いました。

フロントエンドの事前の作業としては、iOSのApp Store, AndroidのGoogle Playストア関連で普段のリリースでは変更しない掲載内容（アプリの説明、スクリーンショットなど）の更新準備を行いました。 OSや項目によって事前に審査を経て公開されたり、操作した時にすぐ反映されたりの違いがあるので注意が必要です。

リリース当日は、計画した順番と時間単位のタイミングどおりに（iOS, Androidのストア公開後、実際に確認できるまでの時間は許容）リリース作業を行いました。そしてLPやストア情報の更新確認を含め、本番環境での最終チェックを行ない、問題ないことを確認して体制解除をもって無事リリースは完了しました🎉

振り返り

最終的に無事リリースできたのですが、対応全体を振り返ると今後に向けての課題もいくつかありました。

単純なところですと、品証後に置き換え漏れが発覚したり、逆にストア関連の課金名称がリリース前に変わってしまったりすることがありました。作業・品証箇所を漏れなく網羅することを徹底し、更新フローが不明な箇所（特にストア関連）は名称に空白だけ入れてみるなど実質影響のないリハーサルするなどして再発防止に努めようと思います。

フロントエンド対応全体に関わるところでは、今後、同じような対応をする時はなるべく作業量を予測・計測可能にする工夫をしようと考えました。例えば、全作業箇所を網羅しなくても画面数やリソース量から概算値を出し、置き換えのような繰り返し作業を一部実施してみてモデル工数を出すというような工夫です。