何番煎じか分かりませんがバズワードについて怪文書を書きます。
自分の思考の整理でしかありません
（技術的）負債の誤用
技術的負債という言葉を多くの日本人はまちがって使っているらしい（要出典）。
本来的な意味はこちらであった
https://t-wada.hatenablog.jp/entry/ward-explains-debt-metaphor
自分なりに解釈すると。
簡単に言えば、元々の意味は、場当たり的なコードのことではなく不完全なものをインクリメンタルにブラッシュアップして開発すること。
その不完全さを一時的に許容することを負債と呼んでいた。返済も必要だとのこと。
なるほど、負債ってそういうものか。技術的負債に関して、元々の会計上の負債という考え方に沿って元銀行員の方が考えたのが面白かった。
https://zenn.dev/ikeo/articles/33e3e6a0905577dcc0e3
技術的不良債権、技術的破産、技術的踏み倒し
こういう、微妙に原義と変わってしまった言葉って結構自分としては引っかかる。
定義が曖昧になりつつ、負債にばかり目が行き、返済がなかなかされない場面に出くわすし、やってしまいがち。
それでは、それを正しく表現するとなると、
技術的不良債権とか破産とかになりそう。
借金踏み倒し、みたいなのが良いんだろうか(別に名前をつけたくてこの記事を書いているわけではないが…)。
「技術的負債を返済したいですよね〜」という会話だけで実際に返済していないのだとすれば、違和感がある。
返済計画無しのものは、もはや負債ではなく踏み倒し、破産、不良債権などに近い気がしている。
何が負債かチームで考える
そもそも、なんでもかんでも気に入らないものを負債と言ってしまっていないか。
実はそれはただの個人的な趣味嗜好かもしれない。
負債が生産性に影響を及ぼすのは、開発チームという単位かもしれない。
したがって、負債となり得るものかどうかはチームで認識を揃えたほうが良さそう。
その問題があることで、チームの開発スピードにどれほど影響を及ぼすか。
その視点で考えるのが重要そう。
返済計画を立てる
細かい定義は何にせよ、そういった問題により、生産性に影響が出ているとすれば返済計画を考えたほうが良い。
お金のメタファーなので、その視点で考えると、
- 月々の返済など定期的な返済
- ボーナス返済
- 一括返済
などが思いつく。
ボーナス返済、一括返済は現実的ではなさそう。
開発にボーナスタイムはないし、一括返済もおそらくビックバンリリースとなり現代的なプロダクトのリリースサイクルで考えれば対極を行く。
自然と、月単位など、定期的な返済に選択肢は絞られる。
定期返済のための余剰
定期返済をするには、余剰(余裕)が必要である。
収入に対して消費が多すぎては、返済に資金を回せない。
となると、
- 収入を増やす
- 節約して消費を減らし返済に回す
のどちらかになる。
開発における収入、消費
収入=チームのベロシティ、ストーリーポイントなど開発工数=消費と置いてみる。
ベロシティが上がることを期待するのはあまり現実的ではない。
急に開発スピードが上がることはないし、むしろ、負債が増えればベロシティは下がっていく。
となると、収入を増やすのは諦め、節約して返済に回すことになりそうである。
ここで重要そうなのは、返済だけに収入を使わないこと。
そうしてしまうと普段の生活がままならない。
普段の生活のため開発(=消費)を続ける必要があることに似ている。
開発における定期返済の難しさ
定期返済の難しさは、負債と返済を数値として表しにくいところである気がしている。
極端な話、賃借対照表のように数値に出てくれれば良いのかもしれない。しかし開発の負債も返済も動きは早いので、実現は厳しそうな気がするし、そこを厳密に管理するのが目的ではない。
うまく数値で表せたとして、返済によってどの程度の効果があるかというのも分かりにくい。
また、インクリメンタルな開発においてその時点のベストだったとしても、将来的に負債となることがある。常に負債は増え続ける。
負債を積み、その負債の返済を繰り返し続けるしかない気がする。
なので、ベロシティの維持を指標として相対的に考えるなどが妥当なとこなんだろうか。
なんにせよ、無理のない範囲での数値管理や効果測定は何かはあった方が良いような気がする。
タイムボックスとリファクタ
ここから、より具体的に返済の方法を考えたい。
自分が思いつくのはリファクタとタイムボックス。
タイムボックスによる返済
ここでのタイムボックスのイメージは、ベロシティを維持しつつ返済作業に時間を充てること。プロダクト価値になる開発はその時間は行わないというもの。
自分が思うに、ベロシティを維持してなるべく下げないというところがポイント。
ここでベロシティを下げてしまうとブロダクト開発が鈍化してしまう。
タイムボックスでの返済の難しさは当然ではあるが定常的な時間の確保。
一時的なベロシティを下げてでもタイムボックスを多く確保して返済に充てるという考えも手としてはありかもしれない。が、価値の生産が減っているので一時的な赤字、将来への投資として合意形成が必要かもしれない。
http://agile.blog.jp/agile_scrum/14887175.html
リファクタによる返済
上記で考えたタイムボックスと比較して圧倒的にローリスク・ローリターンなのは日々のリファクタ。
日々のリファクタをやるためには、安心して構造を変えるために、月並みだが自動テストが必要そう。
また、開発の際に必ずついでにリファクタする習慣づけが大事。
返済するためには強度を持ってやらないといけないはずなのに、ついでにやらないといけないのが難しいところ。我々は、やったー！出来た！ヨシッとなりがち。
また、リファクタという言葉自体、かなり抽象的で、認識がズレやすい点が難しい。
行動自体のイメージはつくが、具体的な変更に関しては認識が揃いにくいので注意が必要そう。
https://プログラマが知るべき97のこと.com/エッセイ/リファクタリングの際に注意すべきこと/
ボーイスカウトルール
リファクタを全対象にする必要はない。今関わる部分の開発について生産性を維持するためにクリーンにしておくという感じで考えるのが良さそうである。来たときよりも美しく。
今必要もない部分までリファクタしようとするのは、下手をすると開発者のエゴになってしまう。
ホットスポットだけを最適化するのは理に適っていると思う。
https://プログラマが知るべき97のこと.com/エッセイ/ボーイスカウト-ルール/
触る機会がない箇所
変更機会が少なく直近の生産性の低下につながらないのであれば、その返済を先送りして良いのかもしれない。
問題は中長期的に見た時、その負債が顔を出してきて将来の選択肢を狭めてしまうということである。
触る機会がないが、中長期的に効いてきそうなリファクタは、もしかするとタイムボックスでやった方が良いかもしれない。
まとめ
- 技術的負債とは返済前提の未完成なもの
- 負債は生産性を下げるもの
- 負債の定義をチームで揃えよう
- 定期的な返済をして生産性を保つ
- 継続的な返済のために負債と返済をうまく測りたい
- 返済は日々のリファクタとタイムボックス
- 何の返済のためのリファクタリングかを明確にする
- タイムボックスは中長期的な投資に効果がありそう
みなさんのいいアイデアや考え方が知りたい
0 件のコメント:
コメントを投稿