プログラミングにかかる時間、正確に見積もるには? 142
ストーリー by makeplex
1人月と1人月を合わせて2人月!!いつもより2倍残業して4人月、そして休日出勤をすれば4人月*3、これが工数を上回る12人月だーっ! 部門より
1人月と1人月を合わせて2人月!!いつもより2倍残業して4人月、そして休日出勤をすれば4人月*3、これが工数を上回る12人月だーっ! 部門より
あるAnonymous Coward 曰く、
本家/.「How Do You Accurately Estimate Programming Time?」より。
オラクルのシニアソフトウエアエンジニアであるSuvro Upadhyaya氏が、プログラミング時間の見積もりに関するブログエントリをIT worldに寄せている。同氏の経験では、スクラムが一つの有効な手法であるという。しかし、しっかりした開発チームであっても正確な見積もりを出せるようになるまで6カ月ほどかかることもあるそうだ。
Upadhyaya氏曰くプログラミングにかかる時間を正確に見積もることは、限界を明確化するプロセスであるとのこと。プログラマーの経験や知識、スピードと質の兼ね合いなどさまざまな要素が関わっており、チームや組織のカルチャーに依るところも非常に大きいという。
/.の読者はどのように見積もりを出しているだろうか?本家/.には「かかると思われる時間を2倍にして、時間の単位を一つ繰り上げる。2日かかると思ったら4週間、1週間かかりそうなら2ヶ月、という具合に」なんて方法も挙がっているが、/.J諸兄方の見積もりの出し方は?
直感×3倍でつ (スコア:4, 参考になる)
今までの経験則で、自分が直感で思ったのと実際の工数というか時間を計算してみるとこうなりました。
直感 ×1 = 無ゲー
直感 ×2 = ややデスマ
直感 ×3 = 余裕をもったスケジュール
他の方はどんなもんでしょうか。
by rti.
Re:直感×3倍でつ (スコア:3, 参考になる)
まったく同感です。自分も見積りを出す時に何度も悩んで、経験則で直感×3という結論に至りました。
恐らく、直感で出した工数って、「作業が滞りなく、サクサク進んでいる状態の1時間」が基準になってると思うんですよ。で、その勢いで「1日10時間、休憩も休日も無く作業し続けたら、これくらいで終わる」ってのが、直感の工数だと思います。
だがしかし。
ずっとモニタに向かっていれば済むわけでもなく、会議や打ち合わせ、その他諸々の割り込みタスクが入ります。これが結構、時間的ロスが多いです。また、ドキュメント作成もそれなりに時間を取られます。ここまでで、おおむね直感×2の状態に。
更に、人間には休息が必要です。飯も食うし、トイレにも行きます。1ヶ月で考えたら、1日も休みが無いというのは、しんどいです。また、常にサクサク行くとは限らず、仕様が甘くて試行錯誤してしまったとか、自分の能力不足で上手く組み上がらないとか、単純ミス(ミスタイプ、変数名を間違ってるとか)もそれなりに発生します。これで、おおむね直感×3の状態。
直感そのままの工数は、短期決戦(数週間とか)で終わるような超小規模のものなら、出来なくは無いですが、1ヶ月以上の規模でこれは論外です。止めるべき。
直感×2の工数だと、人間としての生理活動を無視している状態なので、肉体的精神的に辛いですが、成果物はそれなりのものになると思います。これが連続すると、非常に辛くなりますが。
健康的に働くなら、やはり直感×3は欲しいですね。健康を犠牲にしてまで働くというのは、長い目で見ると損ですが、今の企業はそんな視点で経営を考えてないっぽいので、どうしてもここが犠牲になりがちなんですよねえ。
Re:直感×3倍でつ (スコア:2)
はい。私も直感の3倍です。
Re:シャア!!! (スコア:1, おもしろおかしい)
「計ったな!シャア!」と言いたいわけですね?
Re:直感×3倍でつ (スコア:2)
まさか・・・
直感=コーディング時間
実際=設計時間 + 上記 + テスト時間
じゃないでしょうね?
Re:直感×3倍でつ (スコア:1, おもしろおかしい)
うちの会社のある人の見積もり。
に対するAさんの評価
「3倍しないとだめ」
に対する私の評価
「いや、5倍でちょうどくらいかな、と」
に対するBさんの評価
「10倍かかるよ」
に対する社長の受注工数
1倍
# だからだよ!!!!!
つまり Scotty 原理に基づくメソッド (スコア:3, 参考になる)
自分が100%のパフォーマンスを出せて、予想外のライブラリのバグとかがない前提の見積り x 2 ですね。
仕様がフワフワしてるなら、さらに倍。あとは感覚で日にちを足します。減らすことは絶対にありません。
10倍はしません。4週間以上の見積りは細かく分解するので。
本家でもScotty 原理だって言ってますが、宇宙大作戦から学んだもっとも役に立つテクニックです。
上司に提出した見積りよりもいくらか早く仕上げるのは言うまでもないです。
本当に、驚くほど正確。いやほんと
Re:つまり Scotty 原理に基づくメソッド (スコア:1, すばらしい洞察)
言ったろ? できるエンジニアってのはギリギリの数字は言わないもんだ。
TNG130話で発した彼のセリフは、正確な見積ができるからこそ言える言葉なんだよな……ってことを、
工数計算でサバを読んだはずなのに、なぜかお尻に火がついた状態に陥ってしまう度に思ったものです。
Re:つまり Scotty 原理に基づくメソッド (スコア:1)
「様々な規約に準拠して作業を行うと、1時間ですむことに1日かかってしまいます。」
みたいなのはSpock原理と言わないのだろうか。
Re:つまり Scotty 原理に基づくメソッド (スコア:1)
まあ暗号と言えば暗号だけど、この暗号が「日常会話にしか見えない」からこそ暗号になりえるわけで。
「今度のプロジェクトはとても順調だよ。プロマネの計画通りに進んでいる。」
「PMBOKのおかげだね。HAHAHAHAHA!」
みたいな不自然な会話をしていれば、「怪しい。きっと何か裏があるに違いない。」と思うでしょ?
Re:つまり Scotty 原理に基づくメソッド (スコア:1)
>裏があると思われたら暗号になりません。
うん。だから「様々な規約に準拠して作業を行うと、1時間ですむことに1日かかってしまいます。」で正しいのです。
この時のみ暗号として使われているけれど、これは同時によくしられた原理なのだから。
>これ以上無理しないでください
いや、それはそのままあなたの話なのだが?
理解できないからって無理しなくてもいいのに。。。
Re: プログラミングにかかる時間、正確に見積もるには? (スコア:3, すばらしい洞察)
プログラミングには定型的なプログラミングとそうでないものがありますのでねえ。前者なら見積もり可能でしょうが、後者を見積もるというのは、少なくとも開発初期においてはナンセンスでしょうな。
元記事の筆者はOracleの方のようですが、OracleのRDBMSを作るのは後者、それを使った業務アプリを作るのは前者。どちらの話をされてるんでしょうか。
意味があるのか?精度って? (スコア:2, すばらしい洞察)
プログラミングだけで時間をはかっても意味ないだろうね。
要求案件から仕様の策定、基本設計から詳細設計、そしてプログラミングで、デバッグ、テストとユーザ確認、さらには検収の上、運用判定とかね。
その中でプログラミングは前後どちらからも変更や差し戻し手戻りを要求されるところなんだ。
だから、そこだけ単体でどれだけといっても、意味はそれほどないと思う。
また、精度を高くしようとしても、プログラミングの技巧などプログラミング自体の差がありすぎる上に、はさまれている前後の精度/正確さや速度に影響されやすくて、無理だろうね。
それこそ、「かかると思われる時間を2倍にして、時間の単位を一つ繰り上げる。2日かかると思ったら4週間、1週間かかりそうなら2ヶ月、という具合に」みたいなのが出てくるわけだよな。そもそもの「かかると思われる時間」の根拠が希薄なんだ。
Re:意味があるのか?精度って? (スコア:4, すばらしい洞察)
仕様変更や、上司に説明するための会議の時間、さらにはスパゲッティプログラムを解読する時間を
忘れてもらっては困りますな。
それに比べれば、プログラミングにかかる時間の差なんて誤差みたいなものであることも。
Re:意味があるのか?精度って? (スコア:1)
>仕様変更や、上司に説明するための会議の時間、さらにはスパゲッティプログラムを解読する時間を
>忘れてもらっては困りますな。
そうですねぇ、プログラミングじゃない時間が多くて、
さらにそれがプログラミングの時間を伸ばす方向に作用する場合が多いですね。
>それに比べれば、プログラミングにかかる時間の差なんて誤差みたいなものであることも。
ええ、それは重々,,,
ほかにもまだまだたくさんありそうですね。
http://labaq.com/archives/51391927.html [labaq.com]
部門名 (スコア:2, 参考になる)
語るなら、本文でやらないか?
....ピリっとしたのを希望。
じゃ、同じ筋肉系で。(元ネタはマンガじゃないけど) (スコア:5, おもしろおかしい)
「1人月+1人月は2人月じゃないぞ。弊社は1+1で200人月だ。10倍だぞ10倍」
人数を増やすと効率は下がる (スコア:5, 興味深い)
したがって、2人月の仕事に二人アサインしても1ヶ月では終わらない。
これはもはや常識
って思ってたんですが、PMPとかいうマネジメントの資格を持ってる人達には常識じゃないってことが最近判明しましたよ。
Re:人数を増やすと効率は下がる (スコア:3, 興味深い)
ざっくり見積もりだと、だいたい√(人数)くらいが平均的かなと思っている。
3人月の作業を1ヶ月でやるには9人は必要、となるけど本気で1ヶ月で終わらせるためにはそれくらいかかるな。
どうせ集めたリソース全員が全員エキスパートなわけないし、人数が多いほどチーム間の連携や調整のために動く人が必要になってくるからコード書けない人も出てくる。
営業は「そんなわけないだろ、せいぜいプラス1名くらいだろ」というが、そんなもんですと答えている。
でも実際にはそんなに人員も期間も貰えなくて、開発が始まるとデスマで購うことになるのだが、原価に含まれてない闇残業分の労働が粗利益になっているんだよね。
何とか仕事を終わらせても、それが実績となって次の仕事ではそれが当たり前になって、同じ仕事をするわけではないのに更にハードルの高い(原価のお安い)見積もりを求めてくる。
コストのほとんどが人件費の仕事ほどデフレが厳しいねえ…。
Re:人数を増やすと効率は下がる (スコア:2, 興味深い)
やっぱりこんな感じなんですかね。
>1. 営業が赤字案件を取ってきた.
>2. 開発が月100時間残業でなんとか間に合わせる
>3. 営業は次からは残業100時間込みで見積もりするようになる.
>4. 残業時間が200時間,300時間と増えていく.
>5. 開発メンバーが辞めはじめる.(今の産科医療はここ.)
>6. 会社が潰れる.
http://remote.seesaa.net/article/62499486.html [seesaa.net]
>コストのほとんどが人件費の仕事ほどデフレが厳しいねえ…。
というより、「価格以外の差別化要因を提案できない経営者が無能」ってだけの、ごく普通の話では?
Re:人数を増やすと効率は下がる (スコア:3, おもしろおかしい)
fj.jokes出身:
Re:人数を増やすと効率は下がる (スコア:2, おもしろおかしい)
ワークシェアリングという名目の時短休日の日に、
グループ会社n万人で一気にやれば一日で終わると提案してみたんだけどなぁ。
さすがに真に受ける人はいなかった。
Re:人数を増やすと効率は下がる (スコア:2, すばらしい洞察)
プロマネの計算には、「量」のパラメータはあっても「質」が入ってないことがあったりする。
しかも人数を増やすと、現実世界では人材の質が落ちることも多いんだよな。
優秀な人材一人でやるのに対し、優秀な人が一人にそこそこの人を9人追加した十人でやるのでは
5倍も出れば良い方でしょう。これにさらに低レベル人材90人を追加した100人でやる場合は逆に
遅くなることも珍しくない。ましてn万人となるとね……。
「優秀な人材は無尽蔵」という仮定がプロマネの願望にすぎないと、なぜ気付かないんだろう。
Re:人数を増やすと効率は下がる (スコア:2)
PMだって、既定の手順に従って、既定の数式使うしか脳が無い馬鹿が多いから。
いや、馬鹿と言っちゃ、○○馬鹿と尊敬されている人と同列に扱われそうで可哀想か。
fj.jokes出身:
Re:人数を増やすと効率は下がる (スコア:2)
あるプロジェクトが火を噴きそうになった。
プロマネがゲイツのところに行って、メンバーを増やしてくれと頼んだ。
「チームには何人いるんだ?」
「11名です」
「よし、わかった。月曜までに何とかしておくよ」
プロマネが月曜に出社すると、メンバーが2人減らされ、9人になっていた。
という話(真偽は不明)を思い出した。
Re:じゃ、同じ筋肉系で。(元ネタはマンガじゃないけど) (スコア:1)
人月計算にすら相当な期間が必要だということ。
その問題は解消するのに7年かかったそうだ。
http://leglock.cocolog-nifty.com/kojilog/2006/11/post_2663.html [cocolog-nifty.com]
Re:1+1=0.5 (スコア:2, すばらしい洞察)
最悪の要員を割り当てるのが最悪の仕事なんでは。
見積りと呼べるだろうか (スコア:2, すばらしい洞察)
Re:見積りと呼べるだろうか (スコア:1, すばらしい洞察)
まぁフィクションポイントになってるほうが多そうだがな。
神はまず初めに納期を作られた (スコア:2, 興味深い)
元請や発注元ならともかく、下請けだと
「まず納期ありき」で、最初から納期が決まってるうえに
要求される技術レベルの人材をいきなり集めることもできず、
なし崩しに後ろから各工程の期限を決めることになるので
見積もりというものに意味が無いというか、
嘘であることが確定してる見積もりを毎回無理でっちあげる、そんな状況ですが……
Re:神はまず初めに納期を作られた (スコア:1)
仕方がないから実装機能に優先順位を付けて第1フェーズ・第2フェーズみたいな
感じで交渉するように依頼しても,お客は頑なだし.営業は営業で目の前の金に
目が眩んで,調整する気がなさそうだし.
困ったもんだ.
Re:神はまず初めに金額を作られた (スコア:2)
とか恐ろしいことを考えたりもしますが、無い袖は振れませんし、プロジェクトマネージャ資格持ちなんかが率先してそーゆー状態を作り出す姿しか見たことが無いので、なるようにしかならんのでしょうな
fj.jokes出身:
ああ、なるほど (スコア:1, すばらしい洞察)
1年かかりそうだと思ったら、実際は2世紀かかるわけですね。
"Duke Nukem Forever"がいつまでたってもリリースされないのはそういうわけかぁ。
デスマーチ (スコア:1, すばらしい洞察)
誰が最初に工数計算したのかわからないが、ちゃんと見積もれてないのは確実。
自分ができそうな時間 * 3 * (人数) ^ 0.5 (スコア:1)
正確な見積もりにかかる工数は? (スコア:1)
本当に正確にするには、全ての起こりうるトラブルを考慮しないといけないので、
実際の作成作業よりも、多くのことを検討しなければならない。
従って、実際の作成作業よりも、見積もりを作成する工数の方が大きいこともある。
そして、正確な見積もりの作成にかかる工数を見積もる工数を、さらに考えると・・・・
かくして、永遠に正確な見積もりは、作成できないのであった。
典型的な、仕事のできないやつの陥るジレンマである。
見積りなんだから (スコア:1)
粒度を揃えた仕様数に単位時間辺りの LOCを掛ければ良いのでわ?と常々思っているんだけど、これがむづかしくてねぇ...
まぁ、これで計算出来るのはプログラムの作成に必要な時間の見積りだけで、それ以外の工数をどう見積るかは色々と大変なワケで...
見積もるのか? (スコア:1)
提示のために計算するのは欲しい金額じゃないの?
あっそうかリスクとして実際のコストを考えるって話か
でも結局人がいる分しか出来ないんだよね 何百人いても
だったらコストを正確に考えるより
見積りの条件(根拠ではない)を考えたほうがましでは?
Re:簡単 (スコア:3, おもしろおかしい)
7.ちょっとここ直してね
8.ですまです
Re:単位を繰り上げるのはアレとしても (スコア:1)
Re:倍率ドン、さらに倍 (スコア:2, 興味深い)
プログラム修正は簡単に終わっても、仕様変更が与える影響範囲は工程が後になればなるほど大きくなるでしょ。デグレのチェックなど試験工数が多くなるはず。30倍で出してきた他社はちゃんとリスクを取ってたんじゃないの?
Re:倍率ドン、さらに倍 (スコア:1)
> 1日でできる仕様変更を10日で見積もり出したら、他社が1ヶ月で出してきて
> 我々がやらされる羽目になったという笑い話のような事が最近起きたのでAC。
> (30倍はさすがにひどいだろう・・・)。
1ヶ月を30人日で計算しているのも、大概ひどいと思ふ。(まぁお約束だけれども)
Re:書いてみないと分からない (スコア:1)
記述性の高いプログラミング言語による実装にかかる時間とは、だいたい等しい。
言い換えれば、プログラミングに際して頭を使わない単純作業の比率が高いほど、
全体から見てアフォーダブルな工数で、精度の良い見積りを得ることが容易になる。
Re:ほらね (スコア:1)
>こうやって、政府のIT事業にかかるコストが出されてるんだ。
え?どうやっているの?
> お前らも同じ穴の狢だったんだな。
いや、いろんな意見が出ているので、誰がどの狢と同じ穴にいるか、わからんよ。
Re:ほらね (スコア:1, おもしろおかしい)
Re:KKD (スコア:1)
計測、仮説(or解析)、データの3つで。
でも、データ計測してたら査定につながるのでNGと言われてしまいました。
査定にはつながるかもしれませんがそれが全てじゃないでしょとか思ったのでID
Re:日本のIT産業、しょせんこんなもんか (スコア:1)
Re:日本のIT産業、しょせんこんなもんか (スコア:1)
>なぜそれらに関する議論が無い?
理由は実に簡単。実用に足るだけの見積もり法が、未だに存在しないから。
ソフトウェア開発の見積りに関してその歴史は無駄に古い。
しかし、それに成功した事例は未だ報告されていない。
Re:しょせんこんなもんでしょ (スコア:1, 興味深い)
そこで経験と勘をモデル化するCoBRA法ですよ…と関係者から聞きました。
agileなんかでも対応可能だとか。ご指摘の不可抗力もモデル化したうえで見積りできるらしい。
諦観ばかりじゃなくて、新しい試みにも挑戦してみてはいかがでしょうか?
Re:このジグソーパズルは (スコア:2)
たぶん、適当においてもパズルは完成しないことに気がついた時点じゃないかな。
#つまりプログラミングの場合は、製造工程がけっこう進んだ後…