これは、様々な業務でも、よく行うことだ。所謂、作業見積というもの。
「将来」に向けて行う作業について、どの程度の作業時間がかかるか見積もるという行為は、その見積もる人間によって、その手法は様々だ。
更に、その作業内容がルーチンワークでは無く、初めて取り組むプロジェクトごとに見積もる場合は、なかなかスキルが必要なものとなる。
例えば、システム構築のプロジェクトの作業を見積もるという場合。
ある人は、詳細な仕様を決定して、それを基準に初めて見積ることが出来ると言う人。
また、ある人は、前提条件を自ら仮説を立てて構築し、それを基準に見積もるという人。
どちらも、同じように見積もることは出来る。
前者であれば、精度の高い見積りが行えるだろう。
後者であれば、前提条件を見誤れば、後々にそのしわ寄せが出てしまう。
一方で、プロジェクトを推進するという意味で考えた場合は、少し異なる。
前者は、詳細な仕様が決まらなければプロジェクトは前に進めにくい。
後者であれば、条件を付けながらも、おおよそのスコープを構築することが出来、プロジェクトを前進させることが出来る。
特に、後者の場合、過去の経験値の積み重ねでナレッジが蓄積されていれば、より精度の高い仮説を構築でき、対応できるだろう。しかし、経験値が不足していれば、その仮説を見誤るリスクも高まる。
さて、どちらにしても、まず重要なのがプロジェクトのゴール・目的の明確化。
往々にあるのが、プロジェクトの「手段」が「目的」と勘違いしてしまっているケース。この「手段」がゴールや目的として、独り歩きしてしまうと、後々になって「失敗」という二文字にぶち当たってしまう。
まずは、このゴール・目的を明確化し、チーム全員で共有。
そして、それを基準に前者のタイプで見積もるのか、後者のタイプで見積もるのか。
それぞれ、プロジェクトにおける見積もる側が置かれた役割によって選択してみるのも良いのではないだろうか。
ただし、プロジェクト終了後、そのプロジェクトを振り返り、ノウハウとして蓄積していかない限り、同様の作業を行う場合、スピーディーで精度の高い後者のタイプでの見積は行えないのかもしれない。
