ソフトウェアの見積もり - kawasima
ソフトウェアの工数見積もりは40年以上にわたって研究されてきた古いテーマで、入門書も実践書も数多い。だが現場で広く流布する「常識」の多くは、一次資料まで遡ると実証根拠が確認できない。確率分布が書ける前提で精度を磨いてきた見積もり研究は、確率...
nguyen-oi見積もり手法の歴史からLLM時代の影響まで網羅されててクオリティ高すぎる。結局、不確実性のコーンにエビデンスがなかったって話が面白い
2026/07/07 08:39
otihateten3510ゴールポストが動くので複雑度が異次元になってるよね／ "その平均超過は447%である" バッファを5倍もればOKってことかｗ ／確率的に求めるのは良いかも、活用してみたい→計算したら1.2倍に収まるのがたった49％だ
2026/07/07 09:19★★★
crexistあれ、前もブクマした気がする
2026/07/07 09:39
ultimatebreak直感タイプだったけどAIでもう見積もりなんもわからんなった
2026/07/07 09:49
nuaraべき乗になるのは、中抜きがいるからでないか。知らんけど。
2026/07/07 10:17
shindo_ryo実績時間の分布が右に寄るのってソフトウェア開発の不確実性もありつつ、与えられた期限いっぱいに仕事が増えるというパーキンソンの法則の影響もありそう
2026/07/07 10:49★
sayuremix3段階目のバッファとしてAI要因バッファを乗せてみたらどうなるだろう。AI使用で減った分の工数と現時点ではとんとんになりそうな気がする、肌感でしかないけど。
2026/07/07 11:02★
cinq_na基本は客先の指示と値切りに合わせる。一応感ピュータでも見積もって、大差無いようにする。結局はトラブルで計算は破綻する、自分のミスか相対側のミスかはさておき。
2026/07/07 11:10★★★★★★★
bijui人は正しく見積もることはできない。正しく見積もれるのであれば争いなど起きない。
2026/07/07 11:17
petite_blue「見積もりが大幅に外れる事象の多くは列挙できない不確実性の層から来る」「大幅超過を引き起こす事象の多くは、見積もり時点で考慮対象に含まれていなかった事象」
2026/07/07 11:26
daishi_n「正確な見積もり」は詳細設計と同じだから見積もり費用で作れちゃうのよね。あとは検収、リリースや非機能要件とか発注元と提案側のスコープ齟齬、発注後の追加機能、追加要件かな
2026/07/07 11:41★★★★★★★★★
jerryb「実際のプロジェクトで大幅超過を引き起こす事象の多くは、見積もり時点で考慮対象に含まれていなかった事象である」
2026/07/07 11:48
strawberryhunter真剣に考えるのが馬鹿らしくなるくらい当たらないから、私は顧客にはソフトウェアの開発費用の見積は不可能だと言っている。金額だけ独り歩きして、お互いのためにもならない。
2026/07/07 11:49
Falkyこれこそまさしく科学の敗北史だ。形式的見積手法の発明というのは結局のところ「人類は神ではないので不確実な未来を予知できない」という当たり前のことを永久に検証し続けているだけに過ぎない
2026/07/07 11:53★
hiroyuki1983客の予算ギリギリが見積もり金額だぞ。作業内容はそこから逆算して考える。多けりゃ減らすし足りなきゃ盛る
2026/07/07 12:13★★★★★★
kanjouconvoy非IT分野でも参考になりそう。
2026/07/07 12:25
spray_donuts_3coクライアントが代理店に発注する構図が大半である限り、末端の見積もりに科学など存在しないよ…
2026/07/07 13:11★★★
devgaiやることが小さければ当たるけど大きくなるほど金額を小さく納期を短く見積もりして外れる。ソフトじゃないけどオリンピンク、万博、ダム建設など世界中の公共事業が予算オーバーで納期過ぎてるんじゃないか
2026/07/07 13:36
zZwIwlあれなんか最近同じような記事を見た気がするけどなんだっけ
2026/07/07 13:44
thorthewind分かりました。正確なお見積りをお作りいたしますので、当初のシステム開発の見積りと同額をお支払いください。
2026/07/07 14:22