技術負債が伝わりにくい理由
「リファクタリングをしたい」「コードの品質が問題だ」と伝えても、PMやビジネス側が動かないことがある。
技術負債という概念はエンジニアには自明でも、ビジネス側には「技術者がきれいにしたいだけ」に見えることがある。
伝わらない原因は、技術的な正しさをそのまま話しているからだ。ビジネス側が判断できる言葉に変換する必要がある。
技術用語を事業影響に変換する
技術負債を説明するときに使うフレームは3つだ。
影響1：保守コスト
「コードが複雑でバグの原因特定に時間がかかる」を「1件の障害対応に通常の3倍の時間がかかっています。この先も同様の工数が続く見込みです」に変える。
エンジニアの稼働時間は費用だ。時間が増えればコストが増える。
影響2：障害リスク
「テストが書かれていないので変更の影響が確認できない」を「現状、Aを変更するたびにBとCで想定外の動作が起きるリスクがあります。今年に入って発生した6件の障害のうち、4件が技術負債に起因していると考えています」に変える。
実際の障害件数や影響があれば数字を入れる。件数が把握できない場合は「直近3ヶ月で複数回」など期間で表現してもよい。
影響3：開発速度
「構造が古くて機能追加しにくい」を「現在の構造では新機能Xの追加に3ヶ月かかる見込みです。構造を整備すれば同じ機能が1ヶ月で実装できます」に変える。
開発速度は事業スピードに直結する。PMが理解しやすい言葉だ。
改善提案の出し方
「リファクタリングしたい」ではなく、「改善すると何がどう変わるか」を一緒に提示する。
課題：Aモジュールの技術負債により、月次での障害発生が増加しています。
現状コスト：1件あたりの対応工数が通常の2〜3倍になっています。
改善案：Aのリファクタリング（工数：2週間）
改善後：同種の障害対応時間が半減する見込み。新機能Bの追加工数も1週間短縮できます。
依頼：来期のロードマップに組み込む判断をお願いしたいです。数字が使えるなら使う。推測でも「〜の見込み」として出す方が説得力がある。
技術用語をビジネス言葉に変換する表
| 技術的な言い方 | ビジネス側への言い換え |
|---|---|
| 「リファクタリングが必要です」 | 「この構造のままだと、機能追加のたびに確認範囲が広がり、1回あたりの改修工数が増えます」 |
| 「テストが書かれていません」 | 「変更のたびに手動確認が必要なため、今後の修正コストが増え続けます」 |
| 「コードの品質が低いです」 | 「バグ調査に時間がかかる状態で、1件の障害対応に通常の2〜3倍の時間がかかっています」 |
| 「依存ライブラリが古いです」 | 「来期のセキュリティ要件に対応するために、早めに更新しておかないと追加工数が発生します」 |
| 「設計が複雑すぎます」 | 「今の構造では新機能Xの追加に3週間かかります。整備すれば1週間で実装できます」 |
目的は承認ではなく、判断材料を渡すこと
技術負債の説明は、PMやビジネス側に「やるかどうか」を決めてもらうための話だ。
技術的な正しさを主張するのではなく、判断材料を渡すことに徹すると、会話が噛み合いやすくなる。