プログラミングで一番難しいのは「見積もり」だと思う - Qiita

前書き プログラミングで一番難しいところの一つは、「見積もり」だと私は思う。人から頼まれてプログラミングをする時、必ず最初に聞かれるのが「だいたいどれくらいで終わるか？」だ。厳しいところだと「何日に納品してくれるのか？」を問われる(むしろこれが普通かもしれない)。まっさらな状況から過去の経験を総動員してかかる時間を予想したり、可能な限りタスクに分解して時間を見積ったりするが、いつも不安に駆られる。多くの人も、見積もりに対して困難と不安を感じているのではないかと思われる。見積もりに対する自分の知識と経験を話して他の人にも参考にしてもらいたいと思って記事を書いた。 見積もりという言葉には色々な意味を含むが、今回の記事では「プロダクトをリリースするまでの期間の見積もり」から「頼まれた一つの機能の完成させるための期間の見積もり」までのスコープで話をしたい。 なぜ見積もりをしないといけないのか？ 見

[lorenz_sys]

学術的には否定されるんだろうけどベテランの経験・勘による見積が最も精度が高いと思う。なお見積を外した場合はこれまたベテランが驚異の生産性をもって間に合わせる。頭悪そうなんだけど正直そうやってきた。

[nekochiyo]

調査がらみの仕事だと、見積完了した時点で作業の9割くらい終わってることがあるのが困る

[GEROMAX]

見積もりは誤るし、途中で見直しが必要という考え方、大前提として広く認識されて欲しい。

[mikage014]

「いつできる？」と聞いてくる相手にはいつまでに何が欲しいか尋ねる。次に期限に間に合わない場合どこまでスコープを削れるか交渉する。これで期限とスコープがコントロール可能になる。ならなかったら転職。

[remoteworker]

客が払える費用の少し上からちょい下くらいの金額にすればいいだけ

[kwhrtsk]

ソフトウェア開発は大部分が本質的には製造ではなく設計なので、設計工数の根拠となる要件の大きさを定量化する手法が確立されない限り、正確な見積もりを出すことは難しいのだと思っている。

[mangakoji]

何でも2周間って答えてる。2周間分まで仕事を減らせって意味だ。どうせ2週間後には全く話が変わってる。失敗して見せなきゃ上司は理解できない

[ko-gold]

いつもの http://www007.upp.so-net.ne.jp/kengai/fowler/newMethodology_j.html プログラミングが見積可能だったら、それはすでにプログラミングではないということ(開発依頼に対する見積提示は必要だけど)

[mayumayu_nimolove]

こればっかりは経験かなぁ。プロの人はただ高度な技術を持ってることじゃなくて、自分のスキルが評価できて何をどのくらいかけて成果物を出すのかバッチリ出せる人だからね。

[kakei-akihiko]

期限を定めようとするのがそもそもの間違い。ルーチンワークで済んでいた時代のやり方を捨てるべき。

[skl0123]

見積もり

[yu_fuk]

今更感があるかもしれないが、スッと腹に落ちた。見積は経験者が経験値ベースで行うのが安全かもしれないが、それでも見積の根拠を論理的に説明がつかない事があったりする。相対性の話は参考にしたい。

[twol]

DHH先生ですら大幅に間違えるらしいからなぁ

[masaru_b_cl]

WBS(Work Breakdown Structure)とかクリティカルチェーンとか考えだすと深みにはまっていけるのでおすすめです

[yuu-yuiken]

使ったこともないパッケージを使ったカスタマイズをザックリでいいから見積もれと言われて、そのザックリで契約されてしまうと具合が悪くなる

[qtamaki]

見積もりは覚悟と覚悟のぶつかり合いだよ

[Mabuo_H]

“なぜ見積もりは難しいのか？それはあまりにも不確実性が多いから”わかりみが深い。。。ここ最近、これは自分の中にある一つの課題であると言えるなぁ。

[nakag0711]

開発は見積もれない。精度が上がったと思うならその会社はいつも似たものだけを作る「製造」しかしなくなったということ。ただ、その工数内で作れる範囲で作るというリミット設定の意味合いはある

[tetsugrande]

見積もりは大変

[teruyastar]

スクエニの2011年スライドだと「当初の見積もりはだいたい10倍になるが、仕様3分の1カット、人員60%投入、期限1.5倍、品質3割妥協、残業2倍をかけ合わせて10倍の見積もりを無理やりなんとかする」がゲーム業界デスマ

[pixmap]

ざっと頭に浮かんだ日数を２倍している。自分ひとりでやる仕事なら、これでだいたい余裕持って処理できる。

[miyaaan]

普段のプログラミングに関する話題だとマウントとるブクマカが大量に湧くのに、見積もりの話だと意外とコメ欄がおとなしい。あれか、はっきりと〇〇だと言えない微妙な話題になるとおとなしくなるのか。

[rasterson]

ソフト開発は、今無いものを作るから、見積もりが難しい。（今あるなら、コピー一発）半完成品の組合せと設定で要件満たせるように方向付けすると見通し良くなるよね。それを目指すのが良いと思ってる。

[yarumato]

“アジャイル開発「ストーリーポイントとベロシティ」見積もりを紹介。人は絶対評価よりも相対評価の方が精度が高いので作業Aと作業Bの相対で。ベロシティでSPを時間に変換。進捗共有はバーンダウンチャート”

[kumazooo]

勘による見積もりが割と当たるのは、営業のスタンスや会社の方針、開発チームの状況を考慮した上での見積もりになるからだと思う。取引先の無茶振りも想定出来ると、更に精度が上がる。

[ysync]

なぜ請負なのに、出来たら納品しますねお金くださいじゃダメなんでしょうか？

[yk4192]

それ

[tg30yen]

関係者が依頼者と開発チームの2つしかなければ納期を明確にしないやり方でもいいかもしれないが、実際はプロジェクトの関係者は他にも多数いる。経営陣にいつ終わるのかを伝えないなんてできるはずない。

[cuttoff19]

アジャイルサムライにこういう話あった気がする。またちゃんと目を通しとこう。

[nn0]

上司には「3日～5日です」と言いつつちょこちょこ報告入れて修正してる。そうじゃなければKKD手法かな。。。

[circled]

貰った内容の見積もりは出来るのだが、物を見た段階であれこれ追加要求が発生して、それを対応するなら遅れるという場合がほとんど。仕様が一切変わらない確約を元に、見積も正確さを増す。

[jorira]

わかりみ。

[knitcapmann]

見積りを属人的な作業の積算のみで考えると不幸にしかならないし、顧客もなかなか納得しない。見積りは商売の話なのですよ。

[strow0343]

自分の作業速度は自分しか知らないので経験則になりがち。後はどれだけバッファを確保できるか

[comitlog]

見積もりが「プログラミング」に含まれるっていう発想はなかった。斬新な線引き。

[kknsd]

「アジャイルな見積りと計画づくり」を読まずしてこの手の話してる悪いごいねがー

[findup]

経験・勘・度胸で見積もりなんてSIerしかやらないだろｗwみたいによく馬鹿にされてたのを見かけてたけど、ブコメ見るとSIer以外でもそうなん？

[versatile]

そうだね

[tohokuaiki]

見積りが難しいのは方法面ではなく精神面。外すかも…というストレスが半端ないんだよ。だれも責任を負いたくないから。

[sen47]

そのプロジェクトに対する不確定要素そのものよりもその他のサポートとか社内対応とか営業同行とかが多すぎて期間としての見積ができない。みんなどうしてるんだろう