技術的負債の見える化|返済計画をビジネス側に説明する方法

技術的負債の見える化|返済計画をビジネス側に説明する方法

「そろそろリファクタリングの時間がほしい」と伝えても、なかなか予算が付かない。

片づけたい側には切実でも、受け取る側には「作り直したいだけ」に聞こえてしまうのが、この相談の難しさです。

技術的負債という言葉自体はビジネス側にも通じるのに、返済計画の形で提示できないと会話が止まる

テックリードが引き取ることになるのは、たいていこの翻訳の部分なのです。

負債の比喩は「利息」を語るために使う

まず、この比喩が何を説明するための道具なのかを押さえておきたいところ。

Martin Fowler は技術的負債を、内部品質の劣化(cruft)が積み上がって変更しにくくなった状態を、金融の借金になぞらえる比喩として整理しています。

同氏の説明で肝になるのが利息の置き方で、構造がきれいなら 4 日で終わる機能が、散らかった状態では 6 日かかる。その差の 2 日が利息、という言い換え。

負債そのものではなく、毎回余計に払っている 2 日を数えるのが見える化になります。

「汚い」ではなく「毎回 5 割増しで払っている」と言えれば、相手の土俵に乗るわけですね。

四象限に分けると話し方が変わる

負債はひとかたまりではなく、成り立ちで扱いが変わってきます。

Fowler は 2009 年の記事で、負債を「意図的か、うっかりか」と「慎重か、無謀か」の二軸で四象限に分ける整理を示しました。

リリースに間に合わせるために承知のうえで選んだ手抜きは、慎重かつ意図的な負債。

設計の作法を知らないまま書かれた散らかりは、無謀でうっかりな負債にあたる。

同氏は、負債かどうかを議論するより慎重か無謀かを見分けるほうが有用だと述べているのです。

この区別が効くのは、説明の相手が変わるから。

意図的な負債は「あのとき前借りした分」として交渉の材料になり、うっかりの負債は学習やレビューの設計問題として扱うことになります。

どこまでをテックリードが引き取るのかは、三つの軸に分けた別記事で整理しました。

テックリードに求められる3つの軸|技術・人・プロセス

見える化は「量」ではなく「痛み」を測る

負債の総量を数字で出したくなりますが、そこは踏みとどまりたいところ。

Fowler は、生産性そのものは客観的に測れないと繰り返し書いており、負債の総額を正確に見積もる方向は行き止まりになります。

代わりに測れるのは、負債が生んでいる痛みのほう。

具体的には同じファイルに何度も手が入っている頻度、変更から本番までのリードタイム、同じ原因で再発した障害の件数といった観測値。

「ここを直せば、この数字がこう動くはず」まで言えて初めて計画になるのです。

痛みの大きい順に並べれば、優先順位の議論がそのまま返済順になるという副産物も付いてきますよね。

返済は機能の隣に置くと通りやすい

まとまった時間をもらう形にこだわると、承認のハードルが上がります。

Fowler は元本返済の損得を、5 日かけて構造を直す例で説明している。

一つの機能のためだけなら 6 日が 9 日になって損だが、似た機能があと 2 つ控えているなら、先に直したほうが速く終わるという計算。

つまり返済の正当性は、これから来る仕事の量に依存することになります。

だからロードマップに次の機能群が並んだタイミングこそ、返済を差し込む好機。

「独立した改善タスク」ではなく「次の 3 機能を速く出すための前工程」として並べるのが、通しやすい形なのです。

ビジネス側には「速度のための投資」として渡す

最後に、言葉の置き換えを一つ。

品質か速度かという二択で話すと、たいてい速度が勝って改善の話は流れます

Fowler の「Is High Quality Software Worth the Cost?」は、内部品質の向上は開発を遅らせる cruft を取り除くので、むしろ機能追加のコストを下げると論じている。

内部品質は削れるコストではなく、速度を買うための投資という言い方に寄せる。

この一言があるだけで、返済の相談が「お願い」から「提案」に変わるはずです。

こうした「チームぶんの品質を持つ」感覚は、シニアエンジニアとの境界線を扱った記事にも通じるところ。

シニアエンジニアとテックリードの境界線|何が変わるのか

四象限の原典はMartin Fowler「Technical Debt Quadrant」。

Technical Debt Quadrant

利息と元本の説明はMartin Fowler「Technical Debt」にまとまっています。

Technical Debt

最後に

技術的負債の見える化は、負債の総額を出す作業ではありませんでした。

毎回余計に払っている利息を観測値で示し、次の機能とセットで返済を提案するという組み立て。

私自身はまだテックリードを目指して学んでいる立場ですが、この順番を覚えておくだけでも相談の勝率は変わりそうだと感じます。

まずは、手が入り続けている場所を数えるところから始めてみたいところ。

「動くコードを触るな」と言われたときの返し方は、リファクタリングの合意形成を扱った記事にまとめました。

リファクタリングの合意形成|「動くコードを触るな」への答え方

以上です。