見積もる
- 基本詳細設計書。これを見ればコーディングに落とせる、というドキュメントを書く。
要件定義書、概要設計書、等の設計書が詳細まで記述されている場合は、コピペになってしまうだろうが、プログラマは基本詳細設計書を見てコーディングするので、同一だとしても、プログラマ用に書く。
各工程の作業工数。
- コーディング。自分で実装するとしたら、最低この位かかる、という時間を機能、処理手順の複雑さ、複雑度、難易度、パフォーマンス基準、を勘案し、出す。トラブル(複雑システムのテストデータ作成工数、テストプロセスに時間がかかる)にぶち当たるリスクを積んで、その時の状況に合わせて2倍～3倍の値を出す。（担当者の習熟度による。場合によっては調査工数を積む）
- テスト手順が多い、あるいは、複雑
- テストパターンを作るのが大変
という場合は、テスト工数を厚めに積んでおく。
- 妥当な値はどれくらい？自分でシミュレーションしてみよう。
モジュールはいくつ？
１つ作るのに、どれくらいかかる？
テストケースの数は？組み合わせの数は？そこから省けるケースは？
品質要件や技術要件
IFPUG法
WBS（Work Breakdown Structure）によってボトムアップで見積もる
外作との合い見積
相手が見積提出の締め切り期日に提出できなかったら？
それは約束と違うので、その日以前に必要であることを
（これは依頼時に必ず相手に期限を守ることは理由を説明して守ってもらうのだが）
説明し、約束の期限までに可能なものだけでも提出をお願いする。
差異の根拠
- 要件と自分の思い込みのずれによる差異はありませんか？はっきりしていない仕様は要件定義担当者にヒアリングしましょう。
- 自分の見積が妥当で、外注見積の乖離が感じられる場合→自分が見落としている仕様があるor外注見積が見積もったポイントとずれている→外注見積の根拠をヒアリング
- 自分、あるいは外部ベンダの見積値は客観的な根拠の基づくものですか？LOC(LinesOfCode),ファンクションポイント、テスト項目数、テストパターン数、何にせよ、ある切り口からの算出の積み上げであるのだから、それを探ること。
開発ベンダとのやりとり
- 自分の見積とのずれがある項目は、どちらかに作業項目の漏れや逆に積み過ぎがあることが考えられる。
- 工数や金額でずれがある部分をヒアリング。回答期日は、依頼時にはっきりさせておく。(スピード！！)
関連ドキュメント
お勉強的なこと
開発規模の尺度(サイズメトリクス)としてスケールポイント法を考案した。スケールポイントとは入出力を行う機器の数・画面数・通信コマンド数という開発規模と関係の深い3つの指標から求めるものである。
分からないことは？
最終更新：2009年06月30日 15:50
