「合計 12 人月」「システム開発一式 800 万円」——ベンダーから届いた見積書を開いたら、内訳のない大雑把な数字が並んでいた。上司からは「妥当性をチェックしてから稟議に上げて」と言われたものの、その 12 人月がどんな作業を積み上げた結果なのか、まったく手がかりがない。ネット検索してみると「工程比率で検証しろ」「人月単価を確認しろ」といった記事が出てくるが、そもそも工程別の工数も、単価の内訳も、手元の見積書には書かれていない。
こうした「検証以前に情報が足りない」状態は、初めてシステム発注を担当する方が最初にぶつかる壁です。工数見積もりの根拠は、実は見積書に最初から全部書かれているとは限りません。ベンダー側にも根拠を省略しがちな構造的な事情があり、書かれていない情報は発注者側から能動的に引き出す必要があります。
とはいえ、ベンダーに「根拠を教えてください」と一言送っても、返ってくるのは「経験値です」「概算ですので」といった曖昧な回答になりがちです。相手を追い詰めずに、失礼にならず、それでいて具体的な情報を引き出すには、"何を""どう"聞くかの型が必要です。
本記事では、工数見積もりの根拠を発注者が能動的に引き出すための実践的な手順を、次の3つのステップで解説します。第一に、見積書の情報密度を診断して抜けを可視化する方法。第二に、追加で引き出すべき5つの根拠情報とその優先順位。第三に、そのままコピペで使える依頼文テンプレートと、ベンダーが「概算です」「経験値です」と回答してきた場面での次の一手。読み終える頃には、少なくとも今日中に 1 通の追加情報依頼メールが送れる状態になっているはずです。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
工数見積もりの根拠は"書いてある"のか"引き出す"のか｜発注者が能動側に回るべき理由
工数見積もりの根拠とは、「なぜこの人月数になったのか」を説明する情報のことです。積み上げの方法、工程別の内訳、前提条件、リスクバッファなど、合計人月に至るまでのプロセスすべてが含まれます。多くの発注者は「根拠は当然見積書に書かれているはず」と思って受け取りますが、実際にはそうならないケースが少なくありません。
このセクションでは、まず工数の基本用語を最小限で確認したうえで、なぜ根拠が省略されるのか、そして発注者が"引き出す側"に回るとどんなメリットがあるのかを整理します。
工数見積もりの根拠とは「なぜこの人月数になったかの説明」
工数とは、あるタスクを完了させるために必要な作業時間のことで、システム開発では「人日」「人月」といった単位で表現します。1 人月は、1 人のエンジニアが 1 か月間フルタイムで働いた作業量を指すのが一般的です（実労働時間の目安は 160〜180 時間程度）。
「合計 12 人月」という数字は、その開発案件に延べ 12 か月分のエンジニア工数がかかる、という意味です。ただし、この 12 人月が「要件定義に何人月、設計に何人月、開発に何人月、テストに何人月」と積み上げた結果なのか、あるいは「過去の類似案件がこれくらいだったから」という類推なのか、その積算プロセスが根拠にあたります。
工数・人月の計算方法や単位の基礎については、工数と人月の計算方法で詳しく解説しています。本記事では基礎の解説は最小限にとどめ、「その 12 人月の中身をどう引き出すか」に焦点を絞って進めます。
なぜ見積書には根拠が最初から全部書かれないのか
見積書に根拠が省略されるのには、ベンダー側にも構造的な事情があります。次の 4 つを知っておくと、追加情報依頼の場面で相手の立場を理解でき、コミュニケーションが円滑になります。
- 見積依頼段階での情報不足：発注者から提供された要件が概要レベルにとどまっている場合、ベンダー側も詳細な工数積算ができません。仮定を置いて概算を出しているため、細かい根拠を書くと逆に「確定情報」と誤解される可能性があります。
- 見積書の書式・スペース制約：多くの企業では見積書のフォーマットが決まっており、明細行数や項目数に制限があります。すべての工程内訳や前提条件を書き切れないため、要点のみを記載する運用になっています。
- 不確実性ゆえの丸め：ソフトウェア開発は不確実性が高く、工数はあくまで確率的な推定値です。工程ごとに詳細な数字を出しても、実際には変動幅があるため、あえてざっくり示す判断がなされることがあります。
- 営業段階の概算：契約前の初期見積もりは、詳細な調査工数をかけずに提示するケースが多く、この段階での根拠はどうしても浅くなります。詳細見積もりには別途調査工程が必要です。
つまり、根拠が省略されているのは「隠している」からではなく、「見積書という書式・営業プロセスの制約上、書ききれない」ことが大半です。この構造を理解しておくと、追加で依頼する際に「なぜ書いてくれなかったのか」と身構えずに、フラットな姿勢で情報を求めることができます。
発注者が"引き出す側"に回ることで得られる3つのメリット
根拠を能動的に引き出す姿勢を持つと、発注プロジェクトの成功確率が上がります。具体的には次の 3 つのメリットが得られます。
- 後の変更に強くなる：積算プロセスを共有してもらうことで、要件変更が発生した際に「どの工程が何人月動くか」を発注者側でも予測できるようになります。
- 社内説明の材料になる：稟議・決裁の場面で「なぜこの人月数か」を説明できる材料が揃います。経営層や経理部門への説得力が変わります。
- ベンダーとの信頼関係が育つ：根拠を丁寧に聞く姿勢は、ベンダー側にも「この発注者は真剣に検討している」という印象を与え、以降のやり取りがより協力的になります。
「引き出す」というと強い響きですが、実際にやることは"教えてもらう"依頼です。次章から、その具体的な手順に入ります。
見積書に"書かれていること"と"書かれていないこと"を仕分ける｜情報密度を診断する
引き出すべき情報を決めるには、まず「今の見積書に何が書かれていて、何が書かれていないのか」を仕分ける必要があります。ここでは、既存の「妥当性を検証する」視点ではなく、"情報が揃っているかどうか"の網羅性視点で診断します。
見積書の一般的な構成を俯瞰で確認する
システム開発の見積書は、一般的に次の要素で構成されます。手元の見積書と照らし合わせながら、どこまで書かれているかを確認してください。
構成要素 | 内容 | 一般的な記載例 |
|---|---|---|
項目名 | 作業単位・成果物単位の項目 | 「要件定義」「基本設計」「実装」など |
工数 | 各項目にかかる人月・人日 | 「2.5 人月」など |
単価 | 1 人月あたりの単価 | 「80 万円/人月」など |
小計 | 項目ごとの費用 | 「200 万円」など |
合計 | 総額 | 「800 万円」など |
前提条件 | 見積もりの成立条件 | 「要件は現時点のヒアリング内容に基づく」など |
有効期限 | 見積もりの有効期間 | 「発行から 30 日間」など |
手元の見積書がこの表のどこまでカバーしているか、まずは1つずつチェックしてみてください。
"情報密度が低い"見積書の3つのサイン
情報が不足している見積書には、典型的なサインがあります。次の 3 つのいずれかに該当する場合、追加情報依頼を検討する余地があります。
- 「一式」表記：「システム開発一式」「テスト一式」といった項目のみで、内訳がない状態。何にどれだけ工数を割いているかが不明で、後の変更時にリスク分担が曖昧になります。
- 「合計◯人月」のみ記載：総人月だけが示され、工程別・ロール別の内訳がない状態。工数の妥当性を検証する手がかりが得られません。
- 工程明細なし：要件定義・設計・開発・テスト・移行のいずれかが明細から欠落している状態。抜けている工程の作業が「別途」なのか「含まれている」のかが判断できません。
これらのサインが見つかったら、後述する診断チェックリストで抜けを整理し、追加依頼の準備に進みます。
情報密度診断チェックリスト（8項目）
見積書を受け取ったら、次の 8 項目をチェックしてください。各項目について「記載あり／記載なし／曖昧」の 3 段階で仕分けし、「記載なし」「曖昧」の項目が追加依頼の候補になります。
# | チェック項目 | 記載の有無を判断するポイント |
|---|---|---|
1 | 工程明細（要件定義・設計・開発・テスト・移行） | 各工程の項目が独立して記載されているか |
2 | 画面・機能一覧 | どの画面・機能に工数を割いているかの内訳があるか |
3 | ロール構成（PM／SE／PG） | 誰の工数がどれだけ含まれているかが記載されているか |
4 | 単価内訳 | ロール別・工程別の単価が明示されているか |
5 | バッファ・リスク | 予備工数・リスク工数の記載や説明があるか |
6 | 前提条件 | 前提となる要件・体制・環境が明記されているか |
7 | スコープ（含む/含まない） | 対象範囲と除外事項が明確か |
8 | 保守運用範囲 | 開発後の保守・運用が見積もりに含まれるか |
このチェックリストで「記載なし／曖昧」に該当した項目のうち、優先度の高いものから追加情報依頼を組み立てていきます。次章では、その優先度を決める指針を示します。
引き出すべき"5つの根拠情報"｜発注者が追加で依頼する情報を絞り込む
診断で抜けが見つかっても、すべてを一度に依頼するのは現実的ではありません。ベンダー側の対応工数も、こちらの整理工数も限られています。ここでは、「工数の根拠を理解するのに直結する」5 つの情報に絞り込んで、優先度順に紹介します。
情報①積算方法（積み上げか・類推か・係数か）
まず確認したいのは、その工数がどの手法で算出されたかです。積算方法には大きく 3 種類あります。
- ボトムアップ（積み上げ法）：作業を細かく分解し、それぞれの工数を積み上げて合計する方法。精度は高いが工数がかかる
- 類推法：過去の類似案件と比較して工数を推定する方法。素早く出せるが、類似度によって精度が変動する
- 係数法：画面数・機能数・機能ポイント等の指標に係数を掛けて算出する方法。中規模までの案件で使われることが多い
積算方法によって、「なぜこの人月数か」の説明の性質が変わります。積み上げ法なら作業単位の内訳、類推法なら比較対象の案件情報、係数法なら係数の根拠を、それぞれ追加で確認する必要があります。作る側の積算手法の詳細については、工数見積もりの根拠の書き方で解説しているため、そちらも参考にしてください。
情報②工程別の内訳（要件定義・設計・開発・テスト・移行の工数配分）
積算方法の次に確認したいのは、工程別に何人月ずつ配分されているかです。要件定義・基本設計・詳細設計・開発（実装）・単体テスト・結合テスト・システムテスト・移行、といった主要工程それぞれに、何人月が割かれているかを一覧で出してもらいます。
この情報が揃うと、「テストが極端に少ない」「移行工程が抜けている」といった構造的な違和感を発見できるようになります。また、後の要件変更時に「どの工程がどれだけ動くか」を予測する材料にもなります。
情報③バッファ・リスクの前提
見積もりに含まれる不確実性への備え（バッファ）も、確認しておきたい情報です。ソフトウェア開発は不確実性が高いため、多くのベンダーは工程ごとに一定のバッファを積んでいます。しかし、バッファが可視化されていない見積書も少なくありません。
具体的に聞くべきは次の 2 点です。第一に、バッファは何 % 見込まれているか。第二に、そのバッファはどこ（どの工程・全体・特定リスク項目）に乗っているか。バッファがゼロの見積もりは、一見安く見えますが、想定外事象が起きた際に追加費用が発生しやすい構造です。逆に、過度に厚いバッファは費用の透明性を損ないます。
情報④ロール構成と人月単価
次に、その 12 人月が「誰の工数」で構成されているかを確認します。プロジェクトマネージャー（PM）、システムエンジニア（SE）、プログラマー（PG）といったロール別に、それぞれ何人月ずつ含まれているか。そして、ロール別の人月単価はいくらか。
ロール構成が分かると、「PM 工数が過大／過少ではないか」「上流工程を担当するシニア人材が十分含まれているか」といった観点で内訳を評価できます。ロール別単価の相場感については、独立行政法人 情報処理推進機構（IPA）が公開しているソフトウェア開発分析データ集で確認できます（後述の外部リソースセクションで再度触れます）。
情報⑤前提条件と除外事項
最後に確認したいのは、この見積もりが「何を含み・何を含まないか」の境界線です。特に次のような項目は、後のトラブルにつながりやすいため明示してもらう必要があります。
- 対応するブラウザ・OS・端末の範囲
- 対応するデータ量・トランザクション量の想定
- 移行対象データの範囲と件数
- テスト環境・本番環境の構築有無
- ドキュメント作成の範囲（設計書・運用マニュアル等）
- 保守運用の含有・別途契約の区分
これらが曖昧なまま契約すると、開発中に「これは範囲外です」というやり取りが多発し、追加費用・スケジュール遅延の原因になります。
以上の 5 つが、優先的に引き出すべき根拠情報です。次章では、これらを実際にベンダーへ依頼する際の文面の型を紹介します。
根拠を引き出す"依頼文の型"｜そのまま使えるメール・打合せトーク文例
情報を絞り込めても、それをどう伝えるかで得られる回答の質は大きく変わります。ここでは、失礼にならず、かつ具体的な回答を引き出すための依頼文の型を紹介します。
依頼文に共通する3つの原則
まず、どの情報を依頼する際にも共通する 3 つの原則を押さえてください。
- "疑う姿勢"ではなく"理解したい姿勢"を明示する：「妥当性を確認したい」ではなく「社内で説明できるよう理解を深めたい」というトーンにする。相手を検証対象として扱う雰囲気を避け、協業パートナーとして接する
- 具体的な項目を指定する：「根拠を教えてください」という丸投げの依頼は、ベンダー側も何を答えればよいか分からず、結果的に曖昧な回答が返ってきます。「工程別の工数配分を教えてください」のように、聞きたい項目を具体化する
- 回答期限とその理由を伝える：「◯月◯日までに社内稟議があるため」のように、期限とその背景をセットで伝える。相手が業務スケジュールを組みやすくなり、無理のない範囲で協力してもらえる
この 3 原則を意識するだけで、返信率と回答の質が大きく変わります。
情報①〜⑤それぞれの依頼文テンプレート
先ほど整理した 5 つの情報を、そのまま使えるメール文例と打合せトーク例に落とし込みました。手元の見積書とペルソナに合わせて、必要な箇所を書き換えて使ってください。
共通導入文（メール冒頭）
お世話になっております。株式会社◯◯の△△です。
このたびは詳細なお見積もりをお送りいただき、ありがとうございました。
社内で稟議に上げるにあたり、御見積の内容をより深く理解したく、
以下の点についてご教示いただけますでしょうか。
（回答期限の目安: ◯月◯日 まで／社内決裁のスケジュールの都合です）
情報①積算方法の依頼文
1. 積算方法について
今回の御見積は、どのような方法で工数を算出されたかをお教えください。
（例: 作業を分解して積み上げた／過去の類似案件を参考にした／
画面数や機能数から算出した、など）
特に類似案件からの類推であれば、その案件の規模感を差し支えない範囲で
共有いただけると、社内説明の参考になります。
情報②工程別内訳の依頼文
2. 工程別の工数配分について
合計 ◯人月 について、次の工程別にそれぞれ何人月を想定されているかを
一覧でご共有いただけますでしょうか。
・要件定義
・基本設計／詳細設計
・開発（実装）
・単体テスト／結合テスト／システムテスト
・移行・リリース作業
（フォーマットはExcelでもテキストでも構いません）
情報③バッファ・リスクの依頼文
3. バッファ・リスクの前提について
今回の見積もりに、不確実性への備えとしてどの程度のバッファを
見込んでいただいているか、また、そのバッファがどの工程や項目に
反映されているかをお教えください。
（後工程で要件変動が生じた際に、追加費用の目安を社内で共有できるようにしたく）
情報④ロール構成と人月単価の依頼文
4. ロール構成と単価について
体制表としてPM／SE／PG それぞれの想定人月数と、ロール別の人月単価を
ご共有いただけますでしょうか。
（相場観との比較ではなく、案件の性質に合った体制になっているかを
社内で確認したい趣旨です）
情報⑤前提条件と除外事項の依頼文
5. 前提条件と除外事項について
今回の御見積が想定している前提条件と、含まない範囲（別途費用となるもの）を
明示的にお教えいただけますでしょうか。
特に以下の点は、契約前に明確にできると助かります。
・対応するブラウザ／OS／端末の範囲
・想定データ量・想定同時接続数
・移行対象データの範囲
・ドキュメント作成の範囲
・保守運用の含有／別途契約の区分
打合せの場面で使う口頭質問例
打合せの場でカジュアルに切り出したい場合は、次のような聞き方が有効です。
- 「参考までに伺いたいのですが、今回の 12 人月はどんな考え方で算出されたのでしょうか？ 社内で説明する材料にしたく」
- 「工程別だとどんな配分イメージになりますでしょうか？ ざっくりで構いません」
- 「バッファはどれくらい見ていただいていますか？ 変更が入った時の目安を掴んでおきたくて」
打合せでは詳細な回答が難しい場合もあるため、その場では概要を聞き、詳細は後日メールでいただく形にすると、ベンダー側の負担も抑えられます。
追加情報依頼メールを送るタイミング
依頼メールを送るタイミングは、見積書受領後 2〜3 営業日以内が目安です。時間が経ちすぎると、担当者の記憶が薄れて回答の質が落ちる可能性があります。また、決裁スケジュールから逆算して、回答期限を設定しやすい時期でもあります。
「見積書を隅々まで検討してから聞こう」と時間をかけすぎると、決裁締切に間に合わなくなる恐れもあります。診断チェックリストで抜けを確認したら、細部を詰める前に依頼メールを送り、待ち時間を有効活用しましょう。
"引き出せない"場面別｜ベンダーの反応パターンと発注者の打ち手
依頼メールを送ったからといって、必ずしも欲しい情報がすべて返ってくるわけではありません。「概算です」「経験値です」「時間がありません」といった回答が返ってくる場面もあります。ここでは、そうした典型的な反応パターンと、その場での次の一手を整理します。
パターンA｜「これは概算です」と言われた場合
「今回はあくまで概算ですので、細かい根拠はお出しできません」と返ってきた場合、まず確認したいのは"見積もりの精度レベル"です。システム開発の見積もりには、一般的に次の 3 段階があります。
- 超概算見積もり：企画段階の目安。精度は ±50% 程度
- 概算見積もり：営業段階の見積もり。精度は ±30% 程度
- 詳細見積もり（確定見積もり）：要件定義後の見積もり。精度は ±10〜15% 程度
「概算」と言われた場合、多くはこの真ん中の段階を指しています。この段階では、詳細な根拠を求めても物理的に出せない場合があります。次の打ち手を検討してください。
- 詳細見積もりの依頼：要件定義フェーズを別発注する形で、詳細見積もりを別途依頼する。詳細見積もりの作成自体に費用が発生することも珍しくないため、事前に費用の目安を確認する
- 段階発注の提案：まず要件定義フェーズだけを発注し、要件が固まってから開発フェーズの見積もりを取り直す
- 精度レベルの合意：「今の見積もりは概算です」と社内向けに明示し、±30% の変動可能性を稟議書に明記する
これらの選択肢を持っていれば、「概算です」という回答で会話が止まらずに済みます。
パターンB｜「経験値・過去実績です」と言われた場合
「経験値でこれくらいだと分かります」「過去の類似案件がこの規模だったので」といった回答は、類推法による見積もりです。この場合、比較対象となった過去案件との類似度を具体的に確認する 3 つの質問が有効です。
- 業種・業務ドメイン：「その類似案件は、どのような業種・業務の案件でしたか？」——業種が違うと業務ロジックの複雑さが大きく変わります
- 規模感：「その類似案件の総人月・総ユーザー数・データ量はどれくらいでしたか？」——規模が違えば工数構造も変わります
- 技術スタックと非機能要件：「使用技術や、性能・セキュリティ要件は今回と近いでしょうか？」——技術・非機能要件の違いは工数に直結します
これらの質問で「類似度が高い」ことが確認できれば、経験値ベースの見積もりでも一定の信頼が置けます。逆に「業種は違うが規模が近い」といった回答であれば、その差分がリスクとして残っていることを社内で共有できます。
パターンC｜「そこまで詳しい根拠を出す時間がない」と言われた場合
営業活動と並行して見積書を作成している担当者にとって、詳細な根拠を書き起こすのは大きな工数負担です。「時間がありません」という反応も、正直な回答として理解できます。ここでの打ち手は次の 2 つです。
- 段階見積もりの提案：要件定義フェーズと開発フェーズを分けて見積もってもらう。要件定義フェーズは短期・小規模で発注し、その成果物をもとに開発フェーズの見積もりを詳細化する
- コンテキスト共有時間の確保：発注者側で用意できる情報（現状業務フロー・既存システム構成図・想定ユーザー数など）を事前に整理して共有し、ベンダー側の見積もり工数を減らす代わりに、根拠の詳細化を依頼する
情報を引き出すのは一方的なお願いではなく、こちらも情報提供して協業する構図に持ち込むと、相手も応じやすくなります。
引き出した情報を照合する外部リソース｜1人で判断せず一次情報と相見積もりを併用する
追加で情報を引き出せたら、その内容を客観的な基準と照らし合わせて評価する段階に進みます。ここでは、"評価の詳細" には踏み込まず、参照すべき外部リソースの入り口だけを紹介します。3 指標（工程比率・画面あたり工数・人月単価とロール構成）による具体的な検証手順については、発注者による見積もり根拠の検証方法で詳しく扱っています。
IPA ソフトウェア開発分析データ集（一次情報の入り口）
独立行政法人 情報処理推進機構（IPA）が公開しているソフトウェア開発分析データ集は、国内のソフトウェア開発プロジェクトの実績データを集約した公的資料です。工程別工数比率、規模別の生産性、業種別の傾向など、見積もりの妥当性を判断する際の参照基準として活用できます。
ベンダーから引き出した工程別内訳やロール構成を、この一次情報と照らし合わせることで、「他社と比べて極端な内容ではないか」を客観的に確認できます。稟議書に「IPA データと大きく乖離していない」と一言添えるだけでも、決裁者への説明力が変わります。
相見積もり（複数社の根拠を並べて比較する）
もう 1 つ有効なのは、同じ要件で複数のベンダーから見積もりを取り、根拠情報を並べて比較する方法です。ロール構成や工程配分がベンダーごとに大きく異なる場合、その差分自体が判断材料になります。
ただし、相見積もりは各ベンダーに一定の作業負担をかけるため、依頼時には「複数社に相談していること」を伝えたうえで、要件を統一して提供することが最低限のマナーです。単に安値を引き出すためのプロセスではなく、「同じ要件でどう見積もるかの違いを理解する」ためのプロセスとして位置づけると、健全な比較検討ができます。
まとめ｜工数見積もりの根拠は"引き出す"もの｜今日から送れる1通のメール
工数見積もりの根拠は、見積書に最初から全部書かれているとは限りません。ベンダー側にも構造的な事情があり、書かれていない情報は発注者側から能動的に引き出す必要があります。本記事で示した流れをもう一度振り返ります。
まず、手元の見積書を「情報密度」の観点で診断し、8 項目のチェックリストで抜けを可視化します。次に、抜けの中でも工数の根拠を理解するのに直結する 5 つの情報（積算方法・工程別内訳・バッファとリスク・ロール構成と単価・前提条件と除外事項）に絞り込みます。そして、それぞれの情報を"疑う姿勢ではなく理解したい姿勢"で依頼するメールテンプレートを使って、失礼にならず具体的な回答を引き出します。回答が「概算です」「経験値です」「時間がありません」で返ってきた場合の次の一手も、事前に用意しておけば会話は止まりません。
最後に、今日中に実行できる小さな一歩として、次のアクションを提案します。手元の見積書を開いて、この記事の情報密度診断チェックリスト 8 項目のうち「記載なし／曖昧」に該当する項目を書き出してみてください。そのうち優先度の高い 1〜2 項目について、本記事のテンプレートをコピーして、共通導入文と一緒に 1 通のメールを組み立てます。回答期限は 3〜5 営業日先を目安に設定してください。
「合計 12 人月」の中身を確認する道は、この 1 通のメールから始まります。相手を追い詰めず、"教えてもらう"姿勢で問いを重ねていくことで、稟議書に書ける根拠と、プロジェクトを共に進めるパートナーとの信頼関係が、少しずつ積み上がっていきます。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- 見積書に足りない5つの情報は、一度にすべて依頼してもいいですか？
一度にすべて依頼するのは避けましょう。ベンダーの回答負担が増え、かえって曖昧な回答になりがちです。診断チェックリストで「記載なし・曖昧」だった項目の中から優先度の高い1〜2項目に絞って依頼するのが得策です。
- 依頼メールを送っても根拠が最後まで得られない場合、契約を進めても大丈夫ですか？
根拠が得られないまま確定見積もりとして進めるのはリスクがあります。見積もりの精度レベル（概算か詳細か）を稟議書に明記し、変動幅を許容するか、要件定義フェーズだけを先行発注する段階発注を検討してください。
- 相見積もりを取っていることは、既存のベンダーに伝えるべきですか？
伝えるべきです。相見積もり中であることを明示し、各社に同一の要件を提供することが最低限のマナーです。単に安値を引き出す手段ではなく、各社のロール構成や工程配分の差分を比較材料として活用する姿勢で臨むと、公平な比較とベンダーとの信頼関係の維持につながります。
- 引き出した工程別内訳やロール構成が妥当かどうかは、何と比較すればよいですか？
独立行政法人IPAが公開する「ソフトウェア開発分析データ集」の工程別工数比率や生産性データと照らし合わせると、業界平均との乖離を客観的に確認できます。加えて、同一要件で複数社から取った相見積もりのロール構成や工程配分を並べて比較すると、より実務に即した判断材料になります。
- 詳細見積もりを別途依頼すると、追加費用が発生しますか？
詳細見積もりの作成自体に費用が発生するケースは珍しくありません。要件定義後に精度±10〜15%程度まで高めた確定見積もりを得るには、要件定義フェーズを別途発注する段階発注になることが多いため、依頼する前にベンダーへ費用の目安を確認しておきましょう。
