はじめに
4月からポジションが上がり、プロジェクトを見積もることが増えました。
初めて見積もりを実施したものの、周りから割と精度が良いと言われたので、自分の備忘録を含めてプロジェクトの見積もり方法をまとめてみます。
見積もる際にやること
AWSを活用したプロジェクトを前提に記載します。
また、やることを列挙すると以下になります。
- 要件把握
- 概要アーキテクチャ図作成
- アプリケーションの工数見積もり
- AWS関連の工数見積もり
- DB関連の見積もり
- 他要素の見積もり
- プロジェクト管理
それぞれ詳細を記載します。
要件把握
まずは要件を把握します。
これをやらないことには始まりません。
概要アーキテクチャ図作成
次に要件を満たすための概要アーキテクチャ図を作成します。
この図を作成する中で実装すべきアプリケーションの数や、AWSの構成などをおおまかに把握できれば良いです。
アプリケーションの工数見積もり
アプリケーションの数が分かったところで、この工数を見積もります。
観点としては大きく以下になります。
過去プロジェクトで同様の実装をしたことがある場合
会社であれば過去に複数プロジェクトを実施しているはずです。
それらを参考に過去実装したことがあるか確認します。
実装したことがあれば、その際の工数を参考に工数を決めます。
過去プロジェクトで同様の実装をしたことがない場合
当然過去経験のないトピックも存在します。
R&Dが必要な場合もあるため、多少バッファを考えて多めに見積もります。
AWS関連の工数見積もり
次にAWS関連の工数見積もりです。
こちらもアプリケーションの工数見積もり時と同様の考え方です。
過去プロジェクトで同様の構成としたことがある場合
会社であれば過去に複数プロジェクトを実施しているはずです。
それらを参考にAWS設計・構築の工数を見積もります。
過去プロジェクトで同様の実装をしたことがない場合
過去経験がない場合も当然あります。
この場合、大きく以下のパターンがあるかと思います。
- 全て経験のあるサービスだが、構成が初めてである場合
- 未経験のサービスがある、かつ、構成が初めてである場合
後者ではR&Dが必要な場合もあるため、多少バッファを考えて多めに見積もります。
DB関連の見積もり
次のDB関連の工数見積もりです。
DB関連は1度設計・構築すると後戻りが大変になるため、多めに工数を見積もります。
他要素の見積もり
他にプロジェクト特有の要素があれば見積もります。
プロジェクト管理
これは、プロジェクト管理やクライアントとの調整などの工数です。
規模が大きいほどこの工数がかかるため、これまで見積もった要素の数パーセント、みたいな見積もりをします。
まとめ
プロジェクトの見積もりを初めてやった時は「見積もりなんてできるか」と思っていたのですが、上記の流れでやると割と周りが納得してくれるような見積もりが作れるようになりました。
今後見積もりを作成する人がいたら、少しでも参考になれば幸いです。