システム開発の見積りのポイント。依頼方法と根拠や内訳などを解説【2024年版】

システム開発をIT企業に外注するときは、業者の選び方に注意が必要です。システム開発の見積りは高額となるケースが多いため、システム開発会社はそれぞれ独自の異なる見積り方法をとることが多いです。システム開発はWebの知識がない人にとっては、業者の作業内容が不透明でブラックボックス化もしやすいため、見積りをとる際は必ず根拠や内訳を求めるようにするのがいいでしょう。

ここでは企業担当者が初めてシステムの開発を外注する際に知っておきたい、見積りに関する知識やポイントをまとめてご紹介します。

システム開発の見積もりを外注先に依頼する事例が増加の背景

近年では零細中小企業でも自社のホームぺージを持つことは当たり前となりました。自社でSEOによる施策やWebサイトの更新している企業の中には、エンジニアを雇用しているところも普通にあります。

しかし、Webサイトのシステム開発となれば話は別です。高度なプログラミングスキルを持つシステムエンジニアが複数人必要となるため、IT企業や大手企業でもない限り、自社でシステム開発することは一般的ではありません。

将来的なコストダウン化と組織の肥大化の抑制が目的

しかし、近年は将来的なコストダウン化を目的に、大手企業であってもシステム開発を外注するケースも増えてきました。システムの開発から運用までを一貫して内製化すると、情報漏洩を最小限に抑えられますし、従業員のスキルも向上します。しかし、システムの運用にかかる人件費は重くのしかかり、従業員が退職した際に引継ぎが不十分であると、システム内部がブラックボックス化してしまいがちです。

そのため、コストダウンや組織の肥大化の抑制だけではなく、リスクヘッジの一環としても、システム開発は今後もアウトソーシングする傾向となることが予想されます。

システム開発の見積もりの取り方や外注先の選び方と注意点

初めてシステム開発を外注する企業担当者は、数多くあるIT企業の中からどのような基準で業者を選べばいいのかいまいち分かりません。安価な料金だけで決めてしまうと、想像していたのと違うシステムが納品される可能性もあるかもしれません。

そこで、ここではシステム開発を委託する業者の選び方と注意点をご紹介します。

相見積りでサンプルをとる。料金の妥当の有無を確認

システム開発を外注依頼する場合、最初に行うべきことは「相見積りの取得」です。複数社から見積書のサンプルをとって、費用を比較検討しますが、相見積もりをとる理由は、最安値の業者を探し当てることではありません。上述したように、システム開発のような高額なWeb案件では、品質を最重要視するのが失敗しない重要なポイントとなります。そのため、初回の相見積もりでは料金の相場と妥当性を確認するに留め、明らかに相場よりも突出した業者に関しては避けるようにするといいでしょう。

ただし、発注者が相見積もりをとることは業者も承知の上である場合は、複数の見積りをとっても金額に対して差は出ないこともあるかもしれません。

見積りの内訳が大切。不透明な業者に注意

システムの開発を業者に依頼する場合、料金はもちろん重要ですが、それ以上に注視してほしいのが「見積りの内訳」です。業者によって見積りの算出方法は異なるため、仮に料金が同じでも内訳は大きく違うことも普通にあります。

特に注意してほしいのが「内訳の記載項目が少ない」業者です。システムの開発期間は6か月以上におよぶこともあり、あらゆる分野の専門家が開発に携わります。そのため、開発費用も数百万円から1千万円を超えることもざらとなります。しかし、業者の中には見積りの内訳を意図的に不透明にしてブラックボックスにするところもあります。一方で見積書に料金の内訳をしっかりと明記している業者は、費用の算出を真面目にやっている証拠となるので、依頼主を見て料金を変えるような真似はないはずです。

開発の実績を確認。技術的リスクを回避

システム開発の業者を選ぶ指標の1つに「実績を確認する」ことが挙げられます。これまでどのようなシステムを開発してきたのか、また、今回自社が依頼するシステムに似たような開発実績があるかどうかは、外注先の担当者に直接確認するといいでしょう。

実績を詳しく確認せずに業者とシステム開発の契約をしてしまうと、後になって技術的な不具合が立て続けに発生するリスクがあります。システムを構築しているエンジニアですら原因が分からないエラーが発生し、納期が大幅に遅延したり、当初臨んだ機能を搭載できずに妥協することになる可能性もあります。そのような事態を回避するためにも、外注先がどの程度のシステム開発実績があるかを確認することは、とても重要なポイントとなります。

システム開発の見積りの依頼は根拠と内訳の把握が重要

システム開発の見積りを業者からとる場合、「費用の根拠と内訳」を把握することが必要となります。ただし、システム開発において、「内訳」を出すことは難しくはありませんが、「費用の根拠」を契約前に発注者に提出することは、想像以上に困難を極めます。

初期見積りで根拠を出すのが難しい理由

システム開発に着手するに当たり、最初に要件定義を作成します。要件定義は簡単に言えば「発注者の要望を整理して業務に落とし込む」こととなります。具体的には開発するシステムの運用目的・システムや機能、非機能の要件の定義・予算・スケジュール・発注者と業者の窓口担当や連絡手段などを書面に起こすことになります。しかし、要件定義を作成する前段階で詳細な費用を出すことは困難で、実際にかかる見積り金額と大きく乖離することもあります。そのため、問い合わせ時点で出す見積りに対して「この費用の根拠を明示してくれ」と言われても、業者からすると応答に困ってしまうことがあります。

見積りは2段階が多い。最初の費用は妥当性のみ判断で

しかし、発注する側としては、「会社に稟議をあげる必要があるから見積りは出してもらわないと困る」、「予算取りが必要だから契約前に費用を知る必要がある」という意見が普通です。そのため、近年では多くのIT企業が、概算となる見積りを初回に出して、その後、要件定義や基本設計を行ったのち、正確な見積りを再度提出するといった2段階見積りを提案しています。

ただし、初回の見積りはあくまでも概算となるので、2回目に提示される費用と比較して誤差があるのが普通です。そのため、発注者は多少高くなる可能性を考慮して予算を考えるようにしてください。

インフラ・システム開発の見積手法。工数と人件費で決める例が多い

インフラ・システム開発時に算出する見積手法は複数の方法があります。一般的に見積りは開発するシステムの規模や工数、携わる人の数で決まりますが、計算方法自体は業者によって考え方が異なります。

どの計算方法がいいかなどは特にありませんが、業者の見積手法を知っておくことで、妥当性や費用の内訳を理解することができます。

1．類推見積もり（トップダウン）

小規模のシステム開発でよく使われる見積手法となります。これまで開発したシステムの実績を振り返り、似通ったシステムがあれば、そのときの費用を模範とします。ただし、これまで実績のない内容のシステム構築であったり、大規模なシステム開発の場合は、決して小さくない誤差が生じることが多々あるため不向きとなります。

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

こちらは係数見積りとも呼ばれる見積手法となります。過去の実績から工数を想定して今回の依頼にかかる工数を機械的に算出します。トップダウン式の見積手法と似通っていますが、トップダウン式は過去に出した見積り金額に多少の調整を加えて発注者に提出する一方、パラメトリックは過去のデータから今回のシステム開発にフィットするように計算をし直します。ただし、パラメトリックで算出できるのはあくまでも理論値となるので、実際の労力やコストに差がでることもよくあります。

3．三点見積り

三点見積りは楽観値と悲観値とその中間の最可能値の3つの意見を平均値化した見積りとなります。例えば「このシステム開発は3か月でできる」という意見が最多を占めた場合は最可能値となり、「いや、2か月あれば大丈夫だよ」と言う意見が楽観値、「不具合が発生することを考えて4か月くらいは見ておいた方がいい」という意見が悲観値となります。

この数値を「（悲観値＋４×最可能値＋楽観値）÷６」の数式に当てはめて算出するのが三点見積りの手法となります。三点見積りの特徴は、システム開発の参画者が多いほど、正確な数値を出すことができることにあります。また、費用だけではなく、スケジュールや納期の計算にも使うことができます。しかし、小規模なシステム開発の場合、参画する人間はせいぜい数人程度となるので、数値の信憑性に乏しく、見積手法としてあまり適さないこともあります。

4．ボトムアップ（工数積上げ）

ボトムアップはシステム開発に必要な工数と成果物をブロックごとに分けて、1つひとつの作業量を精査して費用を算出し、最後に総計を求めます。ボトムアップは具体的な工程別の費用を出すことができるので、システム開発の見積り手法に向いていると言われています。

例えばトップダウン式の見積り手法では、発注者に対しては「過去に似たようなシステムを作った実績があります。そのときは〇〇円で契約したので、今回も同じ金額で提案いたします」という形で論理的とは言えません。一方でボトムアップであれば、「この作業には〇〇円かかり、合計で〇〇円となります」と説明できるため、発注者から理解と信頼を得ることができます。しかし、ボトムアップで見積りを作成するためには、ある程度要件定義と基本設計を作成する必要があるので、初期見積で出すのはなかなか困難です。

5．プライスツーウィン法

こちらもシステム開発でしばしば使われる見積り手法の1つです。プライスツーウィン法は、発注者の予算に合わせてできるだけ要望を汲みながらシステム開発をします。発注者の予算を超えないようにするのが優先となるので、発注担当者側からすると安心できます。ただし、発注者が要望するシステム開発が予算とどうしても釣り合わない場合は、搭載する機能を制限しなければならないため、事前に伝えていないと後ほどトラブルになる可能性もあります。

見積りの単価と工数の確認方法

システム開発の見積書には、多くのケースで「工数/人日（月）・単価」で内訳が計算されています。例えば「基本設計」の内訳項目に50人日で単価が200万円だとしたら、その見積書からは「1人のエンジニアが50日でかかる費用」を読み取ることができます。ただし、10人のエンジニアが5日で仕上げたとしても50人日ですし、50人のエンジニアが1日で仕上げても、やはり50人日と表記されるので注意してください。

また、各内訳項目から全体に対しての比率を計算することもできます。例えば基本設計の比率相場は全体の17%と言われておりますので、それを上回る金額で見積もられている場合は、「もしかすると基本設計は苦手なのかもしれない」と考えることができますし、逆に相場を下回る金額であった場合は、「この開発業者は過去に似たようなプログラミング実績があるから、作業が通常よりも少なく済むのかもしれない」などと推測することもできます。

システム開発の見積り項目・内訳を解説

システム開発の見積書に記載されている内訳項目は、業者によってそれほどの差異はありません。ただし、Webの分野に明るくない人が項目を見ても、それがどんな作業内容であるのかは分かりづらく、「要件定義だけでなんでこんなに高いんだ！」と訝しく思うこともあるかもしれません。

そこで、ここでは見積りによく記載される項目・内訳について詳しく説明します。

見積りの根拠も確認できる「要件定義」費用

要件定義は契約後に最初に業者が行う作業であり、システム開発をする各種条件を盛り込んだドキュメントとなります。システム開発を成功させる上で必要不可欠な要素となり、要件定義がしっかりと抑えられていないと、システム開発の根本が崩れてしまい、最悪やり直しになる可能性もあります。

システム開発を大きな流れで説明すると、1．要件定義、2．システム設計、3．導入、4．テストとなります。要件定義はシステム開発の土台となるため、作成にあたっては、業者担当者と綿密なやり取りが必要となります。

発注担当者との窓口業務「進行管理」費用

通常、発注者とシステム開発会社のエンジニアやデザイナーが直接会話することはなく、進行管理役のディレクターが間に入って窓口業務を担います。このディレクション費用は「進行管理費用」として見積りに計上されますが、「ディレクター費・プロジェクト進行費」といった名目の場合もあります。

進行管理の担当者とは契約前に話す機会もありますので、発注者は担当者の人柄で業者を選定するのも有効な方法です。担当者が自社の意見に耳を貸してくれなかったり、コミュニケーション能力が劣ると判断した場合は、いかに見積り金額が安くともリスクが勝ると考えるのがいいかもしれません。

見た目もユーザーの使いやすさで重要「デザイン」費用

システム開発におけるデザイン費用は、見た目（ユーザーインターフェース）と操作性に関わる費用となります。搭載されたシステムを使う従業員がWebの知識がなくとも運用できるよう、分かりやすい・使いやすいデザインであることが大切となります。

最も費用がかかる「開発・実装」費用

「開発・実装」の費用は、システム開発から搭載までの工程となります。見積りの中で最も費用が高額となり、総額の半分以上の比率を占めることになります。最低でもシステムエンジニアとプログラマーの2人は必要となることが多いので、人月100万円であれば3か月の開発期間で600万円かかる計算になります。

人月相場はあるものの、システムエンジニアやプログラマーのスキルによっても数十万円の差があります。開発業者はこの費用から人件費を捻出することになるため、なかなか値引きは難しいかもしれません。

運用後の「保守・管理」はシステム開発費の5%の比率を目安に

システム開発のテストを終えて運用開始後、保守管理に関しては内製化することも可能です。しかし、自社にIT部署がなかったり、エンジニアが在籍していない場合は、保守管理のために雇用するとコストがかかるため、開発業者に保守管理を任せるのが一般的となります。そのため、システム開発を契約するタイミングで保守管理についても打ち合わせをすることは普通にあり、見積りに組み込むとすると、開発にかかるコストのおよそ5%が目安と言われています。

システム開発の見積り上で考慮されるリスクと回避方法

システム開発を外注する場合は、多少なりとも一定のリスクが生じます。しかし、リスクの内容を事前に理解しておけば、契約時や見積り取得時にある程度想定することができます。

下記ではシステム開発を外注する際にしばしば散見されるリスクと回避方法をご紹介します。

1．企業の事業方針に関わる見積り「予算と納期」のリスク

発注する企業側が最も懸念するのが「予算内にシステム開発ができるのか」、そして「納期の遅延がないか」という点です。見積りから大きく予算をオーバーしたり、納期が遅れてしまう原因は幾つか考えられます。

予算をオーバーしてしまう原因

・最初に作成した要件定義が甘かった
・発注者側の要望が多く、追加機能を付けたため予算をオーバーした
・当初の想定よりも開発の工数が増えてしまった

納期が遅れてしまう原因

・開発人員に欠員が発生した
・進捗管理がうまくいかなかった
・ミスのリカバリがうまくいかなかった
・発注者が追加の機能を依頼したため

などが主な要因となります。
契約時や見積り提出時、要件定義作成の打ち合わせ時に予算や納期の確認はできますが、それでも若干の誤差はよくあります。
発注者側が行うリスク回避の対策としては、「予算を増やせないことを告げておく」、「納期に遅れた場合の遅延損害金を契約に盛り込む」などが挙げられます。

ただし、システム開発会社の中には契約条項を守らないずぼらな業者も存在しますので、ホームぺージで会社情報を吟味したり、担当者と複数回のコミュニケーションを図るなど、業者選びの目利きを養うことも重要となります。

2．依頼したシステムと異なる「仕様・機能」で納品されるリスク

予算と納期以外で発注者側が注意しなければならないのがシステム開発の「仕様と機能」です。契約時にしっかりと打ち合わせをしていれば、納品されるシステムの仕様や機能にギャップはないはずですが、それでも長期間におよぶ開発や多くの人がプロジェクトに参画していると、情報共有のミスや誤解が発生し、それがシステムの仕様・機能に影響を与えることは十分に考えられます。

また、進行管理する窓口担当者のコミュニケーション能力が不足していると、発注者が希望するシステムの全体像や運用方法のイメージが不十分で、結果として完成されたシステムに運用上支障がでるケースも想定されます。

このような依頼したシステムと異なる仕様・機能で納品されるリスクを回避する方法としては、「コミュニケーション能力が高い担当者のいる業者に外注を出す」、「システム要件を複雑にしすぎない」などが挙げられます。

3．契約書は最大のリスクヘッジ

システム開発はいずれも高額かつ中長期にわたるプロジェクトとなるため、具体的な項目を盛り込んだ契約書の締結が重要です。不測の事態が発生した際は、契約書に従って問題の解決を図ることができるのが理想となりますので、契約を交わす際は、どちらか一方が優位にならないように、公平で合理的な内容であることが求められます。

初めてシステム開発を業者に依頼するのであれば、「開発の範囲」と「仕様変更や機能を追加したときの対応と追加費用に関して」、そして「損害賠償の期間と上限となる具体的な金額」はとりわけ重点を置いて契約内容を確認してください。

まとめ：システム開発の見積りのポイント。依頼方法と根拠や内訳などを解説

今回はシステム開発の見積り方法や内訳・注意事項をご紹介しました。システム開発は場合によっては自社の業績や事業方針に大きな影響を与える一大プロジェクトとなります。そのため、安易に相見積もりで最安値の業者を選択するのではなく、自社の理想の仕様と機能を搭載したシステムをしっかりと開発してくれる業者を選ぶのが成功するポイントとなります。

初めてシステム開発の見積りをとる企業担当者は、複数の業者に見積り依頼すると同時に、開発会社のホームぺージや評判などの調査も怠らないようにしてください。

• #WEBシステム
• #WEB制作
• #費用