よく見積もりの仕方がわからないと聞くので開発見積もりの手法をまとめてみました。
見積もり方法
今回3つの開発の見積もり手法をご紹介致します。
この記事でも説明しますが、一覧と他サイトへのリンクを付けさせて頂きます。
類推見積もり法
過去に開発した類似のシステムの実績を元に推定していく方式。
過去に類似した経験から見積もるため、見積もり者に左右されやすい方式です。
また、過去に類似した経験がない場合は、見積もり者の経験や勘などから見積もりがなされます。
そのため、未経験分野の見積もりを行う場合、事前段階で調査が不十分だと工数算出を大きく間違える可能性があります。
経験上、この見積もり方法は詳細な情報を聞かない段階で行うことが多いです。
例えば「ECサイトを作って欲しい」→「（今までの経験上）3ヶ月位で出来るよ！」っていう初期での返答。
よくよく聞くと、「◯◯と連動して欲しい」「◯◯機能を付けて欲しい」「決済に◯◯を追加で…」とか言われると、もちろん工数が増えることになります。
なので類推見積もり法だけで見積もりを終わらせることは僕の経験上はありません。
標準タスク法
システム開発の全体を細かな作業工程に分解し、標準作業量を足しあわせて全体の工数を見積もる方式です。
例えば商品機能→登録・編集・削除に分解して登録X日、編集X日、削除X日としてシステム全体で機能毎に分解、更に作業工程でテストX日という形で追加していきます。
ただ、これも工数を入れる見積もり者の感覚によって左右されるので注意してください。
- 1. 機能・作業工程の洗い出し
- 2. 1で洗い出した機能毎に工数を入れる
- 3. 2の合算値 = 工数
見積もり担当者が自分基準で作ると炎上することがあります。
それは見積もり担当者の作業速度が早く、チーム全体の平均作業速度を考えてないことから発生します。
チーム全体の力量を見て、平均的な日数で工数を入れることが重要です。
プログラムステップ法 【Lines Of Code method】LOC法
ソースコードの行数を用いる方式です。
ソースコードの行数によって変動するため、開発者の書き方によって左右されます。
この見積もり方式ですが僕は使用してるのを見たことがありません。
例えば過去のソースコードから算出する場合なら、類推見積もり法を使えばいいですし、ソースコードがない状態で算出を行うなら詳細設計まで書いていることになり、そこまで書いているのなら受注されていると思います。（実装が別会社などならあり得るかも知れませんが…
あるとしたら、出来上がったソースコードを何かしらの方法で販売するパターンなのかもしれません。
まとめ
見積もりが苦手なエンジニアでも経験が増えれば、標準タスク法と類推見積もり法を使えば見積もりが出来るようになるはずです。
今回まとめた3つの開発見積もり手法ですが、これはITパスポート、基本情報技術者試験の範囲になります。
これとは別にファンクションポイント（FP）法も試験範囲なので一緒に覚えておきましょう。
ファンクションポイント法は説明が複雑なため、今回省かせて頂きました。
0 件のコメント :
コメントを投稿