こちらは kubell Advent Calendar 2024 シリーズ3 12月20日分の記事です。
こんにちは。都志（@louvre2489）です。 プロダクト開発チームのEMをやっています。
先日、「開発スピード」と「プロダクト品質」というタイトルでブログを書きました。
こちらで開発は原則として相応の時間をかけて相応に良い設計を行い、その中で相応に速いリリースを行うことを目指すべきであると書きました。しかし、それだけの説明では「そんなことしたら徐々にプロダクト品質が低下していってしまうじゃないか！」という印象を受ける人もいるかと思います。
どのようにすれば相応の時間をかけて相応に良い設計を行いつつプロダクト品質の低下を抑止できるかについて、私なりの考え方を書きたいと思います。
「相応に良い設計」によって失われるもの
「相応」というからには何かに目を瞑っていることになります。目を瞑ったものがどのようなもので、それをどのようにリカバリーするかについてを明確にしないまま「相応に良い設計」を実行することに抵抗があるかもしれません。
目を瞑る対象の一例を挙げると、以下のようなものだと考えています。
- コード最適化
- 処理実行時間の最適化
- インフラコストの最適化
- エッジケースなバグの対応
- ドキュメント整備
いずれも「致命的ではないこと」が前提です。が、致命的ではないとはいえ無視し続けたたままではいずれ負債として積み上がり、取り返しのつかないことになりかねません。
そこで計画的に返済する必要があると考えています。
計画的な返済
大きくは以下のタイミングで返済を試みます。
- 長期休みの前後
- 大きな開発が一段落した時
返済をするつもりで目を瞑っているので、目を瞑った時はしっかりとチケット化しておくことが前提です。
休みの前後
具体的には、以下のタイミングです。
- ゴールデンウィーク／シルバーウィーク前後
- お盆前後
- 年末年始
これらのタイミングは開発のイテレーションが不規則になりがちです。また、長期の休みによって直前までやっていたことの記憶を失いがちです。どうせ記憶を失っているのであれば、１イテレーション分くらいリハビリも兼ねて...ということで「お掃除」を行うイテレーションを設けます。その中で、処理の最適化やドキュメント整備等々を実施します。
上記に記載したタイミングは数ヶ月おきに訪れてくれるのも良いところです。（年始〜ゴールデンウィークまではちょっと長い）
大きな開発が一段落した時
数ヶ月単位の大きな開発が終わったタイミングでも「お掃除」を行うイテレーションを設けます。
期間としては開発期間に応じた期間を（できるだけ）確保します。あとは、目を瞑ったことによって生まれたチケット数も考慮にいれます。
イテレーション１回分もあれば十分な場合もあれば、２回分くらい確保することもあります。
目を瞑ったものは全て掃除するのか？
そんなことは無いと考えています。
「お掃除」のタイミングで目を瞑ったチケットたちを見返した時に、大きく以下に分けられます。
- 必ずやるべき内容
- 気にはなるけど優先度は低い内容（好みの問題だったり、置いておいても実害は無さそうに見える）
- 今確認してみると気にならない内容（当時は気になったはずなんだけど...）
- 対象箇所がなくなっている内容
優先的に実施するのは 1. です。
1. の対象があまりにも少ない場合は 2. に手を出すかもしれません。
3. は意外とあることだと思います（個人的の感想です）。実装している当時は気になってたんだけど、俯瞰して見てみるとあんまり気にならないな...って。この時はサクッとチケットを削除してしまいます。
4. も稀にあります。将来的に修正したいと思っていた箇所が他の変更事由によって別のカタチに変わっていたりして、「もうこれ以上いじらなくて良いか...」となったりすることがあります。「稀に」と言いながらも、年に数回は出くわす気がしています（個人の体感によるものです）。この時もサクッとチケットを削除してしまいます。
後から「お掃除」をするなら、最初からキレイに作れば良いのでは？
開発している当時は「必ずやるべき内容」だと思っていたけど、時間を置いて見てみるとやらなくて良く感じたり、今見ると気にすらならなかったり...そのような内容に対して常に時間をかけて全力でキレイなコードを書き続けるのも効率の良い開発だとは思えません（賛否両論あるかもしれませんが...）。
少し間をおいて取り掛かることには、冷静かつ客観的にコードを眺めることができる、というメリットがあると考えています。「他人が書いたコードの意図が理解できて変更に苦労しなさそうなコード」を良いコードだとするのであれば、時間をおいて客観的に見た時に「理解できるし変更に苦労もしなさそうだ」と判断できれば、それ以上変更する必要は無いのだと思います。それ以上は趣味の世界です。
コードだけではなく、ドキュメントも同様です。
また、自分が作成したチケットを他のチームメンバーに確認してもらうのも良いと思います。５分ほど議論を交わして対応要否の判断をすることで、客観的な意見を取り込むことができます。
あとがき
結局、どのタイミングでプロダクト品質を担保しにかかるかという違いだけで「開発スピード」と「プロダクト品質」と同じようなことを書いているな、と思っています。 でも、「相応に良い設計」によって失われるものに対するリカバリー方法について明言できたので良しとします。
