はじめに
株式会社つみきの野田と申します。映画・ドラマ・アニメのレビューサービス「Filmarks（フィルマークス）」でエンジニアリングマネージャーを務めています。日々、新機能の追加や運用改善に取り組んでいます。
本記事では、Filmarksで行っている継続的なリファクタリング活動について紹介します。私たちチームの取り組みが、同じように課題を抱える方々の参考になれば幸いです。
Filmarksとは
FilmarksはiOS/AndroidアプリとWebで提供する、映画・ドラマ・アニメのレビューサービスです。
累計レビュー数は2億件を突破し、多くのユーザーに利用されています。
サービス開始から12年が経過し、積み重ねてきたコードや度重なる機能追加・仕様変更により、技術的負債が蓄積してきました。現在は、負債を解消しながら新機能の開発や改善を行うことが大きなテーマになっています。
リファクタリングの定義
コード・リファクタリングは、外部の動作を変更したり機能に影響を与えたりせずにソフトウェア・コードの内部構造を変更するソフトウェア開発手法です。これらの小さな変更は、コードの読みやすさと保守性を向上させることを目的としています。
コード・リファクタリングとは
Filmarksではこの定義に加え、もう少し定義の幅を広げて負債の解消や開発者体験の向上までを広くリファクタリングと捉えて取り組んでいます。本記事では、主な活動である「リファクタリング日」と「リファクタリング週間」の2つを紹介します。
日々の取り組み：リファクタリング日
導入の背景
以前は案件対応の合間にリファクタリングを行っていました。しかし、案件の優先度が高くなりがちで、負債解消が後回しになるという問題がありました。また、改善できない状態で開発を続けることは、エンジニアのストレス要因にもなっていました。
そこで事情を説明しステークホルダーと合意形成を行い、あらかじめリファクタリングだけに専念する日を設けることにしました。
実施内容
Filmarksでは、1週間のうち1日をリファクタリング日にあてています。この日は新機能開発を止め、リファクタリングに集中します。
活動内容は定義上のリファクタリングに加え、以下も含めています。
- CI/CD改善
- ふりかえりで出たTRYの対応
- 優先度の低い改修（リファクタリングタスクが見つからない時）
- issueの棚卸し・整理
例えば、バックエンドチームではRuby on Railsで開発を行っているため以下のような対応をしています。
- テストの高速化
- RuboCopの修正
- 重複コードの整理
- CSS記法の改善
結果と学び
決まった日を設けることで、リファクタリングに集中できるようになり、技術的負債の解消も進むようになりました。また、リファクタリング日があることで新機能開発のスコープからリファクタする箇所を外しやすくなり、結果的にリリース速度も向上したと感じています。
もちろん緊急性が高い案件はリファクタリング日より優先しますが、見通しが立てやすくなり、工数の計画精度も向上しました。
やらないことの明確化
導入後しばらくすると、リファクタリング日に案件対応や軽微なバグ対応が紛れ込む課題が出てきました。そこでやらないことを明確化し、以下はルールとして除外しました。
- 案件対応
- 軽微なバグ対応
特にバグ対応は、リファクタリング日に依頼されると緊急度が不明瞭になる問題がありました。そのため「今すぐ直す必要があるか」を判定するフローを加えた結果、バグの優先度整理にも効果がありました。
このような日々のリファクタリング活動を続ける中で、リファクタリング日だけでは対応しきれない大規模な改善や負債解消の課題も明らかになってきました。そこで、新たに以下の取り組みを導入しました。
まとまった取り組み：リファクタリング週間(仮)
導入の背景
リファクタリング日では対応しきれない大きな負債を解消するのため、リファクタリング週間を設けました。実際には1スプリント（2週間）を丸ごとリファクタリングに充てています。名前は「週間」が最も呼び慣れていますが、まだ絶賛考え中です！
実施タイミングは、社内外の動きが少ない年末年始のスプリントを選びました。休業明けに案件対応を把握し直す必要もあったため、ステークホルダーからの合意も取りやすく、まずはバックエンドとインフラチームでトライしました。
実施内容
- 1スプリントを丸ごとリファクタリングに集中
- 休業中に大きな案件が動かない期間を活用
- 溜まっていたTRYの消化や大規模負債解消に着手
結果と学び
施策を行った後で、良かったことと改善点についてエンジニアメンバーにアンケートをとり、以下のような声が出ました。
良かった点
- 着手できていなかった大きな負債解消ができた
- 休業中に案件が動かないため、復帰がスムーズだった
- ふりかえりで溜まっていたTRYを解消できた
改善点
- あらかじめ対応内容を計画しておくとさらに効果的
- 実施内容を固めることでMTGを減らし、作業に集中できるようにしたい
- PRが多く出る傾向になったので、マージするまでのバッファを設け、そこまでを一区切りにしたほうがよい
このフィードバックを踏まえ、2回目はGW休み前後のスプリントで実施しました。計画を立てて臨んだことで、前回より効果的に改善できました。今後は定期的な実施に向けてフローを整理していく予定です。
今後の取り組み
現状の課題感として、以下が挙げられます。
- 活動の成果がどれくらい改善につながったかを可視化する仕組み
- 対応する内容によっては案件化して進められるフローの整備
- リファクタリングを習慣化し、改善を積み上げる仕組みづくり
将来的には、リファクタリングの幅を広げて新しい技術を試す場にもしていきたいと考えています。そのためにも、まずは負債を減らし、エンジニアがストレスなく開発できる環境を整えていきたいです！
おわりに
本記事では、Filmarksで取り組んでいるリファクタリング活動を紹介しました。
今後も継続的な改善を通じて、サービスの成長とより良い開発環境づくりを進めていきます。
つみきではこのような活動を行いながら日々Filmarksの成長を支えるエンジニアを募集しています！
Discussion