エラーも出さず正常に動いているのに、誰の役にも立っていない仕事があります。それに気づいても、なぜか誰も手を止めて確認しようとしません。あなたの職場にも、こうした「動いているだけの業務」が、いくつか隠れているのではないでしょうか。今日はその見つけ方と、扱い方を考えます。手がかりは、ソフトウェア開発の世界がすでに何十年も向き合ってきた、地味だけれど効果の大きい習慣の中にあります。
デッドコードとは何か
ソフトウェアの世界では、こうした部分を「デッドコード」と呼びます。プログラムの中に確かに存在し、実行もされるけれど、最終的な結果には一切影響を与えないコードのことです。呼び出されない関数、二度と成立しない条件分岐、計算した後に誰も参照しない変数。これらは動作を確認しても、エラーとしては現れません。プログラム自体は正常に完走してしまうからです。だからこそ、開発者自身も気づきにくく、長期間放置されやすいという特徴があります。
デッドコードが生まれる典型的な経緯の1つに、機能の一時停止があります。ある機能を試験的に導入するとき、開発者はしばしば「切り替えスイッチ」を用意します。問題が起きたらすぐ元に戻せるようにするための仕組みです。試験が終わり、その機能を正式に採用するか廃止するかが決まったあとも、切り替えスイッチ自体とその周辺のコードは、消されずに残ることがよくあります。「あとで整理すればいい」という判断が、次の締切に押されて先送りになり続けるからです。気づけば、その機能を知る人がチームからいなくなり、周辺のコードだけが理由も分からないまま残される、ということも起こります。
多くの開発現場では、静的解析ツールと呼ばれる仕組みを使って、こうした「呼ばれていない部分」を機械的に洗い出します。人の記憶や勘に頼らず、実際の呼び出し関係をプログラムに追跡させて、候補を一覧にする方法です。重要なのは、デッドコードを削除しても、プログラムの動作は何ひとつ変わらないという点です。消すこと自体にリスクがあるのではなく、消すべきかどうかを見極めることにこそ、手間がかかります。
デッドコードとよく似た言葉に、単に読みにくいコードや、汚いコードがあります。両者は別の問題です。読みにくいコードは、動作には影響しますが、直せば結果が変わる可能性があります。デッドコードは、そもそも結果に一切関わっていないという点が異なります。この区別は仕事でも重要です。「使われているけれど分かりにくい資料」を直すのは、次のページで扱うリファクタリングの領分です。「そもそも使われていない資料」をどう扱うかが、このページのテーマになります。両者を混同すると、本来消せるはずのものを一生懸命整えてしまう、という無駄が生まれます。
仕事の言葉に翻訳すると
会社における「デッドコード」とは、今も作り続けられているのに、誰の意思決定にも使われていない資料や手順のことです。特徴はソフトウェアの場合とよく似ています。エラーが出ない、つまり誰にも怒られないので、気づかれにくいのです。提出が滞れば誰かが催促しますが、提出され続けている限り、それが読まれているかどうかを確認する仕組みは、たいてい存在しません。
「作ることそのもの」は評価の対象になりやすい一方、「もう作らなくていい」と判断することは、誰の評価にもなりにくいという非対称性があります。資料を作った実績は、業務量として周囲から見えます。一方で「この資料は不要だと判断した」という実績は、多くの職場で記録にも評価にも残りません。この非対称性こそが、デッドコードが会社に溜まり続ける根本の理由です。誰も悪意を持って無駄な資料を作り続けているわけではなく、やめる決定にだけ割の合わない構造があるのです。この構造を変えるには、個人の意識の問題として片付けず、「やめる決定を下しやすくする仕組み」を用意する視点が必要になります。
具体的な場面
日報が読まれているかどうか。ある部署では、全員が毎日日報を作成し、上司にメールで提出することになっていました。実際には、上司はメールを開封するだけで中身にはほとんど目を通していません。たとえば、部下が20人いて日報を毎日提出しているとしても、上司が実際に文面まで読んでいるのがそのうち数人分だけだとしたら、残りは形だけの提出になっています。それでも「出すこと」自体が習慣として続き、誰もこの運用を疑いませんでした。開封の記録や、上司からの反応の有無を確認して初めて、この日報が意思決定にほとんど使われていないことが分かります。
旧フォーマットの帳票。システムを新しくした際、多くの帳票は新しい形式に置き換わりました。ところが一部の部署だけ、旧フォーマットへの提出を習慣で続けていました。新システム側では、その旧フォーマットの情報を誰も参照していません。提出する側も受け取る側も、それぞれ「相手が必要としているはず」と思い込んだまま、確認しないまま作業だけが続いていたのです。半年後にたまたま棚卸しをして初めて、双方が「相手のために」と思い込んでいたことが判明しました。
担当者不在の議題。定例会議のアジェンダに、ある事業の進捗報告という項目がありました。その事業自体は半年前に終了していましたが、項目は形式的に残り続けていました。担当者は仕方なく「特に進捗はありません」と毎回発言し、会議の時間を数分ずつ消費していました。1回あたりは小さな時間でも、毎週・毎月と積み重なれば、決して小さくない時間になります。
3つの場面に共通するのは、誰も間違ったことをしていない、という点です。上司はメールを開封しているし、担当部署は帳票を確認しているつもりだったし、司会は議題を読み上げているだけです。それぞれの行動は正しく、悪気もありません。それでも全体として見ると、実質的な効果を生んでいない作業が、そのまま続いてしまっています。デッドコードは、個人の怠慢ではなく、確認する仕組みが存在しないことによって生まれる現象なのです。
なぜ「念のため残す」が一番のコストになるのか
デッドコードを消さない理由として、最もよく挙がるのは「念のため残しておく」という判断です。一見すると安全に思えますが、実際にはこれが一番コストの高い選択になっていることが少なくありません。資料や手順は、存在するだけで維持コストを生み続けるからです。提出や更新の手間、確認や引き継ぎの時間、そして「これは本当に必要なのか」と誰かが考え直す時間。これらはすべて、その資料が存在し続ける限り、繰り返し発生し続けます。たとえば、5分で作れる資料でも、月に1度・10年間作り続ければ、合計の作業時間は決して小さくありません。「念のため残す」は一見コストゼロの選択に見えますが、実際には毎回少しずつ支払い続ける選択なのです。消すかどうかを一度きちんと検討するコストのほうが、多くの場合はるかに小さく済みます。
見分け方 — 使用実績をどう確認するか
デッドコードかどうかを判断する一番の材料は、印象ではなく利用実績です。共有フォルダであれば、最終アクセス日時や更新履歴を確認できます。メール配布であれば、開封状況や返信の有無が手がかりになります。定例会議の議題であれば、直近数回分の議事録を見返し、実質的な議論や決定が発生していたかを確認します。いずれも特別なツールがなくても、既存の記録を数分見返すだけで、多くのことが分かります。大切なのは「たぶん誰も見ていない」という感覚だけで判断せず、必ず記録に基づいて確認する一手間を挟むことです。記録が残っていない場合は、対象となる資料の受け取り手に、直接確認するという方法も有効です。「これは今も必要ですか」と一言尋ねるだけで、多くの場合は明確な答えが返ってきます。聞かれるまで誰も気にしていなかった、という反応が返ってくることも珍しくありません。逆に「実は毎回助かっている」という答えが返ってくることもあり、その場合は自信を持って続ければよいだけです。確認は、削除のための手続きであると同時に、続ける理由をはっきりさせるための手続きでもあります。
落とし穴 — 消し方を間違えると
デッドコードだと思って消したものが、実は年に一度だけ使われる重要な処理だった、という失敗は開発現場でもよく起こります。低い頻度でしか呼ばれない部分は、日常の確認だけでは「使われていない」ように見えてしまうからです。業務でも同じことが起こります。毎月は使わないが、決算期や監査のタイミングだけ必要になる資料を、うっかり削除してしまうケースです。消す前には、必ず「誰が・いつ・どんな場面で最後に使ったか」を確認する手順を挟む必要があります。これは、コードの利用状況を追跡する仕組みと同じ発想です。
もう1つの落とし穴は、「作った人がまだ社内にいる」ことと「今も使われている」ことを混同してしまう点です。作成者本人が惰性で更新を続けているだけで、受け取る側は実際には見ていない、というケースは珍しくありません。確認すべきは作り手の意思ではなく、受け手の利用実績です。作り手の熱心さと、受け手にとっての価値は、まったく別の軸にあることを忘れないようにしましょう。さらに、廃止の提案が特定の人の担当業務そのものを否定するように受け取られ、感情的な反発を招くこともあります。「この資料が要らない」ではなく「この形式は今の目的に合わなくなっている」という伝え方に変えるだけで、受け止められ方は大きく変わります。
最後の落とし穴は、一度にすべてを削除しようとして、途中で頓挫してしまうことです。職場中の資料を洗い出し、一気に整理しようとする計画は、たいてい途中で息切れします。関係者への確認だけでも相応の時間がかかり、業務の合間に続けるのは簡単ではありません。デッドコードの削除は、範囲を絞って少しずつ進めるほうが、最後までやり切れます。まずは自分の手が届く範囲、たとえば自分が作成している資料や、自分が主催する会議の議題から始めるのが現実的です。小さな範囲で一度やり切った経験は、次に範囲を広げるときの自信にもなります。
持ち帰り
- デッドコードとは、動いてはいるが結果に影響しない部分のことで、エラーを出さないため気づかれにくい
- 会社の場合、作ることは評価されやすく、やめる判断は評価されにくいという非対称性が原因になる
- 消す前には「低頻度アクセス」の可能性を疑い、記録に基づいて利用実績を確認してから判断する
やってみる
自分が定期的に作成している資料を1つ選び、直近の受け取り手に「実際に見ているか」を1行だけ尋ねてみましょう。