仕事の 「点」 に囚われず、 「流れ」 を読む

　スプリントプランニングをいつ、誰が、どんな内容で実施するのか。あるいは、受け入れ条件の記述書式をどう決めるか。完成の定義は？　デイリースクラムで何を話す？ etc、etc

　これら一つ一つについて考えを煎じ詰めていくのは大事なことだ。クオリティと効力感は細部に宿る。ただ、開発が、仕事が、より良き状態となるのを目指すのに、これら一つ一つに焦点をあてる前に捉えるべきことがある。それが「流れ」だ。

　「流れ」に対して、冒頭にあげたことは「点」だ。「点」の一つ一つがどうあると良いのか？を最後に決めるのは、「流れ」のほうになる。ゆえに、「流れ」を先に描いておく必要がある。
　さもなくば、「点」はどこまでも「点」でしかなく、一般的に言って、あるいは教科書的に、または良く言われることとして、「こうあるべき」としか言えない。インターネットでたれ流す分にはそれでも良いが、目の前の仕事をどうにかしていくためには全くもって十分ではない。

　なぜ、スプリントプランニングが存在するのか。なぜ、受け入れ条件が必要とされるのか。完成の定義は何に向けた役割なのか。「点」の前にあるもの、あるいは後ろに起こることを想像したい。その連鎖が「流れ」と呼ばれるものになる。「点」は点のみであり方を決めることができない。「流れ」野中で、存在が決められる。

　受け入れ条件が必要なのは、該当の機能をつくるのに「どうなればよいか」の到達イメージが持てないからだ。到達イメージがない、あるいはチーム、関係者間で揃っていないまま、「これで良し」と思えるものが作れるだろうか。当然、受け入れ条件は必要だ。では、受け入れ条件はどんな粒度でどのくらい書き上げるべきだろうか。受け入れ条件は、バックログアイテムごとにつくる。受け入れ条件で到達イメージをつけることで、該当スプリントでどのくらいの開発を行うことになるか、行えるのか、算段が立てられるようになる。ということは、スプリントプランニングの前には用意しておきたい。プロダクトオーナーだけで、用意しきれるだろうか？　開発チームの協力が必要だ。では、スプリントプランニングの前に、開発に注力しているであろうチームの協力を得る機会とは何か。あらたにその機会をつくるとしても、何時間も取れないだろう。つまり、受け入れ条件の粒度とは、その準備の仕方とは…といった具合で。

　この内容（受け入れ条件云々）自体は、例であって別に新しいことでも、難しいものでもない。あくまで焦点を当てたいのは、変幻自在の「制約」の存在についてだ。「点」自体を含めたその前後には必ず制約があり、その時点で出来ることには制限が伴う。その度合いは、プロジェクトテーマ、取り組むチームによっても影響を受ける。

　場合によってはかなりの数になる、この「変数（プロジェクト、仕事、状況によって値が変わる）」の存在を捉えるのには経験が問われる。経験のありなしを個人のそれに依らず、乗り越えるためには？　そう。だから、「チーム」でぼくらは仕事をしている。