株式会社ハローで飲食店向け業務支援サービス「Respo」の開発をしている ysirman です。
主に、Ruby on Rails を使ったバックエンドの開発を担当しています。

プロダクトを継続的に開発していると、いつの間にか「もう使われていなさそうなコード」が増えていきます。
いわゆるデッドコードです。

Respo は「おいしい料理を作る。それ以外は全部、おまかせください。」というコンセプトのもと、予約管理から POS レジまで幅広い機能を提供しています。
その分、過去の仕様や一時的な対応がそのまま残り、結果としてデッドコードになっている箇所も少なくありません。

私は既存プロダクトに対する機能追加・仕様変更を繰り返す中で、

「これ、もう使われていない前提で実装していいんだっけ？」
「消したいけど、影響範囲が分からなくて怖い」

という場面に何度も遭遇してきました。

デッドコードの存在に気づかないまま対応を進めた結果、

「不要なコードを考慮した実装になってしまった」
「問い合わせ調査で無駄なコードを読んでしまった」

という時間ロスが発生することもありました。

スタートアップにとって、開発スピードは生命線です。
だからこそ、「気合を入れて一気に削除する」ではなく、
「日々の開発の負担にならない形で、デッドコードに気づき、判断し、削除できる状態を作ること」 が大事だと考えています。

この記事では、「デッドコードかも？」と思ったときに、「どう調査し、どう判断しているか」を紹介します。

デッドコードに気づけるタイミング

実際に多かったのは、機能修正時の影響調査のタイミングです。

機能追加・改修時に「この分岐、意味ある？」と違和感を覚えたとき
APIレスポンスやDBカラムを見て「これ、どこで使ってる？」と思ったとき
仕様変更後もコードが残り続けていることに気づいたとき

重要なのは、「デッドコードかも？」と思った瞬間を逃さないことです。

急ぎの機能開発を進める中で

「一応残っているから考慮する」
「消す自信が無いから触らない」

という判断になりがちです。
しかし、デッドコードは溜まる一方です。

そこで私は、「デッドコードかも？」と思ったときにやることを決め、
単純作業として淡々と消化することが重要だと考えました。

「デッドコードかも？」と思ったら、まずやること

怪しいコードを見つけたら、
まずは本来やりたい開発への影響があるかどうかを軽く調査します。
すぐに削除しない場合でも、方針を決めて issue 化するところまでを最低限やります。

調査時に意識しているのは、以下の点です。

本来やりたい開発への影響はあるか？
削除前提の方が開発しやすいか？
部分的に消せるか？
対応に時間はかかりそうか？
今やるべきか、後回しにするか？

これらの判断材料を集めるために、次の調査を行います。

1. 動的な実行実績を確認する

まずは「本当に使われているのか？」を確認します。

Coverbandでコードカバレッジを確認
- ハローでは実際のリクエスト処理時に実行されたコードがカバレッジとして記録されている
- ダッシュボードでファイルごとや行単位での利用状況を確認する
GCPのログエクスプローラーでログを確認
- エンドポイントへのリクエストが発生しているか？
- 意図的に仕込んだログが出力されているか？

# ログを仕込む例
# TODO: 2025/10/01頃にログ確認する。確認後、このログは削除する
Rails.logger.info({
    # 対象コード、実行時の変数、ログの目印など、判断に必要なkeyを追加しておく
    event: "hoge_model.create_xxx_on_complete.created_xxx",
    order_id: params[:id],
    investigation: true,
    tag: "調査用"
}.to_json)

特にログは重要で、できるだけ早く仕込むことを意識しています。

ネイティブアプリの旧バージョン利用者を考慮すると、削除判断に1ヶ月以上かかるケースもあります。
そのため、「怪しい」と思った時点でログを仕込んでおくと、判断のタイミングを早めることができます。

2. 静的に「使われていない」ことを確認する

次に、コードベース上の証拠を集めます。

Claude Code などを使って「このコードはどこから呼ばれているか？」をざっくり確認
grep でコードベース全体を検索
DBを確認し、特定の時点からレコードが作られていないことを確認

コードを実際に追うのは大変ですが、複数の観点で証拠を積み上げ、削除判断の精度を上げます。

3. なぜデッドコードになったのかを辿る

どうしても判断に迷う場合は、「いつ・なぜ不要になったのか」 を辿ります。

git blame で最終更新を確認
- VSCode の GitLens 拡張から Pull Request のリンクを辿る
git log -S {コード} で該当コードが使われなくなったコミットを特定
上記で見つけた、当時のPRや、Slackのやり取りを確認し、背景を理解する

背景から何が「正」か分かると、判断に自信を持ちやすくなります。

いつデッドコードを削除するか？

調査結果をもとに、

issue化だけするか
その場で対応するか

を判断します。
基本スタンスは、「削除できると確信できたタイミングで、なるべく早く」です。

判断	条件	アクション
今すぐ削除	削除できる確信があり、今回の開発にプラスになる	削除対応の Pull Request を作る
部分削除	全体は怖いが、特定の分岐やフィールドは不要	消せる箇所だけ先に消す
Issue化して保留	削除の影響が大きい、または一定期間のログ観測が必要	調査結果を記載してチケット化

特にDBカラムやAPIレスポンスフィールドは放置すると、

うっかり新規APIレスポンスに含めてしまう
フロント側で使用箇所が増えてしまう

といったことが起き、削除コストが一気に上がります。

新機能開発が優先される場合でも、

本来の開発に影響するか
削除にどれくらい時間がかかるか

の2軸で、issue化だけするのか、すぐに対応するのか判断します。
部分的に対応できる場合は、影響部分だけ先に削除することで、新機能開発で余計な考慮を不要にできます。

どうやって削除していくか（順序と注意点）

主に2つのポイントを意識しています。

可能な限り小さくリリースする
フロントエンド（特にネイティブアプリ）を意識する

私たちは React Native + Expo を使っており、OTA（Over-The-Air）アップデートが可能です。とはいえ、営業中の店舗に影響が出るリスクはゼロではありません。

そのため、

フロントエンドで未使用にする
一定期間様子を見る
（ログ出力がなくなり、全てのアプリ利用者が新バージョンに切り替わったことを確認）
バックエンドを削除する
- DB カラムも削除する場合は、ignored_columns を使って、複数回のリリースに分けた段階的な削除を行う

という順序を意識しています。

削除後に気をつけること

エラー監視・ログをしばらく注意深く見る
万が一の切り戻しができる状態を保つ

「削除して終わり」ではなく、削除後の安定性確認まで含めてデッドコード対応だと考えています。

これからデッドコードを増やさないための心がけ

デッドコードを増やさないため、普段の実装では次のことを意識しています。

1. 調査しやすいコードを書く

動的呼び出しを避ける

# 動的呼び出しはgrepしづらい
public_send("size_of_#{category}") 

# 代替案（size_of_smallやsize_of_largeでgrep可能にする）
def size_of(category)
  {
    small: size_of_small,
    large: size_of_large
  }.fetch(category)
end

ユビキタス言語・命名規則を揃える
（用語が揃っていることで、検索時に抜け漏れや関連処理に気づきやすい）

2. 用途別にコードを分ける

用途ごとにAPIを分離し、ログ確認とエラー調査を容易にする
- 例えば、同じリソースへの検索機能だとしても、検索シーンが異なる場合はAPIを分ける（全ての用途に対応できる1つの万能APIにしない）
- 「この用途が消えたら、この塊を消せる」状態を作る

3. 必要最低限の実装にしておく

APIでは必要最低限のフィールドを返す
- Serializerにフィールドを追加した際、意図しないAPIで返ってしまうのを防ぐ
- 不要なものを含んでいる状態だとフィールドを削除したい時に調査の手間が増えてしまう
「後で使うかも？」なコードは書かない（YAGNI）
- 「せっかく書いたので、一旦、コメントアウト」もしない

4. TODOコメントを残す

未来の自分や他のメンバーが判断できる状態を作るために、削除条件と参考リンクを残す

  # 2025/10にフロント削除から xxヶ月経過する。その時点でログ出力がなければ削除する
  # https://github.com/xxxx/pull/999

おわりに（エンジニア採用について）

デッドコード削除は地味なテーマですが、プロダクトを長く、速く成長させるためには欠かせない技術的取り組みだと考えています。

私たちは、こうした「技術的負債への向き合い方」も含めて、エンジニアリングを楽しめる仲間を探しています。

もしこの記事を読んで少しでも興味を持っていただけたら、ぜひカジュアルにお話しできればと思います！

https://www.hello.ai/careers