見積もりが甘い

質問

スケジュール通りに仕事が進まないと、「見積もりが甘い。」と言われてしまいます。スケジュールがきついのだと思うのですが、正しく見積もるには何に気をつければいいのでしょうか。

回答No.5

mf2-256hd · ベストアンサー

「見積もりが甘い。」おっしゃっている方は論点がずれています。
これは、スケジュール管理ができていないので見積もりとは切り離して考えた方がすっきりすると思います。

従いまして、スケジュール管理がまずいのだと思われますので、完了までの要所、要所でスケジュールの見直しを入れてみてはいかがでしょうか。

お礼

その通りです。聞き違いだったのか、勘違いだったのか。スケジュール管理する時間が勿体なく、仕事そのものの方に時間をかけてしまいますが、スケジュール管理したほうが能率が上がるのでしょうか？ありがとうございました。

回答No.9

angband

プログラム仕様書に基づいて作るにしても、ある機能が
あるプログラマに何日でできるかなどというのは、
根本的には計算できるわけがないと思います。

ましてや本人にわからないものを、別の人(SE)が
スケジューリングするなんて、うまくいく可能性の方が
少ないでしょう。特に開発経験もないようなSEや
管理職のオジサンでは・・悲惨なことになりますね。

本当に管理できるものなら世の中のプロジェクトに
これだけデスマーチが多い説明ができません。

ただスケジュールを聞かれた場合は事情が違います。
「何日でできるか？」と聞かれて、自己申告した場合は
遅れてしまうと「見積もりが甘い」と言われても
仕方がないと思います。

ルーキーだった時に先輩によく言われたのは「できると
思った日数 X 2 + α」かかる、ということです。例えば
もし問題なく作業が進めば3日でできる機能であれば
7,8日はかかるという経験則です。この場合3日でできると
いうのはバグも少なく、技術的な問題もなければ・・と
いうことに過ぎないからです。
この7,8日という日付が社内の平均的なプログラマと比べて
そう遅くないのであれば問題ないと思います。

あと早い段階で「なぜ見積もりどおりに進捗できないのか」
をプロジェクトリーダーに情報をあげておくことでしょう。
理由が「さぼってるから」でもない限り。

お礼

優しい先輩ですね。私なんて、ゆとりのある見積もりで報告すると、「なぜそんなにかかるんだ。」といわれてしまいます。(..)　ありがとうございました。

回答No.8

noname#12673

#3のharisenbonです。

＞見積もるだけのデータというものが存在しているのでしょうか。
まぁ、無いでしょうね。
そういうデータを収集しているところは、すでに
それなりの管理をしているでしょうから。

技術の発展と共に開発手法なども変わるので実際は、
結局熟練者の経験と技術的見識に頼るしかないと思います。（見積もりの手法も熟練者が使うものですし）

また、他の方へのレスからですが、
＞計画を立てるより、作業に時間を使いたい。
気持ちはとても分かります。
でもチームで開発するものならば、全体最適や
リソースの配分、リスク管理などを考えなければならず（リーダークラスの人が考える問題ですが）、
個人の生産性を多少犠牲にしてもスケジュール管理
した方が良いと思います。

お忙しいとは思いますが、もしお時間がありましたら
この本を読んでみてはどうでしょう。
『デッドライン―ソフト開発を成功に導く101の法則』
http://www.amazon.co.jp/exec/obidos/ASIN/4822280535/249-8321182-0233156

ご質問のような問題に悩んでいる時に読むと
面白く読めると思います。
（直接的な解はありませんが）

お礼

本の紹介ありがとうございます。上の人の気持ちが少しはわかるかもしれません。

回答No.7

noboru0510

＃２です。

あなたの言う「見積」とは「誰が誰に、どういうタイミングで提示する、何の見積の事でしょうか？

お礼

「見積もり」ではなく、「スケジュール」の間違いでした。似たような言葉ですよね。すいませんでした。ｍ(_"_)ｍ

回答No.6

densha

#4です。
追加ですが、ネットワーク工程表を作る事はないのでしょうか？
サイクルがある場合は、それを１工程と見なして作成してみると
わかりやすいかも知れません。

お礼

上級ＳＥくらいの仕事なのではないでしょうか。どのようなことができると作れるのでしょう。これを作るのに、なにかデータがあるのでしょうか。ありがとうございました。<m(__)m>

回答No.4

densha

別業種のモノですが・・・

　正しく見積もるにはですね・・・・
#2さんがおっしゃる様にするのが良いのですが、
経験を積むと、若干の余裕を持った工程の組み方を覚えます。
　本来は、綿密に行うと良いのですが、それ自体が工程に組み込むべきほどの
大きな作業になっては本末転倒です。(笑)
　経験というか、各種ケースの統計を取って残しておく事で
後々の工程組み立ての参考にあると思います。
これが本来のあるべき姿なのですが・・・・

　丼勘定にならない程度に誤差を勘定に入れて、
余裕を持った工程を組むのがよろしいと思います。

>正しく見積もるには何に気をつければいいのでしょうか
の答えにはなっていないですね・・・

お礼

余裕を持って仕事ができる時代が来るのでしょうか。お金が絡みますからね。(-_-)ありがとうございました。

回答No.3

noname#12673

質問に具体的なことが書いていないので、抽象的なことしか言えないのですが・・・

１．実際の進捗とスケジュールを比較して、どの工程がどの程度スケジュールに対してインパクトがあったかを分析する。

２．それに対して、作業方法、工程に対する工数の見積もり、発生した問題とそのリスクに対する見積もりなどを洗い出す。

３．改善方法を考える。

４．次回に生かす。

PDCAサイクルに合わせて考えるとこんな感じでしょうか。

でも、"正しく見積もる"能力と同じくらい、状況によってはそれ以上に"正しい見積もりだと相手に納得させる"能力が必要かもしれません。
そういう意味で＃１さんの意見も参考になりますね。

見積もりの手法というのも幾つか存在するので、
それで知識武装すれば説得力のある（正しいとは限りませんが）見積もりが出来るのではないでしょうか。

どちらにしろ、根拠のない見積もりを立てる
（飲まされる）のが一番良くないと思います。

お礼

見積もるだけのデータというものが存在しているのでしょうか。(-_-)　ご回答ありがとうございました。

回答No.2

noboru0510

コンピュータ関係の営業をしています。

私の会社のＳＥも見積が甘いと思います。
「これで出来るはず」だったのが「結局、こうなっちゃいました」となります。

優秀なＳＥの見積は、緻密なスケジューリングがベースになっているようです。

例えば受注内示の段階で、概要設計に何人日という見積の際に、「受注後、何ヶ月目の何週の何曜日に誰と何の項目についての打合せを何時間で行う」といった具体的スケジュール（小日程）を立てていました。
正直言って、「そこまでやるのか」と思いました。

しかも、開発にゴーサインが出ると、そのスケジュールをあくまで実行しようと努力するのです。そして事実その通りのスケジュールで開発が進んで行きました。

おそらく、ここまでやれば見積との相違なんてありえないのでしょう。（あくまで工数計算ですから）

結局、どこまでの日程計画を作るかだと思います。
大日程・中日程・小日程のうち、大日程しか作らなければ、見積の精度もその程度という事でしょうか。

お礼

#2さんのお仕事は「仕事を貰ってから、自社の中でどれくらいの人数をその仕事に充てるか」というお話なのでしょうか。プログラマには関係ない、仕事の一番最初のお話なのですね。この段階で小日程など作れるのでしょうか？ありがとうございました。

回答No.1

chikyuu

勝手な感想ですが、相手が馬鹿なのではないでしょうか？
見積もりとはあなたが欲しい金額であって、相手が望む金額と一致しないのは当たり前だと思います。
後は打ち合わせの中で値引くものだと思います。
お互いの望む金額に開きがあるならば、契約できないだけです。
自分もよく言われますが、”こいつはアホ”だと思っています。
そういう相手に限って、無能なオヤジが多いと思います。

お礼

プログラマの立場からの質問なのですが、「見積もりが甘い。」と言われたのは、筋違いだったのでしょうか。勘違い？上から厳しく言われると責められているようで…。ありがとうございました。