情シスの方は特に、システム開発が必要な場面で必ず見積を見る機会が発生します。システム開発会社から提出された見積内容が妥当かを判断するためには、見積方法や見積における重要な確認ポイントを知っておく必要があります。
今回の記事では、システム開発における見積方法7種と、重要な確認ポイント3つをご紹介します。見積の計算方法や確認ポイントを知っておくと何かと便利ですので、是非この記事を参考にしてみてください。
システム開発における見積とは？
見積とは、金額や期間などを前もって概算することをいいます。システム開発における見積も同じで、開発するシステムがどれくらいの金額で、どれくらいの期間をかけて作成するかを計算します。
最終的に、その計算した結果を書面としてまとめ、見積として、お客様に確認してもらうところまでが見積工程となります。
見積方法を知っておくメリット
システム開発における見積手法は様々で、企業によって異なります。
そのため、見積の計算方法をよりたくさん知っていることで、どの企業から見積を取得しても、おおまかな計算のロジックが理解できるようになります。きちんと理解ができれば、他社から提出された見積の金額が妥当かどうかの判断もつきやすくなります。
システム開発の見積方法
先ほどもお伝えした通り、システム開発の見積方法には複数の手法が存在します。その中でも、今回ご紹介する見積方法は以下の７つです。詳しく見ていきましょう。
- 類推法
- ボトムアップ法
- プログラムステップ法
- ファンクションポイント法
- 標準タスク法
- パラメトリック法
- プライスツーウィン法
各見積手法に関して順番に解説していきます。
類推法
類推法は見積を行う企業が保有する”過去のシステム開発事例”を参考に、開発するシステムがどれくらいのコストや工数で作成できるかを算出する方法です。企業のシステム開発経験が長い場合、様々なシステム開発の経験を持っている可能性が高いです。そのため、今回作成するシステムに近い規模や難易度のシステムを参考にし、正確な見積を算出することができます。
〇メリット
過去に開発したシステムと作成するシステムを比較して見積を作成するので、見積を短時間で作成することが可能
×デメリット
過去に開発したことがないシステムでは使えない
ボトムアップ法
ボトムアップ法はシステムの機能を洗い出し、各機能を作成するための工数を精査し、各機能を積み上げていき見積を作成する手法です。
〇メリット
各機能を精査し工数を見積もるため、精度の高い見積の作成が可能
×デメリット
各機能の工数を精査する必要があり、見積に時間がかかる
プログラムステップ法
プログラムステップ法は、開発するシステムのコーディング量をステップという単位にわけて、そのステップ数にステップあたりの所要時間をかけることで工数を見積もる方法です。
〇メリット
具体的なステップ数を基にした精度の高い見積もりと、過去のプロジェクトデータとの比較による現実的な工数やコスト予測が可能
×デメリット
プログラムコードがすでに存在している必要があるため新規の開発には適していません。変更が頻繁に起こるプロジェクトでは柔軟性が低下する可能性もあります。
ファンクションポイント法
ファンクションポイント法はシステムの外部入力、外部出力、外部参照、外部インターフェイス、内部論理ファイルの5つの要素と過去の事例から、そのシステムの機能を定量的に算出し、システムの開発工数を見積もる方法です。
〇メリット
この5要素が相手から見た時にどのような機能をさすかが明確になった上で、その機能でどの程度の見積となるかがわかるため、お客様への説明がしやすい
×デメリット
見積作成者の主観が入りやすい
標準タスク法
標準タスク法はWBS（各作業をタスクとして細分化し、一覧表で示し作業状況をプロットした計画書。）に基づいて、処理単位ごとに工数を見積積み上げていく方法です。
〇メリット
作業ごとの工数を考慮できるため、精度が高い見積の作成が可能
×デメリット
各作業の工数を見積もる際に時間がかかる
パラメトリック法
パラメトリック法は、要件や設計箇所を点数化して、見積を作成する手法です。
〇メリット
計算式により見積が算出されるため、担当者の知識や経験に左右されるという人依存を払拭できる
×デメリット
要件や設計箇所の数に依存するため、見積の精度がそこまで高くない
プライスツーウィン法
プライスツーウィン法はお客様の予算を先に決めてもらって、その予算に合った見積を作成するという手法です。
〇メリット
お客様の予算を超える心配がなく、その範囲内での開発となるため予算の過不足が発生しない点
×デメリット
予算ありきでの見積作成となるため、機能漏れなどが想定外の箇所で発生する可能性がある点。重大な機能もれの場合は追加で開発が必要になり、通常よりも多くの費用がかかる可能性がある
システム開発における見積の内訳
見積を理解するうえで必要なシステム開発における見積の内訳をご紹介します。内訳項目は多岐に渡りますので、一般的な項目のご紹介となります。
よく利用される見積の内訳項目
見積の内訳項目は、非常に多岐に渡り分かりづらいとよく耳にします。確かに企業によって書き方もことなってきますので、ここでは頻繁に利用される一般的な内訳項目ををご紹介します。
- 要件定義費用
- 機器購入費
- 設計費用
- 開発費用
- テスト費用
- 運用保守費用
- 交通費
要件定義費用
要件定義費用とは、システム開発におけるもっとも重要な段階と言われており、システムが満たすべき機能や性能を明確にしていくフェーズです。一般的には要件定義が最も費用単価が高く、いわゆるケチってはいけない項目になります。
機器購入費
次に、機器購入費です。先の要件定義で決まった内容に沿って、必要な機器を導入・購入する費用になります。この費用には、開発に必要なハードウェア（コンピューター、サーバー、ネットワーク機器など）やソフトウェア（開発ツール、ライセンス、データベースシステムなど）の購入費が含まれます。
設計費用
設計費用は、要件定義で決定した内容に基づき、システムのアーキテクチャ、データベース設計、インターフェース設計、セキュリティ設計などが取り決められます。適切な設計がなされることで、開発の効率化やエラーの低減、先々のメンテナンスコストの削減につながるため、ここもケチってはいけないポイントです。
開発費用
開発費用には、具体的なプログラミング作業、コーディング、システムの統合などが含まれます。この項目は、主に開発チームのエンジニアやプログラマの人件費が主要な部分を占め、必要に応じて外部リソースの利用費用も計上されます。
テスト費用
テスト費用は、開発されたシステムやソフトウェアが設計通りに機能し、要求された品質基準を満たしていることを確認するための費用です。最終的なシステムの品質に直接影響するので非常に重要な項目なのですが、テスト費用をケチって工数を削減してまう企業の話をよく耳にします。大体の場合は、後から不良が発覚し当初のテスト費用以上の費用をかけて改修を行うことになっているため、テスト費用は重要であり削減すべき項目ではないというてことを念頭に置いておきましょう。
運用保守費用
運用保守費用は、製品のリリース後の段階で発生するコストです。内訳としては、主にシステムの日々の運用、定期的なメンテナンス、アップデート、障害対応などが含まれます。ただし、自社で対応可能な場合は不要な項目です。
交通費
交通費は、プロジェクト関連の移動に伴う経費を指します。打合せで頻繁に訪問する場合の交通費や、導入時に現地へ赴く必要があれば、その費用も計上されます。そのため、事前にどのくらいの頻度で訪問するかも指定する必要があります。
見積時の条件
また、見積を作成する際には、現段階では不透明で決定されていない事項なども仮で決めたうえで、見積を作成する必要があります。これを見積の前提条件といい、見積の備考欄などに記載しておく必要があります。
見積内訳の注意点
要件定義費用からテスト費用までは主に開発部分の費用で、上にも書いたように要件定義が一番単価が高く、開発工程が進むほど単価は安くなります。
運用保守費用に関しては期間やどの程度の範囲を運用保守していくかによって金額は変わってきます。また、運用保守がシステムの初回稼働から1ヶ月などの期間をあけて開始される場合もあります。その点も考慮しておく必要があります。
交通費に関しては、実費精算の場合は後からの見積となります。その場合は、見積を分割して、開発終了時にまとめて交通費を回収するなども可能です。
システム開発における見積内容の確認ポイント
システム開発における見積において、確認しておくべきポイントは主に以下の３つに絞られます。
- 見積の作業範囲が正しいか
- 見積金額が妥当か
- 前提条件の認識にずれがないか
見積の作業範囲が正しいか
見積として計算された作業範囲が打ち合わせた通りの内容になっているかを確認する必要があります。不必要な工程などを口頭で話し合っていた場合などは、不要な機能を作成する工数が含まれている場合もあるので注意しましょう。また、機能として、漏れがあると追加開発として余分な費用がかかる可能性もあるので、その観点でも注意して確認しましょう。
見積金額が妥当か
見積金額が前章で述べた計算方法をもとに考えると、明らかにずれている場合などは、見積作成側かお客様のどちらかが損をしてしまいます。後々の関係悪化なども考えられるため、どちらが損になっているかにかかわらず、金額がおかしいと感じた場合は連絡する必要があります。
前提条件の認識にずれがないか
前提条件は見積項目とは違う場所に書かれていることが多く、見逃しやすいので注意してください。見積条件の認識にずれがある場合、見積金額にもずれが発生してしまうため、少しでもずれがあれば連絡する必要があります。
まとめ
今回は、見積方法を７種と提出された見積が妥当かの判断がするための確認ポイントを3つご紹介しました。
- 見積方法7種
- 類推法
- ボトムアップ法
- プログラムステップ法
- ファンクションポイント法
- 標準タスク法
- パラメトリック法
- プライスツーウィン法
- 見積の妥当性確認ポイント
- 見積の作業範囲が正しいか
- 見積金額が妥当か
- 前提条件の認識にずれがないか
システム開発における見積は最初の重要な工程なので、是非この機会に見積手法や確認ポイントを押さえておきましょう。
