テクニカルデットの管理

18人のプロダクトリーダーからの知見を活用して、ユーザーがテクニカルデットを戦略的に管理するのを支援します。

サポート方法

ユーザーがテクニカルデット対応についてサポートを求める際:

1. 状況を理解する - デットの性質（レガシーシステム、コード品質、アーキテクチャ上の制限）、それが現れている形態（開発速度の低下、インシデント、新機能のリリース難しさ）、ビジネスコンテクストについて質問する
2. 緊急度を診断する - これが重大なビジネスニーズをブロックしているのか、それとも徐々に進む問題なのかを判断する
3. 適切なアプローチを選択する - インクリメンタルな改善、対象を絞ったリファクタリング、または（稀に）完全な書き直しの間で決定するのをサポートする
4. ビジネスケースを構築する - デットのコストを定量化し、ステークホルダーに価値を伝えるのを支援する

コア原則

書き直しはほぼ機能しない

Camille Fournier: 「エンジニアは悪名高く、本当に、本当に、膨大に旧システムから新システムへのマイグレーション時間を過小評価します。ちなみに、新システムに取り組みながら、旧システムをサポートし続ける必要があります。」完全な書き直しはわなです。インクリメンタルな進化を優先する - ゼロから始めるのではなく、特定のコンポーネントをアップリフトする。

テクニカルデットはプロダクトデット

Ebi Atawodi: 「インフラはプロダクトです。以上です。ぐらぐらした基盤の上に高層ビルは建てられません。だからあなたの問題でもある - エンジニアだけが扉を叩くものではありません。」テクニカルデットはPMによって「プロダクトデット」として所有されるべきで、エンジニアだけの懸念として扱うべきではありません。トップ10の問題リストに含める。

スタートアップは戦略的にデットを抱えるべき

Gaurav Misra: 「スタートアップとしてのあなたの仕事は、テクニカルデットを抱えることです。なぜなら、それが大企業より速く運用する方法だからです。」デットはレバレッジです - 問題を今日ではなく将来の雇用で解決できるかを評価する。しかし「利息」を監視する - メンテナンスが80～90%の時間を占める場合、滑走路を使い尽くしている。

書いたコードより削除するコードを増やす

Farhan Thawar: 「私たちはDelete Code Clubを持っています。削除できる100万行以上のコードがほぼいつも見つかります。すべてが簡単になる - コードベースの読み込みが速くなり、理解しやすくなります。」削除されたコードのみに焦点を当てた専用の時間またはチームを作成する。削除は開発速度と明確性を向上させる。

テクニカルデットはユーザーに見える

Matt Mullenweg: 「テクニカルデットはインターフェースで、またはプロダクトがどのように自身と統合するかで見ることができます。」断片化されたUIと機能間の貧弱な統合は、蓄積されたデットのユーザー向けの症状です。デットが蓄積されている場所を特定するために矛盾を探す。

デット削減の価値を定量化する

Casey Winters: 「最も影響力のあるプロジェクトは測定が最も難しいため、慢性的に資金が不足します。価値を示すカスタムメトリクスを構築し、投資の価値を証明する小さなテストを実行してください。」カスタムメトリクスを作成し、ビジネス価値を実証するための実験を実行する。エンジニアリングとデザインと連携して、統一されたメッセージを提示する。

バグはすぐに修正する、バックログに入れない

Geoff Charles: 「私たちはバグバックログを持っていません。表面化したほぼすべてのバグをすぐに修正します。」バグをオンコール中のエンジニアに直接割り当てて、即座の痛みを認識させる。バグバックログは墓場になる。

デットは革新をふさぐ

Eeke de Milliano: 「チームは緊急の仕事に押しつぶされることがある - 多くのテクニカルデット、バグ、不安定性。1日中インシデント処理に頭を悩ませていたら、より大きく創造的なことに焦点を当てる方法はありません。」チームが「ニーズの階層」の罠に陥っている場合を診断する。デット削減を優先して、創造的な仕事のための頭の余裕を作る。

テクニカルデットはシャンパンの悩み

Julia Schottenstein: 「テクニカルデットがあれば本当に幸運です。なぜなら、それはプロダクトが使われているということだからです。ローンチに必要なかったのは分散スケジューラです - ユーザーがいませんでした。」最もシンプルで、最も直感的なバージョンをまず構築する。デットをユーザーの手にプロダクトを届けるための代償として受け入れる。

ダークトンネルに備える

Melanie Perkins: 「6ヶ月かかると思っていたのに、2年間プロダクトをリリースしなかった。」大規模な書き直しは、出荷をすべて停止させる「ダークトンネル」です。もしそうしなければならない場合、長い作業期間中もチームのモメンタムを維持するために、仕事をゲーム化する。

1～2年先を見据えて設計する

Austin Hay: 「1～2年先にどのようなものが必要になるかを考える。ツールをセットアップする際には、『1年後に何も変わらなかったら何が起きるか？』と質問してください。」SSOや適切なデータスキーマのような基礎的な要素を早期に実装して、大惨事的なマイグレーションを避ける。

ユーザーを助ける質問

• 「このデットは重大なビジネスニーズをブロックしていますか、それとも徐々に進む問題ですか？」
• 「エンジニアリング時間のどのくらいがメンテナンスと新機能に割かれていますか？」
• 「書き直しに実際にどのくらいの時間がかかるか見積もってみましたか？誰がその見積もりをしましたか？」
• 「後6ヶ月何もしなかったら何が起きるでしょう？」
• 「書き直すのではなく、段階的にこれを改善する方法はありますか？」
• 「このデットのコストをステークホルダーに定量化したらどのようになりますか？」

よくある間違いのフラグ

• 完全な書き直しを計画する - 書き直しはほぼ計画通りに機能しません。見積もりより2～3倍長くかかり、両方のシステムを同時にサポートする必要があります
• テクニカルデットをエンジニアの問題として扱う - これはプロダクトデットです。PMはエンジニアと一緒にそれを所有すべきです
• バグバックログを蓄積させる - バグバックログは墓場になります。すぐに修正するか、修正しないことを決定する
• プロダクト・マーケット・フィット前にエンジニアリングをやりすぎる - デットはシャンパンの悩みです。最初に直感的なソリューションを構築し、デットを学習コストとして受け入れる
• コストを定量化しない - テクニカルデット投資は価値が測定されないため、資金不足になります。メトリクスを構築し、ROIを証明するために実験を実行する

詳細ダイブ

18人のゲストから20の知見すべてについては、references/guest-insights.md を参照してください

関連スキル

• Technical Roadmaps
• Platform & Infrastructure
• Engineering Culture
• Evaluating Trade-offs