ソフトウェア開発の見積もり入門

見積もりとは？ Wikipediaによると見積もりとは、以下のようにあります。 見積（みつもり。見積り、見積もりとも書く）とは、金額・量・期間・行動を前もって概算すること。見積もること。あらましの計算をすること。また、その計算。目算。「所要時間を見積る」、「一日の来客者数をざっと見積もった」など、おおよその感覚で数字の見当をつける場合の口語体表現でも使われる。 Wikipedia このように見積もりとは、なにかを行う前に事前にその結果を予想しておくことを言います。 見積もりを使うケースは、ソフトウェア開発に限った話ではありませんが、製造業であるソフトウェア開発においては『見積もり』というタスクは様々なケースで登場します。 見積もりが苦手な人は多い ソフトウェア開発では、「この機能を開発するときにどのくらいで完成できますか？」といったケースが見積もりのシチュエーションとしては多いかと思います

[yuu-yuiken]

ざっくりで良いからって出した見積もりが正式になっててかつ通るから嫌なんだよな

[toruhjp]

おおむね同意。誠実だと思う。ただ「バッファ」なる呼称によって説明に苦労することもあるため、「想定外のニーズやトラブルに対応するための品質向上期間を〇〇日確保したいです」と伝える手もあるよ！

[daishi_n]

見積もりの前提条件作るのだってカネかかるし、「正確な見積もり」は設計工程を代替してしまうからアホみたいにコストかかる

[headacher2]

SIer時代だけど安く出してコンペ勝ちたいからかバッファはなんだかんだケチつけて削られるわ超優秀な要員ベースで人月計算させられるわそれで出した見積もりで遂行を迫られるわ（確実に不可能）で毎回炎上してたな

[lorenz_sys]

自分も概ね同意だが見積の前提事項を顧客に対し明示しそれについてコンセンサスを得ておくことを追加で提唱しておく。前提が崩れたら見積は成立しなくなることは当然だけどお客さんはそういうことすらご存じない。

[ppppchan]

「見積もりの精度は経験の量に比例する」これは真面目な人が陥りやすい罠で、実際にはタスクの優先順位に大きく依存する。タスクの構造はスタックではなくてプライオリティキューで考えるべき。

[kanehama]

受託だとバッファは説明しづらいわな…営業ちゃんとうまくやってくれ！！と昔は思ってたけど営業に気付かれないようにバッファ盛ることが大切であると学んだ。

[mouki0911]

本当にもっとコスト抑えられるだろ圧力をなんとかしてほしい。

[d6rkaiz]

後から後から新事実が発覚するような案件だと辛いのは変わらない。

[circled]

早く作ると「ここにxxな機能作れますか？」と聞かれ、追加料金になりますと言うと文句を言わずにお金を払うお客さんしか存在しないなら、適正な見積が存在できる世界線に行けるはず。君は今何回目のループ？

[cumin02]

自分の作業見積もりは問題ないけど、初心者や仕事できない人の見積もりが難しい。あと日程感ない人。

[Keisuke69]

見積もりって必要悪だよな

[edechang]

顧客がめんどくさいタイプでもバッファを多めに取る

[miau]

「徒歩で会社へ通勤している人の通勤時間を見積もる」の例は見積もりがあまりブレなそうなので、不測の事態が起きやすい電車通勤とかのほうがイメージに近いかも

[imwks]

これなら簡単にできそうって思っても実際手を付けると思いの外難しいってのがすんごいある / 毎度まいど同じものを作ることは無いから結局はうまく見積もれないよ・・

[snare_micchan]

すごいざっくりとした説明だこと。裏に物凄い分量のプロセスがあるんだけどね。だからCMMIでは見積もりが一つのプラクティスエリアとしてリスク管理や要件管理などと同じポジションに置かれている

[moronbee]

個人的な経験からすると、アジャイルな見積りと計画づくりの50%見積と90%見積からバッファを出す二乗和平方根法推し。

[soratomo]

「バッファで上乗せしたぶん、上手にプロジェクトが進んでパーフェクトにリリースできたなら、請求の時バッファのぶんは安くなるんよね？」という上司とかいそう。

[carrier_pigeon]

客に出す見積なのか自社開発でＰＬとして出すのか担当として出す見積もりかで状況変わるのでコメもバラバラになるね。画面とかはFPとか画面点数で見積もれるけど未知の分野はプロトタイピングとか工数に入れたいね。

[pavlocat]

手を動かす前に見通しを立てる時間を取る、というのが重要な意義かと思ってる。それによってタスクが具体化されて作業漏れや非効率な作業を低減する効果があると思う。場合によっては何回か分けてやるのも良い

[yuangao]

自分が気をつけてたのは前提条件を明示する、難易度やFP等説明可能かつ再現可能な方法で見積る、要件や概要固まった段階で同じ方法で再見積する（当初に再見積する旨説明する）だな。見積で躓くと赤字デスマ不可避。

[hdampty7]

まず、縦に作業項目を思いつく限り書く。その横の列にどれくらい工数がかかりそうか数値を入れていく。実際にやってみて参考にするのもよし。あとはそれを足し合わせて世にも不思議なマジック係数をかけておしまい。

[sjn]

機械学習ソリューションに丸投げしたい、というかなんでそういう方向になってくれないのかこの国の業界は…

[irimo]

メンバーに言う見積りと、実際考えてたり先方に示したりする見積りを変えるのは普通のテクなんですかね。長いと前半だれます。だれるのがある種の息抜きというか、前走なのかもしれないですが。

[uva]

一点見積もりがよくない。見積もりは確率分布の曲線になる

[t1mvverr]

"見積もりはあくまで予想なので、合意さえとれていれば結果はそれほど重要ではないのです。(もちろん正確に見積もれるに越したことはないですが。)"

[nakag0711]

10年前から何も進歩せず同じようなものばかり作っていれば見積精度は上がる。その会社が10年後も存在しているかは疑問だが／結局のところ、受託開発の見積とは発注者との間のリスク分担の問題でしかない

[taguch1]

見積もりを頼んだ人が読んでください。見積もりの前提を理解してもらうだけで日が暮れる。

[gabill]

受託か自社サービスかでだいぶ違ったなぁ。受託の時は『要件をガチガチに固める』or『仕様を調整できる関係を築く』or『最悪のケースを想定して見積もる』の３択だった。

[ledsun]

「不確実性コーン」の概念は半世紀以上前からある。義務教育で教えよう（高校生くらいでいいかな？）

[uxoru]

見積もりなんて、永遠にわからん！！！

[y_as]

「不確実性コーン」というものがあってな。 個人的には納得感が高いんだが、納得してくれる客ってのはついぞ出会ったためしがないんだなあ。

[frkw2004]

「見積もりは外れる」なのに見積もり分までしか払わない。前提が間違っている。 過大に見積もりしたときに実際の支払いが安くなることがないからか？

[tpircs]

見積もりは確率の話だって思ってる。納期に対して何%の確率で作れそうか、をどう設定してるかで数値が大幅に変わる。

[knosa]

見積もる側が優位な場合はいくらまで払えるのかの予算を先に聞くのとどのくらいの期間でお願いされたら嫌じゃないのか、嫌なのを我慢するのにいくらもらえれば良いのかを自分と相談するだけなんだよな

[anus3710223]

非ITだけどいつそういう部署に飛ばされるかわからないし、契約とかまだまだ勉強中で仕様とか見積もりとか何が適正かわからへんから助かる

[taruhachi]

正確な見積もりには正確な要件定義と設計が必要で、まずはそれを屏風から出してください案件。

[mohno]

“他人の分”まで見積もった事はないけど（←絶対やりたくない）、見積もりは大変だよね。引き受けることになりそうなら、ちょっと手を付けてみる、ということすらある。

[strawberryhunter]

要件の中の見積額に影響を与える落とし穴は近付かないと見えない。近付くにはコストが発生するので既製品販売のような見積もりができない。／弊社は値下げに耐える企業体力が無いので逆に弊社の言い値で仕事してる。