ヌーラボのアジャイル・ライダー長沢です。今回は業務における「見積もり」をテーマに、見積もりの定義や性質、見積もりのズレを最小限にする方法をお届けします。
目次
なぜ見積もりは重要なのか？
突然ですが、悪とは正義があることで生まれるものである。「とある正義」と違う「とある正義」がぶつかることで対立が生まれ、そして勝ったものが「正義」と呼ばれ、負けたものが「悪」と呼ばれます。仮面ライダーのなかにはそんな「悪の正義」に目を向けた作品もあります。
あなたのお仕事においてもそういうことはありませんか？
建前としての概算見積もりがそのまま本決まりになり、計画に盛り込まれ、進捗を迫られ……。それがいつしか「正義」となり、実状は「悪」と呼ばれてしまう。
そんなときは、すこし立ち止まって考える時間も必要です。本記事で「見積もり」について理解して、業務における上手な付き合い方を考察していきましょう。
業務における「見積もり」とは
まず最初に見積もりとは一体何でしょうか？
見積もりとは『金額・量・期間・行動を前もって概算すること』
Wikipedia 「見積」より
つまり概算見積もりは「頭痛が痛い」と同じような意味合いですね（笑）。
それはさておき、業務における見積もりは大きく2種類に分けられます。
1. ざっくりと見積もってあとから正式に詰める
1つ目は、ざっくりと見積もったもので、あとで正式な見積もりをする前提で試算、提示するものが多いです。
2. 細部まで詳細化した上での見積もり
2つ目に、細部まで詳細化した上での見積もりであることが多いです。
PMBOKによれば、超概算見積もり、概算見積もり、確定見積もりというように、見積もりの世界は奥が深いのですが、ここでは主題にフォーカスするためそれらには触れません。
しかし、それぞれに『見積もり精度』というの目安が設定されているのでそちらを参考にします。
| 見積もりの種類 | 精度 |
| 超概算見積もり | -50% 〜 +100% |
| 概算見積もり | -25% 〜 +50% |
| 確定見積もり | -5% 〜 +10% |
ここで注目してもらいたいのは、個々の数字や根拠ではなく、見積もりは“確実なものではない”ということです。あくまでも概算なので、それだけ抑えておけば良いです。
見積もりはズレることがある
さて、ここで軽く主題から離れてみましょう。見積もりといってもいくつかのやり方、考え方があります。
- 絶対的見積もり
- 相対的見積もり
ここではあまり触れませんが、絶対的、相対的な見積もりの特長は、ヌーラボのリアルプロレスラー（他称）中村さんが『タスクの相対見積もりによるプロジェクトの可視化を、Backlogの バーンダウンチャート で手軽に実現する』で詳しく解説していますので、気になる方はぜひ参照してください。
・絶対的な見積もりの正確性
絶対的な見積もりは単位が明確（普遍単位または、任意単位）なので、利害関係者にとってわかりやすいと言えますが、正確性が問われます。
・相対的な見積もりの正確性
相対的な見積もりは、比較によるものなので直接比較や間接比較に関わらず、比較対象に依存するため、当事者にとってはわかりやすいですが、利害関係者に示すのは難しいです。
PMBOKの振れ幅の大きい見積もり精度で示されているように、絶対的見積もりと相対的見積もりの両方で、説明責任としてのあいまい性と正確性が求められることがわかります。
こうした要素を踏まえると「見積もりはズレることがある」という前提は間違いはなさそうです。
しかし「ズレっぱなしで良いのか？」という点についてはよく考えてみる必要があります。
段階的な見積もりと尺度の変化
見積もりに合わせて事実を作ることはとても大変です。
なぜなら、見積もりとはズレることが前提なので、そこに合わせて計画を立てて実施すると、見積もりの“ズレ”に悩まされてしまうからです。
ソフトウェア開発はもとより、さまざまな業務で不確実性が高いものが増えています。過去の成功体験が適用できない*ため、見積もりのズレも大きくなる傾向があると言えます。
*裏を返すと、去年やったこととまったく同じことをすれば良かったり、過去の成功体験を活かせる業務ならば、見積もりのズレも計画のズレも最初の段階で上手に補正できそうです
ズレを少なくするには、見積もりの頻度をまめにすると良さそうです。
PMBOKの「超概算見積もり精度」という段階よりも細かくして、計画後も見直していければ「確定見積もり精度」後も現場で、都度見積もり*できればズレはさらに少なくてすみそうです。
*これを見積もりと呼ぶべきかはひとまず置いておきます
例えば、スクラムならば、デイリースクラム*でスプリントゴールに対しての計画と実行の調整を日々行います。
*デイリースクラムは進捗報告会ではないので要注意です
見積もる方法もすべての業務のフェーズ（段階）で同じにする必要はないかもしれません。案件を取るための見積もり、計画を立てるときの見積もり、実際の作業の見積もり、これらの3つがまったく同じ単位でなくても良いのです。
では、こうした状況下で現場作業の見積もりの精度をなるべく高めるにはどうすれば良いのでしょうか？その方法を1つご紹介します。
現場で使える「期日」の見積もり方法をご紹介
ここまでの前置きでは、見積もりの難しさを皆さんに理解してもらうために、現場で実際に使えそうな見積もりの話はあえてしませんでした。
では、実際に現場で作業を見積もるには何を基準にすれば良いのでしょうか？
「人月」「人日」「期間」と色々な要素が皆さんの頭のなかに浮かんでいると思います。
残念ながら、これらはどれも現実的ではありません。
もう1つ新しい選択肢として「期日」が追加されたらどうでしょうか？
「いつまでにできます！」これが現場にとって一番分かりやすい現実的な見積もりではないでしょうか。
「期日だってやってみなかればわからない」という意見もありますが、結局現場にわかりやすい単位と尺度で見積もってもズレは生じます。しかし、ズレを減らすことはできます。
段階的な期日の見積もり
段階的な期日の見積もりとは、その業務の重要な鍵となる「期日」をいくつか設定して、それらの期日を段階的に見積もり、日時を確定（コミットメント）していく方法です。
例えば、鍵となる期日を以下の4つに定めましょう。
- 開始日: その業務を開始する日
- 実施計画のレビュー日: その業務の計画をレビューする日
- 実施結果のレビュー日: その業務の実施内容をレビューする日
- 完了日: その業務を完了する日
「実施計画のレビュー」では、計画の内容とリスクを明らかにできると良いでしょう。例えば、ソフトウェア開発ならばプロダクトデモ、その他の業務ならば成果レポートなどが相当します。
これらの期日は初期段階で確定できるものでしょうか？おそらく、途中で期日がズレていきます。
| フェーズ | 日時の確定（コミットメント） | 見積もり |
| 開始時 | ・実施計画のレビュー日時 | ・実施結果のレビュー日 ・完了日 |
| 実施計画レビュー | ・実施結果のレビュー日 | ・完了日 |
| 実施結果レビュー | ・完了日 |
つまり「次のフェーズについての日時の確定はするが、その先のフェーズの確定は難しいので、見積もりだけする」というやり方です。
すべての日時を確定したり、曖昧にしたりするよりも現実的なやり方です。実はこの方法は、私がマイクロソフトに所属していたときによく紹介していたものです。
MicrosoftのVisual Studioの開発チームが実践していた方法で、数千人のエンジニアを抱えていても、少人数チームがこの方法で作業の見積もりをしていました*。
*2011年当時の情報であり、現在もこの方法をとっているのかはわかりません
Backlogで段階的な見積もりを実践する方法
さて、これらのフェーズごとの段階的な見積もりと日時の確定を、プロジェクト管理ツールのBacklogで実行するにはどうすれば良いのでしょうか？
以下の2つの方法を試してみましょう。
まとめ
今回は、見積もりについて考察してみました。段階的な期日の見積もりとコミットは、開発プロセスや社内などの規定にもあまり抵触しないと思いますので、これを機会にぜひ試してみてください。
▼プロジェクト管理に関連する記事はこちら▼
こちらもオススメ：
プロジェクト管理とは？目的や項目、管理手法について徹底解説！ | Backlogブログ
プロジェクト管理の基本や主な項目を紹介。CCPMやWBSなどのプロジェクト管理の代表的な手法やプロジェクト管理全体の流れを解説。これからプロ…
backlog.com