の中で紹介されていた、「負債ベースライン（debt baseline）」 と 「負債上限（debt ceiling）」による許容範囲を設けることについてのサマリ。(引用部分はDeepL翻訳を使用しています)
記事には以下のような象限の図がある。良い負債とは、このうち「意図的」かつ「慎重」な負債 について指す。
Good and Bad Technical Debt (and how TDD helps)
良い技術的負債と悪い技術的負債（そしてTDDがどのように役立つか）
ポイント:
- 技術的負債（Technical Debt）は通常、「悪いもの」。
- しかし、常にそうだろうか？良い負債と悪い負債を区別するにはどうすればいいのか？
技術的負債曲線を描く
ポイント:
- 技術的負債とは、長期的に開発速度を低下させるようなコードに関するもの。読みにくいコード、テスト自動化の欠如、重複、依存関係のもつれ、など。悲しいかな、ほとんどのシステムで技術的負債は増え続けている。
負債曲線をどのようにしたいか？
ポイント:
- あなたは「パーフェクト」を追究できるとしたら、「技術的負債ゼロ！」としたいだろうか？
- もし、製品ライフサイクル全体を通して技術的負債をゼロにすることができたら、それは最高？
- 実はそうではない。技術的負債を常にゼロにすれば、おそらくスピードも落ちる。「技術的負債とは、長期的に速度を低下させるコードに関するあらゆるもの」。しかし、短期的な話となると話は別である。
どんな場合に「良い」のか？ 料理をしているときの例
材料や調味料、調理器具がそこらじゅうに転がっています。音楽を録音していると、楽器やケーブルやメモが転がっています。絵を描くときも、ペンや絵の具、道具が転がっています。
野菜を切るたびに、包丁を洗って取り替える。野菜を切れば、包丁を洗って交換し、絵を描けば、筆を洗って交換する。音楽のテイクが終わるたびに、楽器のプラグを抜いてケースに入れ直す。これでは、仕事のスピードが落ち、創造性やフロー、生産性が完全に失われてしまいます。
ポイント:
- 実は「散らかっている」ことで、フロー状態を維持することができる。
一方、問題になるのは、古いゴチャゴチャである
新しいことを始めようとパソコンを開いたとき、昨日までやっていた仕事のウィンドウや文書が何十枚も開いていたら、仕事のスピードが落ちます。夕食を作ろうと思って台所に行ったら、古い食器や昨日の残り物でキッチンがこんがらがっていた、というのと同じです。
新しい機能をコーディングする場合、様々なやり方がある。どこかに非常にシンプルでエレガントな解決策があるはずですが、それを前もって見つけ出すのは本当に難しいことです。それよりも、実験し、遊び、問題に対するさまざまなアプローチを試し、それがどのように機能するかを確認する方が簡単です。
ポイント:
- 過程で蓄積された技術的負債は「良い負債」であり、それを整理することで創造性が制限される。また、技術的な品質よりも、初期のユーザーからのフィードバックが優先されることがある。手早くプロトタイプを作り、その機能が気に入られれば、次の機能に移る前に、コードを修正すればよい。
- 問題は、キッチンと同じように、私たちはしばしば、次の作業に移る前に片付けることを忘れてしまうこと。そして、これが技術的負債を悪化させる原因である。「一時的な」実験的なコード、重複したコード、テストカバレッジの欠如など、そういったものはすべて、後で次の機能を構築するときに、あなたの足を本当に遅くすることになる。
- ではこの「短期間」とはどのくらいまでなのか？
- 経験では、ソフトウェアでは、「良い混乱」は数日、間違いなく1週間以内までしか通用しない。それをこえると陳腐化し、汚れた食器が台所に詰まり、食べ残しが臭くなり、インスピレーションも生産性も下降線をたどる。
理想的な技術的負債曲線
ポイント:
- 理想的な曲線は次のようなもの
- 各サイクルがわずか1日か2日のノコギリ歯のパターンであるべきです。
- 新しい機能を実装する際には一時的な混乱を許容し、次の機能の前に必ずそれを片付ける。
引用
より現実的で理想的な技術的負債曲線
ポイント:
- 「債務上限」を設けましょう。
- あらゆるメトリクスの中で、筆者は、主観的な品質測定基準を好むチームが多いことに気づいた。
- 開発者の多くが深く気にかけられる。つまり自分のコードの品質を、可視化できるため。
- 客観的な測定基準（テストカバレッジ、重複など）を議論のインプットとして使用することも可能です。しかし、結局のところ、開発者の主観的な意見こそが重要である。
- 重要なのは、品質に対する姿勢を貫くこと。品質をどのように測定するか、あるいは負債の基準値と上限値をどこに置くかにかかわらず、定期的に議論し、自分たちがどうありたいかを明確に決定すること。
- 例: 割れ窓理論 - Wikipedia
まとめ: 良い品質＝人々の幸せ
結局のところ、技術的負債は技術に関するものではないのです。人間に関することなのです。
きれいなコードベースは、作業が早いだけでなく、より楽しくなります。そして、やる気のある開発者は、より良い製品をより早く作る傾向があり、その結果、顧客と開発者の両方がより幸せになるのです。ポジティブなサイクルを！
まとめ:
この「良い技術的負債と悪い技術的負債」はつまり、素早く仮説検証するために生じた、数日から一週間以内の技術的負債を「良い技術的負債（good technical debt）」と呼んでいる。あらゆるメトリクスの活用と、大事なのは品質に関する開発者の主観的な意見との話。
以上、参考になりましたらさいわいです。