例えばソフトウェアを開発していて、大きな1つの機能を開発しているとする。3つマイルストーンがあって、それらを全て達成したら無事リリース完了だとする。
こういったとき、よくやってしまいがちなのが、3つのマイルストーンの全ての解像度を上げてうまくいきそうか正確に予見しようとすることで、個人的にはうまくいった試しが無い。
自分がうまくやれているときのやり方は、まず全体のマイルストーンはおおまかに決めた状態で、今やらなければならないマイルストーンの解像度を選択的に上げて、いったんそのマイルストーンの中でスコープを切って考える、という方法。 そのマイルストーンが終わるまでは次のマイルストーンに対する考え方はぼんやりとしているが、それは問題無いというスタンスにしている。次のマイルストーンは、その時にまた解像度を上げれば良い、という心構えでいる。 なるだけlazyに判断を先送りして、柔軟に考える余地を残しておく。マイルストーンの分解がある程度正しければ、それでうまくいく。先のことまで先に決めてしまうと、それに適合するように行動しなければならなくなり、かえって非効率になることがある。
短く表現すると、うまく分解して、やっている所の解像度だけ上げよ、となる。
しかし当然予見される不安として、他の場所が曖昧なので、突き進んだ先で破滅的な事が起こるのではないか、というものがある。これは自分は割り切っていて、着手できていない概念の解像度は上げるだけ無駄というスタンス。なぜかというと、タスクをこなしているうちに状況は変化していくためで、どのくらい状況を正確に判断できるかで並べ替えると、今やっているタスクが最も正確で、最後にやるタスクが最も不正確にしか予測できないから。ゆえに、あとでやるタスクを今予見してあれこれ考えるより、やるべきタイミングで状況判断したほうが確度が高いし、苦労も少ないはず、という仮説にもとづいてやりくりしている。
ただし注意点として、期限というファクターは最初から正確に固定されている場合が多い。最初から正確な要素は、最初から計画に組込むべきで、マイルストーンにおおまかな工数を割り当てて間に合いそうか考える、という作戦に出ることになる。
そして、これらの理屈はマイルストーンがある程度の正確性をもって分解できているという前提に立っているので、そもそも分解に失敗していたりすると、良からぬ事が起こる。だが完璧なタスクの分解は困難なので、タスクを進めつつ、分解がうまくいっているか、抜けている箇所はないか、というのをケアしていくのが良い。このやり方はスクラムを回しているとうまく適合するような気がする。
