システム開発の見積書「一式」は何が問題？工程・成果物・工数へ分ける確認方法

システム開発の見積書を開いたら「システム開発費　一式　◯◯◯万円」と書かれていた。金額が高いのか安いのかを判断する前に、そもそも何に対する金額なのかが分からない——この記事は、その「一式」を工程・成果物・工数へ分けるための手順書です。相場レンジを当てにいくのではなく、目の前の見積書1枚を、発注判断ができる単位まで分解します。

この記事の結論｜「一式」は金額の問題ではなく、分解単位の問題

先に結論から書きます。

「一式」で困るのは、金額が分からないことではありません。金額を評価するための単位が見積書に存在しないことです。 100万円が高いか安いかは、それが「画面5本の実装」なのか「要件定義から本番移行まで」なのかで判断が正反対になります。一式は、この分母を書かないまま分子だけを提示している状態です。

したがって、一式を見つけたときの正しい反応は「高すぎませんか」と値段を疑うことではなく、「この行を工程・成果物・工数のどれかで分けてください」と分解単位を要求することです。分解を依頼した結果、ベンダーがすぐに内訳を出せるなら、それは単に見積書の表記が要約されていただけです。分解できないなら、ベンダー自身もまだ見積もれていない可能性があります。後者のほうが、発注側にとってははるかに重い情報です。

一式を見つけたら、4つの状態のどれかに割り当てる

「一式＝悪い見積書」と決めつけると判断を誤ります。実務では、次の4状態に仕分けるところから始めます。本記事は最後にこの表へ戻ってきます。

状態	定義	発注側の次の行動
説明済み	一式の内訳が別紙・機能一覧・WBS・提案書のどこかに存在し、参照先が示されている	参照先と見積書の金額が対応しているかだけ確認して先へ進む
要確認	内訳は作れるが見積書に載っていない。ベンダーが根拠を口頭で説明できる	書面で内訳を受け取り、契約書の別紙に添付する
高リスク	内訳を求めても出てこない、または前提条件・対象外が定義されていない	契約前に分解を完了させる。分解できないまま請負総額で契約しない
判断不能	そもそも要件が確定しておらず、ベンダー側も見積もれる段階にない	金額の議論をやめ、要件定義を分離発注できないか検討する

「高リスク」と「判断不能」は似て見えますが、対処がまったく違います。高リスクはベンダー側の情報開示の問題なので、契約前に書面で分解させれば解消できます（口頭の説明だけでは足りません）。判断不能はプロジェクトの成熟度の問題なので、質問しても解決しません。この2つを混同すると、答えの出ない質問をベンダーに投げ続けることになります。

この記事で扱わないこと

金額レンジの話はしません。「システム開発はいくらが相場か」は別テーマで、種類別・規模別の費用構造はシステム開発の費用相場と見積もり妥当性の判断にまとめています。複数社の見積もりを同じ条件へそろえて並べる方法は開発会社の見積もり比較ガイドが担当です。本記事は1社から受け取った見積書1枚を分解する手順に絞ります。

見積書には「一式」がどう書かれているか

「一式」はひとつの表記ではありません。何をまとめているかによって、聞くべきことが変わります。実務で見かける形は大きく3タイプです。

タイプ1｜機能一式（何を作るかがまとまっている）

品名                                    数量   単位   金額
────────────────────────────────────────────────────
会員管理システム開発                       1    式    ◯,◯◯◯,◯◯◯

作るものの範囲がまるごと1行になっている形です。会員管理システムに「退会処理」が含まれるのか、「管理者用のCSV出力」が含まれるのかが、この行からは読み取れません。追加費用が最も発生しやすいのがこのタイプで、稼働後に「その機能は一式の範囲外です」という説明が出てきます。

タイプ2｜工程一式（作る手順がまとまっている）

品名                                    数量   単位   金額
────────────────────────────────────────────────────
設計・開発・テスト                         1    式    ◯,◯◯◯,◯◯◯

工程がまとまっている形です。厄介なのは、この書き方だとテストがどれだけ積まれているかが見えないことです。同じ総額でも、テストを厚く積んでいる見積もりと、ほとんど積んでいない見積もりでは、納品後に起きることがまったく違います。安く見える一式ほど、この行の中身を確認する価値があります。

タイプ3｜費目一式（人件費以外の枠がまとまっている）

品名                                    数量   単位   金額
────────────────────────────────────────────────────
プロジェクト管理費                         1    式    ◯,◯◯◯,◯◯◯
諸経費・管理費                            1    式      ◯◯◯,◯◯◯

PM費・管理費・諸経費・間接費といった名前で計上される枠です。金額の根拠が「総額の10〜15%」という比率で説明されることが多く、比率が慣習の範囲に収まっていると、それ以上は追及されずに通ってしまいます（この水準は業界慣習値で、公的機関が定めた相場ではありません。後述します）。ただし比率が妥当でも、その費用で誰が何を決め、何を出してくれるのかは別問題です。このタイプは本記事の後半で1章を使って扱います。

上の3つは見積書の書式パターンを示したもので、特定の実在する見積書ではありません。金額欄は意図的に伏せています。

3タイプの見分け方と、最初に聞くこと

タイプ	まとめられているもの	分解すべき単位	最初の質問
機能一式	作る対象の範囲	画面・API・帳票・バッチ・権限ロール	「この一式に含まれる機能の一覧をください」
工程一式	作る手順	要件定義・設計・実装・テスト・移行・受入支援	「工程ごとの工数と金額に分けてください」
費目一式	人件費以外の枠	役割・期間・成果物・実費	「この費用で作成される成果物は何ですか」

1枚の見積書に3タイプが同時に存在することもあります。その場合は機能一式から先に分解してください。作る範囲が決まらないと、工程の工数もPM費の期間も確定しないためです。

「一式」が隠しているのは分解単位である

ここからが本記事の中心です。一式を分解するときに、感覚で「もう少し細かく書いてください」と依頼しても、たいてい少し細かい一式が返ってきます。分解には基準が要ります。

基準になるのは、契約で定めるべき項目

IPA（情報処理推進機構）が公開している「情報システム・モデル取引・契約書（第二版）」（2020年12月22日公表。第一版は2007年に経済産業省が公開）は第4条で、個別契約を結ぶときに「以下の各号のうち必要となる取引条件を定める」として、次の12項目を挙げています。この12項目は、そのまま「一式に何が欠けているか」の点検リストとして使えます。

#	個別契約で定める事項（モデル契約書 第4条）	「一式」1行だと欠けるもの	発注側の確認
①	具体的作業内容（範囲、仕様等）	何を作るか・どこまでやるか	機能一覧または作業一覧が別紙にあるか
②	契約類型（請負・準委任）	完成義務があるかどうか	工程ごとに請負か準委任かが書かれているか
③	作業期間又は納期	いつ終わるか	工程別の期間が引かれているか
④	作業スケジュール	途中の節目	マイルストーンと中間確認の日程
⑤	甲・乙の役割分担	発注側が何をやるか	自社側の作業（データ準備・レビュー・受入テスト）の記載
⑥	連絡協議会の運営に関する事項	誰がどの頻度で決めるか	定例会の頻度・出席者・決定権限
⑦	発注側が提供する情報・資料・機器・設備等	自社が渡すもの	提供物と提供期限
⑧	作業環境	どこで作るか	環境の用意はどちらの負担か
⑨	納入物の明細及び納入場所	何が手元に残るか	ドキュメント・ソースコード・環境の一覧
⑩	委託料及びその支払方法	支払い条件	着手金・中間金・検収後の比率
⑪	検査又は確認に関する事項	終わったと判断する基準	検収基準と検収期間
⑫	その他個別業務遂行に必要な事項	個別の前提	前提条件・対象外の記載

注目してほしいのは⑨です。モデル契約書は納入物について「明細」を求めています。一式という表記は、定義上この明細を提示していない状態です。12項目は「必要となるものを定める」という建て付けなので、常に全部が必須というわけではありません。ただし⑨だけは、一式のままでは書きようがありません。「内訳を出してほしい」というお願いを、「契約書に書く項目だから出してほしい」という要求へ言い換えられるのは、この12項目があるからです。

分解の3軸

12項目を発注側の作業に落とすと、分解は次の3軸になります。この順番で進めるのが最も速いです。

1. 工程で分ける（要件定義／設計／実装／テスト／移行／受入支援）── 契約類型と検収の単位が決まる
2. 成果物で分ける（何が納品され、何が手元に残るか）── 検収基準と引き継ぎ条件が決まる
3. 工数で分ける（誰が何時間、どの作業に）── 金額の妥当性を初めて評価できる

多くの発注担当者はいきなり3の工数へ行こうとしますが、工程と成果物が決まっていない状態の工数表は検証できません。工数の妥当性は、最後に分かることです。

軸1｜工程で分ける──どこで契約が切れるか

工程一式を分けるとき、独自の工程名を発明する必要はありません。公的なモデルがあります。

モデル契約書が置いている工程の区切り

IPAのモデル取引・契約書は、システム開発を企画・要件定義段階／開発段階／運用段階／保守段階に分け、各フェーズを別々の契約単位として扱う「多段階契約」の考え方を採っています。IPAの解説資料（2025年4月の講演資料、©2020-2025 IPA）では、フェーズと契約類型の組み合わせが次のように整理されています。

資料のスライド名は「（参考）フェーズと契約類型のパターン」で、開発段階はAとBのどちらかを選ぶ建て付けになっています。表を上から順に流れる工程系列として読まないでください（[P4]と[P6]は同時に存在しません）。

フェーズ区分	工程	契約類型
企画段階	[P1] システム化の方向性〜要件定義	準委任
開発段階（パターンA）	[P2] 外部設計	準委任
開発段階（パターンA）	[P4] 内部設計〜結合テスト	請負
開発段階（パターンA）	[P5] システムテスト〜受入・導入支援	準委任
開発段階（パターンB）	[P3] 外部設計	請負
開発段階（パターンB）	[P6] 内部設計〜システムテスト	請負
開発段階（パターンB）	[P7] 受入・導入支援	準委任
運用・保守段階	[P8] 運用テスト	準委任
運用・保守段階	[P9] 運用〜保守	請負または準委任

AとBの違いは、外部設計を準委任で始めるか請負で始めるかです。資料は、外部設計フェーズとシステムテストフェーズの契約類型をそろえる、という考え方でこの2パターンを示しています（モデル契約書 第3章第3節 第24条）。自社の見積書がどちらに近いかを見ると、ベンダーが完成義務をどこから負うつもりなのかが分かります。

経営判断としてここが重要なのは、請負なら「完成させる義務」があり、準委任なら「専門家として誠実に作業を遂行する義務」があるという点です。要件がまだ動く工程を請負総額で固定すると、変更のたびに再見積もりの交渉が発生します。逆に、仕様が確定した実装工程を準委任にすると、完成の責任が発注側に残ります。工程一式は、この境目を見えなくします。

「一式」で見えなくなる、もうひとつの区切り

モデル契約書には多段階契約と再見積りの考え方が組み込まれており、見積もりも1回で終わらせない前提です。IPAの整理では、RFI（情報提供依頼）はまだ見積もり以前の段階です。**RFP①に対して見積①（試算）、RFP②に対して見積②（概算）**が出され、見積③（確定）はさらに後、外部設計フェーズに入ってから出ます。つまり確定見積もりは、RFPを出した時点ではまだ出てきません。

つまり、一式で書かれた見積もりが「概算」なのか「確定」なのかは、それ自体が確認事項です。概算なのに確定のつもりで社内稟議へ回してしまう事故は、この確認を飛ばすと起きます。

段階ごとに、精度はどれくらい違うか

一般社団法人 日本情報システム・ユーザー協会（JUAS）の「2025年度 システム開発・保守QCDs研究会」（2026年4月9日）の分科会①「プロマネとは見積もりだ！ 見積もりリスクを下げるポイントの検討と整理」は、見積もりを3フェーズに分けて精度の目安を示しています。

先に資料の性格を断っておきます。JUASはユーザー企業の協会ですが、この分科会の成果物は「見積もりを作る側」のチェックシートです（利用想定に「営業が案件獲得の可否判断をする」「失注リスクを減らす」といった記述があります）。発注側は、ベンダーが何を見て見積もりを組んでいるかを知る資料として読むのが正しい使い方です。

また、下表の精度レンジはPMBOKやISO21500で一般に言われる値を研究会が参照したもので、JUASが実測した統計ではありません（資料内でも「PMBOK、ISO21500を参考」と注記されています）。目安として扱ってください。

見積もりの段階	主な目的	精度の目安	「一式」の許容度
①超概算見積もり	案件の初期判断（Go/No-Go）、概略の資金枠	−50%〜+100%	許容される。むしろレンジで示すのが正しい
②概算見積もり	予算確保、提案比較、契約候補の方針決定	−25%〜+75%	工程・主要機能までは分解されている必要がある
③詳細見積もり	契約締結、確定見積もり、変更管理の基準	−5%〜+15%	一式のままで契約してはいけない

この表の使い方はシンプルです。手元の見積書が①なのに③のつもりで扱っていないかを確認します。①の段階の一式に対して「内訳を細かく出せ」と迫っても、意味のある数字は返ってきません。逆に、契約直前の③で一式が残っているなら、それは分解を要求すべき状態です。

同じ資料は、詳細見積もりのアウトプットとして「確定見積・基準スケジュール・変更管理基準・リスク対応費・マネジメントリザーブ」を挙げています。契約に使う見積書には、金額だけでなく変更が起きたときの扱いまで含まれているのが本来の姿です。

軸2｜成果物で分ける──何が手元に残るか

工程が分かれたら、次は各工程で何が納品されるかです。ここが曖昧なまま進むと、検収の基準が作れません。

モデル契約書が定義しているドキュメント

モデル契約書は、工程の節目で交わす書面を条文とセットで定義しています。見積書の一式を分解するとき、この書面が作られる前提になっているかを聞くと、工程の実在性が確認できます。

書面	根拠条文	いつ出るか	発注側にとっての意味
業務終了報告書／業務終了確認書	第23条・第32条	準委任の工程の完了時	準委任でも「終わった」の定義がある
外部設計書検収依頼書（兼納品書）／外部設計書承認書	請負型の外部設計工程	外部設計の完了時	設計を承認した時点が変更管理の起点になる
検収依頼書（兼納品書）	第26条	開発物の納品時	検収期間の起算点
検査合格書	第28条	検収完了時	支払い条件と結びつく
変更提案書・変更管理書	第34〜37条	仕様変更の発生時	追加費用の発生手続き
プロジェクト推進体制図	第9条・第10条	契約時	誰が意思決定するかの明示

「納入物の明細」を書けるかどうかが分岐点

前章の第4条⑨のとおり、個別契約には納入物の明細が要ります。実務では、次のリストをそのまま埋めてもらうのが早いです。

• 要件定義書（機能要件・非機能要件を含むか）
• 外部設計書（画面遷移図・帳票レイアウト・外部インターフェース仕様を含むか）
• 内部設計書（納品対象かどうか。対象外とする会社も多い）
• ソースコード（納品の有無・形式・リポジトリの移管可否）
• テスト計画書・テスト仕様書・テスト結果報告書
• 移行計画書・移行結果報告書
• 運用手順書・障害対応手順書
• 環境構築手順書、またはインフラ構成定義
• 各種アカウント・権限（クラウド、ドメイン、外部サービス）

「一式」で納品されるものが減るわけではありません。減るのは、減っていることに気づく機会です。 内部設計書やテスト仕様書が納品対象外であること自体は珍しくありませんが、それを知らずに保守フェーズへ入ると、別のベンダーへ引き継げないことが後から分かります。

軸3｜工数で分ける──WBSのどの階層まで割られているか

工程と成果物が決まって、初めて工数の話ができます。

WBSの階層を合わせて話す

JUASの資料は、見積もり手法の説明でWBSの階層を明示しています。L3が機能グループ、L4が機能、L5が詳細機能です。超概算ではL3〜L4、概算ではL4〜L5、詳細見積もりではL4〜L5に加えて工程まで割る、という整理になっています。

WBS階層	粒度	例	この階層で見積もれる段階
L3	機能グループ	会員管理、注文管理	超概算
L4	機能	ログイン、ログアウト、ホーム画面	超概算〜詳細
L5	詳細機能	パスワードリセット、ロック解除	概算〜詳細

（L4の例は資料に記載されているもの、L3とL5の例は本記事による補足です）

「一式を分解してください」ではなく「L4（機能単位）まで割った工数表をください」と依頼すると、返ってくるものの粒度が安定します。相手が使っている言葉で聞くほうが、正確なものが早く出ます。

工数の不確実性をどう扱っているか

同資料は、詳細見積もりでは詳細WBS単位に三点見積もりを適用してリスクを織り込むとしています。三点見積もりの期待値は次の式です。

期待値 =（楽観値 + 4 × 最可能値 + 悲観値）÷ 6

発注側がこの計算をする必要はありません。確認したいのは、不確実性を数字として扱っているか、それとも一式の中に感覚で埋めているかです。「バッファはどこに、どれだけ入っていますか」と聞いて、金額と考え方が返ってくるなら前者です。

一式の中で、実際に工数を食っているもの

見積書の課金単位は「画面数」「機能数」「人月」といった数えやすいものになります。ところが実際に工数を食う作業は、たいてい数えにくいところにあります。このズレが、一式の中で最も見えなくなる部分です。

実際に工数を食う作業	なぜ数えにくいか	見積書での現れ方
要件が決まるまでの往復	回数が事前に読めない	要件定義の工数に一括で埋まる
連携先・他ベンダーとの調整待ち	相手の都合に依存する	どこにも計上されず、遅延として現れる
テストの再実行	不具合の件数次第	テスト工数に1回分しか積まれていないことがある
移行のリハーサル	実データを見るまで分からない	移行費に含まれず、本番直前に追加見積もりになる
環境構築とデータ準備	発注側の作業と混ざる	役割分担が曖昧だと双方が「相手がやる」と思っている
レビューと承認の待ち時間	発注側の意思決定速度に依存する	PM費に埋まる

この表の右列は、そのまま「後から揉める場所」の一覧です。 一式を分解する目的は金額を削ることではなく、これらが誰の負担でどう扱われるかを契約前に決めておくことにあります。

とくに「要件が決まるまでの往復」「調整待ち」「レビュー待ち」は、発注側の動き方でコストが変わる項目です。ベンダーの見積もりが高いように見えて、実は自社の意思決定の遅さを織り込んだ金額だった、ということも起こります。第8条（協働と役割分担）を確認する意味は、ここにもあります。

機能一式を、画面・API・処理へ分解する

工程一式より厄介なのが機能一式です。工程は名前が標準化されていますが、機能は案件ごとに違うため、分解の切り口を発注側が持っておく必要があります。

数えられる単位に落とす

分解の切り口	数えるもの	見積書で確認すること
画面	画面数、画面あたりの状態数（一覧・詳細・編集・確認・完了）	「画面20本」の20が何を数えたものか
API・外部連携	連携先の数、インターフェースの本数、認証方式	相手側の仕様が確定しているか、相手側の調整工数が誰の負担か
帳票・バッチ	帳票数、定期実行処理の数	帳票のレイアウト確定が誰の作業か
権限・ロール	ロール数、ロールごとの操作可否	管理者機能が範囲に入っているか
データ移行	移行対象のテーブル数・件数・変換ルール数	移行が一式に含まれるか、別計上か
非機能要件	同時接続数、応答時間、稼働率、バックアップ世代	数値目標が書かれているか

この表の右列は、そのまま質問になります。「画面20本」という記載があっても、20が何を数えた20なのかは書かれていないことがほとんどです。一覧画面と編集画面を1本と数える会社と2本と数える会社では、同じ「20本」でも実際の作業量は大きく変わります。

一式のままだと、追加費用の境界が引けない

機能一式の実害は、稼働までではなく稼働直前に出ます。「この機能は入っていると思っていた」という認識のずれが起きたとき、一式には含まれる／含まれないを判定する文書がありません。結果として、力関係で決まるか、関係が悪化するかのどちらかになります。

モデル契約書が第36条で「未確定事項の取扱い」を定めているのは、この事態を予防するためです。同条は、発注側の事情で確定できない事項がある場合に、未確定事項の内容とその確定予定時期、確定によって委託料・作業期間・納期の変更を要する場合はそれを受け入れることを、双方記名押印した書面で残す手続きを置いています。つまり、決まっていないことを「決まっていない」と書いたうえで契約する方法が用意されています。一式は、決まっていないことを見えなくするだけで、決めたことにはなりません。

追加費用が発生する条件そのものの整理は、開発費が後から増える条件と対象外・仕様変更の見方で扱っています。

「PM・管理費という一式」をどう確認するか

見積書の中で、最も一式のまま通過しやすいのがPM費・プロジェクト管理費・管理費・諸経費といった行です。ここだけは章を分けて扱います。

割合で判断すると、判断したことにならない

PM費の妥当性は、しばしば「総額の10〜15%程度が一般的」という比率で説明されます。この水準自体は、複数のSIerの公開資料や実務の慣習として広く語られているもので、頭に入れておく価値はあります。ただし業界慣習値であって、公的機関が定めた相場ではありません。IPAが公開していた「ソフトウェア開発分析データ集」は5,546プロジェクトの定量データを扱っていましたが、最新版は2022年版で、同ページには事業終了に伴い今後の発行予定はない旨が記載されています（2026年8月18日確認）。工程別の比率を最新の公的統計で検算できる状態ではない、というのが実情です。

そして比率で見ることには、根本的な限界があります。比率は「総額が正しい」ことを前提にした指標だからです。総額が2倍に膨らんでいれば、比率が12%でもPM費は2倍になります。比率が妥当だという確認は、金額が妥当だという確認になりません。

代わりに、意思決定と成果物で確認する

PM費が何の対価かを言い換えると、「決めること」と「決めた記録を残すこと」の対価です。ここはモデル契約書が具体的に書いている領域なので、条文を手がかりに確認できます。

PMが担う意思決定・作業	根拠となる条項	発注側が受け取るもの	見積書・提案書で確認すること
役割分担を決め、共同作業と分担作業を定義する	第8条（協働と役割分担）	作業責任分担表（別添）	発注側の作業が書かれているか
推進体制を定め、窓口と決定権限を明示する	第9条・第10条	プロジェクト推進体制図	PMの氏名・稼働率・兼任状況
定例で協議し、決定事項を記録する	第12条（連絡協議会）	議事録、決定事項一覧	開催頻度と出席者の役割
中間資料を承認させ、後戻りの起点を作る	第35条（中間資料のユーザによる承認）	承認記録	承認をどの単位で取るか
未確定事項を書面化し、確定予定時期を握る	第36条（未確定事項の取扱い）	未確定事項リストと確定予定時期	未確定事項が存在する前提になっているか
変更を管理し、費用とスケジュールへ反映する	第37条（変更管理手続）	変更提案書・変更管理書	変更管理の手続きが定義されているか
複数ベンダーがいる場合の調整責任を負う	第13条（マルチベンダの調整等の責任）	調整範囲の定義	他社との調整が範囲に入っているか
検収の基準と手続きを設計する	第26条〜第28条	検収基準、検査合格書	検収の合否基準が数値化されているか

第37条は、変更管理書に記載する事項として次の8項目を挙げています。

1. 変更の名称
2. 提案の責任者
3. 年月日
4. 変更の理由
5. 変更に係る仕様を含む変更の詳細事項
6. 変更のために費用を要する場合はその額
7. 検討期間を含めた変更作業のスケジュール
8. その他変更が本契約及び個別契約の条件（作業期間又は納期、委託料、契約条項等）に与える影響

発注側にとって最も重いのは8番目です。個々の変更が納期と委託料へどう効くかを、変更のたびに書面で示させる項目だからです。PM費を払うということは、この8項目が埋まった書面が変更のたびに出てくる体制にお金を払うということです。「PM費に何が含まれますか」より「変更が起きたとき、この8項目はどの書式で出てきますか」と聞くほうが、返答の質が上がります。

PMは発注側にも義務がある、という前提

IPAの解説は、プロジェクトマネジメント義務と協力義務について、ベンダーとユーザーの間の情報の非対称性を前提にしたものだと整理しています。システム開発についてはベンダーが専門性を持つ一方、そのシステムが扱う業務についてはユーザー自身が精通している。**「一方が主でもう一方が従という関係ではない」**という点に注意が必要だ、と明記されています。

これはPM費の見方に直結します。PM費を「ベンダーが勝手に進めてくれる費用」と理解していると、発注側の協力が滞ったときに、PM費を払っているのに進まないという状態になります。見積書を受け取った段階で自社側が誰を何%出すのかを確認すると、PM費の議論が現実的になります。第8条が定める作業責任分担表は、そのための書面です。

PM費が0円、または書かれていないとき

PM費が計上されていない見積書は、安く見えます。しかし管理作業が消えるわけではないので、実際には次のどれかが起きています。

• 他の工程の工数に溶かして計上している（悪いことではない。ただし内訳を聞けば分かるはず）
• 管理を発注側がやる前提になっている（自社に管理できる人がいるかの確認が必要）
• 管理コストを見込んでいない（進行が滞ったときに誰も動かない）

3つ目が最も危険で、これは過小見積もりの典型例です。総額が安いこと自体は問題ではありません。問題は、安さの理由が「効率的だから」なのか「必要な作業を数えていないから」なのかが、一式のままでは区別できないことです。

「諸経費」「管理費」との違いを分けておく

PM費と諸経費・管理費は、まとめて計上されることがありますが性質が違います。

費目	性質	確認の仕方
プロジェクト管理費（PM費）	人の稼働に対する費用	誰が、何%の稼働で、何か月入るか
諸経費・一般管理費	会社の間接費の配賦	何に対する何%か、他の見積行にも乗っているか
実費（交通費・ライセンス・クラウド利用料）	立替または実額請求	実額精算か定額か、上限があるか

このうち実費は、システム開発費と混ざると総額の意味が変わります。クラウド利用料やサードパーティのライセンス料が一式に含まれている場合、稼働後も継続して発生する費用が初期費用に紛れ込んでいることになります。「この一式のうち、稼働後も毎月発生するものはありますか」という質問で切り分けられます。

「一式」が合理的なケース

ここまで分解の手順を書きましたが、すべての一式を分解すべきというわけではありません。次のケースでは、一式のままでも問題になりにくく、むしろ分解を求めることが交渉全体の効率を落とします。

ケース1｜金額が小さい付帯費用

総額に対する比率が小さい付帯費用（郵送費、軽微な備品、少額のドメイン費用など）は、一式でも実害が出ません。分解を求める行を絞ることは、発注側の交渉力を保つうえでも重要です。すべての行に同じ強度で質問すると、本当に重要な行への回答も薄くなります。

ケース2｜超概算段階で、意図的にレンジを示している

前述のとおり、超概算見積もりの精度目安は−50%〜+100%です。この段階では、細かい内訳を出すこと自体が精度の誤解を生みます。一式＋レンジ提示は、この段階では誠実な出し方です。確認すべきは内訳ではなく、「どの段階の見積もりか」「確定見積もりはいつ、何が決まったら出せるか」です。

ケース3｜納入物の明細が別紙に存在する

見積書の本紙が「システム開発費　一式」でも、機能一覧・WBS・提案書のいずれかに内訳があり、見積書がそれを参照しているなら、実質的には分解済みです。この場合に必要なのは分解の依頼ではなく、別紙を契約書に添付して、参照関係を契約上有効にすることです。冒頭の4状態でいう「説明済み」がこれにあたります。

ケース4｜成果物ベースの固定価格で、検収基準が明確

工数ではなく成果物に対して価格を決める契約では、内部の工数配分は受注側の裁量です。成果物と検収基準が定義されていれば、工数の内訳を開示させる必然性は下がります。この場合に確認するのは工数ではなく、検収基準・変更条件・保証範囲です。

ケース5｜パッケージやSaaSの標準機能部分

既製品の標準機能を導入する部分は、そもそも工数で積み上がっていません。ここを人月へ分解させても意味のある数字は出ません。確認するのはカスタマイズ部分との境界です。「標準機能でそのまま使う範囲」と「設定で対応する範囲」と「作り込む範囲」の3つに分かれていれば、一式でも判断できます。

確認が必要なケース｜4状態に仕分ける判定表

冒頭の4状態へ戻ります。分解を依頼する前でも、見積書と提案書を突き合わせるだけで、ある程度の仕分けができます。

確認項目	説明済み	要確認	高リスク	判断不能
作業範囲	機能一覧または作業一覧が別紙にある	提案書に記載はあるが見積書と対応していない	範囲を示す資料がどこにもない	要件がまだ固まっていない
工程	工程別に金額が分かれている	工程名はあるが金額が1行	工程の区切りがない	開発方式も決まっていない
契約類型	工程ごとに請負／準委任が明示	契約書ドラフトで確認予定	総額のみで類型の記載なし	契約の相手も未確定
納入物	納入物の明細がある	口頭で説明を受けた	納品されるものが不明	何が必要かも定義できていない
検収基準	合否の基準が書かれている	「協議のうえ決定」とある	記載なし	検収する主体が決まっていない
前提条件・対象外	対象外が列挙されている	前提条件のみ記載	どちらも記載なし	前提を置ける情報がない
変更時の扱い	変更管理の手続きが定義されている	「別途協議」とある	記載なし	変更以前に初期範囲が未定
PM費	体制・期間・成果物が対応している	金額のみで内容は口頭	計上なし、または説明なし	体制を議論する段階にない

表の読み方

• 「説明済み」が大半なら、分解の依頼は不要です。参照関係を契約書へ落とす作業に進みます。
• 「要確認」が混じっているなら、次章の依頼文面をそのまま送ります。1〜2往復で片づく範囲です。
• 「高リスク」が3つ以上あるなら、金額の交渉を始める前に分解を完了させます。ここで急いで契約すると、追加費用の交渉材料を発注側が失います。
• 「判断不能」が並ぶなら、見積もりの問題ではありません。要件定義を分離して発注できないか、あるいは小さな範囲で試作してから本体を見積もれないかを検討する段階です。

「高リスク」と「判断不能」の切り分けだけは、間違えないでください。判断不能の状態で分解を要求すると、ベンダーは推測で埋めた内訳を作ることになり、精度のない数字が「確定見積もり」として一人歩きします。 これは一式より悪い状態です。

安い「一式」のほうが危ないことがある

一式の議論は「水増しされているのではないか」という方向に流れがちですが、実務で被害が大きいのは逆方向です。

過小見積もりが引き起こすこと

JUASの研究会資料は、過小見積もり（実見積額 < 適正見積）のリスクを品質・コスト・納期・対外面の4面で整理しています。品質面ではテスト不足・手戻り増加による品質低下と顧客クレームの増加、コスト面では追加人員・残業・外注による追加コストの発生、納期面では納期遅延や納品失敗、対外面では信頼の喪失が挙げられています。

発注側から見ると、過小見積もりは契約時点では「安くて助かる」としか見えません。問題が表面化するのは、テスト工程に入ってからです。そしてその時点では、もう他社へ切り替えられません。

一式に埋もれやすい4つの工程

同資料は、見積もりが上手くいかない原因を7つに分類しており、1番目に挙げているのが「要件・スコープ関連」（仕様が曖昧／受け入れ基準不在、スコープクリープ、非機能要件の把握不足、前提条件の未共有）です。実際、一式の中で削られていても気づきにくいのは次の4つです。

抜けやすい工程	一式のとき、どう見えるか	確認の質問
テスト	「設計・開発・テスト一式」の中に含まれているように見える	テスト工程の工数と、単体・結合・システム・受入のどこまでを含むか
データ移行	開発費に含まれているように見える	移行が範囲に入っているか。対象データ・件数・変換ルール数・リハーサル回数
セキュリティ	触れられていない	脆弱性診断・セキュリティ要件の実装が範囲か。モデル契約書第50条の観点
PM	計上されていない、または比率だけ	前章の意思決定と成果物の表で確認

JUASの資料が概算見積もりの前提条件として「性能要件・運用要件・監視要件・可用性」を挙げ、「漏れると追加費用・再作業に直結」と注記しているとおり、非機能要件は一式の中で最も見えなくなりやすい部分です。

テスト費用が見積書でどう扱われるべきかは、テスト費用が高い・書かれていないときの判断でより詳しく整理しています。

ベンダーへそのまま送れる分解依頼文と、確認質問10

ここからは実際に送る文面です。相手を疑う書き方をせず、契約に必要だから聞いている、という立て付けにするのが要点です。

依頼メールの文面

お世話になっております。
お送りいただいたお見積書について、社内の稟議および契約書の別紙作成にあたり、
いくつか内訳を確認させていただきたく存じます。

金額の妥当性を疑うものではなく、契約時に定める作業範囲・納入物・
検収条件を明確にするための確認です。
下記のうち、既存の資料（機能一覧・WBS・提案書等）でカバーされている
ものがあれば、該当資料のご送付でも差し支えありません。

ご対応が可能な範囲・期日について、まずご教示いただけますと幸いです。

確認質問10（コピペしてそのまま使えます）

1. この見積もりは、試算（超概算）・概算・確定（詳細）のどの段階にあたりますか。確定見積もりを出せるのは、何が決まった後になりますか。
2. 「一式」と記載された行について、工程（要件定義・設計・実装・テスト・移行・受入支援）ごとの工数と金額に分けていただけますか。
3. 各工程の契約類型（請負・準委任）はどのようにお考えですか。工程ごとに分けて締結することは可能ですか。
4. 納入物の明細をご提示ください。ソースコード、内部設計書、テスト仕様書、運用手順書、環境構築手順書が納品対象に含まれるかを、それぞれお聞かせください。
5. 機能一覧をWBSのL4（機能単位）まで割った形でいただけますか。画面数を記載いただく場合、一覧・詳細・編集などをどう数えているかも併記してください。
6. テスト工程について、単体・結合・システム・受入のどこまでが範囲で、それぞれ何人日を見込んでいますか。受入テストで当社が担当する作業はどこまでですか。
7. データ移行・セキュリティ対応（脆弱性診断を含む）・非機能要件（性能・可用性・監視・バックアップ）は、この見積もりの範囲に含まれますか。含まれない場合、別途費用の目安をご教示ください。
8. プロジェクト管理費について、担当されるPMの稼働率と参画期間、および当社が受け取る成果物（体制図、議事録、進捗報告、変更管理書など）をお聞かせください。
9. 仕様変更が発生した場合の手続きと、追加費用の算定方法を教えてください。変更管理書に相当する書式はありますか。
10. この見積もりの前提条件と、明示的に対象外としている事項を一覧でご提示ください。当社側で実施すべき作業（データ準備、レビュー、環境提供など）があれば併せてお願いします。

質問を絞りたい場合は、1・2・4・7・10の5問を優先してください。この5問だけで、段階・工程・納入物・過小見積もりの有無・範囲の境界という、判断に必要な骨格が埋まります。

回答が返ってきた後、何を見るか

返答の中身より先に、返答の速さと形式を見ます。

• すぐに既存資料が出てくる → 分解済みだった。「説明済み」へ。金額の議論に進めます
• 数日で新しく作って出てくる → 見積もりの根拠はあった。「要確認」から「説明済み」へ。ただし新しく作られた内訳は、総額に合わせて逆算されている可能性があるので、工数の合計と当初総額の関係を確認します
• 抽象的な説明が返り、書面が出てこない → 「高リスク」。契約前の分解が必須です
• 「要件が決まっていないので出せない」と正直に返ってくる → 「判断不能」。これは誠実な回答です。要件定義を分離発注する方向へ話を切り替えます

4つ目を悪い回答だと受け取らないでください。モデル契約書が多段階契約と再見積りを前提にしているのは、まさにこの状態が正常だからです。 決まっていない段階で確定見積もりを出させることが、後の追加費用の原因になります。

根拠資料と適用条件

本記事で使った資料の位置づけを分けておきます。どれを根拠にしているかで、主張の強さが変わります。

区分	資料	発行元・年	本記事での使い方
主要根拠	情報システム・モデル取引・契約書（第二版）	IPA／2020年12月22日公表（第一版は2007年・経済産業省）	第4条の12項目、フェーズと契約類型、第8条・第13条・第26〜28条・第35条〜第37条の条文構成。分解単位と成果物の定義に使用
主要根拠	2025年度 システム開発・保守QCDs研究会	一般社団法人 日本情報システム・ユーザー協会（JUAS）／2026年4月9日	見積もり観点確認シートの構成、WBS階層、過小見積もりのリスク整理、見積もり失敗の7分類
条件付き	同資料の精度レンジ（−50%〜+100%ほか）と三点見積もりの式	同上	PMBOK・ISO21500の一般値を研究会が参照したもので、**実測統計ではありません。**目安として使用
参考（発行終了）	ソフトウェア開発分析データ集	IPA／最新版は2022年版・5,546プロジェクト	工程別比率の公的な検算材料が最新版で止まっている事実の確認に使用（2026年8月18日確認）
業界慣習値	PM費「総額の10〜15%」	複数のSIer公開資料・実務慣習	**公的機関が定めた相場ではありません。**参考値として言及するにとどめ、判断の根拠にはしていません
一般的な確認観点	画面数の数え方、非機能要件の抜けやすさ等	実務上よく見る論点	価格相場の根拠ではなく、確認の切り口として提示

適用条件として4点補足します。ここは読み飛ばさないでください。

• モデル契約書が想定しているのは、大きめの取引です。 第二版は契約当事者として「対等に交渉力のあるユーザ・ベンダ」（例として委託者＝民間大手企業）を、対象システムとして「重要インフラ・企業基幹システムの受託開発」を想定しており、中小企業ユーザとの契約やパッケージのカスタマイズは別途論点を整理する、と明記しています。数百万円規模のWebシステムに12項目すべてを要求するのは過剰です。自社の規模に合わせて、⑨（納入物の明細）・⑪（検査・確認）・⑫（前提と対象外）あたりから優先してください。なお、民間中小・中堅企業や地方自治体を想定した第二版追補版も公開されています。
• ウォーターフォール型を前提とした整理です。 IPAはアジャイル開発版のモデル契約書を別途公開しており、アジャイル開発では準委任契約を前提とする考え方が示されています。反復開発では「一式」の意味も変わるため、本記事の分解手順をそのまま当てはめないでください。
• モデル契約書は雛型であり、法令ではありません。 条文番号は第二版のものです。実際の契約書はベンダーごとに条文構成が異なります。
• 金額の妥当性そのものは扱っていません。 本記事の手順で分解しても、その先の単価や工数が適正かどうかは別の検証が必要です。

見積書の「一式」をレビューする

分解した内訳を並べたあと、抜けている項目を自分で洗い出すのは手間がかかります。koromoでは、受け取った見積書のテキストから項目を確認できる開発見積書のAIレビュー（登録不要）を公開しています。登録不要で、結果を見るまでメールアドレスの入力も必要ありません。テキストの抽出はブラウザ内で行い、送信前に内容を確認できます。

この記事の質問リストで受け取った回答を、そのまま貼り付けて確認する使い方を想定しています。診断結果は法的・会計的・技術的な最終判断ではなく、ベンダーへ次に何を聞くかを整理するためのものです。既存の見積もりのまま進めるのが合理的、という結論になることもあります。

よくある質問

まとめ

システム開発の見積書にある「一式」は、金額が不当だというサインではなく、金額を評価するための単位が書かれていないというサインです。対処は値引き交渉ではなく、分解単位の要求になります。

手順をもう一度整理します。

1. 一式のタイプを見分ける（機能一式／工程一式／費目一式）。複数ある場合は機能一式から
2. IPAモデル契約書 第4条の12項目を当てて、何が欠けているかを特定する
3. 工程 → 成果物 → 工数の順で分解を依頼する。工数から入らない
4. PM費は比率ではなく、意思決定と成果物で確認する
5. テスト・移行・セキュリティ・PMが一式に埋もれていないかを確認する（過小見積もりの発見）
6. 回答を説明済み／要確認／高リスク／判断不能の4状態へ仕分ける
7. 判断不能なら、分解ではなく要件定義の分離発注を検討する

最後の1点が、この記事で最も伝えたいことです。分解できない見積もりのすべてが不誠実なわけではありません。まだ決まっていないことを、決まっていないと書いたうえで契約する方法が公的なモデル契約書には用意されています。一式を分解する作業は、その状態を見えるようにするための手続きです。