kokimizuochi

2023年1月30日読了時間: 12分

システム開発の見積もりを徹底解説！工数などの一目で分かる比較項目も

更新日：2023年12月7日

システム開発をする際、まずは各社に見積りを依頼します。

その際に会社ごとの見積もり金額が違っていて、比較に困ったという経験はありませんか。

特に初めてのシステム開発を依頼する場合、見積もり金額や作業工数が適切か判断するのは簡単ではありません。ただ、見積もり項目や比較するポイントを事前に知っておけば見積もりを確認しやすくなります。

本記事では、システム開発の見積もりに関する、各項目や工数の見積もり方法、見積もり金額の根拠について紹介します。

システム開発における見積もりの重要性とは

システム開発における見積もりは、発注者と受注者の認識のすり合わせをするために重要な役割を果たします。

なぜなら、発注者は見積もり内容を見て必要な費用の概算だけでなく、作業工程の情報を把握し、受注者は見積書を作る過程でシステム構築に必要な工程を洗い出し、それぞれに必要な費用を想定して事前にスケジュールを組めるからです。

下記のとおり、システム開発の作業工程は複雑で同時進行で進める内容も多く、発注側が作業内容を把握しきない場合もあります。

引用：[NTT データのプロセス定義におけるシステム基盤構築]

もし、見積もり書の内容で双方の認識の違いがあれば契約前に修正ができ、作業工数などの認識違いで起こりうるトラブルを事前に回避できます。

システム開発における見積もりは契約前に発注者と受注者の認識をすり合わせ、作業をスムーズに進めるために重要な確認書といえるでしょう。

各社で見積もり金額が違う理由

見各社で見積もり金額が違うのは、下記の理由が原因かもしれません。

・リスクを考慮して多めに見積もる

・導入するツールや作業範囲によって異なる

・見積の算出方法は4つある

それぞれ詳しく見ていきましょう。

【保険】リスクを考慮して多めに見積もる

見積もりを作る際は作業の遅延やトラブルなど、作業工数や金額が増える可能性を考慮しななければいけません。

プロジェクトの規模によっては大人数が作業に関わるため、人数や工数が増えるほどトラブルなどのリスクが高まります。

もし、開発が終了した段階で見積もりより高い金額になれば、発注者から「最初と話が違う」と不満が出るかもしれません。発注側は見積りによって予算を組むため、見積もり時点と作業完了時点の金額のズレはできるだけ防ぐ必要があります。

会社によって、どの程度リスクを考慮しているかで見積もり結果が異なるでしょう。

【クオリティー】導入するツールや作業範囲によって異なる

見積もり内容によって、受注側はどんなツールを導入すべきか、どの作業範囲を対応すべきか判断して見積もりを作成します。

例えば、開発したシステムをネット上にアップするまでの作業か、その後の運用まで対応するかで作業範囲や工数が異なります。

受注者側でクオリティーを確保するために、デザインや運用まで全て対応するように見積もりを提案される場合もあるため、見積もり内容をよく確認することが大切です。

【算出方法】見積の算出方法は4つある

算出方法が違えば、見積もり金額も変わります。ここでは、見積もりで利用される4つの工数算出方法を紹介します。

・類推見積

・WBS法

・パラメトリック見積

・プライスツーウィン法

それぞれ詳しく見ていきましょう。

　過去の事例をもとに見積もる｜類推見積（トップダウン）

類推見積は過去の事例をもとに、必要な工数や費用を予測して見積もりを出す方法です。過去の事例を参考にするため、作業に必要な時間や起こりうるリスクを把握しやすく、見積もり精度が高いのが特徴です。

一方で、データが無ければ見積もりの概算が出せない点がデメリット。実績が十分にあり、規模の大きいシステム開発会社で利用されることが多い方法です。

　細かく工数を分けて考える｜WBS法（ボトムアップ）

WBS法はシステム開発にかかる工数にかかる時間や予算を計算し、見積もりを出す方法です。完成までに必要な工数を洗い出すため、工数や費用が分かりやすいのが特徴のひとつ。

下記は経営管理システムを作る際のWBSモデルです。プロジェクトの中に細かく作業を分解しており、必要な工数が明確で見積もり内容が分かりやすいです。

引用：[標準プロナビWBS]

一方で、システム開発の規模や期間が大きくなる場合は見積もりを出す労力がかかるというデメリットも。

WBS法は小〜中規模のシステム開発の見積もり算出方法に向いているでしょう。

　特定の数式をもとに作成する｜パラメトリック見積（係数モデル）

パラメトリック見積は、システム開発にかかる工数を特定の数式を用いて計算する見積もり方法です。

特定の数式のことを係数モデルと呼ぶこともあり、係数モデルの一部を例に出すと下記のとおりです。

・FP法

・COCOMO法

・CoBRA法

データの取り出しが上手くいけば正確性が高まり、規模や期間に関わらず工数のデータが算出できるメリットがある一方、データの種類によって質が下がる可能性もあります。

　依頼者の予算をもとに作成する｜プライスツーウィン法

プライスツーウィン法とは、発注者の予算をもとに作業内容を決める見積もり方法です。予算内で開発を進めたい場合に活用され、見積もりと差が出にくい点がメリットです。

しかし、予算によってクオリティーや工数の制限がかかり、完成品の質が保証できないというデメリットが。

予算が厳しく設定されている場合は、プライスツーウィン法とそれ以外の見積もり方法を比較しながら見積もり内容を精査すると良いでしょう。

【全9項目】見積もり対象となる費用を徹底解説

ここからは、見積もり対象となる費用を9つ紹介します。紹介する項目はシステム開発の段階別で発生する費用です。

・準備

・開発

・導入

・その他

4つの段階に分けて詳しく説明します。

【準備期間】システムの内容をまとめる・進行するための費用

システム開発を始める際、発注者と受注者の間で情報の共有や今後の流れについて話す準備期間があります。準備段階で発生する費用は以下の2つです。

・要件定義費用

・進行管理費用

要件定義とは、発注者の求めるシステムの内容をヒアリングし、システム開発を行う際の作業範囲や工数を確定する作業のこと。要件定義によって、必要な作業内容を明確化し発注者と受注者それぞれの認識のすり合わせができます。

その後システム開発に進みますが、開発中の進捗を確認し、納期通りに作業を進行するにはディレクターが必要です。ディレクターは発注者へ情報を共有することもあり、社内外への連絡、ディレクション業務に対する作業費が発生します。

【開発期間】システム設計にかかる費用

開発期間にかかる主な費用は以下の3つです。

・設計費用

・デザイン費用

・開発費用

設計費用は、発注者用と技術者用それぞれの設計図を作成する費用です。発注者用に設計図が必要なのは、作業内に要件定義で決めた項目を確認するため。開発を始めれば変更ができないため、設計図の確認で開発前の最終確認を行います。

設計図に問題がなければシステム開発の各工程が進みます。デザイン費用や開発費用は、開発に携わるデザイナーやエンジニア、プログラマーの人件費と考えると良いでしょう。

【導入期間】システム完成後にかかる費用

システムの種類によりますが、システム完成後さらに導入するための工程があります。ここでかかる費用は下記の3点です。

・テスト費用

・導入費用

・導入支援費用

試験的にシステムを動かして動作を確認するテスト作業があり、エラーなどの誤作動が無いか、設計書通りに作業が完了しているか確認します。システムをリリースする場合は、導入のためのシステム連携や旧システムの対応など、リリースに関するサポートが必要です。

他にも、システムのマニュアルや初期設定、場合によっては技術者からの運用に関する説明会を実施する場合も。サポート内容によって費用の幅があります。

【その他】必要に応じてかかる費用

すべてのシステム開発でかかる訳ではありませんが、発生する可能性がある費用についても紹介します。

・購入費用

・旅費・交通費用

・運用・保守費用

購入費用とは、システム開発において連携する必要のあるサーバーやツールなどの購入費です。発注する際にすでに購入していれば、見積もり時に伝えておきましょう。

また、打ち合わせや開発段階で技術者や担当者が発注者の元へ訪問する可能性がある場合、旅費や交通費も発生します。オンライン会議などを活用して費用を抑えることも可能です。

システムを導入後、システム開発を行った会社に導入後の運用や保守を依頼することもあり、その場合は運用や保守に関する人件費や作業費がかかるでしょう。

【要確認】見積もりの妥当性を判断するための4つの注意点

ここからは見積もりを確認する際に注意する4つのポイントを紹介します。

・作業範囲を明確に提示しているか

・作業で発生するリスクの想定ができているか

・提示した数字に根拠があるか

・開発費以外の条件は明確になっているか

それぞれ詳しく見ていきましょう。

作業範囲を明確に提示しているか｜工数設定

発注者目線で必要な工数の数を確認しましょう。確認すべき点は進捗連絡の頻度や打ち合わせ数、開発以外の作業工数です。もし、工数に打ち合わせが含まれていない場合、別途打ち合わせ用の人件費がかかる可能性があるからです。

開発以外の作業工数は、要件定義や調査、マニュアル作成などにかかる工数です。工数の内訳が開発内容しかない場合、工数が追加でかかる可能性もあるため、事前に確認しましょう。

作業で発生するリスクの想定ができているか｜リスク管理

リスク管理に対する配慮も確認すべきポイントです。

リスク管理とは、開発中のエラーや修正に関する対応です。システム開発中には、エラーやバグなどが起こる可能性もあり、その修復をするために余分な日程や費用がかかる場合があります。

見積もりでは作業の納期や費用が提示されますが、その内容でリスクを考慮した項目や工数はどのくらいあるか確認しましょう。

提示した数字に根拠があるか｜妥当性

妥当性を判断するために、見積もりの数字について質問するのも良いでしょう。

例えば、開発に関わるプログラマーやデザイナーの人件費は、実力によって異なります。技術力が必要な場所に実力のある人材を配置し、単純作業が必要な場所に人件費の低い技術者を配置するなど、人材の使い方を確認すれば人件費の削減になります。

見積もりを見て、費用が不自然に高い、もしくは低い場合は担当者に質問しましょう。複数社に見積もりを取れば、各項目の大体の費用が分かってきます。

開発費以外の条件は明確になっているか｜事務関係

開発費用以外にも、下記の2点に注意しましょう。

・責任範疇

・検収方法

責任範疇とは、契約を進める際に確認すべき項目です。開発中の工数のずれ込みや途中の変更に関して費用が発生する場合、要件定義後の変更への対応など、受注者と発注者の責任の範囲を決めておけば、契約後のトラブルを防げます。

さらに、検収方法も事前に確認しておきましょう。検収中に発見した不具合に関する対応や修正、検収期間はいつまで有効かなど、事前に決めることが大切です。

【重要】見積もり依頼前に発注者が準備すべき項目

見積もりと実際にかかる費用の差を減らすために、発注者が準備すべき項目があります。

・システム開発の目的を明確化する

・見積もりに必要な詳細条件を提示する

・RFP（提案依頼書）を用意すれば見積もりの精度が上がる

それぞれ詳しく見ていきましょう。

システム開発の目的を明確化する

利用の目的や想定される利用者数、システムの導入によって何を目指すかなどを数値で表すとシステムの必要性が明確になります。

例えば、下記の項目を数値で表してみましょう。

・想定利用者数

・利用目的

・機能性

・操作性

・セキュリティー

例えば、飲食店で利用するシステムを開発したい場合、下のような数値で表せます。

想定利用者数	1日100人
利用目的	・店舗での待ち時間の受付、連絡・予約客の時間管理
機能性	・顧客への通知・タブレットでの使用
操作性	・従業員、顧客画面は別で設定
セキュリティー	・顧客情報の漏洩防止