この記事はANDPAD Advent Calendar 2025の 2 日目の記事です。
メリークリスマス🎄 バックエンドエンジニアの武山 (bushiyama) です。
去年に引き続き、ANDPAD請求管理のバックエンドを担当しています。
多くの開発現場で聞かれる「余裕ができたらやろう」。
しかし、ロードマップは常に詰まっており、その「余裕」は永遠に来ないのでは？
その考え方を「卒業」し、今年1年かけて実践してきました。
ロードマップ(機能開発)という「攻め」と、
リファクタリングという「守り（であり攻めでもある）」を両立させるためにどんなことをして、どんな成果をあげたかアウトプットするものです。
なぜ「卒業」する必要があったのか
よくある話。
「余裕ができたら」と後回しにし続けた結果、以下のような症状が慢性化していました。
- 「あの機能、直したいけど触りたくない…」
- 軽微な修正のはずが見積もり・工数を圧迫
- 新機能開発のたびに「ここは見なかったことにしよう」が増える
このままでは、ロードマップの達成速度自体が低下するという危機感。
「余裕ができてから」ではなく、「余裕を作るために」今やる必要があるというマインドセットの変化から「卒業」を決めました。
実践した「ロードマップと歩む」コード改善
「リファクタリング期間」のような大規模な停止はせず、日々の開発の隙間で「小さな改善」を積み重ねました。
実際にどんなことをしたかを記載していきます。
- Tidy First?
- リーダブルコード的な観点
- linter 導入
- golang.org/x/tools
- DB構造の整理
- AIに依頼する
大前提：リファクタリングによる挙動変化がないことを担保する意味でもテストコードを確認
実装時に抜け落ちたテストケースなどあれば、まずテストを書きます。
それ自体が「余裕を作る」スタートです。
Tidy First?
昨年末に読んで感銘を受けた書籍。
もう少し覚悟を決めてリファクタリングやっていこうと決めたのも、この本を読んでのことだったりします。
様々な実践的テクニックが紹介されていましたが、特に第2部以降は迷った時の指針になりました。
どうやって整理するか?
進め方を迷った際、第2部の管理術が参考になりました。
- リファクタリングは切り出して小さく出す
- 影響範囲を把握し相互作用を理解した粒度感で進める
- AとBで同じ変更をする場合、Aを直してからBを直すのか、両方一緒に直すべきかを判断する。
- 先/後、やる/やらないを決める。
- 連続したリファクタリングを始める前には、必ずメンバー間でディスカッションを行い、目的・範囲・影響範囲を共有してから始めるようにしました。
- "やること"はissue化しましたが、"やらない"場合はコード中にコメントを残しておくことを徹底しました。
なぜやるのか？
第3部の理論について全てを理解実践するのは難しいですが「なぜやるのか？」を意識することで、リファクタリングの目的を見失わずに進めることができました。
リーダブルコード的な観点
説明不要の名著ですね。
こちらで紹介された様々な観点からも、小さくPRを出しました。
取り組み始めて年初のほうは手応えも感じましたが、
Copilot コード レビューなどを利用するようになってからは、実装PRの段階で大部分を検知できている印象です。
linter 導入
複数のlinterをこれ1つでまとめて爆速で実行してくれます。
Goを利用しての開発では、お世話になることが多いですね。
latest指定だと忙しいときにlintエラーでもどかしい思いをすることもあり、version固定をして運用しています。
patch リリースのタイミングぐらいで最新化することが多いです。
golang.org/x/tools
以下をはじめ、公式で便利な機能が揃っています。
いずれも実行は一瞬ですが、まとめてPRやCIに機械的に組み込むことはしていません。
あえて実行結果を小分けにPRして、チームでレビューすることにより「どのようなコードが良いのか」という意識づけを図っています。
DB構造の整理
不用意な修正は危険ですが、それゆえ後回しにされがちなDB構造の整理。
データはアプリケーションが終了した後も長期間残り続けるため、定期的に見直しを行うことが重要です。
- 使われていないカラムの削除
- 名前の変更
- データ型の最適化
- 正規化と非正規化のバランス調整
- ドキュメントの更新
これらの作業を通じて、データベースのパフォーマンスと保守性を向上させることができます。
リリース予定のDB構成で、現行のアプリケーションが正常に動作することを確認するためのテストを実施するなど、
動作を担保しながらDB構造を整理しています。
AIに依頼する
同一観点で広範囲へ同じ修正をすることがよくあります。
このようなケースでは、AIにお願いすることがよくありました。
各サービスのMCPなど、便利に使う下地は弊社でも整ってきています。
しかし私のリファクタリング作業においては、1箇所を人間が修正してから「同じ修正ができるところを探して実装して」などのざっくりとした活用が殆どでした。
去年の今頃は想像もつかなかったぐらい、この１年で充実した印象です。
リファクタリングが機能したか
機能開発の傍ら、１日に１PRはしていく継続的なリファクタリングで今年１年を駆け抜けました。
この取り組みに成功したのは、なによりチームのおかげと思っています。
心理的安全性と「完璧より改善」のマインド
- 「余計な変更だ」と怒られない安心感
- 100点満点の実装・リファクタリングでなくても 0->1 , 1->10 を称賛する雰囲気
性善説に基づいたレビュー
- レビュワーは「変更の意図」をまずポジティブに受け止める
- リファクタリングによってデグレが起きないよう「一緒に」考える（犯人探しをしない）
フラットな議論と「気づき」の共有
- PRを通した議論と知見の共有
- ナレッジを広める雰囲気作り
「卒業」して見えた景色
この１年を通して、リファクタリングが「特別なタスク」ではなく、「日々の習慣」になった感覚があります。
「負債」という苦しい感覚から、「コードを育てる」という前向きな感覚へ。
コードが綺麗になったことで開発者のストレスが減り、ロードマップ開発の速度も爆上げになりました（と信じている！）。
実際にAIに依頼する際の"打率"も上がってきたように感じます。
またなにより、普段は触らない部分や外部との依存性などシステム全体を俯瞰して見ることになるため、
PR・レビューを通じてチーム全体のオーナーシップを高められたように思います。
まとめ
「余裕ができたら」という言葉からの卒業は、一度きりのイベントではなく、日々の積み重ねによって維持されるプロセスでした。
技術的負債の返済は、時として孤独で報われない作業になりがちです。 しかし、この1年を通じて私が感じたのは、「苦しさ」ではなく、少しずつコードが輝きを取り戻していく「楽しさ」でした。
それが可能だったのは、小さなPRを称賛し、意図を汲み取ってくれるチームメンバーがいたからです。
心理的安全性が確保された環境こそが、最強のリファクタリングツールだったのかもしれません。
「余裕」は待っていても来ませんでしたが、チームと協力して積み上げた「日々の隙間」は、確かな開発速度の向上というギフトを運んできてくれました。
来年も、愛すべきチームと共に、愛すべきコードを育てていきます。
アンドパッドではコード改善も楽しく取り組める Gopher を歓迎しています。
明日のANDPAD Advent Calendar 2025 もお楽しみに！
