
技術的負債の見える化|優先順位のつけ方を一人運用の現場で
「ここ、いつか直さないとな」。 そう思いながら通り過ぎた場所が、頭の中に何個もたまっていませんか。動いてはいるけれど気持ち悪いコード、コピペで増えた似た処理、誰も触れないバッチ、古いままのライブラリ——。保守運用をしていると、「直したいところリスト」だけが心の中でどんどん長くなっていきますよね。
やっかいなのは、それが全部あなたの頭の中にしかないことです。数が見えないから不安になり、優先順位もつかず、結局いつも「今日の障害と問い合わせ」で一日が終わる。負債は減らないまま、また少し増えていく。
この記事では、その頭の中の負債を一覧にして見える化し、どこから手をつけるかの優先順位をつける進め方を、一緒に整理します。きれいな管理ツールを入れる話ではありません。テキスト1枚から始められる、一人でも回せる方法です。
結論:技術的負債は、①頭の中にあるものを全部1枚に書き出す → ②各項目に「影響(放置したら何が起きるか)」と「手間(直すのにかかる労力)」を大まかに付ける → ③『影響が大きく・手間が小さい』ものから着手するの順で扱います。完璧な評価はいりません。まず全部を目に見える台帳に出すだけで、「多すぎて動けない」が「この順で1つずつ」に変わります。
負債の中身も直し方も現場ごとに違います。順番と観点を出発点に、自分の現場の言葉に置き換えて使ってください。
何が起きているか:負債が減らない3つの理由
「直したいのに直せない」のは、あなたの意志が弱いからではありません。たいてい次の3つの構造が原因です。まずここを知っておくと、自分を責めずにすみます。
- 見えていないから、大きさが分からない:頭の中にあるうちは、負債は「なんとなく怖い塊」のまま。数も影響も測れないので、着手の判断ができない。
- 緊急の仕事に、いつも負ける:障害・問い合わせ・依頼は締め切りがある。負債の返済は締め切りがない。だから毎回あと回しになり、永遠に順番が来ない。
- 一度に全部直そうとして、動けなくなる:「やるなら根本から」と構えるほど、手間が大きく見えて着手できない。結果、1つも進まない。
どれも「気合いが足りない」話ではなく、見える化と優先順位づけの仕組みがないという構造の問題です。だから、精神論ではなく、書き出して並べる作業で解きます。
技術的負債を見える化する4つのステップ(順番に)

頭の中の塊を、外に出して並べていきます。各ステップは、テキストエディタか表計算1枚あれば始められます。
① まず「全部」書き出す(きれいさより網羅)
最初の一歩は、頭の中にある「直したいところ」を、質を気にせず全部書き出すことです。ここでの目的は評価ではなく、棚卸しです。
- 「気持ち悪い」「怖い」と感じる場所を、思いつくまま1行ずつ書く。粒度はバラバラでかまわない。
- コードだけでなく、古いミドルウェア・切れそうな証明書・手動運用・ドキュメント不在も負債として書く。負債はコードの中だけにいるわけではありません。
- 「なぜ気持ち悪いか」を一言そえる(例:「同じ処理が3か所にコピペ」「テストがなくて触るのが怖い」)。
ここで大事なのは、きれいにまとめようとしないことです。順番も分類も後回し。まずは頭の外に出しきる。書き出すだけで「思っていたより数は多いけど、無限ではない」と分かり、それだけで少し落ち着けます。
② 各項目に「影響」と「手間」をざっくり付ける
書き出せたら、各行に2つの目盛りを付けます。細かい点数はいりません。大・中・小の3段階で十分です。
- 影響(放置したら何が起きるか):これを直さず放っておくと、障害・情報漏えい・作業時間の浪費・引き継ぎ不能など、どれくらい困るか。人の目に触れる事故につながるものほど「大」。
- 手間(直すのにかかる労力):直すのにどれくらいの時間・リスク・検証が必要か。すぐ終わるものが「小」、影響範囲が広く検証も重いものが「大」。
この2つを、全項目にざっと付けていきます。迷ったら直感で置いて先に進んでかまいません。厳密さより、全項目に同じ物差しを当てることが大切です。物差しさえそろっていれば、後で並べ替えたときに比べられます。
③ 「影響大・手間小」から並べる
2つの目盛りが付いたら、優先順位は自然と見えてきます。基本はシンプルで、影響が大きく・手間が小さいものが最優先です。
- 影響大 × 手間小:まずここ。少ない労力で大きなリスクを減らせる、いちばんおいしい場所。
- 影響大 × 手間大:計画して取り組む。一度に全部やらず、小さく分割して少しずつ返す(詳しくはテストがないコードに手を入れる前にやる安全策の考え方が使えます)。
- 影響小 × 手間小:ついでの時に片付ける。障害対応や改修で近くを触ったとき、一緒に直すと効率がいい。
- 影響小 × 手間大:基本はやらない(今は放置と決める)。ここに時間を使うと、大事なものが進まない。
「影響小・手間大は今はやらない」と決めて書いておくのがコツです。やらないことを決めると、罪悪感なくあと回しにでき、頭の中から負債を1つ追い出せます。
④ 台帳にして、定期的に見直す
並べ終えたら、それを消えない場所——テキストファイルや表計算——に台帳として残します。頭の中に戻さないことが、見える化を続ける唯一のコツです。
- 1行1負債で、「対象/気持ち悪い理由/影響/手間/今の方針(着手・様子見・やらない)」を持つ。
- 新しく気づいた負債は、その場でこの台帳に足す(頭の中にためない)。
- 月1回でいいので眺めて、直したものを消し、状況が変わったものの影響・手間を付け直す。
台帳は完璧である必要はありません。「今、負債がいくつあって、次に何をやるか」がひと目で分かる——それだけで、この台帳は十分に働いてくれます。
具体例:頭の中の「気持ち悪い5つ」を並べてみる
たとえば、ある担当者の頭の中にあった5つを、影響と手間で並べるとこうなります。
- SSL証明書が手動更新のまま:影響=大(切れたら全ページ止まる)/手間=小(監視と自動更新を入れるだけ)→ 最優先。
- 同じ集計処理が3画面にコピペ:影響=中(1か所直すと直し漏れが出る)/手間=中 → 近くを触るとき共通化。
- サポート切れ間近のPHPバージョン:影響=大/手間=大 → 計画して段階的に。まずはEOLの棚卸しから。
- 誰も使っていない気がする古いバッチ:影響=小/手間=中(消す前の調査が要る)→ 様子見、ログで使用を確認してから。
- 変数名が全部
data1tmpのレガシー画面:影響=小/手間=大 → 今はやらない、と決める。
5つのうち、まず手をつけるのは1つ(証明書)だけとはっきりします。「全部気になる」だった状態が、「今日は証明書、PHPは計画、あとは触るついで」と整理される。これが見える化と優先順位づけの効きめです。
影響:見える化しておくと、何が変わるか
負債を1枚に出して並べておくと、返済のスピードより先に、日々の気持ちと説明のしやすさが変わります。
- 「山ほどある」という漠然とした不安が、「◯個あって、次はこれ」という具体に変わり、落ち着ける。
- 少しでも時間ができたとき、迷わず「影響大・手間小」の1つに手を出せる。判断のコストが消える。
- 上司や依頼者に「今こういう負債があり、放置するとこのリスク、直すにはこの工数」と根拠を持って説明でき、返済の時間を交渉しやすくなる。
- 引き継ぎのとき、「触ってはいけない場所」「直しかけの場所」を台帳ごと渡せる。属人化がやわらぐ。
逆に、頭の中だけで抱えていると、負債の総量が見えないまま増え、たまに思い出しては不安になる——を繰り返します。見える化は、返済そのものより先に、その不安の連鎖を止めてくれるのがいちばんの価値かもしれません。
明日やること:負債を10個だけ書き出す
いきなり完璧な台帳は要りません。明日できる、いちばん小さな一歩はこれです。
- まっさらなテキストファイルか表計算を1枚開く。名前は「負債台帳」でいい。
- 頭に浮かぶ「直したいところ」を、思いつくまま10個だけ1行ずつ書く。粒度はバラバラでOK。
- 各行に、影響(大中小)と手間(大中小)をざっと付ける。迷ったら直感で。
- 「影響大・手間小」の行に印をつける。それが次にやる候補です。
- 「影響小・手間大」の行に「今はやらない」と書く。これで頭から1つ追い出せます。
きれいに分類しなくて大丈夫です。10個書いて印をつけるだけで、頭の中の霧が「並んだリスト」に変わります。続きは、気づいたときに1行ずつ足していけばいい。
「技術的負債の見える化」チェックリスト
台帳を作るとき・見直すときに当てる項目です。コピーして自分のメモに置いてみてください。全部を最初からそろえる必要はありません。
まず外せない最低ラインはこの3つです。ここだけでも、頭の中で抱えるよりずっと楽になります。
- 【最低ライン】頭の中の負債を、消えない場所に1つでも書き出したか
- 【最低ライン】各項目に「影響」と「手間」を同じ物差しで付けたか
- 【最低ライン】次にやる1つ(影響大・手間小)を決めたか
次は、台帳を続けていくための項目です。慣れてきたら足していきましょう。
- コードだけでなく、古いミドル・証明書・手動運用・ドキュメント不在も負債に入れたか
- 「今はやらない」と決めた負債を、はっきり書いて頭から追い出したか
- 新しく気づいた負債を、その場で台帳に足す習慣にしたか
- 月1回など、見直すタイミングを決めたか
- 影響大・手間大のものは、小さく分割して段階的に返す計画にしたか
- 引き継ぎ時に、この台帳ごと渡せる形にしてあるか
全項目に○が付かなくても大丈夫です。最低ラインの3つだけでも、頭の中だけで抱えているより、確実に前へ進めます。
よければ、こちらも
負債の見える化は、レガシーと長くつきあうための入口です。棚卸し・安全な改修・引き継ぎとセットにすると、返済がぐっと現実的になります。
- サポート切れ(EOL)のOS・ミドルウェアを棚卸しする手順:負債の中でも「期限があるもの」を、抜けなく洗い出すための1枚です。
- テストがないコードに手を入れる前にやる安全策:影響大・手間大の負債を、事故なく少しずつ返すための備えです。
- 作った人がいないシステムを引き継いだ初日にやること:引き継いだ側が、負債の全体像をつかむ最初の一歩に。

技術的負債がこわいのは、それが見えない塊のまま、頭の中で大きくなっていくからです。でも、一度紙に出して並べてしまえば、それはもう「無限の不安」ではなく、「順番のついたリスト」になります。 今日は10個だけ書き出して、次にやる1つに印をつける。それだけで、抱えていた重さが少し軽くなるはずです。
ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。