Library

使われていない機能を見つけて消す

公開日:2026-08-29 更新日:2026-08-29

技術者向け

Article

本文

機能を足してほしいという依頼は来ますが、消してほしいという依頼はまず来ません。十年動いているシステムには、誰も開いていない画面や、結果を誰も見ていないバッチが積み上がっています。改修のたびに影響範囲としてそれらを読み、テスト対象に数え、移行のときには移行対象として見積もりに入れている。使われていないと分かれば、その手間はまるごと消えます。

ただし、勘で消すと事故になります。年に一度しか動かない処理を、半年分のログだけ見て消してしまう。この失敗は取り返しがつきません。何を根拠に消すと決めるか、材料の集め方から書きます。

アクセスログを一年分そろえる

最初にやるのは、URLごとのアクセス件数を一年分集計することです。四半期では足りません。年度末や決算期にしか動かないものを取りこぼします。

着手してすぐ分かるのは、ログがそんなに残っていないという事実のほうです。ローテーションの設定で三か月分しか手元に無いことがよくあります。その場合は、いまから保存期間を延ばして一年待つという判断も現実的です。急いで消すより、材料がそろうのを待つほうが安全です。

集計するときは、パスに埋まったIDやパラメータを落として正規化します。そのうえで、監視のヘルスチェック、クローラ、社内からの疎通確認をユーザーエージェントと送信元IPで除外します。これをやらないと、実際には誰も使っていない画面が毎日数百件アクセスされているように見えます。

件数がゼロだったときは、使われていないのか、そもそもログに出ない経路なのかを区別してください。バッチ処理、非同期のジョブ、別ドメインに置かれた管理画面は、見ているログに現れません。ゼロという結果は、調査の終わりではなく確認の始まりです。

問い合わせ履歴を突き合わせる

ログが教えてくれるのは使われた回数だけで、なぜ使われていないかは分かりません。そこを埋めるのが問い合わせの履歴です。

ヘルプデスクのチケット、運用の連絡メール、社内チャットの過去ログを、機能名と画面名で検索します。二年さかのぼって一度も名前が出てこない機能は、消しても気づかれない可能性が高い。逆に、アクセス件数は少ないのに問い合わせだけ多い機能は残します。使いにくいから避けられているだけで、業務そのものには要る、という形です。

業務マニュアルや手順書に載っているかどうかも見ます。手順書に書いてあるのに使われていないなら、運用が変わって手順書が古いのか、その業務自体が止まっているのか、どちらかです。ここはコードからは分かりません。使っている部署に聞きます。

年に数回しか動かないものを数え落とさない

一年分のログでも足りないものがあります。数年に一度の制度改定に合わせた処理、特定の取引先だけを対象にした分岐、障害時にしか使わない復旧用の画面。

これらはコードの側から探せます。条件分岐に日付や取引先コードが直接書き込まれている箇所を洗い出し、その条件を満たす期間のログだけを別に確認します。ログの保存期間を超えている場合は、消す対象から外してください。分からないものを消す理由はありません。

消す前に、届かなくする

判断がついても、いきなり削除はしません。まず到達できない状態にします。メニューから項目を外す、ルーティングで応答を止める、バッチはスケジュールから外す。コードは残したままです。

止めている間、そのURLに来たアクセスは記録に残します。メニューから消しても、ブックマークや共有された直リンクで来る人がいます。月に数件でも来るなら、使っている人がいるということです。

期間はひと月では短い。決算や年度切り替えに関わる領域なら、その時期をまたぐまで待ちます。そして止める前に、戻す手順を書いておきます。すぐ戻せると言えるかどうかで、関係者から合意を得られる速さが変わります。

コードを消して、データは残す

削除の順番はコードが先です。テーブルとデータは残します。機能を消した後になって、過去の数字を出してほしいと言われることがあります。テーブルが残っていれば直接照会して答えられますが、消していたら何もできません。

外部との連携を含む処理は別扱いです。他社から呼ばれているAPIは、こちらのログで件数がゼロに見えても止められません。相手先がいつ呼ぶかはこちらでは決められないからです。連携先がある機能は、先方に確認が取れるまで残します。

消したら記録を残します。いつ、何を、どの数字を根拠に消したか。リポジトリの中のテキストファイルに数行書いておけば十分です。半年後に「あの機能どこ行った」と聞かれたとき、これがあるかないかで話が変わります。

全部を判定しようとしない

この作業は、システム全体の棚卸しとして始めると終わりません。改修で毎回読まされる場所、移行の見積もりを押し上げている場所から順に、必要な分だけ調べます。

材料を集めても判断がつかないものは出ます。そのときは保留と書いて残してください。調べたうえで判断できなかったものと、まだ調べていないものを分けておくだけで、次に手を付ける人の作業がかなり減ります。

もうひとつ、消してよいと決められる人がいない機能は消しません。技術的にはどう見ても不要でも、その業務の責任者が誰か分からないなら、消す判断は誰の権限でもない状態です。そこは残したまま、調査済みで影響なしという注記を付けておく。次に触る人が読む時間を短くできれば、それでいったんは足ります。