一式見積とは？システム開発見積書で最初に見るべき内訳

システム開発の見積書を受け取ったとき、最初に目が行くのは総額だと思います。ただ、総額が高いか安いかを判断する前に確認しておきたいのが、その金額が「何に対する金額なのか」です。とくに「システム開発一式 ◯◯◯万円」のように、工程や作業の内訳が示されないままひとつの金額にまとめられた見積書は、金額の妥当性を判断する材料がそろっていない状態だといえます。

本記事は、連載「システム開発の見積書を読む技術」の第1回として、この「一式見積」をどう読むかを整理します。一式という書き方そのものが問題なのではなく、一式の中身を発注側と開発会社が同じ認識で共有できているかどうかが論点です。

まず結論

• 「一式」表記そのものは問題ではありません。問題は、対象範囲・工程・成果物・追加条件が見えないまま発注判断に進むことです。
• 最初に見るべき項目は、対象範囲、含まれる工程、含まれない作業、成果物、追加費用の条件の5つです。
• 内訳の依頼は値下げ交渉ではなく、社内説明と前提共有のために行うと伝えると、開発会社との関係を崩さず確認できます。

見る項目	判断のしかた	発注前の確認ポイント
対象範囲	どの業務・機能まで含むか	「販売管理一式」ではなく対象業務を明文化する
含まれる工程	要件定義・設計・開発・テスト・移行・教育の有無	工程別に含む/別途を分ける
追加条件	どこから追加費用になるか	仕様変更、移行、帳票、外部連携を先に確認する

この連載での位置づけ

• 次に読む記事：連載第2回：人月単価と工数
• 比較表で整理する：連載第11回：比較表
• 発注前の質問に落とし込む：連載第12回：開発会社への20問

---

一式見積とは何か

一式見積とは、要件定義・設計・開発・テストといった複数の工程や作業をまとめて、ひとつの金額として提示する見積の書き方です。たとえば次のような表記が該当します。

• 「業務システム開発一式 800万円」
• 「Webサイト構築一式 250万円」
• 「基幹システム改修一式 1,200万円」

一式という表記自体は、商習慣として広く使われています。問題は、その金額に「どの作業まで含まれているか」「どこからが追加費用になるか」が読み取れないと、後から認識のずれが生じやすい点にあります。

発注側が「当然含まれている」と考えていた作業（たとえばデータ移行や操作研修）が、開発会社の見積では含まれていなかった、というずれはよく起こります。これは一方が不誠実だから起こるのではなく、内訳が言語化されていないために、それぞれの前提が見えないまま進んでしまうことが原因です。

---

一式見積で起きやすい3つの認識のずれ

一式見積のまま発注に進むと、次のような認識のずれが起きやすくなります。

ずれの種類	発注側の想定	開発会社の前提	後で起きること
範囲のずれ	データ移行も含まれている	移行は別途見積	移行費が追加請求になる
工程のずれ	要件定義から伴走してくれる	要件は確定済みの前提	仕様調整が追加工数になる
品質のずれ	テストは網羅的に行う	主要機能の動作確認まで	不具合対応の範囲で揉める

いずれも、契約後・開発着手後に表面化することが多く、その時点では仕様も体制も動き始めているため、調整のコストが大きくなります。見積書の段階で内訳を分解しておけば、これらのずれは発注前に確認できます。

---

一式を分解して見るべき工程

一式見積を受け取ったら、最低限、次の工程単位に分解してもらうと内訳が読みやすくなります。これは値下げを求めるためではなく、金額の根拠と範囲を共有するための分解です。

• 要件定義：業務のヒアリング、やりたいことの整理、要件の文書化
• 設計：画面設計、データ設計、システム構成の設計
• 開発（実装）：プログラムの作成、単体での動作確認
• テスト：結合テスト、総合テスト、受入テストの支援
• 移行：既存データの移行、移行リハーサル
• 教育・導入支援：操作マニュアル、操作研修、立ち上がり支援
• プロジェクト管理：進捗管理、課題管理、定例会議の運営
• 保守・運用：リリース後の障害対応、軽微な改修、問い合わせ対応

工程ごとに金額が分かれていれば、「どの工程に重みがある見積なのか」「自社で巻き取れる作業はあるか」を発注側でも検討できます。各工程の費用構成や妥当性の見方は、システム開発の見積書の見方やシステム開発の見積書の内訳ガイドでも整理しています。

---

一式見積を受け取ったときの確認の順番

金額を見て交渉に入る前に、次の順番で確認すると論点が整理しやすくなります。

1. 対象範囲：どの業務・どの機能までが対象か
2. 含まれている工程：要件定義からテスト・移行・教育まで、どこまで含むか
3. 含まれていないもの：別途見積になる作業、前提として発注側が用意するもの
4. 成果物：各工程で受け取れるドキュメントや納品物
5. 追加費用の条件：どういう場合に追加費用が発生するか

この5点が見積書または補足資料で確認できれば、一式という表記であっても、内容を理解したうえで判断できます。

---

一式見積が適している場面、分解したい場面

一式見積は、どのような場合でも避けるべきというものではありません。作業範囲が小さく、内容がはっきり固まっている場合は、一式のまま進めるほうが手続きがシンプルになることもあります。一方で、金額が大きい、複数の業務にまたがる、要件がまだ固まっていない、といった場合は、内訳を分解して確認しておくほうが、後の認識のずれを抑えられます。

場面	進め方の目安	理由
範囲が小さく内容が確定している	一式のままでも検討しやすい	内訳のずれが起きにくい
金額が大きい	分解を依頼したい	工程ごとの妥当性を確認したい
複数の業務にまたがる	分解を依頼したい	範囲のずれが起きやすい
要件が固まっていない	分解を依頼したい	前提の共有が先に必要

内訳の共有を依頼するときの伝え方

内訳を求めると身構えられることがありますが、目的は値下げではなく前提の共有です。たとえば「総額の妥当性を社内で説明したいので、要件定義・設計・開発・テスト・移行・教育・保守の工程ごとに分けて教えてください」と伝えると、意図が伝わりやすくなります。分解の依頼に率直に応じてくれるかどうかも、相手の姿勢を知る手がかりになります。

依頼のタイミングは、提案書や見積書を受け取った直後が自然です。「検討を進める前に内容を正確に把握したい」という趣旨を添えれば、先方も答えやすくなります。また、工程を分解してもらった後は「各工程で受け取れる成果物は何ですか」と続けて聞くと、費用の使い道がさらにつかみやすくなります。

一式の中の工程を読む——実務的なアプローチ

一式見積を受け取ったとき、内訳が示されていなくても、発注側で「おおよその工程配分」を想定してから確認に入る方法があります。たとえば中規模の業務システムでは、要件定義・設計・開発・テスト・移行・教育・管理のそれぞれが、全体に対してどの程度の比重を占めるかには、ある程度の目安があります。

あくまで会話の出発点として使える概念的な目安を示すと、次のようなイメージになります（実際の比率はプロジェクトの特性で変わります）。

工程	比重のイメージ	主な作業
要件定義	比較的重め	ヒアリング、整理、文書化
設計	中程度	画面・データ・構成設計
開発（実装）	最も重め	プログラム作成、単体確認
テスト	中程度	結合・総合・受入支援
移行・教育	プロジェクトによる	データ移行、研修
管理・保守	一定割合	進捗管理、リリース後対応

この概念図を頭に置きながら「要件定義はどの程度の比重ですか」と尋ねると、開発会社は工程の比重を説明しやすくなります。提示された内訳が想定と大きく外れている場合は、その理由を確認する自然な糸口になります。

---

発注前チェックリスト（一式見積を受け取ったら）

次の項目を確認してから、社内検討や相見積もりの比較に進むことをおすすめします。

• 「一式」の対象範囲（業務・機能）が言葉で説明されているか
• 要件定義・設計・開発・テストの工程が区別されているか
• データ移行が含まれているか、別途かが明記されているか
• 操作研修・マニュアルなどの導入支援の扱いが分かるか
• 保守・運用がこの金額に含まれるか、別契約かが分かるか
• 各工程で受け取れる成果物（ドキュメント類）が示されているか
• 追加費用が発生する条件と、その場合の単価の考え方が分かるか
• 前提として発注側が用意すべきもの（データ、素材、決裁）が書かれているか
• 複数の工程を通じてアサインされる担当者の役割が説明されているか
• 工程ごとの完了条件（何をもって完了とするか）が共有されているか

---

開発会社に確認する質問

一式見積の内訳を共有するために、次のような質問が有効です。いずれも金額を下げる交渉ではなく、内容を理解するための質問です。

• 「この一式金額には、要件定義からテスト・移行・教育のどこまでが含まれますか」
• 「データ移行は含まれていますか。含まれない場合、別途の目安はどの程度ですか」
• 「各工程で、私たちはどのような成果物を受け取れますか」
• 「追加費用が発生するのは、どのようなケースですか」
• 「私たち発注側で事前に用意しておくべきものはありますか」
• 「各工程の完了時点で、私たちは何を確認・承認することになりますか」
• 「この一式の金額は、要件が変わった場合にどのように見直されますか」

回答が具体的であるほど、見積の前提が言語化されており、進め方を共有しやすい相手だと判断できます。

---

相談前に整理しておくとよい情報

開発会社や第三者に相談する前に、次の情報を手元で整理しておくと、内訳の確認がスムーズになります。

• 解決したい業務上の課題（何に困っているか）
• 対象としたい業務範囲（どの部署・どの作業か）
• 現状の進め方（手作業、Excel、既存システムなど）
• 希望時期と、社内で決まっている予算の考え方（上限・幅）
• すでに受け取っている見積書があれば、その金額と項目

これらが整理されていれば、一式見積の内訳を確認する際にも、自社の前提を相手に正確に伝えられます。

---

GXOの発注前レビューで見る実務メモ

GXOが見積書の相談を受けるときは、最初から「高い」「安い」を判定せず、見積の前提を分解します。まず初期費用、月額費用、追加費用、発注側作業、リスク項目の5区分に分けます。そのうえで、3社比較、5年TCO、社内稟議、契約条件の順に確認します。これにより、金額の差が価格差なのか、範囲差なのか、リスクの見込み方の差なのかを説明しやすくなります。

発注側で用意しておくとよいのは、完璧な要件定義書ではありません。現行業務の流れ、利用者数、画面・帳票・連携の数、希望時期、予算の幅、社内決裁者、止められない業務、個人情報や機密情報の有無です。これらが曖昧なまま見積を取ると、開発会社ごとに前提が変わり、相見積もりの比較が難しくなります。

確認領域	発注側が用意する情報	見積で確認すること
業務範囲	対象部署、利用者数、現行フロー	どこまでが開発対象か
機能規模	画面数、帳票数、API本数	工数の根拠が説明できるか
データ	移行対象、件数、クレンジング要否	移行費・移行リハーサルの有無
運用	利用時間、障害時の影響、社内担当	保守範囲、SLA、月額費用
契約	請負/準委任、検収、知財、再委託	責任分界と追加費用の条件
稟議	予算上限、比較対象、判断基準	3社比較や5年TCOで説明できるか

この整理を先に行うと、AI開発、セキュリティ要件、補助金活用を含む案件でも、見積の前提を同じ粒度にそろえやすくなります。特に補助金を使う場合は、対象経費と対象外経費、発注前着手の可否、証憑の残し方を見積段階で確認しておく必要があります。

参考にすべき一次情報・確認観点

見積書を社内稟議やベンダー比較に使う場合は、一般論だけで判断せず、公式資料と自社データを照合してください。特に契約形態、責任分界、DX投資の目的、セキュリティ要件は、見積金額より前にそろえるべき前提です。

• IPA「情報システム・モデル取引・契約書」：請負、準委任、成果物、検収、責任分界を確認する際の参考になります。
• 経済産業省「DX推進指標」：経営課題、ITシステム、組織体制を分けて、DX投資の目的を確認する際の参考になります。
• 自社の見積比較では、3社比較、5年TCO、月額5万円・10万円・15万円、画面20件、帳票10件、API3本、移行データ1000件、受入テスト5日、操作研修2回、障害受付24時間、初期予算500万円・1000万円など、仮でも数字を置いて前提をそろえます。
• AI開発、セキュリティ要件、補助金活用を含む案件では、機能要件だけでなく、ログ保管、個人情報、権限管理、証跡、補助対象経費の切り分けも見積条件に入れてください。

よくある質問

Q. 一式見積を受け取ったら、必ず断るべきですか。

A. いいえ。一式という表記そのものが問題なのではなく、内訳の前提を双方で共有できているかが論点です。範囲が小さく内容が固まっていれば、一式のままでも検討できます。金額が大きい場合や要件がまだ固まっていない場合は、工程ごとの内訳を依頼してから判断するのが安全です。

Q. 内訳を求めると、相手に失礼になりませんか。

A. 目的を「社内で総額の妥当性を説明するため」と伝えれば、失礼にはあたりません。多くの開発会社は内訳の提示に応じます。むしろ、その応じ方そのものが、前提を共有しようとする姿勢の手がかりになります。

Q. 一式見積で最初に確認すべき項目はどれですか。

A. 対象範囲、含まれる工程、含まれていないもの、成果物、追加費用の条件の5点です。この5点が確認できれば、一式という表記であっても、内容を理解したうえで判断できます。

Q. 内訳を分解してもらうと、見積の金額が変わることがありますか。

A. 分解すること自体で金額が変わるわけではありません。ただ、内訳を確認する過程で、当初の見積に含まれていなかった作業が明確になり、追加が必要と判明することがあります。それは分解によって初めて見えた項目なので、後で発覚するよりも発注前に整理できたほうが双方にとってよい状態だといえます。

---

まとめ

一式見積は、書き方そのものが問題なのではなく、内訳が共有されないまま進むことで認識のずれが生じやすい点に注意が必要です。総額の高い・安いを判断する前に、対象範囲・工程・含まれないもの・成果物・追加費用の条件を分解して確認することで、見積の妥当性を発注前に検討できます。次回以降は、人月単価や工数といった、内訳の中身そのものの読み方を扱います。

---

関連記事

• 連載第2回：人月単価と工数
• システム開発の見積書の見方｜失敗しないための7つのチェック項目
• システム開発 見積書の内訳ガイド｜人月単価・工数・追加費用の妥当性
• システム開発の相見積もり｜3社比較の正しい方法と判断基準

システム開発の見積・相見積もりを整理しませんか

GXOでは、システム開発の見積書、相見積もり、要件定義、開発会社選定について、発注前の整理をご支援します。総額だけでなく、工数、保守範囲、追加費用、体制、契約条件まで確認し、自社に合う進め方を一緒に整理します。

システム開発の見積・相見積もりを相談する

※ 初回相談では、営業資料の説明よりも見積内容と発注前の論点整理を優先します。