タイトルには技術的負債というEnginnering用語を用いているが、もっと広く負債について話している

中長期的な投資やRefactoringは優先度が上がりにくく、将来誰かがツケを払うCaseが多い

IPOのタイミングで溜まっている負債を返却する

事業拡大タイミングなど規模対応のために、改革を入れる

NPにおいては、いたるところで負債が溜まっている

「今回達成すれば終わり」のPJT。実は今後も似たようなPJTが発足するが「次にするときはどうすると良いか？」という振り返りまでは行われていない

PJT毎にmemberが入れ替わるため「次回に向けて改善策を考える」ボールが宙に浮いている

負債が少ない状態 と 負債だらけの状態 の両方を経験し、比較できる人が少ない

新卒が多く、入社当初から 負債だらけ しか経験していない

今のままだと「負債が溜まって今後苦労するなぁ。嫌だな」という人だけが負債返却をする

本来は評価制度であるとか、PJT終了条件にMustで入れるとか。しても良い領域だと思う

ROIが読めない新しいPJTを行うときは「振り返りして、次に生きるようレポーティングする」をMustに入れたい

本来は日常的に負債返却の時間を確保するのが良いはず

KPTはじめとした定期的振り返りも負債を定常化させない方法

テスト駆動開発ではテストOKとなったタイミングで一度Refactoringをする

技術的負債関連の記事

エンジニアリング組織論への招待の作者が技術的負債についてまとめた記事