見積りをPMとしてレビューする

メンバーやベンダーから見積りが上がってきたとき、PMはそれをどう見ればよいのでしょうか。

「自分は技術が分からないから判断できない」と感じる方も多いと思います。しかしPMが見るべきなのは、技術の妥当性ではありません。「抜けている工程はないか」です。ここだけ見ても、精度はかなり上がります。

■ 見積りは「そのまま受け取らない」

出てきた数字をそのまま計画に載せると、たいてい足りなくなります。理由は単純で、見積りを出す人は、自分が作る部分しか見ていないからです。

実際のプロジェクトでは、作る以外の時間が多く発生します。

これらが「含まれているか、別で見ているか」を確認するだけで十分です。含まれていないなら、どこかに足す必要があります。

■ 受け取ったら、4つ聞く

技術が分からなくても聞ける質問です。

① 前提は何か

「この数字は、何を含んで、何を含まないか」を聞きます。とくに次の3点です。

• どこまでの範囲を含むか（設計だけか、テストまでか）

• 使う技術・環境は決まっている前提か

• 他システムとの連携は含むか

② 誰がやる想定か

同じ作業でも、経験者と初めての人では倍以上違うことがあります。「この数字は、誰がやる前提ですか」と聞きます。

ベテランが出した数字を、初めての人がやると、まず収まりません。見積りを出した人と、実際にやる人が違うときは要注意です。

③ 根拠は何か

根拠には段階があります。

「だいたい2週間くらいです」という答えが返ってきたら、「どんな作業に分かれますか」と聞いて、一緒に分解します。分解する過程で、本人も抜けに気づきます。

④ 何が抜けやすいか

先ほどの表を見ながら、1つずつ確認します。これは疑っているのではなく、一緒に確認するという進め方にします。

■ 「大きすぎる粒度」は分解してもらう

1件で30人日を超えるような見積りは、中身が見えていません。

粒度が大きいと、次の問題が起きます。

• 進捗が測れない（「20人日のうち何人日終わった」が申告になる）

• 抜けに気づけない

• ずれたときに、どこでずれたか分からない

目安として、1件5人日以内まで分解してもらうと扱いやすくなります。分解できないなら、そこは本人もまだ見えていない部分です。

■ 幅で受け取る

1つの数字だけで受け取らず、最短と最長を聞きます。

• 「うまくいけば何日、引っかかったら何日ですか」

• 「何が起きたら、長いほうになりますか」

2つ目の質問が重要です。ここで出てきた答えが、そのままリスクの一覧になります。「他システムの仕様が分からなかったら」「テストデータが用意できなかったら」といった答えが出てきたら、それは先に手を打つべきことです。

■ 合計してから、全体で見る

個別の積み上げが終わったら、全体として見ます。

積み上げると全体が見えなくなるので、最後に一歩引いて、全体の形を見ます。

■ 数字を削らせない

上から「予算に合わせて削れ」と言われることがあります。このときに、数字だけを削るのは最悪の対応です。

やることは、次のどちらかです。

• 作るものを減らす（機能を次期に回す）

• やり方を変える（既存機能で代替する、外部サービスを使う）

「同じものを作るのに、工数だけ減らす」は実現しません。減らした分は、品質か納期のどちらかで必ず出てきます。

■ まとめ

PMは、技術の詳細を評価できなくてかまいません。見るのは次の3点です。

• 抜けている工程はないか（レビュー・テスト・手戻り・会議）

• 根拠は何か。誰がやる前提か

• 粒度は細かいか。幅で受け取っているか

次に見積りを受け取ったら、まず「レビューと手戻りの工数はどこに入っていますか」と聞いてみてください。ここから会話が始まります。