技術負債問題をPMが扱うとき：エンジニアとビジネスの橋渡しの作法

「技術負債を返済したい」というエンジニアの言葉をビジネス側に伝えるとき、多くのPMは「技術的な理由で時間が必要なんですが…」という曖昧な説明になりがちだ。ビジネス側の反応は「具体的にどういうことですか？」「それをやることでビジネスにどんな良いことがあるんですか？」というものになる。

PMの仕事はこの「翻訳」をすることだ。

技術負債とは何か（ビジネス向けの説明）

技術負債とは「将来的に大きなコストになることを分かっていながら、短期的な速さを優先して積み上げてきたコード・設計の問題」だ。

わかりやすいアナロジーが「財務の負債」だ。短期借入でプロジェクトを進めると、返済（負債解消）コストが後でかかる。利子のように、放置するほど解消コストが増える。

ビジネス向けの翻訳例：

エンジニアの言葉：「コードのアーキテクチャが古くなっていて、新機能追加のたびにバグが出る状態です」

ビジネス向けの翻訳：「現在のシステム構造では、新機能1つの追加に通常の2〜3倍の時間がかかっています。このまま放置すると、来期の機能開発コストが今期比で30〜50%増加する見込みです。今、負債解消に1ヶ月を投資することで、その後1年間の開発コストを削減できます。」

ステップ1：現在の影響をコスト換算する

「技術負債があるせいで今どれくらい余計な時間がかかっているか」を数値化する。

エンジニアへのインタビューで確認する質問：

ステップ2：放置した場合の将来コストを試算する

「このまま何もしないと、1年後・2年後にどれだけコストが増えるか」を示す。

例：現在の負債による余剰工数月10時間 × 12ヶ月 × 人件費 = 年間〇〇万円のコスト

ステップ3：解消投資と回収期間を計算する

「負債解消に必要な投資」と「投資後のコスト削減額」を比較する。

例：負債解消コスト 2ヶ月（約40人日）、解消後の余剰工数削減月10時間 → 4ヶ月で投資回収

この計算をROI（投資対効果）として提示すれば、ビジネス側が意思決定しやすくなる。

戦略1：「全て vs 何もしない」ではなく段階的な提案をする

「2ヶ月すべてを技術負債解消に使わせてください」という要求は却下されやすい。段階的な提案の方が承認を得やすい。

例：「まず1スプリント（2週間）をパイロットとして最も影響の大きい負債1件を解消させてください。その結果を見て次を判断しましょう。」

戦略2：「新機能開発との組み合わせ」として提案する

技術負債の解消を単独の作業として提案するのではなく、新機能開発とセットにする。「新機能Aの開発にあたって、その周辺の負債を同時に解消することで、今後の同系統機能の開発が30%速くなります。」

戦略3：リスクとして経営層にエスカレーションする

技術負債が一定以上積み重なった場合、「このままでは本番障害リスクが高まる」「開発速度が競合に比べて低下する」というリスクとして経営層にエスカレーションする。

書籍紹介

著者: PMI — ウォーターフォール・アジャイル・ハイブリッド対応の業界標準PM教科書

技術負債は「放置するほど悪化する」ため、定期的な可視化とモニタリングが必要だ。

技術負債スコアカードの作成（月次）：

カテゴリ	負債レベル	影響	優先度
テストカバレッジ	高（30%以下）	バグ増加	High
コードの複雑度	中（平均循環複雑度8）	保守コスト高	Medium
依存パッケージの陳腐化	低（6ヶ月更新なし）	セキュリティリスク	High

このスコアカードを月次の技術レビューで共有することで、「見えない問題」を可視化し、ビジネス側との共通認識を作る。

技術負債問題においてPMに求められるのは「技術の深い理解」ではなく「技術的な問題をビジネス言語に翻訳する能力」だ。コスト・ROI・リスクという経営言語で技術負債を説明できるPMは、エンジニアにとっても経営層にとっても信頼できるブリッジになる。