1. なぜ開発前に見積りを取る必要があるのか？
そもそも、なぜ開発前に見積もりを取る必要があるのでしょうか。理由はいくつかありますが、最も重要なポイントは、見積もりを失敗するとプロジェクトが失敗する可能性が高まるということです。
システム・アプリ開発の失敗は、開発前に要件が定まっていなかったり、仕様が不確定なままだったりすることに起因します。要件が定まっていなければ、適切な人員配置もできず、スケジュールも立てられません。
また、仕様が不確定だと、思わぬトラブル・バグが発生する可能性もあります。見積もりを取るためには、作業内容を定める必要があるため、必然的に要件定義を行わなければなりません。そのため、見積もりが正確であるということは、プロジェクト成功に必要な要件が明確になっている状態とも言えます。
また、システム開発が企業活動である以上、費用対効果を見極めなければなりません。見積もりを取ることでシステム開発に必要なコストが分かりますから、見積もりは投資判断を行う材料とも言えます。
2. 代表的な見積りの手法
▼ 代表的な見積もりの手法は、下記の4種類です。
・類推（トップダウン）法
・ボトムアップ（工数積上げ）法
・係数モデル（パラメトリック）法
・プライスツーウィン法
それぞれの見積もり手法によって、メリットや特徴、向いている案件が異なります。提出された見積もりの妥当性を判断するためにも、どの手法で作成されたものなのか確認すると良いでしょう。
2-1. 類推（トップダウン）法
類推法は、見積もりを取りたい開発の類似例を基準に算出する方法です。
類似例が基準となるため見積もりが比較的容易で、工数や予算の乖離が大きくなることはありません。ただし、全く同じ開発事例はないため、多少のズレが生じることは否めません。大きく外れることがないかわりに、ピッタリ合うこともないことが特徴です。
さらに、他の見積もり手法と比べるとスピーディに算出できます。
なお、初めて取り組む開発の場合、類推法は使えません。また、大規模案件になると類推によるズレが大きくなりやすいので、中規模以下の案件に向いています。
2-2. ボトムアップ（工数積上げ）法
ボトムアップ（工数積上げ）法は、その名のとおり想定されうる作業の工数を積み上げて算出する見積もりです。各種工程の工数をそれぞれ出すため、比較的精度の高い見積もりが作成できます。
ただし、算出までの手間がかかることはデメリットです。また、工程を分解して設計すること自体に知識が必要なため、見積もり算出者にも技能が求められます。システム完成までの全工程が見通しづらい大規模プロジェクトには向いておらず、小規模〜中規模の案件にオススメです。
2-3. 係数モデル（パラメトリック）法
係数モデル（パラメトリック）法は、係数モデルを使って見積もりを作る方法です。係数モデルとは各作業を数値化し、数式モデルに置き換えたものです。係数モデルにはFP法やLOC法、COCOMO法などの種類があり、それぞれの係数モデルに必要な要素を代入して計算します。
FP法（ファンクションポイント法）は「Function Point」の略で、機能要件を難易度別に分けて計算することで、見積もりを平準化することが目的です。
例えば、あるシステム開発において、簡単な機能が5つ、一般的な機能が3つ、難しい機能が2つ必要だとします。
この場合、簡単な機能は10万円、一般的な機能は20万円、難しい機能は30万円と定めると、システム開発全体の費用は「簡単な機能10万円×5つ ＋ 一般的な機能20万円×3つ ＋ 難しい機能30万円×2つ ＝50万円 ＋ 60万円 ＋60万円 ＝170万円」です。
なお、実務では「外部入力（EI）」「外部出力（EO）」「外部照会（EQ）」「内部論理ファイル（ILF）」「外部インタフェースファイル（EIF）」の5つのファンクションに分類されて計算されます。
LOC法（プログラムステップ法）は「Lines Of Code」の略で、単純にシステムのプログラム（ソースコード）行数で見積もります。例えば、開発に100行必要なシステムであれば「1行当たりの単価×100行」が開発費用です。
ただし、同じ処理を行うシステムでも、ソースコードの行数はエンジニア次第で調整できます。そのため、LOCでは行数の妥当性が問われることも少なくありません。
COCOMO法は、「constructive cost model（構造的コスト推計モデル）」の略語です。ソフトウェアのソースコードから開発期間・工数を見積もります。具体的には2種類の計算式があり、「E（工数） ＝ a（定数） × KLOC^b（ソースコードの行数のb乗）」もしくは「T（期間） ＝ c（定数） × E^d（開発工数のd乗）」で計算します。
式中の a、b、c、dは、プロジェクトの種類・規模によって代入する数値が定められていることが特徴です。
係数モデル法は上記のように数式が用意されていますから、必要な要素さえ集められれば誰でも見積もりを作成できます。見積もり精度としては、トップダウン法とボトムアップ法の中間程度です。
また、係数モデル法は数式で見積もるため、他の見積もり手法と比べると妥当性を示しやすいメリットもあります。全体を見通しづらい大規模案件でも、要素を代入していけば見積もれますので、汎用性が高い見積もり手法とも言えるでしょう。
2-4. プライスツーウィン法
プライスツーウィン法（Price to Win）は、予算に合わせて見積もりを作成する手法です。予算から逆算するため、予算オーバーすることはありません。ただし、必要な機能が入らない場合もあります。機能を追加するために見積もりを追加していくと、結果として予算オーバーに繋がることは覚えておきましょう。
また、プライスツーウィン法は予算ありきで見積もられるため、システム全体の品質が低くなりがちともいわれています。
3. 見積りの対象となる項目・内容
▼ 見積もりの対象となる項目・内容としては、次のような例が挙げられます。
・要件定義費用
・設計費用
・テスト費用
・デザイン費用
・進行管理費用
・開発費用
・導入費用
・導入支援費用
・購入費用
・旅費・交通費
・保守・運用費用
相当量に感じる方もいるかもしれませんが、どれもシステム開発には必要な項目です。いずれの項目も、見積もりに書かれている単価・工数の妥当性を確認しましょう。
3-1. 要件定義費用
要件定義費用は、システム開発前に要件定義書を作成したりシステム全体像をヒアリングしたりする費用です。システム開発を成功させるために最も重要な項目とも言えます。なお、要件定義の内容によっては追加の見積もりが発生する場合もあります。
3-2. 設計費用
設計費用は、主にサーバー環境に伴う費用です。サーバーはシステムが稼働するためのインフラとも言えます。また、開発するシステムに、どのようなプログラミング言語を使用するか決定する費用が含まれている場合もあります。
3-3. テスト費用
テスト費用は、サーバー環境はもちろん、システムリリース前の検証やデバッグについての費用です。テストはシステム開発に直接関わる部分ではありませんが、必ず行いましょう。
3-4. デザイン費用
デザイン費用は、UI（ユーザーインターフェース）・UX（ユーザーエクスペリエンス）など、デザイナーが関わる費用です。
実際にシステムを使うユーザーの利便性に関わる費用とも言えます。
3-5. 進行管理費用
進行管理費用は、プロジェクト全体を取りまとめる費用です。ディレクション費用やプロジェクト管理費用と書かれている場合もあります。
プロジェクトマネージャーや、ブリッジSE（オフショア開発時の橋渡し役）が関わる業務のため、他の項目よりも人月単価が高い場合が多いです。
3-6. 開発費用
開発費用は、実際にエンジニアがシステム開発作業をする項目です。コーディング費用やプログラミング費用と書かれている場合もあります。
この項目は後述するとおり、オフショア開発を活用することで大幅にコスト削減することも可能です。
3-7. 導入費用
導入費用は、システムを実装する費用です。
3-8. 導入支援費用
導入支援費用は、システム利用者に対するレクチャーなどに関わる費用です。マニュアル作成なども含まれています。
3-9. 購入費用
購入費用は、サーバやソフトウェアの実費です。この項目は使用するサーバ・ソフトウェアを選定することで、費用を抑えられます。
3-10. 旅費・交通費
旅費・交通費は、打ち合わせなどで発生する実費です。この項目はオンラインMTGで代替することなどで費用を抑えられます。
3-11. 保守・運用費用
最後に、保守・運用費用は、システムリリース後の運用に関わる費用です。
4. 開発前に見積りを取る際のチェックポイント
▼ 開発前に見積もりを取る際は、次の3つをチェックすることをオススメします。
・プロジェクト期間をチェック
・工数をチェック
・リスクに対する見積りが含まれているかチェック
それぞれの詳細は次のとおりです。
4-1. プロジェクト期間をチェック
見積もりというと費用に目が行きがちですが、全体的なプロジェクト期間もチェックしましょう。
見積もりが予算内に収まっていても、開発期間がスケジュールに収まっていなければプロジェクトは失敗してしまいます。リリース予定はもちろん、検収前の納品時期も確認することが重要です。
4-2. 工数をチェック
各見積もり要素の工数の確認も重要です。いずれの見積もりでも、工数が費用計算の基となります。そのため、算出された工数に不要なバッファーが含まれていると、全体的な費用が高くなってしまいます。
エンジニアはバッファーを求めたがる傾向にあるので、工数が適正範囲に収まっているかは要確認です。
4-3. リスクに対する見積りが含まれているかチェック
リスクに対する見積もりが含まれているかも、確認しておいたほうが良いでしょう。
例えば、開発中のテスト費用・リリース直後の検証費用・リリース前後の導入支援費用などは、システム開発には直接関係しない見積もりです。これらを省いても、システム自体は完成します。
しかし、このようなリスクに対する対応を省くと、予期せぬトラブルが発生することも少なくありません。とくにテスト関係や導入関係の見積もりが含まれているかは要チェックです。
また、システム開発においては、不測事態からしばしば修正が必要になるケースもあります。このような修正が、何回まで見積範囲内なのかも確認しておきましょう。
5. 開発前に見積りを依頼する際の注意点
▼ 開発前に見積もりを依頼する際は、次の4点に注意しましょう。
・見積りは複数社から取得する
・妥当性のある見積りを取得するには？
・不明点は質問をする
・見積りの金額の安さだけに注目しない
それぞれのポイントは次のとおりです。
5-1. 見積りは複数社から取得する
見積もりは複数社から取得したほうが、コストを抑えられます。（いわゆる相見積もり）
複数社から見積もりを取れば、同じシステム開発に最も安く対応してくれる会社が分かります。また、相見積もりを取ることを開発会社側に伝えれば、競合他社より安くする努力をしてくれるかもしれません。
また、複数社の見積もりを見比べることで、それぞれの会社が見落としている項目や対応できない項目を発見できることもポイントです。
例えば、A社の見積もりにはデザイン費用が含まれているにも関わらず、B社の見積もりにはデザイン項目がないとします。この場合、B社はデザインに対応してくれない可能性もありますので、契約前に確認したほうが良いでしょう。
1社のみからの取得では視野が狭まってしまいますので、できれば3〜4社から取得するようにしましょう。
5-2. 妥当性のある見積りを取得するには？
妥当性のある見積りを取得するためには、開発したいシステム・アプリのイメージを事細かに伝えることが重要です。開発企業とのコミュニケーションが大切とも言えます。
見積もりが高くなる理由として、コミュニケーション不足によって開発企業がプロジェクトの全体像を見通せず、バッファーを取ることが挙げられます。無駄なバッファーを取らせないためにも、情報共有は丁寧に行いましょう。
また、必要な機能については網羅的に伝えておかないと、開発が始まってから別途見積もりとなる場合があります。システム開発の目的を伝えて、要件に漏れがないか確認しましょう。
5-3. 不明点は質問をする
見積もりに不明点があれば、躊躇わずに質問することも必要です。不明点を放置すると、必要のない機能が追加されるなど余計なコストを払ってしまう可能性もあります。
特に導入支援やシステムリリース後の運用保守などの項目は、見積もりの範囲内でどこまで対応してもらえるか確認しておきましょう。
5-4. 見積りの金額の安さだけに注目しない
相見積もりを取ったとしても、金額の安さだけに注目しないようにしましょう。
安い見積もりは魅力的ですが、本当にその金額で開発できるかどうかが重要です。中には受注するために大幅に値引きをし、開発途中にオプションとして追加費用を請求する企業もあります。
見積もりは金額以外に、妥当性も確認してください。
6. 開発コストを抑えたい場合はオフショア開発もおすすめ
さて、ここまで見積もりについて解説してきましたが、見積もりの基本構造は「人月単価×工数」です。
例えば、人月単価が100万円で、工数が2か月であれば、「人月単価100万円 × 工数2か月 ＝ 200万円」と計算できます。
つまり、開発コストを抑えたい場合は、「人月単価」もしくは「工数」のどちらかを減らさなければなりません。
このうち、工数を削減することには限界があります。仮にコストを半分にするためには、半分の時間で開発しなければなりません。しかし、工数削減を強要すると、システムトラブルや設計ミスの原因となります。
一方、人月単価はオフショア開発を利用することで大幅に削減できます。オフショア開発とは、日本よりも物価の安い国へ委託することで、人月単価を抑えてエンジニアを確保する方法です。
例えば、日本からのオフショア開発が盛んな各国の人月単価相場は次の表のとおりです。
| 委託先国（人気順） | 人月単価の目安 |
|---|---|
| 日本（参考） | 70万円～100万円前後 |
| ベトナム | 30万円強 |
| フィリピン | 30万円強 |
| インド | 40万円強 |
| 中国 | 40万円強 |
| バングラデシュ | 20万円強 |
オフショア委託先として人気のベトナムであれば、日本国内のエンジニアの半分〜3分の1程度のコストでエンジニアを採用できます。すなわち、同じシステム開発で同じ工数を使っても、開発費用を半分以下にすることが可能です。
また、人月単価が安いからといって、エンジニアの技術力が落ちる訳ではありません。これらの国々はエンジニアの教育に力を入れており、若い労働人口が多いことが特徴です。そのため、日本国内より優秀なエンジニアを見つけやすい環境と言えます。
ただし、あまりに人月単価が安い国の場合は、インフラや政情に不安がある場合が多いです。コストとパフォーマンスのバランスを見ると、ベトナムやフィリピンなど東南アジアの実績が豊富な国を選ぶと良いでしょう。
コストを抑えつつ優秀なエンジニアとシステム開発したい場合は、ぜひオフショア開発も検討してみてください。
7. まとめ
システム・アプリ開発を成功させるためには、見積もり段階からプロジェクトの全体像を見通す必要があります。見積りの対象となる項目・内容は数が多いですが、抜け漏れがないか確認してください。
また、費用を抑えることも重要ですが、見積もりの妥当性やスケジュールについても必ず確認しましょう。
仮に見積もりが予算オーバーしてしまったり、見積もりコストをさらに抑えたかったりする場合は、日本よりもエンジニアの人月単価相場が安い海外でのオフショア開発がオススメです。ベトナムやフィリピンはオフショア開発の実績が豊富で、日本の半分以下で開発できます。
「オルグローラボ」では、ベトナムのオフショア開発事業をサポートしています。オルグローラボを利用すれば、業務スタートまでのプロセスを省略でき、納品後の保守運用までサポートしています。とくにベトナムは上述したとおり、低価格で高品質な業務を依頼でき、国民性も良いのでおすすめです。
