LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

協力会社から届いた開発見積もりが人数と期間だけの1枚で、何にどれだけかかるのかが読み取れない。他社より安いのに、どの作業を省いたのかが書かれていない——。SESパートナーに開発を頼む現場では、こうした迷いが起こりがちです。ベンダーコントロールとは、発注する側が委託先の作業範囲、進み具合、品質、費用を管理することを指し、受け取った開発見積もりの中身を確かめるのもその仕事に含まれます。

見積もりを確かめる目的は、金額を下げさせることではありません。前提と根拠を双方でそろえ、あとで「それは含まれていない」と言い合わずに済む約束にすることです。ただし万能ではなく、要件そのものが固まっていなければ、どれだけ確かめても金額は動きます。本記事では、SESパートナーから開発見積もりを受け取る発注側の担当者に向けて、見積もりの段階、前提と内訳の確かめ方、工数を物差しに当てる方法、そして安すぎる見積もりと複数社の見積もりの見方を整理します。

SESパートナーの開発見積もりとは

SESパートナーから出てくる開発見積もりには、何人のエンジニアが何か月加わるかを示す形と、作る機能や成果物ごとに作業量を積み上げる形があります。どちらの形でも、まず確かめたいのは、その見積もりが開発のどの段階で、どの資料をもとに作られたかです。

IPA（情報処理推進機構）の「情報システム・モデル取引・契約書」第二版は、解説の中で見積もりを段階に分けています。システム化構想の立案では「仮試算見積」、システム化計画の立案ではそれより精度の高い「試算見積」、要件定義書をもとにした段階では「概算見積」とし、画面や帳票などを決める外部設計のフェーズで「確定見積」が可能になると考えています。^*1

同じ解説は、構想や計画の段階の見積もりを「参考値として取り扱われるべきもの」とし、要件定義までの各フェーズの見積もりは確定見積ではないと書いています。^*1 SESパートナーの開発見積もりを受け取ったら、どの資料をもとに、どの段階の見積もりとして出したのかを見積書に書いてもらいます。要件定義書しか渡していないのに確定した金額のように扱うと、外部設計で画面や帳票が増えたときに、どこまでが見積もりの範囲だったのかで食い違います。

なぜ見積もりを確かめるのか

日本情報システム・ユーザー協会（JUAS）の「企業IT動向調査2026」は、ユーザー企業にシステム開発の予算の遵守状況をプロジェクトの規模別に尋ねています。2025年度の調査で「予定より超過」と答えた割合は、100人月未満では10.8％でしたが、100〜500人月未満では36.2％、500人月以上では42.2％でした。^*2

100〜500人月未満の「予定より超過」は、前年度の26.1％から10.1ポイント上がっています。^*2 予算を超えた理由がすべて最初の見積もりにあるわけではなく、この図だけでは理由までは分かりません。それでも、規模の大きい開発をSESパートナーに頼むほど、見積もりを受け取った時点で前提と根拠をそろえておく意味は大きくなります。発注してから前提の食い違いに気づくと、直すための話し合いそのものに時間がかかるためです。

見積もりの前提をそろえる

デジタル庁の「DS-110 デジタル・ガバメント推進標準ガイドライン解説書」は、政府の情報システムで経費を見積もるときの留意点を解説しています。民間の発注にも使える考え方が多く、最初に挙がっているのは、見積もる側に必要な情報を渡すことです。実現したい業務・機能の内容、規模、サービスレベル（求める品質や稼働の水準）、スケジュールなどを伝え、既存の情報システムがあるときは、秘密保持契約を結んだうえで設計書などを閲覧してもらうよう求めています。

要件が固まりきらない場合の扱いも書かれています。その時点で必要と見込まれる要件を置いたうえで、数量や工数、単価などの積算内訳に加えて、「見積り上の前提条件や制約条件を明確にした見積り」を取ることが重要だとしています。^*3 SESパートナーに頼む開発では、次のような前提を見積書に書き出してもらうと、あとで確かめやすくなります。

• 見積もりの対象にした画面、帳票、外部システムとの連携の数
• 発注する側が用意するもの（テスト環境、テストデータ、仕様の確認やレビューに出る担当者）
• 見積もりに含めていない作業（データ移行、本番環境への反映、利用者向けの説明資料など）
• まだ決まっていない事項と、それを金額にどう反映したか

最後の項目が、リスクの積み方に当たります。先のモデル契約の解説は、要件定義書をもとにした概算見積の段階では、セキュリティや障害対策などの要件が、外部設計を進める過程で新たに出てくる場合があるとしています。未確定の部分を単価や工数に紛れ込ませると、発注する側からは見えません。予備として別の行に分けるのか、決まった時点で見積もり直すのかを、見積書の段階で決めておきます。

規模の根拠と工数の内訳

DS-110は、見積もり金額の妥当性を確かめられるよう、「一式 ○○円」といった書き方ではなく、十分に精査できる粒度で内訳を書くよう求めています。^*3 作業を委託する場合は、開発する機能などの成果物ごとに、作業内容、作業工数、作業者の種別とレベル（SE、プログラマなど）、人件費単価を明らかにします。

あわせて、工数の妥当性を説明できるよう、工数を算定した根拠になる基本的な数値と算定方法（画面数、帳票数、LOC、ファンクションポイントなど）も書くとしています。LOC（プログラムの行数）もファンクションポイント（機能の数と複雑さから規模を測る方法）も、ソフトウェアの規模を数える物差しです。規模の数え方が書かれていれば、工数が規模から出てきたのか、先に決めた人数と期間から逆算したのかを見分けられます。

人数と期間だけの見積もりを受け取ったときは、機能ごと、工程ごとに分けて出し直してもらいます。設計、プログラムの作成、テストのそれぞれに何人日かかるのかが並ぶと、テストの工数が極端に少ない、といった偏りも見えてきます。運用や保守の作業を頼む場合には、実際に稼働する人数と、一人ひとりの稼働時間が分かる見積もりを取る必要があるともされています。

工数を物差しに当てる

内訳がそろったら、工数が常識から外れた値になっていないかを、外の物差しに当てて確かめます。IPAの「ソフトウェア開発分析データ集2022」は、規模と工数、工数と工期などの関係を、信頼区間付きの散布図で示しています。資料は使い方として、95％の信頼区間の下限値より下に位置するプロジェクトはほとんどないため、見積もりや計画を立てるときに下限値より下かどうかを実現できるかの目安にする例を挙げています。50％の信頼区間の上下限値に入っていれば、工数の妥当性が高いと見る目安になるとしています。^*5

一方で、同じ資料は、回帰式は「あくまでも分析事例であり、現実の見積りにそのまま利用できるものではない」と注意しています。^*5 集めたデータは無作為に選んだものではなく、定量的な管理をしている組織のものが多いため、生産性は世間の相場観よりよい値を示している可能性があるとも書いています。物差しは見積もりの正しさを決めるものではなく、話し合うべき外れ値を見つけるためのものです。

資料には、避けたい使い方の例も載っています。委託先から示された工数を回帰式に当てたところ、提示されたスケジュールどおりだったので、信頼性と性能の要件が厳しい案件なのに見直さずに発注した、という例です。望ましい進め方として、難易度とリスクを委託先と話し合い、信頼区間に収まる範囲でスケジュールを見直した例が示されています。規模ごとの生産性の分布はFP生産性の中央値を規模別に見る、増員を決める前の4つの手順で、工数と工期の関係は工期は工数の3乗根とは、工数10倍でも月数は2.1倍で扱っています。

安すぎる見積もりの確かめ方

高い見積もりよりも見落としやすいのが、ほかより目立って安い見積もりです。モデル契約の解説は、委託先を選ぶときに入札価格の安さだけで決めず、履行体制なども考えて判断すべきだとし、「極端な安値の場合には注意が必要である」と書いています。^*1

安い理由の確かめ方は、政府調達の低入札価格調査が参考になります。DS-110によると、調査では、対象になった事業者に、履行できるとする具体的な根拠資料として、開発規模、工数、作業工程、作業スケジュール、生産性の詳細などを出してもらいます。そのうえで、仕様の内容を正しく理解し、「必要な作業及び工数を漏れなく見積もっているか否か」を把握して、低価格になっている理由を詳しく確認します。^*4

SESパートナーの見積もりに当てはめると、確かめる点は3つです。見積もりに入っていない作業はないか。想定している生産性が、ほかの見積もりや自社の過去の案件と比べて高すぎないか。そして、その生産性を出せる経験を持つ人が実際に加わるのか、です。DS-110は、事業者の見積もりを使う場面の留意点として、人件費については要員の作業内容、職種、工程、工数などまで細かくし、契約の履行に支障が出ないよう精査することも挙げています。

複数社の見積もりの比べ方

複数のSESパートナーから見積もりを取るときは、比べ方を先に決めておきます。DS-110は、同じ粒度で比べられるように、発注する側が見積もりの様式を指定して提出してもらうことが望ましいとしています。複数の見積もりから金額を積み上げるときも、「見積り合計額を単純に平均するのではなく」、内訳の項目ごとに見積もりの対象、前提条件、制約条件を精査するよう求めています。^*3

合計額だけを並べると、テストを含む会社と含まない会社、データ移行を別にした会社の金額を、同じ土俵で比べることになります。様式で内訳の項目をそろえ、前提条件の違う項目に印を付けてから比べると、どこで金額に差が出ているのかが見えてきます。

ただし、いつでも複数社から取れるとは限りません。DS-110は例外になる合理的な理由の例として、既存の情報システムの部分的な改修で、設計や保守を担っている事業者は設計情報を熟知しているのに対し、ほかの事業者は全体を理解するための作業に多くの工数がかかり、見積もりを得ることが難しい場合を挙げています。今のSESパートナーが長く担当しているシステムほど、この状況になりやすくなります。1社の見積もりで進めるときは、その理由と、何と比べて妥当と判断したのかを記録しておきます。稟議書への書き方は外部人材活用の稟議書は見積りの根拠を添えると通りやすいで、複数社が同時に入るときの役割分担はSESパートナー複数社のベンダーコントロールで整理しています。

まとめ：開発見積もりで確かめておきたい3つの点

SESパートナーから受け取った開発見積もりをベンダーコントロールの目で確かめるうえで、押さえておきたい点は3つに整理できます。第一に、どの段階の見積もりなのかと、見積もりの前提条件や含めていない作業を書き出してもらうこと。第二に、内訳を機能と工程ごとに出してもらい、規模の数え方と工数の根拠を外の物差しに当てること。第三に、安すぎる見積もりや複数社の見積もりは、合計額ではなく内訳の項目ごとに前提をそろえて比べることです。この3点を踏まえておけば、「発注した後で、見積もりに入っていない作業が次々に見つかる」という事態を避けやすくなります。見積もりの読み方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：IPA「情報システム・モデル取引・契約書（受託開発（一部企画を含む）、保守運用）＜第二版＞（2025年4月8日更新）」（Word）（https://www.ipa.go.jp/digital/model/ug65p90000001ljh-att/000087884.docx）。出典：モデル取引・契約書の解説のうち、RFPの記載事項（(7)その他）、提案書・見積書（③開発見積、④セキュリティ関連）、委託先の選び方についての記述を参照（2026年9月確認）
2. *2　参考：JUAS「企業IT動向調査2026」（PDF）（https://juas.or.jp/cms/media/2026/04/JUAS_IT2026.pdf）。出典：一般社団法人 日本情報システム・ユーザー協会「企業IT動向調査2026」（2025年度調査。回収数957社・有効回答率21.3％）。図表7-1-2（プロジェクト規模別・年度別 システム開発の予算遵守状況）の25年度と24年度の値と、その本文を参照。図は資料に示された数値をもとに作成し、資料の図表そのものは複製していない（2026年9月確認）
3. *3　参考：デジタル庁「DS-110 デジタル・ガバメント推進標準ガイドライン解説書」（PDF）（https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/50952dae/20260715_resources_standard_guidelines_guideline_03.pdf）。出典：第3編第3章4.「経費の見積り」の解説(2)(3)(4)(7)を参照（2026年9月確認）
4. *4　参考：デジタル庁「DS-110 デジタル・ガバメント推進標準ガイドライン解説書」（PDF）第3編第6章（https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/50952dae/20260715_resources_standard_guidelines_guideline_03.pdf）。出典：第3編第6章3.「RFP・公告」の解説(3)、4.「審査」の1)審査体制の確立、5.「入開札」の2)低入札価格調査の実施とその解説(2)を参照（2026年9月確認）
5. *5　参考：IPA「ソフトウェア開発分析データ集2022」本編（https://www.ipa.go.jp/digital/software-survey/metrics/hjuojm000000c6it-att/000102171.pdf）。出典：A4.3.3「回帰分析」の信頼区間付き散布図の使い方、A4.4.2「本書の収集データの理解」、A4.4.3「データの危うい使い方の例」、A4.5「本書利用にあたっての注意事項」を参照（2026年9月確認）

Tweet