49-見積りとは何か - やさしいデスマーチ

「プログラマが知るべき97のこと」の49個目のエピソードは、見積りに関する話です。見積に関するこのエピソードは日頃よく思う部分です。しかし、残念な事に本当に読んで理解して欲しいのはプロジェクトマネージャです。そして、プロジェクトをリードしていく事になるプログラマも知るべき内容です。
このエピソードではあるプロジェクトマネージャとプログラマとのありがちな会話を例にして、見積りの定義を再確認しています。大辞林で「見積もり（る）」を調べると次のように書かれています。

1. 目分量や心づもりではかっておおよその見当をつける。目算する。「入場者数を―○る」
2. 工事や製品などの、原価・日数・経費などを前もって計算して出す。「経費を―○る」「工事を―○る」

ソフトウェア開発では、現実として1の「おおよそ見当をつける」事しかできません。工業製品などと異なり、プログラマのスキルに依存する部分が多いこと、要求が変化する可能性があること、見積りの時点で全ての情報が揃うことはほとんどないことなどが理由です。工業製品の生産だけに限るのであれば、原材料のコスト・原材料の調達時間・加工時間・ラインの稼働状況などを計算することで、2の「計算して出す」事が可能ですが、ソフトウェア開発には適用できません。しかし、実際のソフトウェア開発の現場では、2の「計算して出す」として使われているのが現状です。この問題を解決するには、「見積り」と「コミットメント」の違いを知る事が出発点になります。

「見積り」とは、何かの価値、数字、量、程度などについて概算、あるいはおおまかな判断をすることを指します。

「見積り」では、正確な数値を出すことはできません*1。「見積り」は信頼できるデータや経験から基づく予想でしかないため、幅がある方が自然です。例えば、「ｘｙｚ機能について、特に大きな問題も発生せずに順調に実装ができれば３日程度でできると思いますが、ｘｘの部分で気になるところがあり最大で５日かかる可能性があります」と言ったように大雑把な数値で幅が出るのが自然です。言い換えれば、正確な値を出すことができないのです。

「コミットメント」とは、「約束」と言い換えても良いでしょう。

「コミットメント」は文字通り「約束」です。別の会話はよくある会話ですが、プログラマであれば似たような違和感を感じたことがあるでしょう。

PM　「機能ｘｙｚはまだ出来ていないようだが、開発期間の見積もりは５日と言っていたはずでは？」
プログラマ　「はい、思った以上に手こずっていまして、最終的には６ー７日になるかと思います。明後日には完成するかと」
PM　「それでは（私が/WBS上で）困る。５日と見積つもった以上、５日で終わらせるのが仕事だろう」
プログラマ　「・・・・」

このありがちなケースではプロジェクトマネージャは完全に「見積り」を「コミットメント（約束）」として捉えています。日本語の「見積り」には「計算して出す」というコミットメントに近い意味と２つの意味があるのが問題なのです。しかし、はじめからプログラマとプロジェクトマネージャの間で言葉の定義を合わせておけばトラブルは避けられました*2。

プログラマとしては、言葉の定義を正確に行いコミュニケーションを行う必要があります。
１つ目として、チームメンバーやステークホルダから「見積り」を依頼された場合は、それがコミットメントかどうかを確認するべきです。コミットメントであれば、見積りにリスクを加味した上で自分がやり遂げる自信のある数値を呈示するのがプロの見積もりです。例えば、コミットメントとして７日と提示する場合でも、「実装自体は５日程度の見込みですが、一部の機能に調査が必要な部分があり最大で２日程度使うかもしれません。７日あれば終わらせます」という具合です。勿論、5日の根拠もあると望ましいですが、それが見積もりでなく約束になる事を踏まえて伝えなくてはなりません。そして、不可能なコミットメントを要求されてもそれを簡単に受け容れてはなりません。
２つ目として、細かい単位でのコミットメントは避ける事です。例えば、おおよそ３−５日で終わる見込みの機能を１つ実装する為にはどうしても５日をコミットメントとする必要があるでしょう。しかし、同じボリュームの機能を１０個実装する時に最大値である５０日をコミットメントにする必要はないと思うはずです。勿論、最悪のケースでは５０日かかるわけですが、最短で３０日ということを考え、４０日程度をコミットメントとする事は可能だと思います。実際には、３日よりももっと早く終わらせる事の出来る機能もあれば、５日以上かかる機能もあるでしょう。しかし、全体として調整できる余地が残ります。これは、見積額を出す場合は行っているでしょう。言い換えると、１−３日程度の個々のタスクにコミットメントを求めるのはナンセンスということです。金額の見積りについて補足ですが、初めはリスクやコミットメントを加味せずに見積りを行う事が重要です。初めから納期がｘ月だからとか予算がｘｘｘ万円だからというコミットメントを意識して見積りを行うと、単純な引き算になってしまい、現実と乖離するだけです。現実に見積もりを行い、適切なリスク係数などを加味して見積額を算出しましょう。
ソフトウェア開発には変化が付きものです。正確な見積もりや正確なスケジュールを立てようとしてもコスト的に見合うことはほとんどありません。「アジャイルな見積りと計画づくり」には、どのようにして変化に向き合ってソフトウェア開発を進めていくかが書かれていますので必読です。