１人の開発者の直感に基づく見積もりのリスク
経営者や管理者や営業の都合を考えると、迅速に案件の見積もりが出てくると助かります。
見積もりが早く出てくれば、案件の優先順位付けや案件の受注がスムーズに進むようになるためです。
要件が明確で見積時点で具体的な実装がイメージできるようであれば、１人の開発者が直感に基づいて迅速に見積もりをする体制でも、問題は発生しにくいです。
しかし、ここに要件が不明確な場合、見積もり時には想定していなかった要件調整や作業範囲の拡大が発生し、見積もりから大きく工数が膨れ上がり、案件が炎上し、長時間労働や追加人員投入を強いられるばかりで利益が出ない案件となってしまうリスクが出てきます。
このような見積もりの誤りを防ぐためには、１人の開発者が直感で見積もりを行っている状態から脱する必要があります。
見積もりに時間がかかるようにはなりますが、そこに時間をかけることで案件が炎上するリスクを減らすことができるため、時間をかけるだけの価値はあります。
過小見積もりを防ぐための方法
具体的には、以下のような方法により、見積の誤り（過小見積もり）を減らしやすくなります。
複数人で要件読み合わせや見積もりレビューを行う
それぞれの開発者には得意不得意や経験の違いがあるため、見積もり時に感じやすいリスクにも違いがあります。
また、開発者の観点では見つけにくいリスクもあります。
そこで、立場が異なる人を集めて、要件の読み合わせや積算もりの妥当性の確認を行うことで、事前に見つけるべき要件の問題点や作業範囲拡大の可能性を見つけやすくなります。
客観的な見積手法を用いる
具体的には、ボトムアップ見積もりや類推見積もりといった手法です。
直感に基づく妥当性の確認や補正は必要になりますが、これらの客観的な見積もり手法を用いることで、積算もり時に見つけるべきリスクに気付くきっかけを得られます。
後工程での再見積を提案する
要件が不明確な案件では、積算もりと実際の工数にブレが生じやすいです。
要件の不明確さがクリアされブレが生じにくくなった段階で精度が高い見積もりを出す、ということが可能であれば、それを提案した方が良い場合もあります。
（もちろん、最初の見積もり時にできる限り要件をクリアにしようとするのが前提です。あくまでも、ある程度作業を進めないと具体的に見えてこない要件に対して有効な手段です。）
直感で出した見積に一定の係数をかける
積算時に見落としが発生することを見越して、直感で出した見積に一定の係数をかける、という方法もあります。
あくまでも個人的に見聞きした範囲ですが、一般的には1.5～3.0倍の係数をかけると上手く行くことが多いようです。
不確実性コーンの理論では最大4.0倍の工数上ぶれが発生するので、この係数は妥当なものであるように思います。
あとがき
システムは技術力があれば作れるというものではなく、システムを作るための人員や時間を確保する必要があり、それを確保するためには適切な見積もりを出して経営判断を行う必要があります。
基礎的な技術を身につけないと妥当な見積もりも出せなくなるので、今回の記事で説明したこととは別に、前提として基礎的な技術力を身につけると良いでしょう。
株式会社サイゼントでは、即戦力のJavaプログラマーを育てるための書籍「絶対にJavaプログラマーになりたい人へ」をKindleで販売しています。
同じく、Spring Frameworkについてきめ細かく解説した別冊も販売中です。
また、上記の書籍をテキストとして用いたプログラミングスクール「サイゼントアカデミー」も開校しています。
このスクールは、受託開発事業・SES事業である弊社が、新入社員向けの研修で培ったノウハウを詰め込んだものです。
ご興味がある方は、上記画像から個別ページにアクセスしてみてください！
コメント