コラムColumn

　開発を始める前に置いた見積りは、いつまで使えるのでしょうか。
　開発を進めれば、実際にどれくらい作れるのか、どこで時間がかかるのか、どのような想定外が起きるのかが少しずつ分かってきます。最初にはなかった情報が増えるのであれば、その情報を使って予測も更新すべきです。
　見積りは、一度作って終わる成果物ではありません。新しく得られた情報をもとに、予測を更新していきます。

■分かることが増えれば、予測も変わる
　開発の初期には、分からないことが多く、見積りにも大きな幅があります。不確実性コーンは、開発の初期ほど予測の幅が大きく、情報が増えることで予測を見直していく必要があることを捉える助けになります。

【図：不確実性コーン】

　ただし、時間が経てば自然に予測の幅が小さくなるわけではありません。実際に作り、結果を観察し、当初の前提との差を確認する。その過程で新しく得られた情報を次の予測に反映することで、少しずつ見通しが立ちやすくなります。
　たとえば、開発を始める前には、ある機能にどれくらいの時間が必要なのか分からなかったとしても、実際にいくつかの機能を完成させれば、チームが一定期間にどれくらい進められるのかという実績が得られます。また、技術的な難しさや、想定していなかった作業が見つかることもあります。
　最初から高精度な数字を求めず、その時点で得られる情報から予測を置き、情報が増えたら更新していきます。

■実績を使って予測を更新する
　見積りを繰り返すのは、開発を通じて得られた実績や新しい情報を使い、より現実に即した見通しを持つためです。
　そのため、毎回すべてを細かく見積もり直す必要はありません。残っている仕事の規模や、それまでの実績をもとに、着地の見通しを更新します。
　第2回では、何を制約として守り、何に変更の余地を持たせるのかを考えました。開発を進めることで、当初は分からなかったことが少しずつ見えてきます。そこで、得られた実際のデータを使って予測を更新します。

■現場の実績 ― 計画が変わっても、着地を予測する
　著者の現場では、ある四半期で、仕事の規模をポイントで表したところ、当初計画した仕事が236ポイントだったのに対し、最終的に完了した仕事は245ポイントとなったことがありました。結果だけを見れば、その差は約3.8％です。ただ、最初に立てた計画をそのまま実行したわけではありません。実際に完了した仕事のうち約3割は、四半期の開始時点では計画に入っていませんでした。
　開発を進める中で新しい仕事が加わり、当初の計画からスコープは変化しました。そして四半期の終盤には、それまでの実績と残された期間を踏まえ、優先順位の低い仕事は実施しないという判断も行いました。
　重要なのは、最初の計画をそのまま守ったことではなく、スコープが変化する中で実績をもとに見通しを更新していたことです。
　この事例の3.8％という結果は、最初からその精度で予測できていたことを意味しません。開発を通じて得られた情報と実績を反映しながら、その時点での見通しを更新していった結果です。
　こうして見通しを更新できれば、当初の計画との差を確認するだけでなく、残された期間で何を実施できそうかを判断する材料にもなります。
　分かることが増えるたびに予測を更新する。そこに、繰り返し見積もる意味があります。
　こうした実績は、チームごとの状況に左右されます。同じ規模の仕事でも、業務への理解、技術的な経験、チームとしての習熟度によって、進められる量は変わります。見通しの更新には、他のチームの数字よりも、そのチーム自身の実績を使います。

■素早く繰り返せる見積りが必要になる
　予測を何度も更新するなら、見積りそのものに大きな時間や労力をかけることはできません。必要以上に精緻な数字を作るより、必要なときに素早く見積もり、新しく得られた情報を反映できる方法が適しています。
　では、見積りを素早く繰り返しながら、必要な情報や認識の違いを捉えるにはどうすればよいのでしょうか。次回は、相対見積りやプランニングポーカーを通じて、見積りを単に数字を決める作業ではなく、チームの対話として活用する方法を取り上げます。

※このコラムは全6回を予定しています。