誰でもシステム開発の見積もり根拠をチェック・評価できるようになる方法～工数・妥当性の基礎知識～

システム開発の見積もりは複雑で分かりにくいと思われがちです。

依頼者側からすると工数や費用の妥当性も分からない場合が多く、開発側も依頼者との認識の相違が生まれるとトラブルの元となります。

この記事では、システム開発の見積もりの根拠をチェック・評価できるようになる方法を解説します。

これから見積もりをとる方、見積もりを出す会社の方に読んでいただけると幸いです。

本記事でご紹介している「見積もりの評価」をされたい方へ、弊社代表が無料で30分のスポットコンサルをさせていただきます。ご不明点をお気軽にご相談いただけますので、下記お問い合わせフォームよりご連絡くださいませ。

システム開発における見積もりには何が書かれているのか

システム開発における見積もりには、費用はもちろん工数や期間、算出方法などが記載されていますが、複雑化しやすい傾向があります。

さらに、プロジェクトによって、作業工程・開発方法・規模などが大きく異なるうえ、開発会社により費用の差も出やすいものです。

しかしシステム開発において、契約の前に見積もりを取ることは非常に重要といえます。なぜなら契約するか否かの判断だけでなく、契約後の費用面のトラブル防止にも大きく役立つからです。

また事前に相場を理解しておき、相見積もりを取ることで、よりマッチする開発会社を比較検討することができます。

システム開発のみならず、契約の前に見積もりを取ることは非常に重要です。契約するか否かの判断だけでなく、契約後の費用面のトラブル防止にも大きく役立ちます。

また事前に相場を理解しておき、相見積もりを取ることで、よりマッチする開発会社を比較検討することができるでしょう。

契約後や作業中にトラブルを生まないためにも、見積もりの内訳や費用の根拠を確認したうえで外注先を慎重に選びましょう。

システム開発の見積もり構成内訳～よくある費目・根拠を解説～

システム開発にかかる費用は多数ありますが、大部分が人件費です。よくある費目としては以下のものが挙げられます。

要件定義費

実際の設計などを行う前のシステムの方向性を決めるための費用です。機能の要不要や仕様を依頼者のニーズとすり合わせていきます。費用は作業時間に応じてかかる場合が多いため、システムが複雑であるほど費用はかかる傾向にあります。

設計費

要件定義で決めた仕様をプログラミングするための設計書を作る費用を指します。

プログラミング言語の選択や機器の環境も含まれます。

デザイン費

デザインとはユーザーインターフェース（UI）のデザイン費用を指します。

ユーザーから見た画面となるので、使い勝手・見やすさに大きく影響します。

開発書

プログラミングをするための費用を指します。

プログラマー・エンジニアの人件費がほとんどです。

テスト費

プログラミングしたシステムの操作性のテストを行うための費用を指します。

1つずつ構成単位をチェックする「単体テスト」、構成単位を組み合わせてチェックする「結合テスト」、ユーザーの使用前の「統合テスト」を段階をふみ確認していきます。

導入費

開発したシステムを導入するための費用です。

システムの初期設定の作業が該当します。

導入支援費

システムによっては、依頼者がスムーズに利用できるように支援が必要となる場合があります。例えば、操作に関するマニュアルを作成したり、操作方法の説明会を行ったりする費用が該当します。

運用保守費

開発したシステムを継続的に運用し、障害発生時に復旧するための費用です。

運用保守を含まないケースもあります。

交通費

打ち合わせの際の移動に費用がかかった場合、交通費と見積もりに含まれる場合があります。遠方の開発会社であれば交通費がかさむ可能性もあるでしょう。

システム開発の見積もり算出手法のパターン～根拠・妥当性のある工数算出手法とは何か？～

システム開発の見積もり算出手法は大きく4つに分けられます。それぞれの概要とメリットとデメリットをまとめました。

類推見積(トップダウン)

過去の類似したシステム開発のデータを元に、コストや必要な工数を見積もる手法です。他の手法と比較するとややざっくりとした推計手法と言えます。

メリット	デメリット
見積もりの算出が早い 類似データがあれば正確性に優れている 安価に算出できる	類似事例がないと算出できない 複雑・大規模なプロジェクトには不向き

係数モデル(パラメトリック)

係数モデル（パラメトリック）は特定の数学的「モデル」を利用し、システム開発に必要な各作業を「点数化」して見積もりを算出する手法です。

過去のデータを元にパラメータ化（点数化）し、システム開発の各項目を自動算出する手法であり、類推見積もりと併用もされます。

メリット	デメリット
知識や経験に左右されず見積もりの算出ができる プロジェクトの規模に差があっても対応可能	データとサンプルがないと精度が落ちる 点数で評価できない項目の選出が難しい

ボトムアップ(工数積上げ)

ボトムアップ（工数積上げ）は、システムを作るための作業を仮定して、工数を積み上げる手法です。工数を正確に細分化できれば、最も信頼性の高い見積もり方法で、開発会社と依頼者間のトラブルを防ぎやすくなります。

プロジェクトに要する作業の詳細を把握するために、WBS（ワークブレイクダウンストラクチャー）を活用すると良いでしょう。

メリット	デメリット
作業工程が抜けが発生しにくい 見積もりの精度が高い 依頼者が納得しやすい見積もりが作成できる	見積もりに時間がかかる 大規模な開発案件には不向き

プライスツーウィン法

プライスツーウィン法とは、依頼者の予算に合わせて見積もりを算出する手法です。

予算を元に工数などを見積もるため、予算ありきの開発であれば一見優れた手法に見えます。しかし論理的な根拠なしで予算に合わせた見積もりは、あまり良いとは言えず、避けられる傾向にあります。

メリット	デメリット
設定した予算の過不足を防ぎやすい	予算によっては機能不足などの影響を受ける

三点見積もり

三点見積もりとは、作業時間やコストを楽観値・最可能値・悲観値の3つから見積もる手法です。

通常よく使われる「最可能値」だけでなく楽観値と悲観値を加味するため、状況に応じた見積もりが可能となります。

メリット	デメリット
参加者の多いプロジェクトでも精度の高い見積もりが可能 信頼範囲の計算も可能	小規模プロジェクトには不向き

システム開発の見積もりを正しくチェック・評価するためには前提条件を合意しておく

システム開発の見積もりを評価するためには、見積もり発行者と合意を取るべき前提条件が多数あります。

依頼者と開発側のイメージの乖離を防ぎ、見積もりの精度を上げるためにも、前提条件は十分に明確にしておきましょう。

見積もりの対象範囲

システムの対象範囲を明確にしておきましょう。大規模システムになるほど、機能や連携のシステム等考慮すべきものが増えていきますので注意が必要です。

見積もりの対象外範囲

対象範囲と同時に、何を対象外とするのかも明記しておきましょう。どちらも明確にしておくことで前提条件における曖昧さを防ぐことができます。文章だけでは分かりにくいので、図面等の視覚的によりはっきりとした記載をすることもおすすめします。

使用技術

開発言語だけでもC言語、Java、PHP、Python、Rubyなど多岐に渡ります。サーバーやクラウドの使用有無など、見積もりの段階で分かるだけでも明記しておきましょう。

開発手法

システム開発のプロセスにはいくつか種類があります。ウォーターフォール型開発・アジャイル型開発・スパイラル型開発・プロトタイプ型開発・DevOpsなど、どのモデルで進行するか決めておきましょう。

プロジェクト期間

開発作業の期間がどの程度かかるかで費用は大幅に変わります。依頼者の要望と開発会社の人数によっても異なるため、スケジュールを確保しておきましょう。

要件

開発工程において要件定義が基盤となるように見積もりに大きく関わる部分です。どのような機能を必要としているか明確にしておきましょう。

運営方法

プロジェクトの進捗管理や推進をどうするのかを明記します。スケジュール通りに進行できているか、主にプロジェクトマネージャーによって行われます。

開発・ネットワーク環境

開発・ネットワーク環境は購入以外にも借りたり構築したりといった選択肢もあります。購入金額や借りられるかどうかの確約など、確実に確保できるようにしておきましょう。

テスト

どういったテストを行うのか、またテストの動作環境によっても工数が増えていきます。OSやブラウザのバージョンアップの影響を受けて費用がかさむ可能性があります。あらかじめ明記しておきましょう。

納品物

システム開発における納品物はシステムのみではありません。設計書1つとっても、ざっくりとした記載にせず、詳細が分かるようなレベルのものを依頼すると良いでしょう。

システム開発の見積もりを評価するためのチェックポイント～根拠の有無を見抜く方法～

システム開発の見積もりを評価するためには、どういった内容を確認すれば良いのでしょうか。

数字の根拠を見抜くために重要なチェックポイントをまとめました。

数字の根拠が明確か

各項目を確認し、適切であるか・不自然な箇所がないか・詳細が記載されているか確認しましょう。

曖昧であったり、項目内容が一括りにされていては費用の妥当性は分かりません。

前提条件を満たしているか

上記の前提条件を満たしているか、改めてチェックしましょう。対象範囲・使用技術・要件など、これらが正確でなければ見積もりの費用にも影響が出てしまいます。

リスクに対する見積もりが含まれてるか

システム開発の工程において、修正が必要となるケースは多々あります。修正の度に工数は増えてしまうため、必然的に費用も追加されてしまいます。見積もりでは、この修正等に対しての工程の費用が含まれているのか確認しておきましょう。

作業内容が明確か

システム開発は多数の作業工程を積み重ねています。そのため面倒でも、これらの工程1つ1つが明確にされているかチェックしましょう。ひとくちに「設計」「テスト」「導入」といっても、作業範囲や採用する手法は様々です。見積もりにも大きく影響するので、依頼者側も十分に把握しておく必要があります。

管理工数が含まれているか

工数に管理工数が含まれているかチェックしましょう。よくある作業として、進捗管理・品質管理・変更管理・障害管理がありますが、これらは他の作業の片手間でできるようなものではありません。別途計上しておく必要があります。

調査分析項目が含まれているか

要件定義の前の、事前調査や分析にかかる費用はよくある作業工程の中になく見落としがちです。現行システムだけでなく新しい技術に関しても調査分析が必要となる場合があるので、開発外で必要なコストが計上されているか確認しましょう。

機材の購入代が含まれてるか

システム開発の際に、機材の購入が必要な場合があります。ハードウェアやソフトウェア、サーバーなどその他必要なものがあるか、購入代が含まれているか確認しましょう。

検収について明確になっているか

要件通りにシステムが完成しているかどうか「検収」を行い判断しなければなりません。

この検収には様々な方法があり、また複数回行うケースも増えています。見積もりでは、検収方法や期間・不具合が見つかった場合の費用負担などが明確になっているか確認しておきましょう。

まとめ

この記事では、システム開発の見積もりの根拠をチェック・評価する方法を解説しました。

システム開発の工数・妥当性をおさえておけば、複雑になりやすい見積もりも自分で評価できるようになります。的確に判断してより良い費用で外注できるよう知識として覚えておきましょう。

本記事でご紹介している「見積もりの評価」をされたい方へ、弊社代表が無料で30分のスポットコンサルをさせていただきます。ご不明点をお気軽にご相談いただけますので、下記お問い合わせフォームよりご連絡くださいませ。