技術的負債は誰の責任か

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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