見積もりにおいてバッファを付与すべき？
結論
見積もり時に雑にバッファを付加するのではなく、リスクアセスメントをすると見積もり精度向上・PJの成功につながりやすい
そもそもなぜ見積もりを行うべきか
以下の記事にある通りだと思います。
一つは投資判断である。そのプロダクトや機能の開発にどれくらいの金銭的なコストがかかるかを計算し、それに見合う価値が得られるかどうかを判断するためには、時間的な見積もりが必要になる。「どれくらいかかるか分かりません。できた時が終わる時です」ではそもそも開発をスタートすることも任せられない。
いつ頃にプロダクトが完成するのか、はエンジニアチームと関わるビジネスサイドが最も知りたいことの一つになることが多いでしょう。期日が他チームの行動に大きく影響するためですね。
特に日本においてはビジネスチームが基盤となってエンジニアを集めて開発を進める事業会社が主要となっていることを考えると、期日を設定することは自然のように思えます。よって、エンジニアチームは見積もりを実施し、期日を設定することが重要となります。
以下の記事にあるように、アメリカの会社においては期日（納期）よりも質を重要視することもあるようですね。特にエンジニアチームが中心となっている会社であれば、このような方針をとる可能性もあるのかと思いました。ただ、この方針であったとしても会社の今後の方向性、スケジュールを株主やステークホルダーに伝える上で見積もりと納期の設定は雑であっても必要でしょう。
「納期」って本来そこまで重要だろうか？例えば、クラウドサービスがリリースされるのは伸びてもだれもわからない。ある日できてからアナウンスされるだけだろう。
数少ない、プロジェクトは納期は重要かもしれないが、大抵のものは納期よりも「使ってもらえるサービス」になってるほうが本来ずっと重要じゃないだろうか？
既存の見積もりの課題点
見積もりにおいて、頻繁に行われているのは全てのタスク量/人日に対して、1.5倍だったり1.8倍だったりとなんとなくのバッファを加えていくことは多くのプロジェクトにおいてありがちです。
が、これだと追加分に対しての曖昧なバッファ算出になってしまいがちです。バッファとは未来におこりうるリスクへの工数ということになります。
例えば従来の見積もり・納期の出し方・計算方法に日本情報システム・ユーザー協会（JUAS）が発表している標準工期があります。「投入人月の立方根の2.4倍」と言われているようです。
この計算に則ると、1000人月のプロジェクトの場合は24カ月の工期を設定するのが標準的となります。
このような計算方法は過去の様々なプロジェクト事例を基盤に考案されておりある程度の参考にはなると思いますが、それが必ずしも自分のプロジェクトに適合するとは限りません。各プロジェクトが抱えるリスクの大きさはそのプロジェクトによります。
よって、バッファを曖昧に算出することはPJの納期・工期を曖昧にすることにつながると考えられます。
曖昧な見積もりを防ぐためのリスクアセスメント
では、バッファ・リスクに対してどのように対応するのが良いか。
上の図のリスクを分解して見てみると、リスクとは既知のリスク+未知のリスクに分けることができます。既知のリスクはどの程度の大きさなのか、それに対してどれくらいの工数かを見積ることができるリスクです。
例えば
実装コストはあまりないと考えられるが、既存のコードがAのようになっている場合はA'の対応を行わなければいけない。Bの用になっている場合はその対応の必要はない。
この場合においては既存のコードの調査とその対応コスト（A`）が既知のリスクになります。この既知のリスク２つに対しての見積もりも実施できているとタスクにおいて見積もりができている割合が増えて正確性があがるでしょう。
上記の例だと、Aの場合は明らかに多い見積もりになってしまう可能性もありますが、見積もりは少ないよりも多い方がよっぽどPJにとっていいですね。
また、ユーザストーリーマッピングという書籍のP83に以下のような紹介がありました。
プロジェクトチームは何度もマイルストーンを達成できなかった。クライアントは不満を持ち、チームの士気は低かった。ふりかえりの際に、期限内に仕事が終わらない最大の原因は、プランのない仕事の進め方にあることに気づいた。そのほとんどは、不確実性および既知のリスクによるものだった。
彼らはストーリーマップの頻度と精度を上げた。中間リリースのたびにストーリーマッピングを行うように頻度を上げ、リスクを発見できる可能性を向上させた。また、「リスクストーリー」(通常のアクティビティ、タスク、詳細の他に)を追加してマップの精度を上げた。より上等な視覚化と議論ができる土壌を作り、リスク管理が改善されることを期待した。結果は驚異的なものだった。
このように既知のリスクに対して見積もりを実施することで、見積もりの正確性があがることに繋がると言及されています。
PJにもよりますが、基本的に見積もり時に以下の点を考慮して一つのタスクの見積もりを実施することが重要かと考えています。
- 設計書を書く工数（必要であれば）
- テスト仕様書を書く工数
- コードを書く工数
- テストコードを書く工数
- レビュー工数・レビュー後の修正工数
- 現時点で考えられるリスク
PMとしてのリスクへの対応
リスクを意識して算出することで、現在のチームが抱えているリスクを洗い出すこともできます。
これによって、リスクを先回りして解消することができるようになります。
例えば以下の事例の場合
実装コストはあまりないと考えられるが、既存のコードがAのようになっている場合はA'の対応を行わなければいけない。Bの用になっている場合はその対応の必要はない。
既存のコードの調査をPMが事前に対応することで、見積もりの精度は上がります。できる限り早くAなのかBなのか調べておくことで、今後の対応方針も定まりPJが円滑にすすむことができるかと思います。
あるいはリスクを洗い出しておくことで、他のエンジニアがそれについて知っている場合は相談することができるかもしれません。チームでリスクに対応できるようになっているとさらにいいチームと言えそうですね。
まとめ
リスクアセスメントを行ったとしても、未知のリスクはまだ残るため最終的に1.1-1.5倍程度のバッファ付与を行うことは避けられないとは思います。
が、不明確さをできる限り明確にするリスクアセスメントはビジネスサイドに正確な情報を伝えるのに役立ち、PJの炎上を防ぐことができるのではないかと考えています。
参考文献
Discussion