この記事は 食べログアドベントカレンダー2023 の12日目の記事です🎅🎄
はじめまして。食べログシステム本部 アプリ開発部の 神永 と申します。
私は10年ほど前に食べログのアプリチームにiOSエンジニアとして加入しました。
その頃の食べログアプリはまだ店舗検索と店舗詳細ページくらいしかない状態で、これからアプリの機能をどんどん増やしていくぞ！という段階でした。
そのため来る日も来る日も新規画面をひたすら作り、その間に開発言語が Objective-C から Swift になったりもしましたが、とにかく新機能をずっと作り続けておりました。
しかし現在は基盤チームという食べログアプリの保守や開発環境の改善を担当するチームに所属し、主にリファクタリングを行っています。
食べログの機能を作っていくという点ではリファクタリングもプロダクト開発と同じなので、それほどの違いはないだろうと思っていました。
ところが実際には作業の進め方の面で大きな違いがあり、それにより日々誤算が生じ続けました。
そこで今回は、私が感じたプロダクト開発とリファクタリングの違いについてお話させていただこうと思います。なお、技術的な話はまったく出てきません。
リファクタリングのつらいところ
初手で壊れる
プロダクト開発は実装を進めるうちにだんだんできあがっていくものですが、リファクタリングの場合は最初の一手で完成品が壊れます。
作業の進め方や状況によって異なるのかもしれませんが、私の場合は大体こうなります。
次にビルドが通るときは実装が完了したときなのだと思うと気が遠くなります。
あけてびっくり感がある
対象画面についてある程度把握している場合でも、いざ取りかかってみると裏機能・謎仕様・謎コードと出会うことが多々あります。
食べログアプリには画面仕様書がなく「コードが仕様」という状況になってしまっているため、コードから仕様を読み解く作業が必要になり、これに結構な時間がかかります。
プロダクト開発の場合は要件が日本語でまとめられているので、なんて楽だったんだろうと感じました。
やることが最初から決まっているプロダクト開発と、取りかかってみてからやることが明確になるリファクタリング。
リファクタリングは、他人の押し入れの掃除をしてるみたいな感じだなぁと思いました。何が出てくるか本当にわからない。。
変わり映えしないテスト
実装が終わるとテストに入りますが、できあがったものはリファクタリング前のものと見た目も機能も全く同じなので、何の新鮮味もありません。
プロダクト開発の場合だと、思ったよりいい感じとか、ここはちょっと使いづらいから見直した方がいいかも？など色々思うところがあったり、新しい機能をいち早く体験できるという楽しみもあります。
ですがリファクタリングは成果物の差異が見た目ではわからないので、ちゃんとリファクタリングを行ったアプリでテストしているのか不安になってきて、何度も確認したりしました。
たまに既存バグをリファクタリングとあわせて修正するのですが、その場合は動作確認時に見分けがつくようになるのでとても嬉しくなります。
実装したもののテスト方法がわからない
仕様が複雑な画面の場合はテスト方法のわからない機能が稀にあり、調査してみると、ものすごくレアケースだったとか、実質呼ばれる機会のないものだったりすることがあります。
大体は仕様変更時の残骸なのですが、なぜこの状況に陥っているのか、削除して問題ないのか等の調査・確認が必要となり、テスト以上に時間がかかります。
プロダクト開発の場合だと、実装者にテスト方法がわからないということはほぼないですし、テストに予想外の時間を要することは少ないように思います。
また実装中に動作確認しながら進めることもできるのでテストは最終確認という心持ちだったりもしますが、リファクタリングの場合はその都度確認しながら進めることが難しいので、テストがぶっつけ本番となり計画通りに進まないことがよくあります。
リファクタリングのいいところ
グチめいたことをたくさん書いてしまいましたが、もちろんいいところもあります！
実際私はプロダクト開発に戻りたいのか、このまま基盤チームで保守作業を行うのがいいのか決めきれない現状ですので、悪いところばかりではないのです。
コード以外と向き合わなくていい
プロダクト開発だと企画・デザイナーとの認識合わせや相談など、やりとりが頻繁に発生します。
案件によっては、実装時間より調整に要する時間の方が長いこともあります。
その点リファクタリングは既存コードを元に作業していくので、人とのやりとりはほぼ発生しません。
基盤チームでは毎日朝会を行なっていますが、朝会以外では誰ともやりとりしない日も結構あります。
人によってはそれがストレスに感じることもあるかもしれませんが、私は以前の職場でー週間に一言二言しか話さない環境にいましたが全く苦痛ではなかったので問題ありません。
また、私は現在子育て中で勤務時間が 7:30〜16:30 と他の人たちとかなりずれているので、まわりとペースをあわせなくてもいいというところにもメリットを感じています。
プロダクト開発をしていたときは、議論が盛り上がってきた頃に「すみませんが帰りま〜す...」なんていうこともよくありましたので。。
リリース予定日に追われない
リファクタリングでもプロダクト開発でも予想外のことはあるもので、リリース予定日に間に合わないかもということはよく起こります。
食べログアプリは現在1週間に1回のペースでリリースを行なっているので、少しでも時間をロスしてしまうとその締め切りに間に合うかどうか雲行きが怪しくなってくるのです。
プロダクト開発の場合は多くの人が関わっていることもあり、リリース日の変更には調整が必要になります。
もしくは、少しくらいのトラブルなら残業で何とかしたりします。
しかし子育て中の私には残業時間の確保が難しく、少しでもハマったら間に合わなくなるという恐怖に日々怯えていました。
また作業が順調な場合でも、子供が体調不良になると突然ピンチになります。「今日休むのは難しい...！リリースに間に合わなくなる！」ということが多く、あるとき夫に「毎回そう言うよね」と言われてハッとしました。私は常にリリース予定日に追われていたようです。。
その点、リファクタリングはリリースが遅れても影響を受ける人は限られているので、事情を説明すれば難なくリスケできます。
なんせ本人でさえ成果物の見分けがつかないので、そのリリース時期を気にしている人なんてほとんどいないのです。
妥協せずにコーディングができる
実装をしていると「もう少し時間をかければもっとキレイになるけど今はいったんこれで！」ということが往々にしてあります。
リファクタリングでもついその状況になってしまいそうになることがありますが、中途半端なリファクタリングになるならリファクタリングをしている意味がないのでは？と思いとどまり、影響範囲が広がっても基本はやりきる方向で考えています。
プロダクト開発時に時間を惜しんだことにより貯まった負債を、時間を惜しんでリファクタリングしていては負の連鎖を断ち切れませんし、リファクタリング担当としてのアイデンティティにも関わってきます。
幸いチームの人たちも同じ考えなので、そのあたりは理解を得て作業を進めることができています。
妥協せずにコーディングができて、やりきったと思ってリリースできることは、エンジニアとしてはありがたい環境だと思います。
まとめ
以上が、プロダクト開発とリファクタリングにおける私が感じた違いです。
私はもともとアプリの機能を作ることが好きで、ユーザーに自分が作ったものを使ってもらえることが嬉しかったので、基盤チームへの異動の打診を受けたときは気が進まない気持ちも正直なところありました。
しかしリファクタリングや保守作業を担当することでアプリ開発者としての視野が広がり、今では思い切って異動してみてよかったなぁと思っています。
こちらの内容はあくまでも私が感じたことなので、全てが一般的なことではないとは思いますが、もし何かの参考になれば幸いです。
明日は taichirou_sasaki さんの「飲食店DXプロダクト開発を支えているかもしれない1on1」です。お楽しみに!
