先月配った週次報告のフォーマットを、今も全員が同じ形式で出していますか。引き継ぎ資料を開いたら、前任者と前々任者のやり方が層になって残っていませんか。なぜオフィスには、こうした「動いてはいるが、もう誰も見ていないもの」が静かに積み上がっていくのでしょうか。この問いへの答えは、実はコンピュータサイエンスの中に、すでにいくつも用意されています。
職場に溜まっていく「地層」
新しい担当者が着任するたびに、業務は少しずつ増えていきます。前任者のやり方をいきなり捨てるのは怖いので、まずは残したまま、自分のやり方をその上に足す。次の担当者も、また同じことをします。たとえば、ある部署で3年のあいだに担当者が3回替わったとします。最初の担当者が作った申請フォーム、次の担当者が追加した確認欄、さらに次の担当者が付け足した承認ステップ。どれも当時は理由があって足されたものですが、その理由を知っている人はもう社内にいません。結果として残るのは、誰も全体像を説明できない、分厚い手続きの束です。
似たことは会議の場でも起こります。定例会議のアジェンダを思い浮かべてください。最初は5項目だったものが、担当者が異動するたびに項目が1つずつ増え、今では10項目を超えている。そのうち半分は、報告する本人も「なぜこれを毎回話しているのか」を説明できません。それでも「アジェンダから外す」という決定を誰も下さないまま、会議時間だけが延びていきます。数年もすると、誰ひとり全体像を把握していない「地層」のようなものができあがるのです。
配布リストにも、似たことが起きます。週次報告の宛先に、すでに異動した人や退職した人が残っていることは珍しくありません。誰かが気づいてリストから外さない限り、その人は永遠に「読者」として数えられ続けます。実際には誰にも読まれていないのに、送る側は「一応送っておく」を続けてしまいます。たとえば、宛先30人のうち実際に開いて目を通しているのが10人だけだとすると、残り20人分の配布・確認・体裁調整の手間は、実質的に誰の役にも立っていないことになります。これは決してその部署だけの怠慢ではありません。むしろ、誰も明示的に「やめよう」と言わなければ自然に起こる、構造的な現象です。
なぜ地層は放置されるのか
厄介なのは、これらが「壊れている」わけではないという点です。むしろ問題なく動いているからこそ、誰も手を付けずに放置されます。壊れたものなら誰かが気づいて直しますが、動いているだけのものには、気づく仕組みそのものがありません。誰かが「これ、まだ要りますか」と言い出さない限り、地層は増え続ける一方です。そして、言い出す役目は、たいてい割に合いません。整理をしても評価されにくく、逆に消したものが実は必要だったと分かれば、責任を問われるのはその人です。「触らなければ減点されない」という判断が、職場のあちこちで静かに積み重なっていきます。だからこそ、多くの職場でこの地層は、誰も悪気なく放置されたままになります。
ソフトウェアも同じ形で汚れていく
実はこの現象、ソフトウェア開発の世界でもまったく同じ形で起きています。プログラムも、要件が変わるたびに、古いコードを消さずに新しいコードを上に積み増していく傾向があります。締切に追われた開発者は、既存のコードを整理する時間を取れないまま、動くものを足していきます。ある機能を一時的に止めるための切り替えスイッチが、役目を終えたあとも消されずに残ることもあります。「今は動いているコードに、余計な手を入れるな」という空気は、多くの現場に存在します。その空気は短期的には安全に見えますが、長期的には地層をさらに分厚くします。結果として、もう呼び出されていない関数や、二度と実行されない条件分岐が、コードの内部に静かに堆積していきます。放置されたコードは、エラーを出しません。テストを実行しても、通常の動作を確認しても、何の問題も見つかりません。ただそこにあり続け、後から読む人を惑わせ、修正のたびに「これは本当に使われていないのか」という確認の手間を生みます。新しく参加したメンバーは、地層のどこが今も生きていて、どこがもう死んでいるのかを見分けられず、時間を浪費します。この構造は、あなたの職場で起きていることと、驚くほど重なります。
CSの世界にある「棚卸し」の技術
ソフトウェア開発の現場では、この堆積に対処するための考え方が、長年かけて整理されてきました。本章で扱うのは、次の4つです。
デッドコード削除は、動いてはいるが結果には何も影響しない部分を見つけて取り除く考え方です。先ほどの「もう誰も読まない議事録の項目」を思い浮かべてください。それを削除の候補として名指しする発想が、これにあたります。
リファクタリングは、最終的な結果を一切変えずに、内部の作りだけを整理し直す技術です。承認フローの順番を入れ替えて時間を短縮する、フォーマットをひとつに揃える、といった作業がこれにあたります。出てくる結果は変わらないまま、そこに至る道筋だけを効率化します。
技術的負債は、今の効率を優先して先送りにした整理には、あとで利子がついて返ってくるという考え方です。「今回だけ」の例外対応が、毎回の定例作業になっているとしたら、それはすでに利子を払い続けている状態です。
ボーイスカウトルールは、大掛かりな計画を立てずに、日々の作業のついでに少しずつ整理していく習慣です。何かの資料を開いたついでに、古い注記を1つ消す。その積み重ねが、地層の増加をゆっくりと押しとどめます。
これらは、それぞれ独立した技法というより、ひとつながりの発想です。まず「もう要らないもの」を見極めて手放し、残すものは結果を変えずに整理し直し、後回しにした整理には利子がつくことを意識して優先順位をつけ、そして日々の作業の中で少しずつ続けていく。4つのうちどれか1つだけを実行しても、効果は限定的です。消すだけでは残ったものが整理されず、整理するだけでは優先順位が付かず、優先順位だけ分かっても継続する仕組みがなければ、また地層は積み上がります。
なぜ「棚卸し」を怖がらずにできるのか
業務の整理を後回しにする最大の理由は、「触ると何かが壊れるかもしれない」という不安です。この不安は、動いているコードに手を入れる開発者の不安と、まったく同じ構造をしています。だからこそ、ソフトウェア開発の世界では、安全に整理を進めるための判断基準が発達してきました。「これは本当に使われていないのか、どう確認すればよいか」。「結果を変えずに整理するとは、具体的にどういう作業なのか」。「先送りにした整理の代償は、どれくらいの大きさなのか」。こうした問いに、CSはすでに一定の答えを用意しています。共通しているのは、いきなり大きく手を入れるのではなく、確認しながら小さく進める、という発想です。「消せるかどうか分からないから、とりあえず全部残す」のではなく、「使われた形跡があるかどうかを、まず確かめる」。この一手間があるだけで、棚卸しは賭けではなく、根拠のある判断に変わります。「なんとなく不安だから残す」から、「確認した上で、必要なら残す」へ。この違いは小さく見えて、棚卸しを続けられるかどうかを大きく左右します。本章では、その答えを1つずつ、職場でよくある場面に置き換えながら確認していきます。特別な権限や大きな予算がなくても、明日から始められる小さな確認方法から見ていきます。
棚卸しをしないことの代償
「触らなければ減点されない」という判断は、個人にとっては合理的に見えます。しかし、組織全体で見ると、その代償は静かに積み上がっていきます。たとえば、10年分蓄積された手順書のうち、実際に今の業務で参照されているのが3割程度だとすると、残り7割は誰かが引き継ぐたびに「念のため目を通す」対象になり続けます。新しく着任した人は、その7割が本当に不要かどうかを自分では判断できません。結局、前任者に確認するか、そのまま丸ごと引き継ぐかのどちらかを選ぶことになります。どちらを選んでも、地層はそのまま次の代へ引き継がれます。棚卸しをしないことは、何もしない選択ではありません。「確認と引き継ぎのコストを、次の担当者に先送りする」という、積極的な選択なのです。
地層が厚くなるほど、身動きが取れなくなる
棚卸しを先送りにする一番の弊害は、個々の資料や手順が無駄になることそのものではありません。本当の弊害は、地層が厚くなるほど、新しい変化を受け入れる余地が狭くなることです。新しい仕組みを導入しようとするたびに、「今動いているものとどう整合させるか」を考える手間が増えます。その手間が積み重なると、担当者は次第に「今のままでいい」を選びやすくなります。変化そのものを拒んでいるのではなく、変化にかかる調整コストが高すぎて、割に合わないと感じているだけです。経営や上司から見れば「現場が変化を嫌っている」ように映りますが、実態は逆で、地層の分厚さが変化のコストを押し上げているだけのことが少なくありません。棚卸しは、過去を整理する作業であると同時に、これから先の変化を受け入れやすくするための準備でもあります。
この章の進み方
次のページから、先に挙げた4つの考え方を1つずつ取り上げます。それぞれのページで、CSの世界での意味、仕事の言葉への翻訳、具体的な職場の場面、そして誤用しやすい落とし穴の順に確認します。最後のページでは、4つの考え方をつなげて、日常業務の中でどう習慣化するかをまとめます。読み終える頃には、あなたの職場に積もった「地層」のどこから手をつければよいか、輪郭が見えているはずです。どのページも独立して読めるように書いていますので、気になる単元から先に読んでもかまいません。ただし、4つを一通り知っておくと、削除・整理・優先順位づけ・継続という一連の流れとして扱えるようになります。
持ち帰り
- 業務にも、コードと同じように「使われないまま残るもの」が静かに堆積していく
- 整理を後回しにする理由は「触ると壊れそうな不安」であり、CSにはその不安を扱う判断基準がある
- 本章では、デッドコード削除・リファクタリング・技術的負債・ボーイスカウトルールの4つを扱う
やってみる
今、手元にある定型フォーマット(週次報告・議事録・申請書のいずれか)を1つ選んでください。それを最後に「誰かが実際に使った」のがいつだったか、次のページを読む前に思い出してみましょう。