業務システム開発の費用はどう決まる？見積もりの内訳を工程別に解説

「開発会社から見積書が届いたが、金額が妥当なのか判断できない」「『システム開発一式 500万円』と書かれていて、何にいくらかかっているのか分からない」と感じていませんか？

結論からお伝えすると、業務システムの見積もりは、工程ごとの作業量（人日）を積み上げて、単価を掛けたものです。逆に言えば、工程の内訳さえ分かれば、専門知識がなくても「この見積もりは何を前提にしているのか」を読み解けます。

本記事では、見積書に出てくる金額が工程別にどう配分されるのか、同じ依頼なのに会社によって金額が変わる理由、そして見積書を受け取ったときに確認すべきポイントを、実際に業務システムの見積もりを作っている立場から解説します。

結論：見積もりは「工程 × 人日 × 単価」の積み上げ

業務システムの見積もりは、次の式でできています。

費用 ＝ 各工程の作業量（人日）の合計 × 1人日あたりの単価

「人日（にんにち）」とは、エンジニア1人が1日（8時間）働く作業量のことです。1人日あたりの単価は、依頼先によって幅がありますが、中小企業向けの開発会社では4万〜8万円程度が一つの目安になります。

そして、その作業量は工程ごとに積み上げられます。おおまかな配分は次のとおりです。

工程	費用に占める割合の目安	何をする工程か
要件定義	10〜20%	業務を整理し、何を作るかを決める
設計（画面・データ）	10〜15%	画面と保存するデータの構造を決める
実装（プログラミング）	30〜40%	実際にプログラムを書く
テスト	15〜25%	正しく動くか、業務が回るかを確認する
導入・データ移行・教育	5〜10%	本番環境の準備、既存データの移行、操作説明
プロジェクト管理	10〜15%	進行管理、仕様の調整、レビュー、検収対応
予備費（リスクバッファ）	10〜15%	仕様変更や手戻りへの備え

※開発会社や案件の性質によって配分は変わります。厳密な基準ではなく、「極端に偏っていないか」を見るための物差しとして使ってください。

この表で最も伝えたいのは、プログラムを書く工程は全体の3〜4割にすぎないということです。「実装だけ頼めば安くなるのでは」と考えても総額があまり下がらないのは、残りの6〜7割が別の工程で使われているからです。

なお、そもそもの費用の決まり方（作り方による桁の違い、SaaSやノーコードとの比較）は「システム開発はいくらかかる？中小企業向けに費用の相場と考え方を解説」で、規模別・機能別の金額感は「社内システム開発の費用相場はいくら？規模別・機能別の目安を中小企業向けに解説」で解説しています。本記事はその次の段階、受け取った見積書の中身を読むための記事です。

基礎知識：見積書によく出てくる3つの言葉

内訳を読む前に、見積書に頻出する言葉を押さえておきます。

• 人日（にんにち）：エンジニア1人が1日（8時間）働く作業量。「20人日」なら1人で20日、2人なら10日かかる量
• 人月（にんげつ）：1人が1か月働く作業量。おおむね20人日＝1人月として換算されます
• 単価：1人日（または1人月）あたりの金額。エンジニアの技術レベルや会社の規模で変わります

見積書の項目が「日報入力機能　15人日」となっていれば、これは**「その機能を作るのにエンジニアが15日分働く想定です」**という意味です。単価が5万円なら75万円になります。

ここが分かると、見積書は「金額の羅列」から「作業量の申告」に見え方が変わります。金額に納得できないときに問うべきなのは「安くなりませんか」ではなく、**「この作業に本当に15日かかりますか」「その15日で何をしますか」**です。

工程別の内訳：何にお金がかかっているのか

7つの工程それぞれで、実際に何が行われているのかを見ていきます。

要件定義（10〜20%）：何を作るかを決める

現場へのヒアリング、業務フローの整理、既存のExcelや帳票の確認を行い、「システムで何をどこまでやるか」を決める工程です。

軽視されやすい工程ですが、ここでの決定が残り全ての工程の作業量を決めます。要件定義を省いて安く見せている見積もりは、後工程で「これは聞いていません」という追加費用が発生しやすくなります。

業務が複雑な会社ほど、この工程の比率は上がります。特に、複数の部署や拠点で運用が違う場合は、その違いを吸収するか統一するかの判断そのものに時間がかかります。

設計（10〜15%）：画面とデータの構造を決める

画面の構成、入力項目、権限の範囲、データベースの構造などを決める工程です。

ここで効いてくるのが画面の数です。画面が1つ増えれば、設計・実装・テストの3工程すべてに作業量が加算されます。見積もりを下げたいときに「画面を減らせないか」を確認するのが有効なのは、この構造があるからです。

実装（30〜40%）：プログラムを書く

見積もりの中で最も大きな塊ですが、それでも全体の4割程度です。

実装の作業量は、単純な入力・一覧画面か、計算や集計を伴う画面かで大きく変わります。たとえば「日報を入力する画面」より、「日報の工数から案件ごとの原価と仕掛を計算する画面」のほうが、画面数は同じでも作業量は数倍になります。計算のルールが業務ごとに違い、例外も多いためです。

テスト（15〜25%）：業務が回るかを確認する

プログラムが動くかどうかの確認（単体テスト）だけでなく、実際の業務の流れで使えるかの確認（結合テスト・受入テスト）が含まれます。

業務システムでは、このテストが実装に迫るほどの比率になることも珍しくありません。「月末の締め処理をしたら先月分が変更できなくなるか」「集計結果が既存のExcelと一致するか」といった確認は、業務を理解していないとできず、時間もかかるためです。

見積書のテスト工程が極端に薄い場合は、その分の検証を発注側が負担する前提になっていないかを確認してください。

導入・データ移行・教育（5〜10%）：使える状態にする

本番サーバーの構築、既存データの移行、操作マニュアルの作成、社員への説明などが含まれます。

比率としては小さく見えますが、既存データの移行は状態次第で大きく膨らむ部分です。Excelの表記ゆれ（「株式会社ABC」と「(株)ABC」が混在しているなど）が多いと、移行前の整理に想定外の時間がかかります。

プロジェクト管理（10〜15%）：進行と判断を管理する

打ち合わせ、進捗管理、仕様変更の判断、レビュー、検収対応にかかる工数です。見積書では「PM費」「管理費」と書かれることもあります。

「作業していないのに費用が発生するのはおかしい」と思われがちですが、この工程がない開発は、仕様の食い違いが放置されて後半で大きな手戻りになります。開発期間が長い案件ほど、比率は上がります。

予備費（10〜15%）：手戻りに備える

要件の確認漏れ、想定と違ったデータ、受入時の修正依頼など、事前には読み切れない作業への備えです。

見積書に明示されている場合もあれば、各工程の人日に上乗せされていて見えない場合もあります。明示されているほうが健全です。予備費ゼロの見積もりは、実際には各工程に隠れているか、後から追加請求になるかのどちらかである可能性が高いと考えてください。

同じ依頼なのに金額が違う3つの理由

複数社から見積もりを取ると、2倍以上の差がつくことがあります。原因はほぼ次の3つです。

1. 単価が違う

同じ作業量でも、1人日4万円の会社と8万円の会社では総額が倍になります。単価の差は、会社の規模、技術者の経験、間接部門の人数などから生まれます。

ただし、単価が安い＝総額が安いとは限りません。作業効率が低ければ人日が増え、結果として総額は変わらないこともあります。

2. 想定している作る量が違う

最も多いのがこれです。A社は「日報の入力と一覧だけ」、B社は「原価集計と帳票出力まで」を想定していれば、金額が違うのは当然です。

金額を比べる前に、各社の見積もりが同じ画面数・同じ帳票数を想定しているかを確認してください。ここが揃っていない比較は、比較になっていません。

3. 保守・移行・教育の扱いが違う

初期費用に導入支援を含む会社と、別見積もりにする会社があります。保守費も、月額に含める範囲が会社ごとに異なります。

初期費用が安く見えても、5年間の総額では逆転することがあります。判断は必ず初期費用＋保守費×利用年数＋サーバーなどの利用料×利用年数で行ってください。保守費にサーバーのホスティング費が含まれる契約と、別請求になる契約があるため、どちらの扱いかも確認が必要です。

見積書を受け取ったら確認する7つのポイント

金額の妥当性を判断するために、次の7点を確認してください。開発会社に質問してよい内容です。

1. 工程ごとの人日が書かれているか：「一式」だけの見積もりは、後から範囲の解釈違いが起きやすい
2. 1人日（または1人月）の単価はいくらか：単価が分かると、他社との比較が作業量の比較に変わる
3. 画面数と帳票数はいくつを想定しているか：作る量の前提が揃うと、金額差の理由が見える
4. テストの範囲は誰がどこまでやるか：受入テストを発注側が担う前提なら、自社の工数も見込む必要がある
5. 既存データの移行は含まれているか：対象データの範囲と、整理を誰がやるかを確認する
6. 保守費に何が含まれるか：不具合対応のみか、小さな改修も含むか、対応時間帯と一次回答の目安はどうか
7. 仕様変更が発生したときの扱い：追加見積もりになる基準と、単価が決まっているか

このうち特に重要なのは1と3です。工程別の人日と、想定している画面・帳票の数。この2つが分かれば、金額の妥当性はかなりの精度で判断できます。

初期費用に含まれないもの

見積書の金額が「作る費用」だけを指している場合、次の費用は別に見込む必要があります。

• サーバー・ドメイン費用：小規模なシステムで月額数千円〜数万円程度
• 保守費用：月額数万円〜、または開発費の年10〜15%程度を目安にする会社が多い
• 機能追加の費用：使い始めてから出てくる要望への対応。保守枠内か都度見積もりかは契約次第
• 社内の工数：ヒアリング対応、受入テスト、社員教育にかかる自社の時間

最後の「社内の工数」は見積書に載りませんが、実際には確実に発生します。特に受入テストは、業務を知っている人でなければ判断できないため、現場の担当者に一定の時間を確保しておく必要があります。

ByteBloomの視点：実際の見積もりはこう積み上げている

ByteBloomで業務システムの見積もりを作るときは、機能を「作業区分」に分けて、区分ごとに標準人日を置き、最後に予備費を乗せる方法を取っています。

たとえば、製造業向けに日報・工程・原価を扱うシステムを見積もった際は、次のような区分で積み上げました。

• 現場ヒアリング・業務フロー整理
• 既存Excelの仕様・入出力整理
• 工程・ステータス・権限の定義
• 基盤（サーバー・データベース）の構築
• 認証・アクセス制御
• 案件・工番・マスタ管理
• 日報入力・承認・締め処理
• 集計・原価・仕掛計算
• 帳票・Excel出力
• 結合テスト・受入支援
• マニュアル作成・社員教育・本番切替
• プロジェクト管理・仕様変更対応

この積み上げで実感するのは、現場でよく話題になる「日報の入力画面」の人日は、全体から見れば一部にすぎないということです。実際には、集計・原価計算と、結合テスト・受入支援が大きな比率を占めます。前者は業務ルールが会社ごとに違うため、後者は既存のExcelと数字が一致することを1つずつ確認するためです。

もう1つ、この案件では合計人日に対して15%の予備費を明示して乗せています。理由は、仕様の確認漏れ、既存データの差異、受入時の修正依頼が、実務上ほぼ必ず発生するからです。ここを見積もりに含めずに進めると、追加請求か、品質を落とすかのどちらかになります。

見積書を見比べるときは、金額そのものより、この積み上げの過程を説明できる会社かどうかを見てください。「なぜこの機能が20人日なのか」を業務の言葉で説明できる会社は、業務を理解したうえで見積もっています。逆に、質問しても「そういうものです」としか返ってこない場合は、根拠の薄い数字である可能性があります。

案件・日報・原価をつなげる場合に作業量がどこで膨らむのかは、「案件管理・日報・原価管理がバラバラだと何が起きる？情報の分断が生む5つの問題と解決方法」で業務の側から解説しています。

まとめ：内訳が読めれば、金額の妥当性は判断できる

• 業務システムの見積もりは「工程ごとの人日 × 単価」の積み上げでできている
• プログラムを書く実装工程は全体の3〜4割。残りは要件定義・設計・テスト・導入・管理・予備費
• 同じ依頼で金額が違う理由は、単価・想定している作る量・保守や移行の扱いの3つ
• 見積書では「工程別の人日」と「想定している画面数・帳票数」を必ず確認する
• 初期費用のほかに、サーバー費・保守費・自社の工数がかかる

見積書の金額は、開発会社が「これだけの作業が必要だと考えた」という申告です。その根拠を聞くことは、値切ることとは違います。根拠を説明できる会社を選ぶことが、結果として費用の失敗を防ぎます。

見積もりの内容を一緒に確認したい方へ

ByteBloomでは、他社の見積もりについてのご相談も承っています。「金額が妥当か分からない」「この項目が何を指すのか知りたい」という段階でも構いません。業務の内容を伺ったうえで、内訳の読み方と、範囲を調整する余地があるかを一緒に確認します。

• 費用の決まり方の全体像は「システム開発はいくらかかる？中小企業向けに費用の相場と考え方を解説」をご覧ください
• 規模別・機能別の金額の目安は「社内システム開発の費用相場はいくら？規模別・機能別の目安を中小企業向けに解説」で解説しています
• SaaSで足りるかどうかの判断は「SaaSとオリジナルシステム、どちらを選ぶべき？中小企業向けに判断基準を解説」が参考になります
• 実際の開発事例は開発実績・事例のページ、開発の進め方はサービス紹介ページで紹介しています
• 見積書を見ながら相談したい方は、お問い合わせフォームからお気軽にご連絡ください