「今回だけ」のつもりで済ませた例外対応が、気づけば毎回の定例作業になっていませんか。その場ではうまく切り抜けたはずなのに、なぜか同じ苦労を何度も繰り返している業務はありませんか。なぜ一度片付けたはずのことが、形を変えて何度も戻ってくるのでしょうか。それは負債であり、しかも利子がついて増え続けている、と考えると見え方が変わります。借金と同じように、負債そのものよりも、返さないまま放置する期間の長さが問題になります。
技術的負債とは何か
技術的負債という言葉は、ソフトウェア開発者ウォード・カニンガムが1990年代に使い始めたとされています。本来やるべき設計や実装を省略し、応急処置で済ませることで生まれる、将来の修正コストを指す言葉です。お金の借金にたとえているところがこの言葉の面白さです。借りた瞬間には何の問題も起きません。むしろ、その場をしのげて助かったとさえ感じます。問題は、返さないまま放置したときに発生する「利子」にあります。その部分に関係する機能を追加するたび、担当者はまず応急処置の中身を思い出し、注意深く回避しながら作業しなければなりません。この余計な手間こそが利子です。負債そのものは悪ではありません。締切に間に合わせるために、開発チームが意図的に負債を選ぶこともあります。本当の問題は、借りたことを忘れたまま、返済の計画を持たずに放置することにあります。
ソフトウェア設計に関する著作で知られるマーティン・ファウラーは、技術的負債を「意図したかどうか」と「思慮深いかどうか」という2つの軸で整理しています。締切に間に合わせるために、分かった上であえて簡略化する負債は、意図的で思慮深い負債です。一方、そもそも設計の知識が不足していて、後から見れば明らかに問題のあるやり方を、本人が気づかないまま選んでしまう負債もあります。前者は計画的に返済すればよいものですが、後者はまず「負債があること」自体に気づく必要があるという点で、対処の難しさが異なります。自分たちの職場にある負債が、意図した借金なのか、気づかないうちに背負っていた借金なのかを見分けることが、返済計画を立てる最初の一歩になります。
仕事の言葉に翻訳すると
業務における技術的負債とは、本来整えるべき手順や仕組みを省いて、その場しのぎの対応で済ませたことによって生まれる、将来の追加作業のことです。そして「利子」とは、その仕組みに触れるたびに発生する、余計な確認・調整・手戻りの時間を指します。借金と同じで、金額が大きいほど、また借りている期間が長いほど、支払う利子は増えていきます。業務の負債も同じで、影響する範囲が広いほど、そして放置される期間が長いほど、利子は膨らんでいきます。
この翻訳をすると、業務の中にも「意図した負債」と「気づかれていない負債」の両方があることが見えてきます。締切に追われて「今回だけ手作業で」と決めた例外対応は、意図した負債です。一方、誰かが引き継いだときに、前任者の癖を無自覚にそのまま踏襲しているだけの手順は、気づかれていない負債にあたります。どちらも利子を生む点は同じですが、対処の入り口が違います。意図した負債はすでに存在が分かっているので、返済の計画を立てればよいだけです。気づかれていない負債は、まず「これは実は負債だったのか」と気づくところから始める必要があります。
具体的な場面
例外処理の手作業化。新システムを導入した際、ある特殊なパターンだけ「今回は手作業で処理しよう」と決めました。本来であれば、システム側にその例外パターン用の設定を追加すべきでしたが、導入の締切が迫っていたため、手作業での対応を選びました。当時の担当者にとっては、正しい判断だったはずです。締切に間に合わせることが最優先で、例外パターンの発生頻度もそれほど高くないと見込まれていました。ところが3年後、担当者は既に何度か入れ替わっており、この手作業の理由を知る人はいなくなりました。それでも毎月、同じ質問が新しい担当者から飛び交います。「なぜこのパターンだけ手で処理しているのですか」という質問に、誰も明確に答えられません。毎回15分ほどの手作業だとしても、担当者が変わるたびにこの15分の意味を確認し直す時間が加わり、実質的な負担はさらに膨らんでいきます。
仮運用のまま固定化した承認ルート。急な組織変更のとき、本来の承認ルートを整備する時間がなく、仮のルートで運用を始めました。「落ち着いたら正式なルートに戻す」という前提での仮運用でしたが、落ち着いた頃には、誰もこの仮運用が仮であったことを覚えていませんでした。今では、この仮のルートが正式なものとして扱われ、新入社員はこれが最初から正しい姿だと思い込んで学んでいます。その結果、本来なら不要だったはずの承認者を経由する手間が、恒久的な仕組みとして定着してしまいました。
口頭伝承のままの手順。「あとで正式な手順書を作る」と言いながら、担当者は口頭での説明だけで新人に手順を教え続けていました。文書化されていない手順は、担当者が変わるたびに少しずつ内容がずれていきます。気づいたときには、部署内で3通りの微妙に異なるやり方が併存していました。どれが正しいやり方なのかを確認するために、担当者同士で改めて話し合う時間が必要になり、本来なら発生しなかったはずの調整コストが生まれています。最初に1時間かけて文書化しておけば防げたはずの手間が、何年にもわたって少しずつ支払われ続けている状態です。
利子は複利で効いてくる
技術的負債の厄介さは、利子が単純な足し算では終わらない点にあります。1つの負債を放置したまま、その上に新しい仕組みを重ねると、次の担当者は元の負債と新しい仕組みの両方を理解しなければならなくなります。理解すべき対象が増えるほど、次の作業にかかる時間も増えます。その結果、また新しい応急処置が生まれやすくなり、負債はさらに積み重なっていきます。借金の利子が元本に上乗せされて次の利子を生む複利のように、業務の負債も、放置期間が長引くほど、増え方そのものが加速していきます。最初の数ヶ月は誰も気に留めない程度の手間だったものが、数年後には部署の誰もが「面倒だけれど仕方ない」と諦めて受け入れる、大きな塊に育ってしまうことがあります。早い段階で気づいて返済に着手するほうが、結果的に支払う総額は小さく済みます。「まだ大丈夫」と感じている今この瞬間こそが、実は一番身動きの取りやすいタイミングであることが多いのです。
見分け方 — 利子の大きさをどう測るか
技術的負債は、放置していても表面上は問題なく見えるため、見つけるにはいくつかの手がかりが必要です。1つ目の手がかりは、「同じ質問が繰り返されているかどうか」です。新しい担当者から同じ疑問が何度も出てくる箇所は、たいてい理由が失われた応急処置です。2つ目の手がかりは、「毎回、確認や調整に余計な時間がかかっているかどうか」です。本来なら数分で終わるはずの作業に、毎回それ以上の時間がかかっているなら、そこに利子が発生しています。3つ目の手がかりは、「口頭での説明でしか引き継がれていないかどうか」です。文書化されていない手順は、担当者の記憶に依存しているため、引き継がれるたびに少しずつ形を変え、後から見ると誰も正確な姿を把握できなくなっています。これらの手がかりは、いずれも特別な調査を必要とせず、日々の業務の中で「あれ、また同じ確認をしているな」と気づくだけで見つけられます。
落とし穴 — 返済の判断を誤る
技術的負債への対処で最もよくある誤りは、すべての負債を一度に返そうとすることです。完璧な設計にこだわりすぎて、いつまでも本来の業務が前に進まない、という状態は、開発現場でもしばしば起こる失敗です。すべての負債を返すのではなく、利子が高い、つまり頻繁に触れる箇所から優先して返していくことが現実的です。たとえば、月に1度しか発生しない例外処理よりも、毎週発生している例外処理のほうが、返済の優先度は高くなります。影響範囲の広さも判断材料になります。自分1人だけが困っている負債より、複数の部署が関わるたびに毎回同じ確認をしている負債のほうが、組織全体で見た利子は大きくなります。
もう1つの落とし穴は、負債を作ったこと自体を責める文化です。締切に追われて応急処置を選んだ担当者を責めると、次からは誰も負債の存在を報告しなくなり、隠れたまま拡大していきます。むしろ「今回はここを意図的に簡略化した」と明示し、いつ・誰が返済するかの計画を残しておくほうが、組織全体としては健全です。借用書を残す感覚に近いと考えると分かりやすいかもしれません。借りたこと自体は責めず、返す約束だけを明確にしておくのです。負債そのものより、負債が見えなくなることのほうが、はるかに危険なのです。
3つ目の落とし穴は、返済を「大きなプロジェクト」として構えすぎることです。負債を返すには専用の期間と予算が必要だ、と考えてしまうと、いつまでも着手できません。実際には、返済の多くは、日々の業務の中で少しずつ進められます。たとえば、例外処理の手作業を1つ正式な設定に置き換える、口頭伝承の手順を1つだけ文書化する、といった単位で十分です。大きな返済計画を立てる前に、まずは利子が一番高い箇所を1つだけ選んで着手してみることが、現実的な一歩になります。
技術的負債と、この章の他の考え方との関係
技術的負債は、前のページで見たデッドコードやリファクタリングと深く関係しています。デッドコード削除は、そもそも要らないものを手放す作業でした。リファクタリングは、残すものを結果を変えずに整理し直す作業でした。技術的負債という考え方は、この2つのどちらを、どの順番で、どれくらい優先して行うかを決めるための判断材料を提供します。利子が高い、つまり頻繁に触れていて毎回余計な手間がかかっている箇所から優先して手を入れる。この優先順位のつけ方があるからこそ、限られた時間の中で、棚卸しの効果を最大化できます。次のページで扱うボーイスカウトルールは、この優先順位に沿って返済を進めるための、日々の実践方法にあたります。
持ち帰り
- 技術的負債とは、応急処置によって生まれる将来の追加作業のことで、放置すると利子として積み重なる
- 利子は複利的に効くため、早い段階で気づいて返済するほうが総額は小さく済む
- 負債を作った人を責めず、意図的な負債として明示し、返済計画を残す文化のほうが健全である
やってみる
今、自分の業務の中で「今回だけ」のつもりで始めた例外対応を1つ思い出し、それが今も続いているかを確認してみましょう。