プロジェクトの規模見積もりは経験と勘と度胸(KKD)？【開発規模見積もりの考え方】

プロジェクトの見積もりは、プロジェクトを成功させるには外せないポイントです。

「これこれこんなシステムを作りたいんですが、明日の朝まで見積もりだしてください」

２０年以上前の話なので、電話１本で見積もり、みたいな話は近年は減っているのかわかりませんが、それにしてもシステムの概要をヒアリングしてから数日内に見積もりの提示を求められることは、世の中にはたくさんあります。

今回は、システム開発プロジェクトの実際の見積もりの方法について、お伝えします。

プロジェクトの開発規模と工数・費用の見積もり

プロジェクトの工数、費用見積もりの公式

プロジェクトの開発では、工数や費用の見積もりは生命線です。
考え方は、シンプルです。

上記にプロジェクト固有のタスクやマネジメントの費用なども発生しますので、その部分は加算します。

開発費用の原単位は、細かくするなら、ＳＥ（システムエンジニア）のランクや仕事内容（上流工程、開発工程）等によってかわったりもしますが、基本的な考え方は、上記で算出できます。

費用の原単位は、お客様との関係で決まっていたりもありますので、システム開発のプロジェクトにかかるコストを左右する最大の要素である、開発規模の見積もりの手法についてみていきます。

プロジェクトの開発規模見積もり―３つの方法

次の３つの方法に分類できると考えています。

実は未だに存在する―経験、勘、度胸。

最初、ＫＫＤ法と見た時は、何か特別な見積もり方法があるのかと期待したのですが、Ｋ（経験）、Ｋ（勘）、Ｄ（度胸）かぁ、と逆に驚きました。
ただし、経験豊富な人のＫＫＤは、かなり有用です。

類推や積み上げで最終的には判断するにしても、この程度のシステムなら、何億程度は必要だ、というような経験に裏打ちされた勘は、あるのとないのと大違い。

もっと規模が大きいはずなのになぜだろう、という話で見積もりとして大幅にもれていたタスクを発見できたという話は、何度もきいたことがあります。

また、根拠がないときに、そのシステムの過去実績と類似のシステムからの推測は、規模感を出すのには有用です。
詳細の積み上げ見積もりに対しての規模のズレをみるのにもよく使う方法です。

最後の積み上げ法は、様々な方法が考案されています。

ようするに、システムの要素を小さく分割してそれを積み上げて数値を導き出す方法です。

数値が大きくなればなるほど規模は大きくなるという話です。

ポイントは、小さく分割する、というその分割の項目、内容と、積み上げられた数値を作り上げるのに必要な工数になります。

システム開発プロジェクトの規模見積もりの方法

ＫＫＤ法

いわゆる、経験・勘・度胸で見積もる方法ですが、プロジェクトの規模を積み上げて見積もると、実は見積もりで極めて大切になる、非機能要件部分の見積もりが抜けてしまうことがよくあります。

非機能部分とは、例えば、運用面を整備対応する工数だとか、性能はどこまでもとめているだとか、セキュリティ要件をどこまで考慮するだとかです。
あわせて、管理工数なども、単純積み上げのみでやるともれるし、プロジェクトによって状況が違うから一律には入れきれない、そんなときには、ＫＫＤが活躍します。

性能出すのに、前回のプロジェクトでは１０人月程度かかったぞ。開発規模の５％くらいだから、今回も積み上げておくか？

開発標準や設計標準なども、この規模のプロジェクトでは手厚く対応していく必要がありそうだ、前回のプロジェクトでは１５人月だったけど、今回の方が規模も大きいし２０人月つんでおくか。

管理工数は、１０％は必要だな、そうしないとプロジェクトマネージャの工数が確保できない。

などなど、現実的にこのような見積もりも結構ありそうですが、この部分は大切で、抜けると工数不足でプロジェクトが立ちいかなくなります。

詳細に見積もるには、細かいタスクをあげて、そのタスク単位積み上げて見積もるのですが、プロジェクト初期段階ではそこまでのブレークダウンは難しいと思われます。

実際、お客様にご理解いただくのは難しいのですが、規模が大きくなれば管理・非機能で２０％以上の工数が必要になる場合もあります。

管理工数：１０％前後（実質一般的に８％から１２％程度です）
標準化・性能確保工数：１０％前後（プロジェクトがどこまで力をいれるかですが、大規模の場合は必要になると思います）

プロジェクトの２０％は大きいと思います。
そもそもシステム開発のプロジェクトは、そこまで利益幅が大きくないのが普通だと考えられるので、２０％見積もりショートしたら、おそらく失敗します。

これ以外にも、更新の場合には既存システムからの移行、他システムと複雑に連携している場合は、他システム連携、などの工数を必要分を積み上げておくのは不可欠です。

アナロジー法

アナロジー法、いわゆる類推です。

要するに、今までの経験や過去の類似プロジェクトの実績から見積もる方式になります。

類似プロジェクトでよくあるのが、システムのマイグレーション、再構築の場合、前回の規模をもとに規模を算出する、というパターンがあります。

前回、１００人月だったので、今回もスコープに変更がない単純な移し替えなので、１００人月相当。

ただし、要件検討や仕様検討がないからその分で３割カットとお客さんからいわれて、７０人月かぁ、とかいうやつです。

ちなみに過去からの移行、単純マイグレーションプロジェクトは、コストカットどころか増える傾向にあるのが、一般的なので、お客さんからコストカットを迫られても簡単には同意しないほうが無難です。

マイグレーションプロジェクトのコストが増える原因は、別の記事でまとめています。
マイグレーションプロジェクトの罠【マイグレーションでもコストが増える理由】

実際には、過去と同じスコープと言ってしまうには、移行の場合には時代も異なり開発する仕組みも違ったりするのが通常なので、

「以前、同じようなプログラムを開発したことがある」

「別のプロジェクトで、類似ソフトウェアを作っていた」

という過去のデータから、新しく開発する機能や、不必要な機能を考慮し、過去のプロジェクトでの規模を増減させ、これから開発するプログラムの規模を見積もることになります。

これに、プロジェクト特性を読んで今回は、性能要求が厳しい、運用が３６５日２４時間対応だからその分をリスクとしてコストに反映させよう、などというのは、まざに高度な技術、知識、いわゆる経験（Ｋ）、勘（Ｋ）、それとこれでいこうという判断―度胸（Ｄ）が必要となります。ＫＫＤ法の面目躍如です。

アナロジーとＫＫＤをうまく組み合わせて見積もるのが必要になります。

積み上げ法

基本的な考え方は、プロジェクトで実施することを見積もり可能な範囲まで細分化し、それを積み上げる方法です。

積み上げるためには、ある程度仕様書が細かく定義されているとか、設計ができてないと見積もれないとか考えてしまうかもしれませんが、実はこの方法を極めて、ＫＫＤ法をあわせれば、かなり初期のころからプロジェクトの規模も見積もることができます。

あとは、精度の問題だけになります。

実際にプロジェクトを細分化といいいますが、考え方は３つです。

１）タスク分割
タスクを細かく分割して、それを積み上げる方法です。

２）比率分割
作業工程の割合で推定してしまう方法です。
例えば、仕様検討が１０人月かかったら、設計は検討とほぼ同じ、開発は２倍程度、とかの過去の社内データより、比率で見積もってしまいます。
設計は積み上げるので、積み上げ法にしましたが、アナロジー法との組み合わせかもしれません。

３）ファンクションポイント法

正式なＦＰ法もありますが、考え方としては機能分割です。

先ほど初期でも見積もり可能と書きましたが、例えば、１画面の開発は１人月、今回６０画面だから、６０人月というのも相当簡単なファンクションポイント法といえます。

これを、画面への入力項目、出力項目、更新、ファイルＩＯなどと要素を増やしていけば見積もり精度があがるという考え方です。

このあたりについては、機会を設けて説明させていただきます。

今回は、ＫＫＤから積み上げまで、見積もりは様々な方法があるという話をさせていただきました。

見積もりは、プロジェクトの生命線になると思っています。

プロジェクトマネージャーは、いくつかある見積もりの中で複数の方法で検証して、これならいけるという確信のもとプロジェクトを進めたいですね。

不安はメンバーにも伝わります。見積もり技術は、しっかりしたものを身に着けておきたいものです。

今回は、ここまでにします。最後までお読みいただきありがとうございました。

このブログでは、実際の自分の経験も元に、プロジェクトマネジメントやＩＴ最新技術などの発信をおこなっております。

変化の激しいＩＴ業界は、日々話題もつきません。

継続して発信予定ですので、今後ともよろしくお願いします。