「良いアイデアがあるのに社内で開発できない」場合、「エンジニアを採用できない」 場合など、ソフトウェアの開発を外部に委託するケースもあると思います。その際に最初のハードルとなるのが「見積もり」にかかる行程ではないでしょうか?

ソフトウェア開発の見積もりは、専門的知識無くしては分かりにくいものです。

今回の記事では、一般的な見積もりの種類や手法について解説していきます。

新規事業を担当される方や、これからアプリ開発の外注をお考えの方に、是非参考にしていただければと思います。

ソフトウェア開発の見積もりの基本的な考え方

まず、ソフトウェア開発における内容を具体的に細分化して解説します。
 

見積もりの対象

 
・コスト

ソフトフェア開発に必要な費用のことを指します。

・工数

ソフトフェア開発に必要なを時間指し、見積もり時に使われる作業量を表す単位になります。

・規模

ソフトフェアの開発量を指します。

・工期

ソフトフェア開発の作業期間を指します。主には要件の定義からリリースまでです。

システムやソフトウェア開発のコストを構成する要素

 
・開発と運用

ソフトウェアの開発費及び、運用・保守費用

・付帯作業

移行作業、操作教育、インフラの構築など、間接的に必要となる費用

・機器等

ハードウェア、ネットワーク費用

発注者が知っておくべき見積もりの基礎知識

見積もりを依頼する前に、発注者側もあらかじめソフトウェア開発における基礎知識を身につけておく必要があります。しかし、全ての方がソフトウェア開発に精通しているわけではありません。ここでは、ソフトウェア開発を初めて担当する場合には、”どんな手法があるか“、”見積もりの内訳や種類“など、外注する前に把握しておくべき基礎的知識を解説します。
 

基礎知識1「見積もりの種類、目的ごとに金額の精度が異なる」

 
一度の見積もりで完璧な精度の見積もりをとることが理想ではありますが、構想から発注までの流れで3種類の見積もりをとるケースが多いです。

超概算見積書

自社内でソフトウェアの開発に対する外注予算を組む上で、費用の大枠を把握するために利用する見積書になります。やりたいことは決まっているものの、どんな画面や機能が必要かをしっかり洗い出せていない段階での見積もりとなります。仕様が不確定なため、見積もり額の精度は正直高いとは言えません。見積もり金額から「−50％から+100％」ほどのズレがでるケースもあります。
 

概算見積書(相見積書)

超概算見積書より具体的な見積書のことを指します。必要な機能や画面の洗い出しが完了したのち、RFP*などをもとに、目的や用途に沿った具体的な提案を受けるための見積もりになります。相見積もりをとり、開発会社選定のために利用されることもあります。超概算見積もりよりは精度が高い見積もりを期待できますが、この段階ではUI/UXなど細部までは決まっていないケースが多く、正式見積もりとズレが出るケースもあります。（あくまで目安ですが、「−25％から+50％」など）

正式見積書（確定見積書）

先ほどの”概算見積書”をベースに、UI/UX、性能要件など出来る限り詳細な部分を話し込みながら、正確に内容を盛り込んだ見積書になります。この時期までくると正式な発注・契約となりますので、この段階で大まかなスケジュールや作業分担が、大枠で決まってきます。しかし、作業段階の行程では色々と変更が起こります。トラブルがあった際も対処出来るように、わかる範囲で契約に盛り込むなどのリスクヘッジをしておきましょう。

基礎知識2「見積もり手法を把握する」

 
ここではソフトウェア開発の見積もりについて、主な手法におけるメリットとデメリットを解説していきます。

類推見積もり

システム開発やコストや工数を見積もる際に用いる手法です。
過去に開発済みの類似システムの実績値をもとに推定していく方式です。主に初期見積もりとして

・主な手法

類推法、デルファイ法

・メリット

システム・ソフトウェア開発などの規模、工数、リスクの想定などを見積もる際に用いられることが多く、一般的に小規模なものであれば、正確性が高く早く見積もりを出すことが可能です。また初期段階でのある程度の工数やコストを算出することが可能です。

・デメリット

過去に類似システムの前例がないと、担当側の勘や経験をもとに見積もりが行われるため、またプロジェクト特有の要件への考慮が漏れている場合もあり、精度が低くなります

係数モデル見積もり（パラメトリック見積もり）

最も一般的に使われており、ソフトウェアの工数や期間、規模などの要件に合わせて、機能数や画面数を積算していく手法になります。中小規模プロジェクトのソフトウェア開発に多く用いられる手法です。

・主な手法

LOC法、FP法、COCOMO/COCOMO II、スケース・ポイント法

・メリット

ユーザーの納得度を得やすいという特徴があります。また利用実績のあるデータをもとに構築されることから信頼度も高い手法となります。

・デメリット

見積もりに必要な要素が厳密であることが挙げられます。また内部の機能を数え上げ、複雑度の評価、ソフトウェアの特性などを加味して機能別に作成されるためかなりの時間を要します。また操作性やデザインなどの工程が反映されません。

ボトムアップ見積もり

プロジェクト全体で実施する作業単位を細かな工数に分解して、それぞれを足し合わせて積み上げていく見積もりの手法になります。主に小中規模のシステムに多く用いられる手法です。

・主な手法

WBS法、標準タスク法

・メリット

作業内容が細分化されているので、スケジュールやコストの管理が行えます。

・デメリット

成果物を基準に見積もりを行うため、ソフトウェア開発の要件等の定義が完了していなければなりません。

依頼する前に開発の無駄を省いておく

プロジェクトを失敗に導く一つの要因として、「無駄なことにコストを支払う」ことが挙げられます。ソフトウェア開発を依頼する前に、本当に必要な機能だけになっているかをチェックすることが重要です。悲しいことにシステムをリリースすると思ったよりも使われない機能がでてくることがあります。メールアドレス認証とSNS認証を導入したがほぼSNS認証しか利用されない、管理画面で集計できる機能を開発したが、運用担当者はローデータをダウンロードしてエクセルで集計を行っているなどはよく聞く話です。見積もりを依頼する前に本当に必要な機能か、他に代替できる手段はないか、検討してみるのがよいでしょう。

発注者として無関心にならないこと

「外注」となると、プロに依頼することになるので安心してしまいがちです。しかし、システム化される実際の業務やサービスに最も精通しているのは発注者です。一つの仕様の認識の齟齬が、見積もり、開発、工期全てに影響を与えます。任せる側も開発に参画する気持ちで依頼することが大切です。あくまでソフトウェアを開発することが目標ではなく、その後にいるユーザーの方に気持ちよく使っていただくことが前提となります。
しっかりと多方面とコミュニケーションをとり、 みなさんにとって有益なシステム開発となることを心がけましょう。