おいしい健康のトンマナを一新したときのプロマネの話

はじめに

こんにちは、おいしい健康のWebエンジニアの二宮です。

おいしい健康のWebサイトは、去年の夏に大幅なトンマナのリニューアルを行いました。その際、サービスのトンマナ変更の主にプロマネ的な側面について、Web上になかなか参考になる記事が見当たらなかったので、おいしい健康ではどのように進めていったのか、参考までに記載しようと思います。

トンマナ変更の経緯

そもそもエンジニアチームのタスクとしては膨大なキューが溜まっている中で（おそらく読者のエンジニアのみなさまも同じような状況だとお察しします・・😅）、なぜトンマナ変更を実施しようとなったのかの経緯を記載します。

おいしい健康は、もともとはクックパッド(株)のひとつの事業部に所属していました。初期のおいしい健康はその中で生まれたサービスであったため、トンマナについてもクックパッドと似たような見た目になっていました。

その後、(株)おいしい健康として独立していく中で、事業の方向性としてレシピサービスから一歩前に進めて、総合的なヘルスケアサービスを目指していくこととなりました。その中で、これまでの UI ではユーザが受ける印象としてレシピサービスの枠から抜け切らず、ヘルスケアサービスとして制作されていたアプリ版おいしい健康（ iOS, Android ）と比べて、ユーザ体験に大きな乖離ができるようになっていました。

そのため、何か新しい施策を試す際にも「Webどうしようか・・」のような声もチラホラ聞こえるようになってしまい、仕様検討やデザインにも別途工数がかかるようになってしまっていたため、大きなPJになることは想定されていたのですが、思い切ってWebのほぼ全てのページのトンマナを変更することとなりました。

進め方

PJ開始当初、Webチーム専任のエンジニアは2名しかいなかったため、1名が他サービス調査やワイヤーフレーム作成などのビジネス的なタスクを、もう1名が技術基盤周りのタスクを担当することにしました（ちなみに、おいしい健康ではディレクタ、デザイナに比べてエンジニアの数が全然多いので、施策検討やディレクションなどのビジネス関連のタスクもエンジニアが主体的に行うことが多いのも特徴かなと思います）。

その後、それらのタスクが片付いたらトンマナを変えるための画面実装は一緒に行う、という進め方にしました。

画面実装に入る前のタスクについて

ビジネス関連タスク

まずはトンマナ変更後のデザインについて、どのようなレイアウトにするか、というところから決めなくてはなりません。今回の変更では、おいしい健康が持っているコンテンツを適用しやすいことと利用ユーザが多いことから、Twitter の UI を参考にしました。

デザインチームの工数が逼迫していたため、エンジニア間で検討した UI をもとに以下のような各画面ごとのワイヤーフレームを作成し、その後デザインチームに修正してもらう、という流れを取りました。

ちなみに上記の小さな1つ1つが各画面のワイヤーフレームで、画面数としては、似たようなレイアウトの画面も含め約100画面弱くらいになりました。

技術基盤関連タスク

基盤関連のタスクについては実際に調査しないと見えにくいものも多かったのですが、今回は大まかに以下のようなタスクを実施しました。

Dockerfile の Ubuntu のイメージの更新（16.04 => 18.04）
Ruby on Rails のバージョンアップ（5.0 => 5.1 => 5.2。おいしい健康のサーバサイドは Ruby on Rails で動いています）
bundle update
webpacker 導入
CoffeeSripet から TypeScript へ
フロントエンドの CSS 設計の調査（ FLOCSS を導入することにしました）

スケジュール作成と実際にかかった工数

スケジュール作成については、非常に難儀でした。。仕様検討やワイヤーフレーム作成については、画面数はわかっていたので比較的見通しが立ったのですが、基盤関連のタスクについては手をつけてみないとどこで躓くかもわからないので、大まかなマイルストンだけを決めておいて、進捗に合わせてスケジュールやタスクを都度調整する、という進め方にしました。

ビジネス関連タスクについては、仕様検討から全画面の大まかなワイヤーフレーム作成までで約1人月、その後デザインに落とすまでに更に約1人月、と見積もっていました。基盤関連タスクについては、上に記載したそれぞれのタスクを約1.5週で終わらせるようなイメージで、約2人月程度で完了させるようなスケジュールを組んでいました。その後、膨大な量の画面実装が待ち構えているわけなのですが、それについては明確なスケジュールは作成せず、なんとなく7.5人月（3人 × 2.5ヶ月）くらいで実装しようと思っていました。（このあたりの工数感については、各サービスの状況ごとにまちまちだと思います）

最終的な工数ですが、ワイヤーフレーム作成については約1.5人月で済んだのですが、細かな詰めが甘い部分も多く、その後のデザイン作成については約2.5人月（＋実装していく中で都度デザイン修正工数も発生）が必要でした。また、基盤関連タスクについては、スケジュールが間に合わず途中から基盤周りに強いエンジニアにも入ってもらい、約4人月くらいかかったかなという感じでした。

画面実装について

画面の実装については、作成されたデザインを元に、ひたすら約100画面分の実装行っていくという形です。

コードとしては、主に手を入れたのは haml、css、JS( TypeScript )のみで、モデルにはほぼ手を入れず、コントローラもレイアウトファイルの分岐を追加するくらいにとどめるようにしました。

また、全ての画面の新しい UI が実装されるまでは、これまで通りの UI で表示をしなければなりません。ただ、修正した全てのコードを一気に master にマージするのは非常に危険なため、新旧どちらの UI を表示するかを環境変数で切り替えられるようにして、実装したコードは都度 master にマージしていくようにしました。

また、スケジュールに対して進捗が思うように進んでいない状態が継続して発生していたため、

意図的にコードレビューの精度を下げる
新しくWebエンジニアを採用して、実装できる手数を増やす

ということを行いました。

特に前者については、今後に技術負債を残すことは明らかで、エンジニアとしては非常に苦渋の決断だったのですが、収益基盤がまだそこまで強くないベンチャー会社でPJのスピード感を損なうことのリスクの方が大きいと判断して、このような方針にしました。

後者については、このタイミングでエンジニアの採用が行えた（しかも3人も！）というのは非常に幸運で、かつタスクとしても画面側の実装のみ（ロジックには手を入れない）、という比較的切り出しやすいタスクであったことも、追い風として働いたかなと思っています。

最終的に実装にかかった工数についてですが、上記の他に要件を削ったりなど都度スケジュールを短くする対応を取っていたものの、当初の7.5人月程度という見込みからは大きくずれ、約11人月程度の工数を要して、ようやくリリースにこぎつけました。リリースタイミングとしては、当初は8月くらいを目処にしていたものが9月半ばにずれ込んだ程度なのですが、工数としては当初の想定の1.5倍程度が必要だったという形でした。

なお、リリース後も追加の改修は発生していたのですが、ロールバックを伴うような障害は発生せず、大きなPJではあったのですが、なんとか無事にリリースできて非常にホッとしました。

KPI について

ちなみに、運用中のサービスのトンマナ変更については、一般的には利用ユーザからは使い勝手が変わってしまうので、なかなか歓迎されない施策ではあります😭（開発側は、新しい施策をリリースしやすくなってよいのですが・・）。おいしい健康のトンマナ変更も例外ではなく、多少 UU の減少が見られました。

その意味で、KPI の下げ幅をどの程度まで抑えられるかというのは、ひとつ重要なポイントとなってきます。

こちらが実際のトンマナ変更前後の UU 数の推移なのですが、約10〜15%程度 UU 数が下がっていました。ただ、この程度の下げ幅はある程度想定しており、また、この後においしい健康の有料会員化PJが控えていて、UU はいずれにしても減少してしまうことも見えていたので、結果的に KPI の減少はそこまで大きなインパクトではありませんでした。（と思っています😅）

振り返り

PJとしては（どうにかこうにか）無事リリースを迎えたものの、反省点も多く見つかりました。

その中で特にチーム内で意見の多かったのは、画面のデザインが作成された際に、UIのコンポーネントの整理・共通化が行われていない状態で画面実装に入ったため、細かな点が微妙に違うだけの UI コンポーネントをいくつも実装する事態が発生した、という点でした。

この点については、事前に多少想定はしていたものの、コンポーネントの整理・共通化をしている工数もないし、まぁ大丈夫かな・・と軽く考えていたことが最大のミスだったなと思っています。UI コンポーネントの整理については、ここまで大きな UI 変更を伴う施策でなくとも、新しいデザインを起こすことがある際にはぜひ対応しておくこととおすすめしたいと思います。