@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- @IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
見積もりと工程表について
投稿者 | 投稿内容 | ||||||||
---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2007-04-03 01:45
まぁ、それはそうなんですが。。。おそらく順番というかリスクのおき方の問題だと 思います。 まず「技術見積もり」を一度変換して工程を立てるとします。 自分で見積もると簡単にできるように見積もってしまう(自分はやるべきことを 知ってて見積もるのだから当然)のでx1.5倍します。でそれを「技術的見積もり」(標準) と称する。 でとりあえず工程をたてはします。 でAさん(標準な人)を工程に当てはめる時には、そのまま割り当てます。 Bさんではできなさそうな内容の場合は、実際のところ長めの期間を取ります。 それはBさんが安いからではなくて、リスク分をあらかじめとってという意味合いです。 金額はともかく、出来ないかどうかは、PMと話せば合意が取れるかと。 その場合は見積もり時は「標準」ときどき「リスク分」となるかと。 でも、そうでない場合、文化的にプログラマが誰でもいいという場合はリスク分は 先に乗せておくのでしょう。つまり全員がBさんだと思っておく。 この場合は「標準」+「リスク分」を全工程にわたって入れておくことにしている のでしょう。 ということでAさんでもBさんでも同じ見積もりになります。全員リスク分も含んでいます。人によって線を換えなくていいので管理者は楽です。おそらく「遅れ」も少ないでしょう。 私は、TOCに反するので、嫌いなのですが。。 でもコスト会計や、完全滝流れだと後ろにずらせないので、どうしても先にリスクを 多くつんでしまうやり方が多いのだと思いますがね。 | ||||||||
|
投稿日時: 2007-04-03 01:50
当たり前のことです。でもって、その期間のもとになるのは、単価ではなく能力です。 人によっては作業時間が10倍以上違うことも良くあると思いますので、能力を考えて見積もりをしないと外しまくってひどい目にあいます。 しかし、見積もり資料には、工数を見積もるという役割のほかに、外部(この場合はPLやPM)の人に工数を説明する、という役割があります。資料を読む人は自分の論理で理解しようとするので、それに合わせて作る必要があります。 PLやPMが「誰がやっても5日でスケジュールを組むべきだ。」「昔からそうやっている。」 というのでしたら、その考えをすぐに変えることはできないと思われます。 ですので、見積もりそのものは、能力を考えた見積もりとし、 資料はPLやPMの考えに沿うようなものにすることをお薦めします。 資料の見積もり値は「能力を考えた見積もり」とできるかぎり一致させるようにしましょう。差はなんとか理由をつけて埋めましょう。 でもってプロジェクトが終わったら、その実績をちゃんと数値にして、「AさんとBさんの能力にこれだけ違いがありましたので、次からはこれをベースに見積ります。こうした方が正確に見積もれます。」とかなんとか言って、PLやPMの考えを変えて行きましょう。 | ||||||||
|
投稿日時: 2007-04-03 09:24
結局、ベテランと初級者とで平均して5日ってことじゃないですかね? ベテランが早く終わったら、初級者の手伝いをするなどして現場レベルで調整を はかるというのはよくあることです。3日で終わるベテランと7日かかる初級者で 平均をとって5日。あとは現場で調整。
よく見たら、ここに答えが書いてありましたね。 単価が100万/月であろうと、1円/月であろうと、工数に変化はありません。 | ||||||||
|
投稿日時: 2007-04-03 15:01
このPL,PMの「5日でスケジュールを組むべき」という発言みて思ったのですが、納期は5日という前提条件があるのでしょうか? もしそうだったら、単価とか以前にAさん*5日しか選択肢がないような気がするのですが・・・Bさん*5日にしてしまうようでは見積もりとは言えないと思います。 個人の開発能力を考慮して見積もるのであれば、スケジュールを組んでから人を選ぶのは矛盾してます。私だったらそのあたりを説明して「誰がやっても5日」が無理であると納得してもらうようにしますが。 [ メッセージ編集済み 編集者: sanderi 編集日時 2007-04-03 15:02 ] | ||||||||
|
投稿日時: 2007-04-03 17:28
だいぶ想像込みです。違っていたらごめんなさい。 多数でユーザ常駐しているのなら、いくつかある案件の中の1つの案件の話ですよね。 メンバーほぼ固定なら、AさんとBさんはもう実際にいて仕事してるのですよね。 損得はそこでの案件全体で見ているのではないですか? その案件が+になっても、その分他の案件で−になるだけなのでは。 (PM/PLに聞いてください) ということなら会社の損得に関係する話では無いですよね。 工程表は実際にいつ終わらせるのかで現実的に考えればいいんじゃないでしょうか。 その後全体で必要な要員や納期を調整するんでしょう。 | ||||||||
|
投稿日時: 2007-04-04 00:04
基本的に見積もりはメンバーのスキルを考慮していません。
つまりアサインされるのが新人(Bさん)がだろうとベテラン(Aさん)だろうと、見積もり工数はかわりません。 ただ新人がアサインされた場合はスキルも低いので期間を長くとるべきでは?ということです。(初めにスキルではなく単価を評価値として挙げてしまったため皆様を混乱させてしまったようです。申し訳ございません。) 別に長くとったとしてもBさんの単価はAさんの半分なのだから開発期間を倍にしても何も問題ないんじゃないかと思ったしだいです。 *開発期間は今回の場合、制約としてない前提で話していました。 | ||||||||
|
投稿日時: 2007-04-04 00:11
その通りです。 ただ、明らかに初心者>ベテランの場合でも平均工数でスケジュール化するため、調整しきれず残業しまくっています。。。 (ここでいう平均工数とはそのチームの平均ではありません) [ メッセージ編集済み 編集者: ルーキー 編集日時 2007-04-04 00:31 ] | ||||||||
|
投稿日時: 2007-04-04 00:31
たしかにおっしゃる通りです。 PJ全体の人数はほぼ決まっているので個別の案件がどうであれ全体的なコストや売上は一定です。 ただしBさんに5日でやってもらうと、とても5日で終わるわけもなく残業でカバーせざるをえなくなってしまいます。(コスト増) |