見積り手法

見積りの概念と、手順の説明。

「～を見積もれ」と命じられたとき、技術者として見積りができるようになることを目標としている。
ソフトウェア開発の流れについて、知識があることが前提です。

営業見積りは範囲外だ。
「ゴタクはいいからてっとり早く」の人は、「エッセンス」だけ読むといい。

まず、「見積もり」の用語をはっきりさせる。用語がはっきりすることで、意識が向くようになるからである。
次に、例から見積りを作る手順を説明する。
次に、自分自身の見積り能力をチェックしてもらう。
最後に実習だ。

■エッセンス

見積もり、ターゲット、コミットメントを区別する。
見積もりは工数で、確率で表わされる。

1. 計測できるものの最小単位で、最良ケースと最悪ケースにあたりをつける
   最良ケース：完璧に準備された場合。
   最悪ケース：まあ70%はこの期間内でできるだろう。
   ※これは私の勘による算出方法で、根拠も何もない。
   　「この画面なら１日で作れるだろ」＝8人時間、という程度。
2. 最有力ケースを計算する
   最良ケース×2~8倍。プロジェクトサイズ（大=8,中=4,小=2）と、関係する会社の性格（+1～2倍）で計算する。
   ※これは私の場合の計算法であり、根拠も何もない。
   最有力ケースは、50%はこの期間内で終わるだろうというもの。
3. マネジメント工数などを足す
   1. マネジメント工数＝実装工数×10%
   2. 要求＝実装工数×10%
   3. 設計＝実装工数×10%
   4. システムテスト＝実装工数×10%
   5. 事務、ITサポート（環境構築など）、構成管理＝実装工数×10%
   6. 新機能・新言語・新ツール＝実装工数×最大20%
4. ★内部レビュー１
   この時点で見積もり（＝工数）が爆発していても気にしない。それは計画の話だから。
5. 期間・人数を出す。
   期間＝3×工数の立方根（Excelだと=power(n,1/3)）
   人数＝工数÷期間の切り上げ
6. 線表を引く
   プロジェクトは、おそらく要求・アーキテクチャ設計までがフェーズドアプローチで、実装～リリースが反復・並列型になるだろう。
7. チェック
   • 前提条件
   • 開発見積り（工数、期間、体制）
   • リスク要素の表
   • 機能階層図（機能ごとの工数見積り表）
   • 線表
8. ★内部レビュー２

これで計画のたたき台ができた。
ここから営業用見積もり作成が始まる。それは別文書で説明する。

*** 以降は、より深く学習したい人だけが読む ***

■意味の違いを明確に

見積り、ターゲット、コミットメントは違うものだ。

• 見積もり：　工数。
  ターゲットを達成するためのコントロールを行う上で、適正な意思決定ができる明快な視点を提供するもの。
  分析的。正確性が必要。
• ターゲット：　ビジネスターゲット。
  「～までには完成させる必要がある」、「～円以内に収めねばならない」、「～までに安定させねばならない」
  実現したいビジネスの目標を明文化したもの。
• コミットメント：　約束。
  定義された機能を、特定の品質を確保しながら、期日までに納品するという約束。
• 計画：　スケジュール、体制、マイルストーン。
  ゴールに達するための手段の特定作業。
• ゴール：　いろいろ。
  • （ゴールの例）スケジュール：　求められる品質レベルで、求められる機能を開発する可能な限り最短のスケジュール。
  • （ゴールの例）コスト：　求められる時間内に求められる機能を開発する最小コスト。
  • （ゴールの例）機能：　与えられた時間とお金に対して最大の機能。

見積もり、というのは、この文書では工数のことだ。
一般人は、見積もりというのを計画の意味で使ったり、ターゲットだったり、ゴールだったりする。

用語が区別できていないと、全部がごっちゃごちゃになったまま、「見積もりなんて作れないよ～」になりがちだ。

■見積りの範囲による違い

*技術者の見積り

見積もりといっても、技術者と営業では違うものである。
技術者は両方作れるが、営業は技術者の計画がないと見積もりが作れない。

見積もりはまず工数だ。「全体でどのくらい」を正確に出す。精密じゃない。
これは「規模の見積り」と呼ばれる。私の場合には、これは「～人月」だ。
プロジェクトごとに違う（実際は、LOC:Lines of codeによって異なるようだ）が、まあ、全体工数から、工期と人数を計算して、作業予定表（線表）を作る。

ここまでが「技術者の見積り」。まず、これがないと話し合いにはならない。
ただでさえ定性的なのに、工数もテキトーなら雑談や愚痴になりがちだ。

これを作るのに、私の体験だとどんなに早くても３日かかる。それ以下の日数で作成されたものは、いいかげんだ。まったく信用できない。
逆に言うと、１５分間考えたものと、２日間考えたものは、はっきりいって差がない。ものすごく急いでいる、というのなら、１５分以上の時間を使っても、あまり正確にはならないだろう。はっきりこう言うと怒られるので黙っていたが…、まあ、言ってしまったな。

• 15分～3日間の見積り
  正確さは10～30%くらい。
  この正確度で約束（コミットメント）はまったくできない。実現可能性は0.1x項目数だから、百万分の一くらいの確率だろう。サルがハムレットをタイプする確率よりはいい、という程度だ。
• 3日間の見積り
  正確さは50～70%くらい。

この見積りは対外的にコミットメントするものじゃない。
これをこのまま営業用の見積りにするのは間違いだ。
これは計画を立てるための基準とするものだ。そう考えれば、この時点での重要さは、「計画を立てるための判断材料を提供しているか？」を基準に考えればいい。プロジェクトがうまくいくかどうかは、計画で考えるのだ。

もし、「見積もりを出す」に、ヘンテコなプレッシャーを感じているのなら、そのプレッシャーが何なのかを見極める必要がある。それはひょっとすると、計画のプレッシャーなのかもしれない。
あるいは、そのプレッシャーは勝手な思い込みかもしれないのだ。コミットメントは別なんだ、計画は別なんだ、ということをしっかり意識しておこう。

正確な見積りは、計画のためのベースになる。不確定要素は全部リスクだ。
リスクは隠すより、顕在化させること。コミットメントは交渉だが、見積り（＝工数）は交渉じゃない。

この技術者の見積りをベースに、計画を詳細化していく。
コミットメントを決める。

*営業の出す見積り

ここから先は営業的な話も出てくる。
これだけでは、ハードウェアやソフトウェアの費用が入っていない。いくらだ？
どういうアーキテクチャ（ハードウェア、ソフトウェア、ネットワーク）を使用するのか？　そのトレードオフは？
保守計画は？　サービスレベルは？　プロジェクトの前提条件は？　開発場所、納品物、ユーザー教育は？
誰が実行するのか？　責任範囲は？　支払方法は？
この工期、人数では対外的に問題があるかもしれない（予算、期間プレッシャー、競合の存在など）。じゃ、どうする？　誰がリスクを負うんだ？

どこで対外的にコミットメントするのか？　誰がどのくらいのリスクを負うのか？
リスク判断は、経営判断かもしれない。技術者が勝手に判断しないほうがいいだろう。それよりも、技術者は正確にリスクを提示するほうが望ましい。「最悪２人月必要になってしまうかもしれない」。もちろん、最悪は「永遠に終わらない」だが、そういうありえない正確さを提示しても何もならない。「75%の確率で」と楽観的に考えればいいだろう。

リスクを提示されて、経営者が怒ったら（そんなことはないはずだけど）、それは別の問題がある、という意味と考えてまず間違いない。
「問題は経営者の脳だ」と考える前に、コスト、期間、機能について確認していこう。

すったもんだと、調達費用の調査などを行い、トータルの金額をゴニョゴニョやってると、どんなに早くても２日は飛ぶ。

できれば1日は置いて見直したい。ずうっとこんなことをやっていると、頭もぼんやりしてくる。見直さないと、とんでもない漏れがあるものだ。

対外的な「見積もり」（営業見積り）を作るには、だから、最低（残業＆徹夜付きで）まるまる１週間はかかるものである。ここまでの見積もり作成コストは最低でも0.5人月。うっかりしていると、0.75～1人月はかかる。
一週間未満の見積りは、相当なドラフトであると思ってよい。いいかげんな可能性が高い。例の「15分間見積り」と同レベルである可能性がある。
いいかげん＝不正確、ということだ。不正確を根拠にして話し合いをおこなうと、後は運任せ、ということになる。運任せのプロジェクトの士気が最低になるのは、すべての心理学者、社会学者の認めるところだろう。ここにマネジメントが介入して強権発動すると、プロジェクトは完全に破壊される。

そういうプロジェクトはすごい多い、気がしますね。

この文書は、技術者の見積もりを作れるようになることを目標としている。
技術者の見積り、は最低で2人日くらいが潰れる。
しかし0.5人月に比べれば小さいかもしれない。

技術者の見積りを要求されたら、既存の業務のスケジュールを2～3日間延ばせ。

■「見積りを出せ」の意味

*いきなり計画を出すのは考えものだ

通常、「見積もりを出せ」で求められるのは見積りではなくターゲットの達成方法＝計画だ。

ちょっと待って。

この文書では計画と見積りを別なものとして考えている。見積もりは工数だ。
一気に計画まで提示できれば素晴らしいが、無理だ。
無理を前提にすると道理は引っ込んでしまう。まず、工数を計算するのだ。工数の計算でも相当間違える。レビューしたほうがいい。計画はそれからだ。

見積りはシングルポイントにならない。シングルポイントになるのはターゲットとコミットメント。ちゃんと意識しておくこと。

例）

• 18～24週で終わる可能性は90%。
• 最良で18週、最悪は24週。

相手にこの用語の違いを説明することは、有効なこともあるし、意味がない時もある。
「単にいくらかかるのか知りたいだけなんですよ」とか、「ざっくりでいいから」と平気で言ってくる人には説明しても無駄だ。「単に」、「とりあえず」と言ってくる人は、適応型の人ではないので（反応的な人）、学習できにくいのである。

この人たちに、「それを知るにはリスクを加味した計画を立てないと出ないのです」とか、「ざっくりとは百万分の一の確率で運任せになってしまうのです」とか言ったら、もう大変なことになる。
「あいつは使えない」から始まって、「ガキじゃあるまいし」くらいは覚悟したほうがいいだろう。相当不愉快になるので、無視したほうが無難である。余計なプレッシャーは無視して、着々と工数を見積もろう。

「根拠を教えてください、知りたいんです」型の人にも要注意だ。
無邪気でかわいいと思うかもしれないが、独習できる程度のことを人に聞く、という神経の人の可能性がある。唯我独尊型のわがまま人間である場合がある。つまりはバカであるが、これと付き合うには、無償の愛情がないと辛い。これも無視して、テキトーにごまかしながら、着々と見積りを進めよう。

やってはいけない考え方を提示しておこう。
これらは「やってはいけない」。

• 「３人月くらいと思う。でも何があるかわからないから１人月追加して「４人月」としよう」
  《見積もりがコミットメントと思っている》
  ソフトウェア開発は、大失敗すると１０倍以上の工数増になる。
  追加した１人月には、何の根拠もない。
  工数算定全体がウソのにおいで充満する。誰も君の見積りを信頼しなくなる。
  見積もりを交渉してはだめだ。交渉するのはコミットメントである。
• 「まともにいけば３人月だろう」
  《見積もりを「その日で終わらないことが証明できない最も早い日」で考えている》
  見積もりは工数で、要求されるのは正確さだ。
  ピンポイント予測はまず命中しない。この「預言」では、当たるも八卦、であろう。
  範囲で表わさないと、3人月の根拠がまるでわからないのだ。
  誰も預言を求めてはいないのに、しばしば技術者は預言してしまう。
  ズルズルと遅れる理由はこれだ。ピンポイントで「不可能ではない日」をコミットメントしてしまい、どんどん遅れていくように見える。
• 「一か月でこれをやるのは無理だ。だから「不可能です」と答えよう」
  《見積もりと計画を混同している》
  不可能かどうかを決めるのは計画だ。完全な越権行為というか、順番が間違っている。
  まずは工数はどれだけか、を計算しないことには始まらない。
  機能を削ったり、期間を延ばしたり、予算を増やしたりするための材料を全く提示しない、この手の「見積もり」は、きっと経営陣からむちゃくちゃ叱られるだろう。
  「お前のゴタクは聞いてない」から、「ガキじゃあるまいし」くらいは言われてしまうかもしれない。相当ムカつくだろうな。

問題は、正確な工数を出さない点であり、いきなり計画やコミットメントを考えている点でもある。

正解は、「3～5人月の可能性は7割です」だ。
本気で不確定要素が大きいのなら、「3～20人月の可能性（が9割）ですが、もっともありそうなのは7人月ですね」だ。

まず工数を出す。複数の人が複数の視点で出すのが望ましい。暇な人を見つけて巻き込もう（しかしまず見つからない）。

*計画を立ててみる

きっと「来月末までになんとか」と、最初に言われているだろう。それなのに、7人月ではちと辛い。無理だ。こんなの不可能だよ！

誰もそんな預言を要求していないことを思い出す必要がある。「見積りました。プロジェクトはゆるぎなく失敗します」、と言われれば、誰だって怒るだろうな。

全部やるのはそりゃ無理だ。だから、計画でコントロールしようとするわけである。
たとえば、フェーズを３つにわけよう。
たとえば、不確定要素の大きいものは、後に回そう。
たとえば、もう一人余計に投入しよう。
たとえば、期間を延ばそう。
などですね。

計画をどこでコミットメントするのかは、見積り範囲内ならどこでもかまわない。
大事なのは、コミットメントが見積りのどの位置であるか知り、それに応じた計画を立てることである。

*プロジェクトの優先度

ゴールの優先度は、プロジェクトによって違う。

真正直に尋ねても（「機能と期間とどちらが優先度が高いですか？」、「～月に終わらせるために、どの機能を削減しますか？」）、実りある解答は絶対に得られないだろう。「できるだけ安く、早く、高機能で」とか、そんなことしか言わないだろう。

こういう決定をしてくれと要求すると、フツーの人はビビるのである。いろいろ独創的な言い訳や愚痴をエンエン語られるだけで、時間の無駄だし、不愉快になるだけだ。

人の話から判断できる。文学や芸術など勉強してきた人ならよくわかってると思うが…、私は学がないのですごい苦労した。

「来月末までにはできなきゃならないんだよ」→機能やコストより、期間を強調しているようだな。
「予算内でやらなきゃならない」→予算はたいてい期限と金額が固定だ。その範囲の最大の機能を求めているようだ。
「来月末までにできなきゃならない」→これが法令遵守（コンプライアンス）の話なら、機能と期限は譲れないだろう。

*ちょっと雑談

優先度をつけられる人、というのはかなり強固な意思がある人である。こういう人は貴重だ。経営をやっている人だと、こういう決断ができる（訓練してきた）はずである。重要と緊急の区別がつけられる人である。聞く相手を見極められれば、そういう人に尋ねるべきだ。それだけで、見積りの正確性は段違いに増す。
「3～20人月」が「7～10人月」になるためには、プロジェクトの不確定要素を容赦なく削減（つまりは意思決定）していくしかないのだ。
しかし、たいていの場合は聞くチャンスは与えられない。なぜだろう？　本当にわからない。

ここで、投げやりになるか、やる気をだすかが、分かれ目だ。
投げやりになると、熟練者にはなれるかもしれないが、適応者にはなれないだろう。
「決められたことをこなすのがうまい」のが熟練者ね。
「一生学習することができる」のが適応者ね。熟練者は寿司は上手に作れるかもしれないが、寿司ロボットに代替されちゃうかもしれないな。

*プロジェクトの優先度２

えー、ウチらの仕事は以下のようなものであることがほとんどだ。

• 期間もコストも決まっている：　「今季の予算内で…」のケース。最大の機能を実現する。
• 誰もよくわかってはいない：　「～というのを作れと上司に言われたんで見積もってください」。最小コストになるようにする。
• 期間が決まっている：　「～までにできないと、～が間に合わないんです」。機能を削る。

手順は以下のようになる。 これは以下のページの目次である。

• 計測できるものを数える。
  画面、コントロールブロック（フレームなど）、機能、外部インターフェース、データテーブル、データ項目、既存のソースコード行数…など、計測できるものは全部計測する。
  全部印刷する、またはExcelの表に洗いざらい広げてみる。
• 工数算出の単位をきめる。
  現状のレベル感のなかで、なるべく細かい単位に計測できたものを基準にしよう。
  表になっていないなら、まとめる。
• 工数を見積る。
  項目ごとに、最良ケース、最悪ケースを出す。
  同時に機能ごとに疑問点が出てくるはずだ。これはリスク可能性として、最終的に相手に叩きつける必要がある。リストは作っておく。
• 「もっともありそうな値」と、「期待ケース」を計算で出す。
• 標準偏差と分散を取る。
• 漏れはないか？　ではレビューだ。
  この時点で一度誰かとレビューだ。★
  ここまでで、早くても１日は「完全に」潰れる。というか、一日でできないなら訓練する必要がある。
• マネジメント工数や、未知テクノロジーなどの工数を計算で出す。
• チェックリストで自己チェック。
• 公式で期間と人数をざっくり出してみる。
• 計画線表を引いてみる。
  あんまり真剣でなくてもいい。人時間で工数を出したなら、線表は週単位で引く。細かい精度は無意味だからだ。精度に見合った計画にする必要がある。
  線表の引き方は別項で説明する。
• 工数（人月）、期間（～か月）、 体制（人数）をまとめておく。
  他の人はここしか見ない。
• 見直す。
  以下の文書がそろっているか？
  提出用のテンプレートで書いておくと、後が楽だが、内部用なので体裁はどうでもいいといえばいい。
  最終的に見積りは営業が出すものだからだ。
  • 前提条件
  • 開発見積り（工数、期間、体制）
  • リスク要素の表
  • 機能階層図（機能ごとの工数見積り表）
  • 線表
• この時点でもう一度誰かとレビューだ。★
  ここまでで、もう3日間くらい経っている。二人日は「完全に」潰れていると思う。

■例

この間やった、あるインターネットサイト作成の見積りを例にしよう。

■工数を見積もる

工数は、細かい単位で、計測できるものをベースにして、最終的にはカンで決める（…）。
「これまでの作業実績値から」とか、「業界標準から」とかいろいろ言われるんですが、「これまでの作業実績」は統計取ってないから結局はカンだし、業界標準はプロジェクト規模や形態にあってないので、うまく適合できないのだ。

私は、人時間単位である。1人時間、2人時間,4人時間,8人時間,16人時間…というように。
項目ごとに、最良と最悪の２つをカンで出す。「スゲーうまくいきゃ4時間、ハマってもまあ32時間」のようにして出している。

この時点では、マネジメント工数や、設計や、インストール、移行などは考えない。
実装する工数を出す。実装とはコーディング、単体デバッグのこと。まあ、「動くコードを作るのに」というふうに解すればよい。

*楽観主義

工数を見積もるときの問題は、開発者はかなり楽観的であるということだ。

これは調査結果でもはっきり出ている。約30%が「幻想ファクター」だそうである。

• 今度使う手法（言語、開発方法論、環境、メンバー能力）は、前にやったのより格段に良い。だから…
• お客さんはきっとむちゃな要求はしてこないだろう。だから…
• 前よりもっと頑張ろう。だから…

無理ですよ。

「この日に終わらない可能性がゼロではない日」を見積もりと称することがよくある。だから、最良と最悪なのだ。

ここはサイエンスで私は説明できない。そこまで理解できていない。すまない。
私の場合を例として説明する。参考にしてほしい。

最良は、カンである。「ま、2時間くらいじゃないの？」
しかし、この工数では絶対に終わらない。私は「この工数ではできないと説明できない最良の日」と考えて出している。

最悪は、これもカンである。最良の工数を、2～32倍する。
例えば、「こんなの2時間くらいだろ。でもデータモデルがよくわからないから16倍しておこう」→2人時間～4人日。
「ドはまりして、余計にマスター管理画面作らなきゃならなくなったとしても、4日ありゃなんとかなるだろ」というふうにして、自分なりに検証している。

*どれだけ真剣に（時間をかけて）やるべきか？

工数見積りに日にちをかけても、正確にはならない。
これは真実だ。

正確にするには、プロジェクトの不確定要素を取り除く（要求や、UIなどの意思決定をする）以外の方法はないのだ。だからといって、一切の努力を放棄するのはナンセンスである。

これも経験則であるが、この作業に1日以上かけても、意味がないと思う。
むしろ、1日以上かけると、頭がぼんやりしてきてまとまりがなくなってくる。
「次の資料」が送られてきて、今までの作業が吹き飛ぶことが多くある。
さっさと工数を出すべきだ。 丸々一日かけて。

くどいが、この工数はコミットメントではない。

*工数の幅を狭くする要因

工数の幅を狭くする要因…というかプレッシャーは、自分自身の勝手な思い込みだ。

この手の思い込みが、見積りを不正確にする。わからないことがあるなら、幅は十分取らねばならない。「2時間と4人日って16倍も違ったら、もう見積りじゃない」と思うのは、見積りと計画を混同しているからだ。見積もりは正確でなければならないのだ。

「わからないこと」は、リストにしておく。細かくしすぎても、後で自分がわけわからなくなるので、大雑把でいいと思う。
実際に構築するわけではないのだから、今の時点では、見積りに影響するものだけでいい。「ここの色がはっきり決まっていない」のは、実装時には困るが、今決まってないからといって、見積りは変わらない。
「～機能のデータモデルにわからないことがある」、「～機能のUI動作（インタラクション）に不明確な要素がある」、レベルでいいと思う。

これを自分の内部にしまっておくと、後で大問題になる。だから、リストにするのだ。
そして、キーマンに、「こういうリスクがあるのです。このリスクを取るか、取らないかをコミットメントしてください」と言おう。

誤魔化されんなよ。
キーマンが「目標は…」とか言ってきたら、そりゃ他人事と思ってる証拠だ。
「リスクを取ることを約束してください」→「いつまでに決定するか、見積ってください」だ。
「そんなの負えない」なら、「誰が責任を負うかということを、いつまでに決定するか約束してください」だ。

当事者化させないことには、いつまでたっても不確定要素は不確定要素のままだ。

「目標」より強い言葉として、決意とか約束がある。
「あなたが何を」「いつまでに」「どうやって成果を教えてもらえるか」の三点セットだ。
これは確認のスキルと呼ばれる。

• あなたは何をやりますか？
• それはいつまでにやりますか？
• その結果をどうやって知らせてもらえますか？

暗記しろ。
少なくとも、君の真剣さは伝わるだろう。
これに反応しない奴は、社会人ではない。もう相手にする必要はない。

■「もっともありそうな値」と、「期待ケース」を計算で出す。

*最有力ケース

最有力ケースを出す。私は計算で出してしまっている。 かなりいいかげんなのはその通りであるが、これでやってきた。

上図の右端。この例では最良ケースを3倍している。

工数見積りに大きな影響があるのは、規模である。
1,000行のコードと、100万行のコードでは、工数が異なる。
私自身は、プロジェクトサイズを大中小に分けて考える。

次に、担当者や間に挟まる企業の性格、担当者の性格などを考える。嫌いな奴なら係数が上がる。

これで決めた係数を、最良ケースに掛けて、最有力ケースを計算する。
まあ、こんな感じだ。

大：8倍。中：4倍。小：2倍。
嫌いな奴なら+1～2。

「まあ、こんな画面、2時間くらいだろ」→中規模プロジェクト係数4倍を掛けて、「最有力ケースは8人時間」。

*こっからサイエンス（標準偏差と分散）

各機能ごとに標準偏差と分散を計算する。

標準偏差＝（最悪－最良）÷n

nは、工数見積り全体が、どのくらいの自信あるかによる。
まあ5割…1.4
7割は間違いない…2.1
※注意：「5割」というのは、最有力ケースの、見積りを上回る成績と下回る成績が、結果として半々だ、という意味である。
「自信がある」、「やれそうな気がする」、「よくわからない」程度だと、確率は3割未満だ。それでは見積りにならない。
例では1.4で除している。(40-4)/1.4=26というわけだ。

次は分散だ。

分散＝標準偏差の自乗

そして、分散の合計から標準偏差を求める。

プロジェクトの標準偏差＝sqrt（分散の合計）

これがプロジェクトの標準偏差である。
例では、分散の合計が26,996。そのsqrtが164となっている。164が標準偏差だ。

*期待ケース

各機能ごとに「期待ケース」を計算で出す。

期待ケース(50%の確度)＝（最良＋（4×最有力）＋最悪）÷6

期待ケースを合計する。

全体工数（50%の確度）＝期待ケースの合計
＊＊＊（全体工数（75%の確度）＝期待ケース ＋ 0.67×プロジェクトの標準偏差）＊＊＊　←　のはずだが…。計算するとヘンテコになってしまう。勉強します。
これでざっくりと工数がでた。

■漏れはないか？　ではレビューだ

*レビューワって？

まずはチェックだ。

この期に及んで読んでいないドキュメントはないと思うが。見忘れていた文書はないか？
機能項目に漏れはないか？
リスクリストは印刷できる形になっているか？

他人（レビューワを自称する人）は、まずは総合計しか見ない。
（まじめなレビューワは、全部ちゃんと見る。私は一般則を述べている）
そして、思いつきで自分がわかりそうなところをチェックして、文書全体の信ぴょう性を探ろうとするだろう。
このときに効いてくるのが、最良ケース、最悪ケース、最有力ケース、期待ケースだ。

• 最良ケース：　まあ、最短だとこんなもん、というもの（本当は25%確度が望ましい）。
• 最悪ケース：　ぱっと思いつく「ひどいことになった」場合（本当は75%確度が望ましい）。
• 最有力ケース：　本当は「50%確度のケース」だが、私の場合はこれが最良×2～8程度の計算値である。
• 期待ケース：　統計的に計算された、「50%の確度の工数」。そう説明しなさい。これは本当は、上記のように、25%,50%,75%のケース見積り後に計算できるものなのだが。

合計の工数を目立つフォントにしておこう。
工数は、「人時間」では細かすぎるので、全部合計したあとに人月に変換しよう。
1人日＝8人時間
1人月＝20人日
人月は切り上げでも四捨五入でもどちらでもよい。どうせそこまでの精度はないから。

933人時間。でも、そこまでの精度はない。だから、「6人月」である。

では、レビューワに電子メールで送ります。
レビューワには、「実装工数を出したので、この時点でレビューしてほしい」と誘おう。

レビューで期待したいのは、機能的にごっそり落ちているものがないか、系統的に（全項目で）忘れていたことはないか、複数の目でチェックする、という程度だ。
詳細項目の抜けレベル、項目の工数の妥当性レベルは、普通のレビューワではチェックできない。 しないだろう。ぽつりぽつりと思いつきの項目でツッコミを入れる程度のことしかできないし、しないだろう。

馬鹿にすんな、と思うか？
ここまでやったのに！　と思うだろうか。
しかし、レビューワは貴重な時間を割いて付き合ってくれているのだから、敬意をもって接しよう。 過度の期待は禁物だ。

レビューでは、いの一番に、「これは、実装と単体テストの工数です」と言い切ること。忘れているようなら、何度言ってもいい。
マネジメントや環境構築コストが含まれていないことを忘れない。
このあとに出てくるが、総工数はこの数字の1.5倍程度になるのが普通だ。
これを総工数と思われると災厄である。こう言っていても忘れてしまう人は多い。

レビュー結果を見積りに反映しよう。

■マネジメント工数や、未知テクノロジーなどの工数

ちゃんと計測して見積れれば、それに越したことはない。しかし、「ざっくり出して」といわれることもある。ここではざっくり方式を提示する。

• マネジメント工数：　実装工数×10%
• アーキテクチャと計画（いわゆる設計）：　実装工数×10%
• システムテスト：　実装工数×10%
• 事務、ITサポート（環境構築など）、構成管理：　実装工数×10%

不安要素も入れる。

• 未知環境、未知言語、未知ツール：　実装工数×20%

おやおや、なんだかんだ足したら、10人月になったぞ。

工期に対するプレッシャー（「～までにできなければならない」）は、この時点ではまだ無関係である。
それは計画の話なのだ。
それでもこれに固執する場合、胸に手をあてて考えよう。
「プレッシャーは、開発者の思い込みだ」。

この時点では、見積りを出すのが目的なのだ。
見積りは、工数だ。計画じゃない。顧客や経営陣が混乱してるのは仕方ないが、開発者が混乱してはいけない。

計算してみよう。たぶん、実装工数の1.5倍くらいになったんじゃないのか？

■チェックリストで自己チェック

漏れやすい機能要件

• セットアップ・インストールプログラム
• データ変換ユーティリティ
• サードパーティ、オープンソースを使うためのラッパ
• ヘルプシステム
• 配置モード（リリースモード）
• 外部システムインターフェース

忘れがちな非機能要件

• 正確性
• 相互運用性
• 更新性：ごめん、よくわからないで書いている。
• 性能
• 移植性
• 応答性
• 再利用性
• 拡張性
• セキュリティ
• 生存性（？）：ごめん、よくわからないで書いている。
• 利便性（ユーザビリティ）

これをどのように工数に反映させるのか。
私は定型の手法を持っていない。すまない。
計測できるものならするが、非機能要件などは計測は難しいのだ。
テキトーに実装工数を何倍かしている（1.1倍、とか）。

■公式で期間と人数をざっくり出してみる

スケジュールの公式

スケジュール（月）＝3×工数の立方根

Excelで計算するなら、=3*power(工数,1/3)です。
アカデミックな見積り専門家によると、期間は工数の立方根の関数になるんだってさ。
係数の3は、モノやヒトによって2～5で変動するようだ。

プロジェクト人員数の公式

プロジェクト人員数＝工数÷スケジュール

これは確かにざっくりだ。しかし、線表を引く取っ掛かりとしては悪くない。

10人月、に対して、期間4か月、人員3名、と出たな。
ん、経験からしてもいい感じだな。

■計画線表を引いてみる

*タスクアクティビティ

WBS（Work Breakdown Structure）があればそれを使ってもいいが、こんな大雑把な見積り段階でそこまで細かい精度を求めても無駄だ。
この精度は、営業見積りでは必要な場合があるが（コケオドシにすぎない）、技術者の見積りでは無用だ。
あとでテキトーにねつ造すればよい。今の段階では、大雑把でいい。

ざっくり見積りのタスクアクティビティは、こんなレベルだろう。

• 要求
• 設計
• 実装・単体テスト
• 結合テスト
• 総合テスト
• 文書化

ウチの規模のプロジェクトでは、大体以下のような感じで進むと仮定してはどうだろうか。

• プロジェクトの初期段階（期間の20%程度）で要求と設計を固める。
• がりごり実装（期間の60%程度？）
• テストフェーズ（期間の15%程度）
• 文書化（5%？）

計算が合わなくなってしまった。
文書化を削るなら、テスト期間を延ばす。

*線を引く

アクティビティと機能ごとに線を引いて、担当者名（まずはSE,PG1,PG2レベルでいい）を置いていく。
線表の横軸は週単位がいいと思う。精度のいいかげんさは、これくらいがちょうどいい。
プロジェクト基本計画は、おそらく月単位である。
保守改修プロジェクトなら、日単位かもしれない。

縦軸は、上記「タスクアクティビティ」で、実装・単体テスト、のところが、前の章で作った見積りの項目のコピーである。その横には、期待ケースの人日が書いてある。
右端にあるAとかBとかは、仮人員名である。AがSE（System Engineer）、B・CがPG（Programmer）とした。※ちなみにSEというのは日本だけの呼び名らしいな。
週単位だから、 線は重複しているように見えるが、実際には「１人日＋２人日＋２人日＝１人週」というふうに引いている。わりと精密なのである。ただし見た目は不精密にわざとしているわけだ。
私はもっぱらExcelを使うが、MS-Projectでもいいかもしれないし、Powerpointでもいい。
自分の慣れたツールを使えばいいだろう。
手書きはいただけないが、まあ、整理するためにまず手書きしてみてもいいかもしれない。

*横軸の精度

プロジェクトの性格に応じて、横軸の精度を決めること。
細かすぎる精度は、見積りを不必要に正確そうに見せてしまうので、弊害のほうが大きい。
だからといって、このレベルで月単位の表を作ったら、それはあまり役に立たない。

例）

• 円周率は3だ。→これは正確。
• 円周率は3.37882だ。→これは精密だが不正確だ。
• 私の背の高さは2m。→これは正確だが、あまり精密ではない。
• 工数は397.5人日です。→非常に精密であるが、精度ほど正確ではない。
• 工数は0.5人年です。→あまり精密ではないが、正確かもしれない。

見積りに要求されるのは、精度ではなく正確さだ。
見積りの正確さに見合った精度を心がけよう。

■工数（人月）、期間（～か月）、 体制（人数）

見積もり作業で、全体工数は分かった。
線表を引いたことで、期間（始まりから終わりまでの時間）と、体制（SEとPG何名？）がわかった。

普通の人はここしか見ない。
唸って作った線表は、誰も真剣に見ないものである。部分だけ拾い読みして、ハッタリをかましてくるだけだ（経験による一般論）。
だからといってがっかりする必要はない。

この線表は、自分で作ったものだ。
おそらく、プロジェクトに関して現時点では非常に詳細なレベルにまで理解が進んでいるはずだ。
現時点でここまでの詳細度を達成している人は、自分以外いないだろう。
自信を持っていい。

人は、まずこの3点しか見ないので、まとめておく。
10人月、4か月で3名体制。

たまに本気で読んでくる人がいる。その人はおそらく自分なりの線表を引いている。貴重なので仲良くするようにしよう。

■見直す

*計画

結果はありきたりのものかもしれない。それなら、プロジェクトはきっとうまくいくだろう。
とんでもなくオーバーしているかもしれない。
それでもいい。そうだとしたら、この時点からプロジェクトコントロールのための計画が始まるのだ。

とてつもなくオーバーしているなら、プロジェクトをフェーズ分割する必要があるかもしれない。
機能単位を二つに分け、「こっちはここまで、つぎはここまで」というリリース方式を検討してみる。
マイルストーンを線表上に置いて、フェーズを明示しよう。

期間を延ばす戦略もあるが、普通使えない。予算ベースだとまず無理だし、他のビジネス予定と連動しているのが普通なので（ビジネスターゲット）、期間はずらせないことの方が多い。

期間を縮める戦略のほうがフツーだ。
しかし、その期間は30%以上は絶対に縮まらないそうだ。
下の表はそのままは使えないが、「がんばって縮めてよ」型の人に対抗する材料にはなるかもしれない。これは研究者が複数プロジェクトを調査して出したもので、私の経験則じゃない（その発言の重みが違う）。

• スケジュールを15%縮めるには、工数は+100%
• スケジュールを10%縮めるには、工数は+50%
• スケジュールを5%縮めるには、工数は+25%
• 見込み値なら、工数は＋0%

「がんばる」という選択肢や、「見積もりが間違っていると決めつける」や、「ツールに習熟したので今度はうまくやれると思います」は、あまり根拠がなく、経験から必ず失敗することがわかっている。
見積りは交渉できない。それは積み上げた計算結果だからだ。
しかしコミットメントは交渉できる。意欲的・楽観的目標に約束するか、堅実・悲観的目標に約束するかの差である。しかし、約束は見積り工数範囲内に収まっていなければならないし、その差が期待ケースの20%を超えるとプロジェクトコントロールでは手も足も出ない、ということが、研究によりわかっている。
マネジメントが「開発者の見積りは、悲観的要素（学生症候群：試験直前にならないと勉強しない）をもとにしているから、さらに30%縮められるはずだ」と言ってきたら、そんな会社辞めろ。
説得は無理だ。時間の無駄だから。辞めたほうがいい。
見積もり（工数）は交渉できない。見積もりをもとにして、現実的な計画を立てる。そしてコミットメントは交渉だ。

人員を突っ込む、というのはいい策ではないが、可能性はある。
プロジェクトの人員数が5名未満なら増やすのは現実的な解かもしれない（7名を超えると弊害が無視できなくなる＝実際に工数が増える）。
コミュニケーションパス（人と人とのコミュニケーション経路）の数は、n×(n-1)÷2である。nの自乗の関数だ。人数が増えると、不経済的なのだ。
これは、研究によると、小規模プロジェクトと大規模プロジェクトで2～3倍の生産性の差、ということになっている。

機能を落とす、という選択肢もある。
特に管理系などは、極端な話、画面なんてなくてもいいかもしれない。
一番重要と思われる機能の工数は莫大だろう。何とか減らしたい、と思うかもしれないが、そこは削れない。そこを削ってしまっては、プロジェクトの意味がなくなることが多い。だとしたら、周辺の機能はバッサリ落としてしまったらどうだろうか。

*前提条件

「見積り前提条件」は必ずつけよう。

しかし、経験上、見積り前提条件は無視されることが多い。
別に保険屋や株屋と契約しようってわけじゃないから。

サンプルで提示したものを下に書いておく。

ベースラインとなるスケジュールの見積りは４か月で、50%の範囲内で正確と考えます。
この見積りは、計画を立てる基準にはなりますが、対外的なコミットメントを行う基準にはなりません。
見積りは以下の条件を前提にしています。

3/12（三月第二週初め）に、２名のSE、PGが、プロジェクト選任になる。
3/26（三月第四週初め）に、３名のSE,PG,PGが、プロジェクト選任になる。
3/12（三月第三週初め）までに、要件（要件、機能、ユーザーインターフェース）が確定し、ビジネスルールは変更されない。
3/12（三月第三週初め）までに、データベースモデルが確定する。
3/26（三月第四週初め）までに、画像、ページフォーマット（スタイルシート）が納品される。
選任プロジェクトメンバーは、期間中の長期休暇（ゴールデンウィーク）は休まない。
選任プロジェクトメンバーは、期間中に他のプロジェクトによる割り込みがない。
下記、個別画面ごとの不確定要素、リスク要素が大きく変更になる場合には、見積りを修正する必要があります。
下記、見落とされがちな機能要求・非機能要求・アクティビティは、見積りに含んでいないか、折り込み済みです。
大きく変更になる場合には、見積りを修正する必要があります。

この時点の前提条件にケチをつけてくる人がいるとしたら、真剣なあまり見るべき視点がズレているか、ハッタリかどちらかだ。

視点がズレている、の意は、この時点では見積もりの正確さと、計画の実行性を見るべきタイミングなのに、前提などに神経を集中しているという意味である。
ハッタリの意は、見るべきものがわかっていない、ということである。「何か言わないとカッコがつかない」程度で発言している可能性がある。

やんわりと、「見るべきものは、見積りの正確性と、計画の妥当性なんですよ」と伝えよう。
視点がズレている人は、焦点がはっきりするし、ハッタリの人には、そんなに身構えなくていいということを伝えるのだ。

しつこく追及してくるようなら…、まあ、何か気になる点があるのだろう。はっきりとそれを述べられない、というのはお気の毒だが、相手の知性のなさを嘆いてもしかたがない。足がない人に走れというのは差別であるから、相手の懸念理由をゆっくり聞いてやれ。

本気で嫌がらせだと思うなら、逆襲するかね。お勧めはしない。ゲームになってしまうから。
「それによって、見積りはどれだけ変更になると思いますか？」、「御懸念のリスクは、いつまでに解消しないとプロジェクトを破壊すると考えているのですか？」、「そのリスクは、誰がいつまでに解消することを約束してくれますか？　その結果はどうやって知らせてもらえますか？」

*リスクリスト

懸念事項はまとめておく。

たぶん、誰も読まない。拾い読みしてケチつける程度だ（経験による一般則）。
しかし、書いておくことで、自分自身の整理になるし、この件について忘れることができるようになる。
ちゃんと書いておけば、来週読み返しても思い出せるだろう。
書いていなければ記憶に頼ることになる。人間の記憶は相当怪しい。記憶に頼って、漏れがあったら、申し開きはしにくいな。

「ここまで読み込みました」という証拠でもある。
これがいいかげんなら、見積もりはきっといいかげんだろう。

以下の文書はそろっていますね？

• 前提条件
• 開発見積り（工数、期間、体制）
• リスク要素の表
• 機能階層図（機能ごとの工数見積り表）
• 線表（スケジュール）

■もう一度レビュー

それでは、印刷できる形態に整えて、もう一度レビューだ。
関係者にメール送れ。

レビュー結果を反映して、技術者の見積りは終わった。

■参考資料

• 見積もり資料.xls
• 見積もり画面仕様.xls
• 見積もり機能一覧.xls

■見積りテスト

自分自身の見積り能力というものをチェックしてみよう。
結果は誰に話す必要もない。テストといっても、評価のための材料にするわけじゃないので身構えないで。

*見積もりテスト

次の説明をよく読んで、指示を守って解答してみよう。

それぞれの問題について、正解は90%の確度でこの範囲内にあると自分が考える範囲の上限と下限を記入する。範囲の幅が大きすぎたり、小さすぎたりしないように気をつける。
自分の最善の判断として、正解が含まれることが90%は確かだと思える幅を記入すること。

このクイズは見積りスキルを見るものである。調査スキルは関係ない。だから、答えを調べたりしてはいけない。それぞれの問いにあなたなりの答えを記入する。空欄は誤答として扱う。
解答時間は10分間以内。

1. 太陽の表面温度。
2. 上海の緯度。
3. アジア大陸の面積。
4. アレクサンダー大王の生まれた年。
5. 2004年時点の米ドルの通貨流通量。
6. 五大湖の総水量。
7. 映画「タイタニック」の全世界での総興行収入。
8. 太平洋に面した海岸線の総延長。
9. 米国で1776年以降出版された書籍タイトルの総数。
10. シロナガスクジラの重さの世界記録。

配点は、正解を含む範囲を書いた回答一つ当たり1点。

結果はどうでしたか？
がっかりすることはないそうです。たいがいの人は、このクイズでロクな成績を残せないそうです。

*考察

90%確か、というのは、どのくらい確かなのか。
クイズでは「90%の確度」で見積ることを明記してある。クイズは10問あるので、本当に90%が確かだと思う見積りならば、9点前後になるはずだ。

本を見てみると、600人の平均正解数は2.8問だそうだ。8問以上の正解者は全体の2%。10点満点は一人もいない。
この結果からすると、常人が直感的センスで考える「90%確か」は、実際には30%確かにほぼ近いということになる。
他の研究結果でも同様の結論らしい。

私は3点だった。
「90%間違いありません」は、何らかの統計的裏付けがない限り、意味がないということだ。そうでないパーセンテージは、希望的観測以外のなにものでもない。

クイズを解かずに、ズルをしている人も、もう一度戻って試してみればいい。
タネ明かしを読んだ後ですら、90%正解するのは難しい。

*見積もりの適正な幅

7～8問正解できた人に尋ねると、きまって「幅を大きくとりすぎましたね」と答えるという。
しかし、設問は90%確度だ。まだ幅が狭すぎるのだ。

私たちは、幅の狭い見積りのほうが、幅の広い見積りより正確だと信じがちだ。
広い幅は能力が低い証だと一般は信じているものだが、実際は逆だ。
実際のデータの裏付けがあれば、幅は狭いほうが望ましいが。

不必要に見積り幅を狭めてはいけない。見積り幅とあるべき見積りの確度の整合を確認すること。

学究的に解明されてはいないようだが、見積もり幅を狭くするプレッシャーは存在する。誰でも知っているだろう。
結論は、プレッシャーの大部分は、個人の勝手な思い込みだということだ。
一部は、プロとしてのプライドに起因する。幅の狭い見積りが良い見積りだとの誤解に基づいている。
また、不必要に狭い幅の数値を要求する上司や顧客のやり取り経験から生じるものもあるそうだ。

プレッシャーを感じたら、それが自分の強迫観念でなく、実際に存在するものであるか確かめる必要がある。

■見積りのプレゼンテーション

くどいが、ここは営業が出す見積りの話ではない。

幅のある見積りが役に立たない、と思わせているのはプレゼンテーションのせいである。
かっこよく一点見積りしたところで、プロジェクトの不確実性はみじんも変わらない。単に不確実性を無視しているだけか、強迫観念に似た思い込みによるものである。この見積りは誰にとっても役に立たないし、有害ですらある。

ただし、コミットメントは別だ。コミットメントは一点である。明確であるべきだ。
営業が顧客に出す自称「見積もり」はこっちだ。だから、それは一点になるだろう。
これを区別して考えれば、見積もりに不必要な思い込みは入らないだろう。

見積もりは正確さを追及する。それは不確実性に応じた幅になるのは当然だろう。
不確実性を提示し、評価するための材料にならなくては役に立たない。

*「政治的」な影響

「政治的」は適切な言葉じゃないと思うが…。

具体的な期日が、ビジネス上非常に重大な場合がある。
法令遵守のためなら、その日は譲れないだろう。展示会や～商戦に間に合うかどうかが致命的な場合もある。
競合他社の存在が、コスト上非常に重要な場合もある。
予算ベースの仕事だと、金額と納期はまったく交渉の余地がない場合もある。

これらの要求は、単発で存在するより、複数が絡み合うことのほうが普通である。
必ずしも全部満たせるわけではないが、要求を真摯に受け止めている姿勢は提示する必要がある。

先に真剣さを訴えたほうがいいと思う。
世の中には信じられない人もたまにいて、重大なビジネス上の要求を隠す（教えてくれない）人もいる。こういう人たちにとっては、見積りはたぶんゲームだ。
「勝とう」としているわけだ。
しかし、見積りは交渉できない。太陽の表面温度は交渉すると変わるのか？　ここでゲームをしようというのは、どれほど馬鹿らしい行為だろうか。

ゲームの人は、はっきりいって真剣さにおいて二流である。二流を相手にするときは、相手をバカにするのではなく、一流の真剣さを見せつければいいだろう。
先に真剣さを訴えて、その真剣さが本物ならば、ちょっとまともな神経なら恥ずかしくてゲームにできないものだ。
一枚、二枚の差ではなく、段違いだというのを見せればいい。

コミットメントは交渉である。

技術者「見積もりは5～7か月です」
経営「じゃ5か月だな」
技術者「提示しているリスクを全部負うことを、全員が合意してくださるなら、5か月でコミットしましょう」
経営「？」
技術者「5か月の可能性は16%です。7か月の可能性は84%。6か月だと50%」

リスクのうち、対外的要因（要求、ユーザーインターフェースなど）を指す。

技術者「この部分は私たちでは不確定要素を削減できません。このリスク要因を管理してくれませんか？　いつまでに決定するのか、そのために何をしていただけるのかを約束してください」
経営「…」
技術者「それをどうやって確認すればいいのか教えてください」

*多すぎる見積り：受け入れられない場合には？

見積もりが多すぎるから、プロジェクトが却下されるかもしれないと心配するのは越権行為かもしれない。
経営陣はプロジェクトがコストに見合うかどうかを判断する責任と権利がある。技術者が故意に見積もりを過少にすることは、効果的な判断の機会を奪うことになる。
間違った材料をもとにした間違った判断では、結果は当然運である。関係者全員は不愉快だ。

問題解決型のアプローチは、ここでは説明しない。
星の数ほどテクニックが紹介されている気がする。そして、テクニックでは解決しない、という論も、星の数ほど発表されているような気もする。
パキッと話せるほど、私は理解していない。

■実習

さて、実習です。

1. この長い文書を1ページにまとめる。
   1. 見積もる。
   2. 実行する。
   3. 診断する。
2. 添付のプロジェクトを見積もる。

やってみてください。

■参考文献

• 「ソフトウェア見積り　－　人月の暗黙知を解き明かす」Steve McConnell著、日経BPソフトプレス
• 「人月の神話」フレデリック・ブルックス著、ピアソン・エデュケーション
• 「ラピッドデベロップメント」Steve McConnell著、アスキー出版局

■考察（雑記）

見積もりをお願いするとき

見積もりは最低で3日間、2人日は完全にかかる。これ以下の手間しかかけていないとすると、その見積りの確度は10%程度だ。でも、世の中的にはこの程度の自称「見積り」が大手を振っている。

誰かにお願いして、10%程度の見積りしか出てこないのだとしたら、そんなものを基準にビジネス計画を立ててもあとは運任せだ。よりどころの「運」の確率は？　10%の確率が三つ続く確率は、0.1×0.1×0.1=0.001、つまりは0.1%である。この計算ができない人がいると信じられるか？　でもフツー計算できないよ。

その場合には、その10%程度の見積りを平気で出してくる相手と一緒に見積もりをするしかないだろう。これは自分自身の1人日は完全にかかるし、相手は1.5～2人日潰れる。この手間をかけるだけの主体性が自分にあるかどうか。ないなら運を天に任せてぼえーっとしているしかない。ずうっと忙しいままだろう。

なぜ見積らないのか？

そりゃ苦痛だからだし、実際に見積りに意味があるとは誰も思っていないからだろう。見積もりを信じるのは上層部だけだ。なんて牧歌的なんだ。幽霊を信じる方がまだ信ぴょう性がありそうだ。スケジュールは常にどんどん遅れるし、修正するためにさらに時間を取られるし、覚えなきゃいけないことが増えるから実務に使える脳が減る。

見積もりに意味なんてないんだ！

これを知ったとき、私はすっかり気が楽になった。真剣に、がんばって見積もろうとしていたが、意味がない。歯をくいしばって見積もっても意味がない。上司に言われて、嫌々やっても意味がない。私がどういう気持ちでやったとしても、プロジェクトの不確実性は全く変化しない。見積もりが苦痛なのは、プロジェクトが不確実性に満ちているからだ。プロジェクトの不確実性は「がんばる」とか「知識」とかでは全然軽減しない。
だとしたら、気楽で楽しみながらやった方が断然マシだ。

もし、あなたが嫌々見積りをしているとか、毎度毎度スゲー苦労しているというのなら、それは不確実なものに付き合っているからだ。誰だって不確実なものに直面するとうんざりするが、プロジェクトはそういうもんなのだ。プロジェクトの不確実性は、利害関係者の容赦ない意思決定によってしか軽減されない。嫌々見積もりをやっているのなら、一生そのままだろう。あとはうつ病になるしかない。

技術者の見積りは、「容赦ない意思決定」をするための判断材料になっていなければならない。意志決定はリスク管理であって、それは駆け引きとか交渉とかが関わるゲームである面がある。技術者がゲームに付き合う必要はないが、ゲームする人たちに適切な判断材料を提示する義務…というか権利はある。きちんと判断材料を提示できると、精神衛生上ものすごくいいもんだぞ。あとのウザい「リスクを誰が負うのか」とか、「責任範囲」とかを丸投げできたほうが楽だぞ。

逃げ回る、という戦略もある。開き直る、という方法もある。怒鳴るもあるかもしれない。これらを実施している人を見かけることがある。フーン。まあ、かわいければ馬鹿でもいいだろう。私はかわいくないので、この選択肢はちょっとなかったな。

もっと細かい単位のときのアドバイス

この文書の例のような単位ではなく、もっと小さい単位のときはどうするといいだろう。
「～画面作ってくれ。どのくらいかかる？」

アクションと時間に分割して表にする。
Joel on Softwareにアドバイスがある。これは見積りじゃなくてスケジュールの話だが、かいつまんで転記する。
…と思ったが、多いな。多すぎだ。細かく知りたい人はサイト見てもらうか（英語）、本読んでもらうとして、俺が感心したことだけにしよう。

MS-Excelで、列項目は。

• 機能
• タスク
• 優先度
• 当初見積（時間）
• 現在見積（時間）
  最初は当初見積と同じ。そしていつでもアップデートしていい。後で学ぶためのものだし、アップデートし続ける限りスケジュールは機能する。
• 経過時間（時間）
  累積。アップデートする。
• 残り時間（時間）
  現在見積－経過時間。入力しない（計算させる）。ゼロになったら終わっている、という意味だ。

当初見積と現在見積と経過時間。とくに当初見積。なるほどな。

最初に作るのは、機能・タスク・優先度・当初見積、だ。こんだけである。この表が作れないのなら、自分が何をやっているのかさっぱりわかっていないのである。そして、現在見積に当初見積をコピーして、経過時間を全部ゼロにする。残り時間は計算セルで、当初見積＝現在見積＝残り時間になっているだろう。

毎日、2分かけて現在見積、経過時間をアップデートする。昨日やったことだけだから、全部アップデートする必要は全くない。

これならアップデートは毎日2分しかかからない。昨日やった分の現在見積と経過時間しか更新しないから。プロジェクトが終わった時に見直せば、自分自身の見積りレベルがよくわかって学べる。意味のなかった見積りが、意味をもつ。耳が痛いな。

タスクの粒度は細かくする。
面倒くさがって「文法ミスチェック機能を実装する」とすると、実際には何も考えていないだろう。何をするのか全然わかっていない。わからなければ、どのくらいの工数が必要かわかるはずがない。目安は2～16時間程度なんだってさ。40時間以上のタスクがあるなら、粒度が大きすぎるそうだ。耳が痛いな。