Engineering開発しているシステムが大規模かつ老朽化しかけていることもあり、最近は負債の返却を念頭に置いて普段の開発をしている。前提として、個人的には負債を返す頻度は多いほど良い*1と考えている。この立場に立つときに生まれる問い、「では、日々の開発のスピードを落とさずに頻度を上げるためにどうすれば良いか?」の1つの答えとして「まずは15分向き合ってみる」というのを実践している*2。その実践に関するメモが本記事である。TL;DRたった15分でも日々負債に向き合ってみると良い全体像も見えない、どれだけ時間をとられるかわからないものならなお良いここでいう負債には技術的負債だけでなく使われていないが残存している機能など(便宜的にプロダクト負債と呼んでみる)も含む全体像が不明瞭で手も付けづらい何かが頭の片隅にあること自体が精神衛生上よくない一方、わずかづつでも改善に向かっているという実感を個人ないしチームで得られるというのは精神衛生上とても良い「技術的負債」は少しでも解決に近づける実感として15分で解消できるものは意外と多い。まとめる使わないコードを消す小規模リファクタリング技術的負債への取り組みは完全解決に至らなくても少しでも解決に近づけるだけで価値がある。複雑な問題を複数の小さい問題に分解するなぜ難しいかを言語化する解決への道筋を立てる手に入った情報に対して他の人が議論を重ねたり代案を出したりしてさらに前進することもしばしばある。「プロダクト負債」はステークホルダーに先手を打つ技術的負債は基本的には非開発者からは見えないのに対してプロダクト負債は"見える"もの。ステークホルダーへの確認・コミュニケーションが高確率で発生する。そのため15分で何もかも片付くようなケースはあまりない。許可より謝罪*3という美しい言葉で攻めていきたいが信頼貯金を失うのは長期的に見て得策ではない。イシュートラッカーやチャットで非同期にディスカッションするなど、手を動かす前に15分で合意を得るための先回りをしておくと後で物事がスムーズに進む。多少強引なやり方としては「この機能の使用率n%なので消します。反対意見があれば何日までに返事ください。反対なければ進めます」というのもある。これはチームの文化・意思決定プロセスによっては良くないかもしれない。15分?正直15分でも1ポモドーロ25分でも何分でも良い。大事なのは「1日の間に捻出できる」「息抜きとして使える」「何も成果が出なくても許せる」程度の時間ということ。smart、損失の限定らへんの考え方から影響を受けている。これが1時間2時間ともなると同日のメインタスクの計画・見積もりに影響が出てくる。影響が出てくると周囲に「今日ちょっとこの負債見ますね、なぜなら...」みたいに都度ことわっていく必要が出てくる。マイクロマネジメントされているわけではないので裁量の範囲で片付けてもよいが、チームメンバーが何に時間を使っているかわからないというのは嫌なものだ(そのメンバーのタスクが遅れるならなおさら)。どれから手をつければいいか?コスパが良い・NPVの高い投資をするのが理想的だが15分の取り組みであればあまり意識しなくても良いと思う。「負債返却プロジェクト」みたいな大掛かりなものであれば慎重に吟味する必要はある。負債を辛いと感じたら普段からメモしておく。何度もメモしたくなるタイミングがあるならその問題に取り組むことはきっと費用対効果が高い。普段から課題発見を意識しておくと質の良い課題を発見するスキルを向上するトレーニングになると思う。技術的負債との戦い方は幾度となくどこでも語られたことと思うが、結局のところ少なからず個人やチーム、ないしは会社の状況なりのやり方を模索することになる。自分も今まさに模索フェーズなのでその現状を経験知としてダンプすることに価値があると考える。いう、メインタスクとは別の改善活動に充てる予算(=時間)を設けている。2週間に一度、チームメンバー全員が丸1日を改善に使って良いというこの試みはこの4月にスタートしたばかりなので、いずれ振り返りを書く。2019に初参加してきた。5はてなブログをはじめよう!ohbaryeさんは、はてなブログを使っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。