こんにちは、最近プロジェクトの見積もりをやり始めた筆者です。
分かるとは、物事を分解して理解した状態を指す
プロジェクトを遂行する上で見積もりを取るのはすごく重要なことですよね。僕が今所属しているチームは見積もりが甘くて開発遅延が多発しています。見積もりのとり方がわかっていなかったり、振り返りをしていなかったり原因はいっぱいありますが、いちばんの原因は見積もりを取る理由がわかっていないことだと思います。
今日は最近見積もりを取り始めたことで心がけていることを話したいと思います。
1. トップダウンで分割
トップダウンというのは大きな要素が何でできているのかを階層ごとに分解して考えるということです。例えば「掃除」というタスクを分解すると、「掃除機をかける」「拭き掃除をする」「物を片付ける」などとなります。
いきなり、掃除にどれくらいかかると言われても経験からしか見積もりを行うことができません。しかし、トップダウンに物事を考えてそれぞれかかる時間を算出すると、それを足し合わせるだけで見積もりができます。
つまりは、見積もりとは、物事の最小単位の集まりということになります。はじめから大きな目線で考えることは誰にもできないので小さな目線の積み重ねで見積もるようにしています。
2. やりたいことから考える。コストから考えない。
見積もるときにはいろいろな側面で考えてしまうものです。あたらえられたコストや人員からできることを考えるのもその一つでしょう。しかし、その目線で考えてしまうと、コストを十分に使った施策を考えることになります。バッファーを取って考える人もいるかも知れませんが、バッファーの時間を見積もることは経験に左右されるものとなります。
ですが、やるたいことが制限されているため、実際に作業を開始すると作業漏れなどが多発しコストを使い果たす形で進んでいきます。それによって見積もりをオーバーした工数が発生してしまいます。そのため、まずは、やりたいことを精査して、それを満たすように人員やコストを決めていくことがベストです。
まずは、抜けがない見積もりを心がけるようにしています。
3. ベースラインの共有は必ず行う
ベースラインとは、取り組むスコープと前提条件のことです。スコープとは作業範囲のことを指しています。主に曖昧な仕様書のまま進んでしまうプロジェクトなどは、スコープを開発側で考えてしまい、実際作業に入ると、作業のスコープの漏れがどんどんと発覚し、工数を圧迫します。
前提条件とは、プロジェクトを行う際に前提となっている条件です。（例：開発環境、業界の常識）これらが抜けていると実際にプロジェクトが始まる際に、制作物に対して差し戻しなどが発生し、ものによってははじめからやり直しといった自体になる可能性があります。
はじめにすべてを共有することは難しいですが、疑問に思った点や詳細な状況を共有することで齟齬をなくすことを心がけています。
最後に
はじめにも話しましたが、見積もりとは詳細な分割だと考えています。そのため、物事をいかに分割して、いかに網羅的に知ることができるかに気をつけることで漏れのない見積もりができると僕は考えています。
