一命を取り留めたので、過去の自分宛に、見積もりのポイントを3つだけ書きます。
1. 見積りは、高難度で、非常にクリエイティブな作業である
見積りは、一つの学術分野を成し、そこに専門家や数え切れない本・論文が存在します。
そして、その専門家たちの見積もりも、外れます。
あなたがこれから着手する見積りという作業は、高難易度な作業であることを、自覚する必要があります。
ついつい「これ見積もっておいて〜」「OKです。2日くらいっすね〜」みたいな会話が繰り広げられてしまいますが、自分やチームメンバーのスキル、まだ見えない対象や関連領域、これらを理解した上でのステークホルダへの説明責任など、非常にクリエイティブな側面が存在します。
まずはこういう前提に立つことが大事な気がしています。
2. スプレッドシートをちゃんと開く
見積もりするとき、どのように行なっているでしょう？
「うーん、この資料か〜」
「大体2日くらいかなあ」
こんな感じで線表やチケットに書いているとしたら、それはほぼ何もしてません。
見積りは、不確実な要素をできるだけ明らかにし、確実な領域を増やしていく側面があります。
上記は、不確実な要素も確実な領域も、何一つ明らかになっていません。
自分用にスプレッドシートを開いて、やることを書いていくと、不確実なことが見えてきます。
ここは調べよう、意見を聞こう、レビューしてもらおう、といった細かい作業も見えてきます。
その上で、本当に2日か計算してみましょう。その実装、1日で終わるって言っているけど、レビューは何時間で返ってくる想定？
スプレッドシートだと、タスクや実績列の追加など柔軟にでき、一覧で見れるのが良いです。
最終的には、線表やチケットで管理するとしても、その過程としては、スプレットシート（的なツール）が役に立つと思います。
振り返りやプランニングでもこれを見ればいいので、その点も楽。
3. 「判断」しない
ここでは「判断」という言葉を、やや特殊に（狭く）使っています。
論拠なく数字を出すイメージ。
「うーん、この資料か〜」
「大体2日くらいかなあ」
これは判断。
で、判断は、見積りとは言わない。
サイコロを振るとか、勘に頼るが近い。
あなたは見積もりを頼まれているわけで、適当な数字を入力しろと言われているわけではないんです。
判断じゃないのは、計算とか計測とか比較とか。
わかりやすいのは、過去の似た成果物の編集履歴を見てみることだと思います。
あなたが2日でできると言ったそれ、編集履歴の開始日と終了日の差は2週間だったりしません？
そんなかからない？
でも信憑性が高いのは、2週間の方です。
サイコロより過去の事実の方が信じられるわけで。
最後に
まるで最近のことのように書いてきましたが、こちらの記事は、2年前くらいに書いた社内記事をリライトしたものです。当時、本記事を公開した時に
設計と計画は同じもの
というコメントをいただきました。その心は、リリースできる単位で、依存関係が発生しない（特に、互いに素である）ように管理する（= 上手に設計を行う）ことで、フロー効率開発を行えるということです。「設計」だとか「実装」のようなチケットは作成しないようにしましょう。