valid,invalid

関心を持てる事柄について

技術的負債を抱えながら突っ走る -日々15分の改善活動-

開発しているシステムが大規模かつ老朽化しかけていることもあり、最近は負債の返却を念頭に置いて普段の開発をしている。

前提として、個人的には負債を返す頻度は多いほど良い*1と考えている。

この立場に立つときに生まれる問い、「では、日々の開発のスピードを落とさずに頻度を上げるためにどうすれば良いか?」の1つの答えとして「まずは15分向き合ってみる」というのを実践している*2。その実践に関するメモが本記事である。

TL;DR

  • たった15分でも日々負債に向き合ってみると良い
    • 全体像も見えない、どれだけ時間をとられるかわからないものならなお良い
    • ここでいう負債には技術的負債だけでなく使われていないが残存している機能など(便宜的にプロダクト負債と呼んでみる)も含む
  • 全体像が不明瞭で手も付けづらい何かが頭の片隅にあること自体が精神衛生上よくない
  • 一方、わずかづつでも改善に向かっているという実感を個人ないしチームで得られるというのは精神衛生上とても良い

「技術的負債」は少しでも解決に近づける

実感として15分で解消できるものは意外と多い

技術的負債への取り組みは完全解決に至らなくても少しでも解決に近づけるだけで価値がある

  • 複雑な問題を複数の小さい問題に分解する
  • なぜ難しいかを言語化する
  • 解決への道筋を立てる

手に入った情報に対して他の人が議論を重ねたり代案を出したりしてさらに前進することもしばしばある。

「プロダクト負債」はステークホルダーに先手を打つ

技術的負債は基本的には非開発者からは見えないのに対してプロダクト負債は"見える"もの。つまりステークホルダーへの確認・コミュニケーションが高確率で発生する。そのため15分で何もかも片付くようなケースはあまりない。許可より謝罪*3という美しい言葉で攻めていきたいが信頼貯金を失うのは長期的に見て得策ではない

なのでイシュートラッカーやチャットで非同期にディスカッションするなど、手を動かす前に15分で合意を得るための先回りをしておくと後で物事がスムーズに進む。

多少強引なやり方としては「この機能の使用率n%なので消します。反対意見があれば何日までに返事ください。反対なければ進めます」というのもある。これはチームの文化・意思決定プロセスによっては良くないかもしれない。

なぜ15分?

正直15分でも1ポモドーロ25分でも何分でも良い。大事なのは「1日の間に捻出できる」「息抜きとして使える」「何も成果が出なくても許せる」程度の時間ということ。

Fail fast, fail cheap, and fail smart損失の限定らへんの考え方から影響を受けている。

これが1時間2時間ともなると同日のメインタスクの計画・見積もりに影響が出てくる。影響が出てくると周囲に「今日ちょっとこの負債見ますね、なぜなら…」みたいに都度ことわっていく必要が出てくる。マイクロマネジメントされているわけではないので裁量の範囲で片付けてもよいが、チームメンバーが何に時間を使っているかわからないというのは嫌なものだ(そのメンバーのタスクが遅れるならなおさら)。

どれから手をつければいいか?

コスパが良い・NPVの高い投資をするのが理想的だが15分の取り組みであればあまり意識しなくても良いと思う。「負債返却プロジェクト」みたいな大掛かりなものであれば慎重に吟味する必要はある。

負債を辛いと感じたら普段からメモしておく。何度もメモしたくなるタイミングがあるならその問題に取り組むことはきっと費用対効果が高い。また、普段から課題発見を意識しておくと質の良い課題を発見するスキルを向上するトレーニングになると思う。


技術的負債との戦い方は幾度となくどこでも語られたことと思うが、結局のところ少なからず個人やチーム、ないしは会社の状況なりのやり方を模索することになる。自分も今まさに模索フェーズなのでその現状を経験知としてダンプすることに価値があると考える。

また、今のチームではこの15分とは別に "Quality Budget" という、メインタスクとは別の改善活動に充てる予算(=時間)を設けている。2週間に一度、チームメンバー全員が丸1日を改善に使って良いというこの試みはこの4月にスタートしたばかりなので、いずれ振り返りを書く。

*1:技術的負債とどうやって戦うか - Qiita

*2:クックパッド社の朝Lint活動などで知られるように、考え方としては目新しいものではない

*3:許可より謝罪 : けんすう日記