そのソフトウェア、いつまでに出来る？

そんな簡単に工数見積り出来たら苦労はしてませんっ！（笑）

って言うと終わってしまうんですけど、それではアンマリなので、yasuhoなりの考えを書いてみますよ。

オラクルのシニアソフトウエアエンジニアであるSuvro Upadhyaya氏が、プログラミング時間の見積もりに関するブログエントリをIT worldに寄せている。同氏の経験では、スクラムが一つの有効な手法であるという。しかし、しっかりした開発チームであっても正確な見積もりを出せるようになるまで6カ月ほどかかることもあるそうだ。
Upadhyaya氏曰くプログラミングにかかる時間を正確に見積もることは、限界を明確化するプロセスであるとのこと。プログラマーの経験や知識、スピードと質の兼ね合いなどさまざまな要素が関わっており、チームや組織のカルチャーに依るところも非常に大きいという。
/.の読者はどのように見積もりを出しているだろうか？

プログラミングにかかる時間、正確に見積もるには？ | スラッシュドット・ジャパン

以前ほとんど同じことを書いてるので「前に読んだ」って人はここでストップしていただいてもいいかと。:)

いわゆるバッファというやつ

本家/.には「かかると思われる時間を2倍にして、時間の単位を一つ繰り上げる。2日かかると思ったら4週間、1週間かかりそうなら2ヶ月、という具合に」なんて方法も挙がっているが、/.J諸兄方の見積もりの出し方は？

ここまで極端ではないにしても、私も多めに見積もりをすることがあります。Best caseならどのくらい。Worst caseならどのくらい。というパターンもあるかも。

この業界の方ならご存知のように、工数見積りって本当に難しいです。その大きな要因はソフトウェア作成が基本的に手作りであることと確立された開発手法が存在しないことにあります。開発を助けるための開発技法やツールは多く存在しますが、最終的には人間が毎回アルゴリズムを考えて作っているわけで、そこにバラツキが生まれてくるのは当然とも言えるでしょう。さらに自分のならまだしも、プログラマのリーダーが見積もりするなんて考えたら・・・

だから工数見積りは乱暴に言ってしまえば、経験とカンによる「どんぶり勘定」にしかならないのが実情。なので、経験豊かなプログラマほどバッファ、つまり「安全ライン」を多く取る傾向があるようです。

でも本当にそれでいいの？

ある優秀なプログラマがこう言っているのを聞いたことがあります。「バッファを多く取りすぎることは良くない」と。

氏曰く「バッファを取ることでプロジェクトに与えるインパクトを減らせるかもしれないけど、かわりにプログラマは油断してしまって、innovativeなプロダクトを産みにくくなってしまう」のだそうです。それは確かにそうかもしれない。人間ある程度追い詰められた方がいい物が出来る可能性が高いもんね。

でもあまりにもtightなスケジュールだとプロジェクトに迷惑をかけるかも。そう思って多くのプログラマはより長めの見積もりをすることが多いのではないでしょうか。あるいは「結局遅れの責任取らされるのは自分だから」と考えるというケースもあるかもしれない。

そもそもバッファって何だろう、って考えていくと

プロジェクトチームの環境にもよるような気がします。開発期間を大きく見積もりたくなる状況ってどんな時ですか！？もしかして、プロジェクトチームの雰囲気が悪かったりしないですか！？「どうせ責任取らされるのは私」みたいな。

「いつまでに出来る」言う方も言われる方も、最終的には信頼関係だと思うのです。ソフトウェア開発は予定通り進まないことがほとんど。正確に期限を図ることよりも、スケジュールが遅れた時にリカバリーする体制づくりの方が重要だとyasuhoは思うのです。