ソフトウェアの見積もりは永遠のテーマです。 色々と試行錯誤しましたが、「そこそこそ正確」「顧客も受け入れられる（高すぎない）」「間に合う（安すぎない）」バランスのよい見積もりが素早く作れるYamahei式をご紹介します。

Yamahei式見積もり法

背景

ワタシが所属するような中小企業の小規模案件を見積もる場合、タスクの工数を積み上げていくとまず失敗します。 安全に寄せすぎると高くなって受注できませんし、受注できる程度に金額を下げていくと工数が足りなくなってきます。

また、見積もり作成にかけられる時間も限られており、短期間で受注できる、そして何よりちゃんと間に合う工数を見積もりが必要です。

見積もり方

たったこれだけ。

補足

見積もり各行は画面-機能単位に見積もります。 画面がないバッチ等ならその名前で良いです。 基本は機能単位なのですが、IFの切れ目（クライアント/サーバ等）で分けることが多いです。 概ね1～数日ぐらいの粒度に分かれているとより正確に見積もれます。

全行の工数を合計すれば見積金額になります。 揺れの大きさでリスクがどこにあるのかを説明できますし、全体としては許される程度の工数に収まります。

楽観について

エンジニアに見積もりさせた時に出てくる 少なすぎる 工数でよいです

何もかも順調じゃないと到達しえない楽観的な工数を記載します

悲観について

この日数でできなければ首が飛んでもやむなしと言える最小の工数を記載します

調査が不足している、実装イメージがわいてない、等々も解決できる工数です

揺れ・工数について

楽観-悲観の差が大きいほど揺れが大きくなります

工数は揺れが大きいほど悲観に近く、揺れがなければ楽観になります

備考

揺れが大きい理由などを記載します

ただ、大きすぎる揺れは実現イメージが不十分なことがほとんどなので細分化の余地が残っています。

注意点

Yamahei式に限らず怖いのは見積もり項目のヌケモレです。 見積もりであっても何を作るかをきちんと定義する必要があります。

• 提案も見積もりも設計に基づくという話

  同じことが見積もりにも言えます。 見せ方は違えど、何をどう作るかを決めておかないと値段のつけようがありません。 （フェーズごとに粒度の違いはあると思います）

類似の見積もり法

2点見積もり（SRSS）法

ワタシの見積もり方法は、最初は2点見積もりを参考にしていたはずなんですが、改めて見直すと全然違います。。

• 2点見積もりと作業バッファの計算方法「SRSS法」のイメージ | Qiita

2点見積もりのSRSSは「Square Root of the Sum of the Squares」、二乗和平方根法とも言うようです。 見積もりというより製造業のばらつき予測に使ったりするもののようです。

PERT法

ワタシの見積もり方法を後輩はPERT法だと思っていたようです。

• Program Evaluation and Review Technique | Wikipedia

こちらも楽観悲観は登場しますが、必要なパラメータが多かったりタスクの順序まで考慮に入れたりと、手軽さに欠ける印象があります。

謝辞

画像は Pexels 様より使わせていただきました。