こんにちはバックエンドエンジニアの中山です。
今回はPR TIMESで継続的に実施しているリファクタリングデーについて紹介したいと思います。PR TIMESでのリファクタリングデーの進め方や他部署との連携、どのようなリファクタリングを行っているかを紹介します。
リファクタリングデーとは
PR TIMESでは毎月1回リファクタリングやライブラリのバージョンアップ、デッドコード削除など、外から見た挙動が変わらない変更のみを実施する日としてリファクタリングデーという取り組みを行なっています。
日々新規機能の追加、修正、削除を続けていると、気づかないうちに古く使われていないコード（デッドコード）が溜まっていきます。こうしたデッドコードの削除は、放置されてしまうことも少なくありません。そこで、デッドコードの放置を防ぐための仕組みとしてリファクタリングデーを行うことで、日々の開発で蓄積しやすいデッドコードの取り除きを定期的に行い、開発速度を落とさないようにしています。
また、ライブラリのバージョンアップを定期的に行うことでセキュリティリスクの軽減や最新機能の活用も可能になります。さらに、エンジニアが「新機能開発だけでなく既存コードをより良くする」文化を意識的に育むきっかけにもなります。
PR TIMESでは、開発速度を落とさず成長し続けるために、毎月リファクタリングデーを行なっています。
リファクタリングデーのリリースまでの具体的な流れ
ここではリファクタリングデーのリリースが完了するまでの流れについて詳しく紹介します。
リファクタリングデー担当
PR TIMESでは、リファクタリングデーの運営をするチームがあり、その中から毎月1名が当月のリファクタリングデーの実施をリードしています。担当者には、最低でもフロントエンドエンジニア1名とバックエンドエンジニア1名をアサインし、リファクタリングデーの日程を決めます。また、担当者は4ヶ月ごとに交代し、継続的に開発組織でリファクタリングデーを開催できる体制を整えています。
リファクタリングデーが終わると今月の成果報告を開発組織全体に共有し、次のリファクタリングデーの日程を運営チームで決めます。
基本的にリファクタリングデー当日も含め担当者は事前に作成したテンプレートに沿って作業をしていきます。リファクタリングデーに必要な作業のテンプレートなどはNotionで管理しています。
リファクタリングデーの日程を決める
リファクタリングデー実施日は開発の都合だけで決めることはできません。他部署との連携も重要です。例えば、月初や毎月10日、15日などプレスリリース配信の多い傾向にある日は避けています。請求周りが関係する月末なども避けます。また、日によってはイベントが重なり、サポートデスクの人数が少ない日があり、万が一インシデントが発生した場合に迅速に対応ができないこともあります。そのため、開発だけでなく他部署とのコミュニケーションをとることも重要です。
そのうえで、担当者はリファクタリングデーの開催日を開発チームに共有し、新機能のリリースなど他の開発スケジュールと重ならないことを確認したうえで、最終的な日程を確定します。
1週間前の準備
リファクタリングデーの開発の準備は1週間前から行います。
リファクタリングやライブラリのバージョンアップは実装者とレビュワーの事情などで当日1日で作業ができない場合があります。そのため、余裕を持って作業を進めるために1週間前から準備をします。
まず、リファクタリングデーに向けて、担当者が変更を集約するためのブランチとプルリクエストを作成します。このブランチに変更を集約する理由は、コンフリクトを事前に検知できるようにすることと、リファクタリングデーで取り込む変更内容を明確にすることです。各開発者は担当するリファクタリング作業やライブラリのバージョンアップなどのプルリクエスト作成し、リファクタリングデー専用のブランチにマージしていきます。リファクタリングデーの担当者はリファクタリングデー当日までの間、毎日 master ブランチへ rebase を行い、コンフリクトが発生していないかを確認します。もしコンフリクトが発生した場合は、関係するメンバーへアナウンスを行い、早期に解消してもらうよう調整します。各開発者は自身の開発が完了したタイミングで、リファクタリングデー用ブランチへマージを行います。
PR TIMESでは、こうしたチケットを Jira で管理しており、リファクタリングデーで実施するチケットは事前にリファクタリングデー用の Jira エピックに紐づけてもらいます。 この運用により、大きなリファクタリングやライブラリのバージョンアップなどの作業内容を事前に把握できるほか、実施後もどのようなリファクタリングが行われたのかを後から確認することができます。
これらの準備を通じて、当日の作業をスムーズに進められる体制を整えます。
リファクタリングデー1日目
リファクタリングデー1日目はまず朝に開発全体にリファクタリングデーであることをアナウンスします。
アナウンスはSlackのワークフローを利用して開発チャンネルに通知しています。
16時には開発終了のアナウンスをし、マージを依頼します。この時に、マージが間に合わないプルリクエストに紐づくJiraチケットは次のリファクタリングデーに回してもらうように呼びかけ、来月のリファクタリングデーのJiraチケットに移動させます。
ステージング環境にリファクタリングデー用のブランチをデプロイした後は、自動 E2E テストを実行しNew Relicで監視します。監視中にエラーが発生した場合はエラー内容に関係するプルリクエストの差分を読みながら調査します。
問題がないことを確認できたら1日目は終了です。
リファクタリングデー2日目
リファクタリングデー2日目はまずステージング環境を使った手動テストを行います。自動E2Eテストでカバーできていない箇所のQAを目的として手動テストを行っています。もし手動テスト中にバグが発覚した場合、原因を調査し、即時対応可能であればその場で修正します。原因の特定に時間がかかり、修正箇所が多く影響範囲が広い場合などはバグの原因になっているプルリクエストをリバートし次のリファクタリングデーに回すことがあります。
上記の対応が終わり次第、本番リリースを行い、本番手動テストに入ります。
手動テスト中はリファクタリングデーチームがNew Relicのログやエラーの監視をします。本番手動テストが終わりNew Relic上にもエラーがないことを確認できたらリリース完了です。
どのようなリファクタリングを行っているのか
フロントエンドの事例紹介
- xoの v0.60.0 から v1.2.2 へのバージョンアップ
- TipTapのv2.10.5から最新までのバージョンアップ
- React Routerのv6からv7へのバージョンアップ
バックエンドの事例紹介
ブログで紹介していませんが、SmartyやGuzzleなどのバージョンアップにもリファクタリングデーを活用しました。また、New Relicに送信される不要なログの削除にも活用しています。
さらに、OpenSearchのバージョンアップ後に生じた不要になったコードの削除に活用しています。
デッドコードの削除
PR TIMESは古いサービスのため日々新機能の追加や修正によりデッドコードが溜まっていきます。ライブラリのバージョンアップも重要ですが、デッドコードの削除も重要です。
2025年11月に行った主にデッドコード削除に関する差分です。
定期的にQA項目の見直しをリファクタリングデー担当者が行う
PR TIMESでは、自動E2Eテストだけではカバーしきれない部分について、エンジニアが手動でテストを行なっています。
新機能をリリースすると、リファクタリングデーで必要となるQA項目も変化します。そのため、リファクタリングデーチームは新機能のリリースごとに、該当リリースのリーダーへ確認を依頼し、追加すべきQA項目や不要となった項目がないかを調査・整理してもらっています。
この定期的な整理により、新たに必要なQAと、不要となったQAを適切に取捨選択し、テストケースを整理します。
リファクタリングデーの工夫ポイント
事前の段取りをきちんと行う
当日のリファクタリングデーも大事ですが、事前準備もリファクタリングデーを安定してリリースを成功させるためには大事です。リファクタリングデーを決めるための他部署との連携、事前にリリース予定のチケットの概要把握、QA担当者決めなど当日までにやることの方が多いので安定してリリースを成功させるために準備を怠らず進めています。
担当者の作業内容をなるべくテンプレート化する
リファクタリングデーの担当者は定期的に交代しています。他部署との連携作業もあるため、引き継ぎ時の混乱を防ぐ目的で、作業内容をできる限りテンプレート化しています。
プルリクエストの変更内容を把握する
リファクタリングデー用のブランチには、大量のプルリクエストがマージされることもあります。内容によっては、プルリクエストを作成した方に何を行っているのか直接確認し、事前に変更内容を把握するようにしています。大変な月もありますが、その分、得られる学びも多いです。
経験と学び
私がリファクタリングデーを担当して2025年11月で4ヶ月になります。
4ヶ月間担当し、一番緊張したのは自分で行うライブラリのメジャーバージョンアップでした。 その他にもデッドコードの削除、ログの改善など行なってきましたが、テストで担保されていてもライブラリのバージョンアップだけはリリースが完了するまで緊張が解けませんでした。
また、リファクタリングデーを担当するまではPR TIMESソースコード全体を読むのではなく、自分の関わっているプロダクトのソースコードを読むことが大半でした。
そして、毎月行っている影響範囲が広いリファクタリングのプロジェクトに興味を持ち出してからは古いコードから新しいコードまで、PR TIMES全体のコードを読むようになり、実際に改善をすることができているので、リファクタリングデーは私個人の経験としても良いプロジェクトであり学びが多いです。
最後に、リファクタリングデーが毎月開催できているのは今の開発体制と文化があるからだと思っています。毎月開催し、リリースできているのは、1人1人がリファクタリングを行い、QAをしてくれているからです。
まとめ
今回は、PR TIMESで継続的に運用しているリファクタリングデーについて、その進め方や他部署との連携、実際の取り組み内容をご紹介しました。
継続して開発が進むサービスでは、デッドコードの蓄積やライブラリ更新の遅れといった課題が生まれます。このような改善は、つい後回しにされてしまいます。そのため、リファクタリングデーを行なっています。
こうすることで、新機能の開発速度を落とすことなく、改善を進められるようにしています。
PR TIMESの取り組みが、継続的な改善活動を導入してみたい方の参考になれば嬉しいです。
We are hiring!
PR TIMESではクラウドインフラからフロントエンドまで、本人が希望すれば幅広い技術分野に挑戦できる環境・文化が整っています。興味を持ってくださった方は、ぜひ一度カジュアル面談にお越しください！
