一時間は大体の目安でちゃんと測ってない.
- PR の作成に時間がかかるときは, 何らか良くないことが起きている可能性が高い
- 試行錯誤を繰り返している
- 変更の規模が過大になっている
- 良くないことが起きているなら, そのまま続けて余計なコストをかけるよりも捨てた方が良い
- 試行錯誤を繰り返していたなら, そこまでは勉強か練習だと思って捨てる
- 変更の規模が過大になっていたなら, 分割して作り直すために捨てる
- 捨てることを躊躇わない
- 時間をかけるほど引き返しづらくなるので, 一時間くらいで打ち切る
- 一時間の手戻りなら一時間で取り返せる. なんなら知識が増えている分もっと短くて済む
- 思ったより進んでいなくても, そのまま思っていたところまで進めようとはせずに諦めて捨てる. とにかく良くないことが起きている可能性が高いので立ち止まるべきで, 思ったところまで進められる (良くない状態に陥らなくなる) 状態は立ち止まって反省した先にある
- いいから捨てろ. 大抵はコードそのものよりもコードを書くことで得た知識の方が圧倒的に価値があるので, コードを捨てるのは大したことじゃない
- 全ての作業を一時間で終わらせるという話ではない
- N 時間を一回でやっているところを一時間を一回にするのではなく, 一時間を N 回やるという話
- 品質で手を抜くという話でもない
- 一時間で品質が低い状態までしか辿り着けなかったとしたら, そこで完成とするのではなく, 一旦捨てて品質が高い状態に辿り着けるような進め方を考えるという話
- 低品質で作る → 高品質化する のように作業を分けるのも, 結局後者が実行されないことがあるので理想的ではない. 高品質で作る → 高品質で作る と作業を分けられた方が良くて, そうできるようになるためには実際にこのように分けようとしてみるしかない
