見積もりについてつらつらと
ちょっと社内での説明資料を作るための考えの整理を。
見積もりを依頼されて提示をする。開発の現場ではよくある光景ですよね。ただ、見積もりにかかる期間というか労力が軽視されること甚だしいですね。なぜか開発チームに話が来る前に見積もりが翌日提示になってたりしてイラッときてしまうこともよくある光景です。開発チームとしては、見積もりのために検討する時間が必要だと思っているのですが、そんなん無視していいから早く出して欲しいというやつ。
開発が見積もりを通じて何をしたいのか、という部分についてちょっと整理して、お話を伺う、翌営業日中に見積もり提示時期を回答という流れにしたいことを納得してもらうための考えを少し整理してみます。
見積もりで知りたいこと
お客さまの立場からいうともちろん「予算の根拠」です。そこにはブレがあることが織り込み済み *1 だからこそ早く欲しいとおっしゃってるわけなんですが、開発の立場からするとちょっと違うんですよね。
開発の立場で知りたいことは、
- まだ分かっていないことは何か？
- 理解を間違うと破綻しそうなところはないか？
- リスクになりそうなことはないか？
といった、ブレの要因になる箇所について、重点的にお客さまに確認したり調査したりしなければならない部分がどれだけ見つけられるか、です。開発チームは対象ドメインの知識がないと開発することができませんから、今後のプロジェクトにおいてより学びを深めるための計画のもとになるわけです。見積もり依頼に対してなるべく検討の場を持ってから提示したいというのはこのような理由があります。
最終的にこれが見積もりにも反映される必要があります。出した見積もりをもとにお客さまとスケジュールやいただくお金について計画をするため、契約をしてから許容範囲を超えてしまうと色々と面倒くさいのです *2 。
メニュー化について
必ず検討の場を持つというアプローチに対して、リードタイム短縮のために見積もりをメニュー化するというアプローチがあります。「この機能でこういう変更ならおいくら」みたいな感じですね。このアプローチは危険性を理解して取り組む必要があります。
このアプローチが効果を発揮するためには、最低限以下の三つの条件を満たす必要があります。
- 十分に小さい(コードレベルで変更がわかる)
- 十分に経験を積んでいるプロダクト
- ドメイン内で過去に実績のある業務
この三つの条件を満たす業務というのは、ほとんど移植でしか発生しないのではないかと。つまり、安易なメニュー化とそれに対する慣れは、開発が知りたいことがリストアップできないリスクが増します。それを防ぐための方法はレビューかチームによる検討しかなくて、結局リードタイムはあまり変わらないじゃん、という結論になってしまいます。本当に先ほどの条件に合うものについては、レビューするメンバーを絞ることでメニュー化しても問題ないのではないかと思います。
まとめ
とりあえず、見積もりに対して検討の場を持つことは、その後のプロジェクトを円滑に進めるためにも必要だから理解して、ということですかね。メニュー化してもいいけど、危ないところは理解して取り組もう、と。
