見積精度の上げ方
- このフォーラムに新規トピックを投稿できます
- このフォーラムではゲスト投稿が許可されています
- このトピックは管理者もしくはモデレータによりロックされています。
見積精度の上げ方
msg# 1
ゲスト
投稿数: 0
現在、SAPプロジェクトでFIT&GAPを終え、GAP部分の追加見積をはじきだしていますが、ブレを少なくするために皆様どのような工夫、観点で行っていますでしょうか?
投票数:219
平均点:4.34
Re: 見積精度の上げ方
msg# 1.1
hiro888
投稿数: 15
私の方法ですが、(スクラッチのときですけど)
GAP部分の要件をもう少し具体的にイメージしてみて、どのような機能が必要なのか、例えばI/Fならばオンラインにつなぐ必要性は? 夜間バッチでOK?、画面はDynpro? パラメーターズ? 更新ビューでOK?、プログラムなら複雑度、帳票?、何か計算やロジックが入ってる?などその機能と難易度を洗い出してみます。そこで難易度によって開発技術者のランクに応じて見積工数当てはめていきます。当然期待どおりの技術者が入ってくるということはないので以下のように加重します。
ランクA(経験4年以上) 8人月 係数1.5
ランクB(経験2年以上) 10人月 係数1.0
ランクC(経験1年程度) 10人月 係数0.8
それぞれ係数を乗じた和が総合工数とするやり方をしてます。
GAP部分の要件をもう少し具体的にイメージしてみて、どのような機能が必要なのか、例えばI/Fならばオンラインにつなぐ必要性は? 夜間バッチでOK?、画面はDynpro? パラメーターズ? 更新ビューでOK?、プログラムなら複雑度、帳票?、何か計算やロジックが入ってる?などその機能と難易度を洗い出してみます。そこで難易度によって開発技術者のランクに応じて見積工数当てはめていきます。当然期待どおりの技術者が入ってくるということはないので以下のように加重します。
ランクA(経験4年以上) 8人月 係数1.5
ランクB(経験2年以上) 10人月 係数1.0
ランクC(経験1年程度) 10人月 係数0.8
それぞれ係数を乗じた和が総合工数とするやり方をしてます。
投票数:223
平均点:4.30
Re: 見積精度の上げ方
msg# 1.2
ゲスト
投稿数: 0
ありかどうございます。係数重み付けは客先に説明する際、納得していただけるものと思います。
投票数:220
平均点:5.27
Re: 見積精度の上げ方
msg# 1.3
emy
投稿数: 25
ステップ数、機能数(FP)などによる見積もり手法がありますけど、私はどちらかというと人によってブレが多いといわれるけどKKD法(経験、勘、度胸)派です。勘は経験からピンとくるものであるし、自信がある経験だから度胸につながります。さまざまな要因を頭に入れて過去事例から相対的、総合的にはじきだす工数は以外にいいところついているものです。そこでプロジェクトマネージメント手法である「リスクマネージメント」を取り入れ、この見積もりにどのようなリスクが潜んでいるかを洗い出していきます。たとえば「ユーザーの参画度」これだって現状、客先の窓口が情報システム部門だけであれば「今後経理部門ユーザーがでてきてくつがえすようなことだって考えられる」これもひとつのリスク。基本設計書承認の遅れ、会議にいつも参加メンバーが異なりいつも同じことの説明し要件FIXの進捗が悪いとか、これもリスク。プロジェクトコントロールのよしわるしで開発工数のブレは広がります。いくら優れたPMであっても最悪のシナリオで、基本設計がどのくらい考慮深く書いているのか、もしジュニアの開発者だったらどの程度手戻りがあるか?なども含め見積時に考慮します。しかし客先にはこんな要因全部正直に説明するわけにはいきませんから、はじきだした工数を逆算でステップ数に落としたり選択条件パターン、チェックロジックの複雑さによるテスト工数として説明しております(まんざらうそじゃない)。hiro888さんの開発者レベルによる係数もいい説明の材料ですしいい見積もり手法です(希望どおりの開発者がアサインされればブレも少ないんでしょうけど・・)
投票数:228
平均点:5.04
Re: 見積精度の上げ方
msg# 1.4
ゲスト
投稿数: 0
emyさん、ありがとうございます。「ユーザーの参画度」確かにブレる要素ですよね。自動車の運転と同じようにタクシーの運転手は飛ばすときはハデにとばすけど危なそうと感じればグッと徐行しますよね。経験が総合的に判断でき見通しも確かなのでしょう。リスク分析するというポイントも大変参考になりました。
投票数:223
平均点:4.22