スクラム」を読みたい人が集まる勉強会8回目。スクラムのコアコンセプトの部でわざわざ技術的負債について1章割くというのがふーんという印象でした。ベロシティに大きな影響を与えるので避けて通れないというところでしょうか。技術的負債を抱えるということは、今後の作業のための時間を担保にした融資を受けるということだ。きていて、後々返済する必要が出てくる代わりに先に経済的効果を得ているものを指しています。単純にまずい設計や実装のことまで技術的負債と世間で呼ばれていることがありますが、個人的には違和感を感じています。本書ではナイーブな技術的負債と呼んでいますね。技術的負債ですが大切なのは、どんなプロダクトであっても技術的負債からは逃れられないということだ。私はここで、技術的負債をなくすよう努力しましょうなどと言うつもりはない。仮にそんなことができたとしても、負債をゼロにするためには大変なコストがかかるだろう。いうことで必ずしも罪悪感を感じる必要のあるものではないことがわかります。把握してコントロールしていくことが重要です。技術的負債の経済的意味についての適切な認識については、正直なところなかなか正確に見積もれることがない気がします。技術的負債を生むという選択をした時にそこまで見積もる余裕がない、あるいはあっても先のことなので詳細化しきれない、そういうケースが多いのではないかと。技術的負債バックログを作るサイズが大きいものは方法2の方が時間をとって返済しやすく、サイズが小さいものは方法3の方が「フィーチャーよりも優先度が低くていつまでも返済されないということがない」ので返済しやすいようです。作業中に偶発的な技術的負債が見つかれば対応できるところまで対応する。スプリントごとに既知の技術的負債のいくつかを返済対象として対応する。価値をもたらすフィーチャーの開発と関連するものを一緒に進めることで金利の高いものから勧められる。スプリント」だとか「リファクタリングスプリント」などといった言葉がチーム内で出てきたら、危険信号だ。いうことで、技術的返済のみに注力するのは価値を提供し続けるというのに反するで望ましくないとありました。実際のところ利息がほとんど発生しない技術的負債もあるので、きちんと見極める必要がありますね。事業の部長をしています。日記(兼パーソナルナレッジベース)です。※内容は個人的見解であり所属組織とは関係ありません。