こんにちは寝る

古い記事の情報は参考程度にお願いします

見積もりについて

「システムに同じものは無い」という性質から
その見積りは難易度の高いものになっていて、よくデスマーチになったり
見積もりと大きく差が出来てしまうというのは日常茶飯事です。

今日はそんな見積もりを私ならどういうスタンスでやっているのか
という事をまとめたかったので、つらつらと書き出してみることにします。

マネージャーとしてスケジュール管理をするというわけではなく
いちエンジニアが自分の身を守るために考えた内容である事には注意です。

何のために見積もりをするのか

ここは必ず抑えておくべき点です。ここを確認しておかないと
「~にかかる日数を見積もって」と言われて回答した次の日にそれが納期になる場合もあります。

ただ、事前に「納期を決定したい」とか確認を取っていれば
回答に余裕をもたせることができますよね?

これがもし「お客様に期日を伝えたい」であった場合、確認していないと
工数を伝えることになってしまい、取り返しのつかないことになってしまいます
なので、何のために見積もりをするのか、という事はしっかり確認するべき点です。

簡単に言えば、見積もりに対する考えの認識合わせをする、といったところでしょうか。

信頼関係を築く

これは処世術みたいなものだったり、社会人なら当然だろうと言われる所ですが
そんな当たり前の事であるがゆえに書かれない部分なので書き出します。

信頼関係の無いマネージャーに対して自分ならどう思いますか
そういう事です、今思ったことはおそらく信頼関係の無い相手からも思われます。
(もし何も思わなければそれも正しい反応だと思います、関心を持つことが信頼関係構築の鍵です)

見積もりはあくまでも自分の能力でやるものなので、見積もりを信頼してもらう必要があります。

しかし相手も立場があります、お客様に早くしてくれと言われている、上の人に詰められている…
いろんな事情があると思います。しかしそういった事情は信頼関係が無いと見えてきません。

時には「そういう事情があるのか、じゃあ残業して作業時間を確保しよう」という事もあるかもしれません。

自分には関係のない事だから放っておくのか、お金をもらってるから渋々やるのか
もちろん信頼関係があれば毎回残業で良いということではありません

よく信頼貯金と例えていますが、日頃の信頼を貯金して
信頼が下がってしまうような時にそこから切り崩していくという感じで使っていきます
信頼貯金があるうちは多少は上手く動くと思いますが、無くなれば終わりです。

そのため、信頼関係があればなにをしてもいい、というわけではないという事です。

マネージャー寄りの話になってしまいましたが
最高なチームの1つの要因として信頼関係はあると思っているのでこんな事を考える以前に
普段からの信頼関係の構築は密にしていくことが大事です。

期日と工数の区別をする

「これいつまでにできる?」
「1日でできます」(工数
「じゃあ明日リリースするから」(期日)
「無理です」

こういう事です。

ここらへんはよく混合します
相手が期日の話をしてるのにこちらは工数で返している場合があるので注意しましょう。
(逆もあります)

1日は8時間で考える

労働時間は基本8時間です。
1日でできます(24時間)だと大きく工数がずれるので注意する。
(24時間かかるなら4日になります)

楽観的、悲観的な工数を出す

見積もりをしている最中で「もしここが動かなかったら大きく遅れるな…
でも今すぐ検証することも出来ないし回答をして判断を仰ぐか」という事があると思います。

その場合は、特に問題なく動いた場合(楽観的)動かなかった場合(悲観的)工数を出しておきます。

この悲観的な部分はプロジェクトの不確実性を知るキッカケにもなります。

早く終わっても気にしない

出した工数通りに終わらせるみたいな事があると思いますが
私は完成したなら終わりでいいと思うんです、それは成長したって事です。

逆に喜ぶべきところだと思うんですが「前、見積もりより早く終わったから短くできるよね」
みたいな事が起こるのは否めません。これはチームとしては不健全だと思いますが…
ちなみに工数が余るとそれを使い果たそうとパーキンソンの法則が働くとのこと。

仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する

出典:パーキンソンの法則 - Wikipedia

ただ、本当にちゃんと出来てるか心配に思われるという事はあると思うので
しっかりと根拠を見せましょう。

見積もりの出し方

三点見積もりの考え方で見積もりを出すことが多いです。

三点見積もり
最頻値、楽観値、悲観値の工数を出して
(最頻値 * 4 + 楽観値 + 悲観値)/ 6をした数値を見積もりにする

これをベータ分布や三角分布で図にするとこの平均値でも完了確率は50~60%ぐらいです
最頻値はもっと低く10~20%になります、なので、楽観的な工数を出すことが大事です。

悲観値の場合は漏れがない場合に限りなく100%に近い確率になります。

終わりに

最近はアジャイル開発とかいろんな手法が生まれ
チームの能力から一定の期間のスコープを見積もる開発も進んでいるそうです。

個人的にはこちらのほうが自然と信頼関係の構築にもつながるのでいいなぁと思うのですが
従来の見積もり方法も場面によってはもちろん必要なので、上手く開発手法と付き合っていきたいです。