開発見積の人月比較|時間・作業範囲・納期を確認

開発会社の見積もりを、人月の時間換算・含まれる作業・納期の3点で比べる方法を説明します。二つの架空の見積もりを使い、業務担当に確かめることと、開発会社へ尋ねることを整理できます。
卸売会社で受注管理システムの開発を依頼する発注担当や経営者が、「5人月」と「6人月」の見積書を受け取った場面を考えます。人月とは、1人が1か月働く量を基準にした仕事量です。数字が小さい方を選ぶ前に、同じ仕事を含むのか、追加の費用や自社の準備があるのか、使い始めたい時期に間に合うのかを確かめる必要があります。
まず人月の時間の定義を確認して換算し、次に作業範囲と完成条件をそろえます。そのうえで工数の内訳・費用・体制・納期を照合し、説明が足りない点を両社へ尋ねます。800時間と840時間という合計だけでは、安さ・品質・納期の優劣は決まりません。
以下の会社の場面・見積もり・質問と記入例は説明用です。実際の会社の見積もりや実績ではありません。時間の定義、作業の有無、未確認事項を混ぜずに読むための例として使ってください。
人月・人数・期間・単価は、それぞれ何を表す?
人月が表すのは仕事量です。担当者の人数、完成までの期間、支払う金額は別の項目として確認します。
受注管理システムを作るには、業務の聞き取り、画面の設計、プログラムの作成、テスト、データの移行などの仕事があります。その仕事に必要な量を「工数」と呼びます。人月は工数を表す単位の一つで、人日や人時で示す場合もあります。人日は1人が1日、人時は1人が1時間働く量を基準にした単位です。
「5人月」から、そのまま読めない3つのこと
- 工数:5人月
- 予定する仕事の量どの作業を、何時間の定義で数えたかを確認。
- 人数:未確認
- 誰が、どれだけ担当するか5人が担当するという意味ではありません。
- 期間:未確認
- 開始から完成までの予定5か月で完成するという意味ではありません。
- 金額:未確認
- 単価・費用の条件が必要5人月だけでは支払額を計算できません。
1人月を何時間で数えるかは、見積書ごとに確認する
各見積書とその前提資料で「1人月の時間」を探します。160時間と明記されていれば、その定義で換算します。定義がなければ、自分で160時間と決めず、作成した開発会社へ尋ねてください。人日なら1日を何時間で数えるかも必要です。
見積もりの合計が「開発だけ」か、打ち合わせ・進行管理・テスト・導入支援まで含むかも確かめます。同じ時間の定義でも、数えている仕事が違えば、工数の数字だけでは比べられません。
IPAの「ソフトウェア開発データ白書 FAQ」は、白書の人時への換算で、特に指定がなければ1人月を160人時とする扱いを説明しています。これは白書の集計上の定義です。すべての開発契約が同じ時間を使うという根拠にはしません。IPA公式FAQの「工数について」
「人月単価」と「毎月の請求額」は同じ?
人月単価は、1人月あたりの金額を示す言葉です。人月数と掛ける計算に使う場合でも、何を含む単価なのか、支払いをいつ・何に対して行う見積もりなのかは別に確認します。「1人月の単価」という記載だけから、毎月同額が請求されるとは読み取れません。
5人月と6人月を、同じ時間単位に直してみる
人月数に、その見積もりで定義された1人月の時間を掛けます。時間に直す目的は、数字の前提をそろえることです。
二つの架空見積書には、一方に「5人月・1人月は160時間」、もう一方に「6人月・1人月は140時間」と書かれている設定です。以下では人時への換算値を、読みやすく「時間」と表示します。
160時間で数える見積もり:
5人月 × 160時間/人月 = 800時間
140時間で数える見積もり:
6人月 × 140時間/人月 = 840時間
人月の数字は5と6ですが、時間に直した差は40時間です。ただし、この40時間が「同じ作業に余分にかかる時間」とはまだ言えません。次の図のとおり、データ移行や試用支援の範囲が異なり、工程別の時間も分からないからです。
1人月は何時間?見積書ごとに確かめる
説明用の架空見積もり。作業範囲はまだそろっていません。
160時間で数える見積書
5 × 160 =
800時間
140時間で数える見積書
6 × 140 =
840時間
同じ仕事が含まれるか比べる
過去の注文データを移す
160時間の見積書:含む。どのデータを移すかは未記載。
140時間の見積書:含まない。
業務担当の試用を支援する
160時間の見積書:未記載。
140時間の見積書:含む。回数は未記載。
定義が不明な見積もりは「未確認」のまま残す
片方の時間の定義が分からなければ、その換算欄は「未確認」にします。もう片方と同じ時間を当てはめると、確認していない条件で比較したことになります。0時間とも扱いません。
換算後の数字だけから、生産性や技術力の優劣を決めることもできません。比較する仕事の量、難しさ、品質を確かめる方法がそろっていないためです。実際にかかった時間と、これからかかると見込んだ時間も分けて読んでください。
時間の単位がそろったら、次は「その時間に何の仕事が含まれるか」を確認します。
「開発一式」を、作業範囲と完成条件に分ける
同じ機能名が書かれていても、使い始めるまでの仕事が同じとは限りません。必要な仕事と、どの状態になれば完成かを具体的にそろえます。
卸売会社の業務担当は、現在の受注の流れ、困っている処理、残したい作業を説明します。発注担当は、それを見積書の項目へ結び付けます。例えば「受注管理一式」だけで比べず、「受注を登録する」「過去の注文を検索する」「取消し・訂正を扱う」のように、使う人の仕事へ分けて確かめます。
以下は同じ架空見積もりの記載です。「含む」は対象と記載、「含まない」は対象外と記載、「未記載」は説明がない状態です。三つを区別し、未記載を作業不要と読み替えないでください。
スマホでは表を左右に動かして、右端の列まで読めます。キーボードでは表の枠に移動して左右キーで動かせます。
| 業務に必要な仕事 | 160時間で数える見積もり | 140時間で数える見積もり |
|---|---|---|
| 受注を登録する画面を作る | 含む | 含む |
| 過去の注文データを移す | 含む。対象データの説明は未記載 | 含まない |
| 業務担当が試用する作業を支援する | 未記載 | 含む。回数は未記載 |
データ移行なら、対象・役割・照合方法まで尋ねる
過去の注文を新システムで使う必要があるかは、まず業務担当に確認します。必要なら、どの期間の注文か、どの項目を使うか、どれだけあるか、誤りや重複のあるデータを誰が整えるかを整理します。件数やデータの状態が分からない段階では、その調査も必要な仕事として残します。
160時間で数える見積もりには、移行対象と、移した結果を何と照合するかを尋ねます。140時間で数える見積もりには、移行を誰が行う想定か、開発会社に依頼するなら別の工数・費用・予定が必要かを尋ねます。必要な範囲が決まる前に、移行分を推測して足し引きしません。
完成条件は「できたことを、どう確かめるか」まで書く
「受注画面が表示される」と「業務担当が商品と数量を登録し、登録した注文を検索して内容を照合できる」では、確認する仕事が違います。後者のように、誰が、どのデータで、何をして、どの結果と比べるかを言葉にすると、開発会社へ完成条件を相談しやすくなります。この条件は説明例で、実際に合意された仕様ではありません。
試用についても、「開発会社が操作説明をする」「業務担当が通常の受注と取消しを試す」「見つかった問題を修正し再確認する」を分けます。試用支援を含むという一文だけで、すべての確認や何度でも行う修正を含むとは決められません。
見落としやすい仕事は、必要性から確認する
- 他の仕組みとの接続:会計や在庫の仕組みへ何を渡すか。相手側の調整・接続テストを誰が行うか。
- 日常業務で使う条件:同時に使う人、処理する件数、誰がどの注文を見られるか、障害時にどう戻すか。必要な条件と確かめる方法を相談する。
- 導入と引き継ぎ:使い方の説明、操作資料、利用開始時の立ち会い、問い合わせ対応をどこまで含むか。
- 利用開始後:不具合の連絡先、保守や運用を依頼する範囲、別途見積もりになる仕事は何か。
これは全案件に同じ機能や工程を追加する一覧ではありません。自社で必要な仕事を業務担当と選び、見積書に含むかを確認するための観点です。
工数の内訳を読み、増える・減る理由を確かめる
合計の大小を評価する前に、何をどれだけ作り、どの確認に時間を見込んだのかを開発会社へ説明してもらいます。
見積書に内訳がなければ、すべてを細かな時間へ分解するよう一度に求めるより、比較できない項目から聞きます。この架空例では、データ移行と試用支援が先です。対象が決まっていない仕事と、対象は決まっているが説明が省かれた仕事を分けると、次に調べることが分かります。
| 仕事のまとまり | 説明してもらう内容 | 発注側が用意・確認すること |
|---|---|---|
| 業務を聞き、作る範囲を決める | 何回・誰に聞き、どの資料を残す想定か | 現在の受注の流れ、困る処理、説明する人 |
| 画面・帳票・接続を作る | 対象の一覧、通常と例外の処理、既存機能を使える範囲 | 実際に必要な操作、出力、つなぐ仕組み |
| テストと業務担当の試用 | 確認する内容、結果を残す方法、修正と再確認の範囲 | 試用する人・データ・確保できる時間 |
| 移行・導入・進行管理 | 準備から利用開始までの担当、打ち合わせ等を含む場所 | 旧データ、切り替える時期、社内判断の担当 |
多い工数にも、少ない工数にも理由を聞く
似た受注画面でも、取消しの扱い、つなぐ他システム、旧データの状態、処理する量が違えば、見込む仕事は変わります。既存の仕組みを使う提案で工数が少ないなら、自社の運用をどこまで合わせる必要があるか、追加で作る部分や利用料があるかを聞きます。
反対に工数が多い場合も、単に減らすよう頼まず、どの仕事が増えているのかを聞きます。テスト・移行・調整が含まれているのか、必要以上の範囲を想定しているのかで、見直す方法が変わります。作業量の根拠には、今回の作業を分けた計算、似た案件との差、試作や調査の結果など、どれを使ったかを示してもらいます。
IPAの「情報システム導入時の価値評価と合意形成に関する調査」の見積もりに関する説明では、発注者自身の見積もり、複数の見積もり、過去の似た案件との比較などが挙げられています。ここでは、比較の根拠を増やす考え方として参照しています。特定の人月数の妥当性を証明する数値ではありません。IPA公式資料(冊子235〜236ページ)
未調査の部分は、調査後に何を見直すか決める
例えば旧データをまだ見ていないなら、「移行に何時間かかるか」は確定していない可能性があります。どの資料を調べれば見積もれるか、調査自体の範囲・費用・期間、調査後に更新する項目を相談します。暫定値を使う場合は、その前提と、どの条件で変わるかを残します。
工程別の数字が得られたら、合計との対応、別項目に含まれる仕事、重複や対象外の仕事を確認します。工程名が異なるだけで不足と決めず、中身がどちらの項目に入っているかを確かめてください。
人月単価と見積額を、同じ作業範囲で比べる
人月の時間定義と対象作業をそろえ、単価・一式費用・別途費用を照合します。小さい人月数や安い人月単価だけでは、必要な仕事を終える支払額は分かりません。
見積書が「人月数×人月単価」で計算されていれば、各項目の単位と合計を確認します。設計と実装で単価を分ける場合は、役割や作業ごとの数量と金額を照合します。一式金額の見積もりを、内訳が分からないまま一つの人月単価で計算したものと決めつけないでください。
工数から金額へ進む前に、3か所をそろえる
人月には円/人月、人時には円/人時。時間へ換算した数量に、円/人月をそのまま掛けません。
設計・実装だけか。テスト・移行・管理・導入支援は、どの金額に含まれるか。
対象外の作業、利用料、運用支援等。必要性と対象期間、税の扱いを確認。
時間単価に直しても、適正価格の判定にはならない
同じ作業範囲の比較に使うため、単価だけを時間単位へ直したい場合は、「円/人月の単価÷1人月の時間」で円/時間相当を計算できます。ただし、これはその単価の換算です。会議・管理・成果物の確認などを含む一式費用を割った値と、担当者別の時間単価を混ぜて順位を付けないでください。
この架空例では、800時間・840時間までは計算できますが、単価、見積金額、別途費用は未確認です。単価が同じとも、工数が少ない方が安いとも仮定しません。また、金額を工数で割って得た平均値だけから、開発会社の利益や担当者の給与は分かりません。
対象外の仕事と、利用開始後の費用も残す
片方でデータ移行が対象外なら、そのままの見積総額を「必要な仕事すべての費用」として比べられません。開発会社の追加見積もりが必要か、自社が担当できるかを確認します。自社で行う場合も、担当者と必要な時間を残してください。
クラウドや外部サービスの利用料、保守・運用なども、初期の開発金額に含むか、別途か、まだ不明かを分けます。比較する期間と税の扱いをそろえ、同じ費用を二重に足さないようにします。詳しい予算整理はシステム開発の費用内訳と予算の立て方で確認できます。ここでは、市場相場や特定の見積もりの適正価格を認定していません。
工数とは別に、体制・自社の作業・納期を確かめる
納期を確かめるには、作業の順序、担当者の確保、発注側の準備と回答日を、利用開始までの予定へ結び付けます。
5人月を5人で担当すれば必ず1か月、という計画は立てられません。前の設計が決まるまで始められない作業や、特定の担当者が必要な作業があるためです。担当者が同じ期間ずっと参加できるか、ほかの案件と兼任するかも確認します。
作業の時間と、確認を待つ期間を分ける
作る
試して回答
再確認
試用できる日や回答できる日も、予定に影響します。
「誰がいつ動けるか」を、仕事の順序と合わせて聞く
開発会社へ、開始条件、主要な作業の順序、並行できる仕事、担当する役割と参加時期を示してもらいます。「テスト担当がいる」だけでなく、今回の試用や修正の時期に参加できるかを確かめます。発注側が回答するまで次へ進めない点も、予定に入っているかを聞きます。
卸売会社側では、業務を説明する人、旧データを用意する人、試用して結果を返す人、社内で範囲を判断する人を決めます。発注担当が一人ですべて回答できるとは限りません。繁忙期や締め処理と重なるなら、その制約を先に共有します。
「納品の日」と「業務で使い始める日」を照合する
画面やプログラムが納められても、データ移行、業務担当の確認、操作説明、切り替え準備が残る場合があります。見積書の納期がどの状態を指すかと、実際に使い始めたい日を照合してください。完成を確かめる作業や修正期間も、どこに含むかを確認します。
使い始めたい日に全機能をそろえるのが難しければ、その日に必要な仕事と後から追加できる仕事を業務担当と分け、開発会社へ実現可能な計画を相談します。段階を分けた場合の工数、費用、完成条件、残る業務を合わせて見直します。日付だけ決め直して、範囲が変わったことにしないようにします。
比較メモと質問文を作り、回答を見積もりへ反映する
同じ条件で尋ね、回答の根拠と版を残します。分からない点を一つでも具体化できれば、その段階から相談を進められます。
まず、見積書の名前・作成日・版と、元にした依頼資料をそろえます。一方だけ後から追加した希望を伝えていた場合は、数字が違う理由が依頼条件にあるかもしれません。同じ依頼条件で比べるのか、提案方法の違いも比べるのかを明らかにします。
比較表は、分かることと質問を隣に置く
架空例では、以下まで記入できます。未記載を埋めるために、自社の判断が先に必要なことと、開発会社へ回答を求めることを分けています。
| 比較する項目 | 今分かっていること | 次に確認する相手と内容 |
|---|---|---|
| 工数の定義 | 5人月×160時間=800時間。6人月×140時間=840時間 | 両社:この時間に含む工程、工程別の内訳 |
| 過去の注文データ | 160時間の見積もりは移行を含むが対象未記載。140時間の見積もりは含まない | 業務担当:移す必要と対象。両社:同じ条件での担当・工数・費用・予定 |
| 業務担当の試用 | 160時間の見積もりは支援未記載。140時間の見積もりは含むが回数未記載 | 両社:試用の支援、修正と再確認の範囲。自社:試用する人と時期 |
| 費用と利用開始 | 単価・金額・予定・完成条件は未確認 | 両社:必要範囲をそろえた見積金額と計画。自社:希望時期と準備できる日 |
開発会社へは、該当箇所と同じ条件を添えて尋ねる
例えば、次の文面を自社の状況へ置き換えます。すべての欄を完成させてから連絡する必要はありません。確認できていない点は、そのまま伝えます。
受注管理システムの見積もりを、同じ作業範囲で比較したいと考えています。1人月の時間定義と、合計に含む工程・管理作業を教えてください。
過去の注文データの移行について、対象データ、データを整える担当、移行結果を照合する方法を確認したいです。対象や件数は業務担当へ確認中です。調査が必要なら、調査の範囲と、調査後に工数・費用・予定を見直す方法も教えてください。
業務担当の試用支援、見つかった問題の修正と再確認をどこまで含むか、利用開始までに当社が準備・回答する内容と時期も示してください。
回答後は、数字だけでなく前提の変更を照合する
- 回答を記録する:誰からいつ得た回答か、見積書・前提資料のどの版に反映されたかを残します。口頭説明だけの場合は、比較に使う条件を文書で確認します。
- 範囲を合わせる:データ移行や試用の支援が両方で同じか、意図して異なるのかを確かめます。異なる提案を比べる場合は、自社が追加で担う仕事も残します。
- 影響する項目を更新する:工数が変わったら、金額、担当者、納期、完成条件も同じ前提に更新されたか確認します。以前の合計だけを使い続けません。
- 判断できる範囲を示す:同じ範囲で確認できた項目から比較し、未調査の仕事は誰がいつ調べるかを決めます。重要な未確認条件を残したまま、採用や開始日を確定した扱いにしません。
コピーして使う比較メモ
次の欄は文章を選択してコピーするための記入例と空欄メモです。入力・送信の機能はなく、このページから開発会社へ連絡されることもありません。コピー先で不要な項目を省き、まず一件から使ってください。
費用の全体を確認したい場合は開発予算の記事へ、比較方法から相談したい場合はシステム開発・業務改善の相談案内へ進めます。見積書を整理しきれない場合も、対象業務と困っている違いを一つ伝えるところから始められます。
まとめ:人月の大小より、違いの理由と次の確認を整理する
人月比較で最初にすることは、数字の小さい見積書を選ぶことではなく、何をどの定義で見積もっているかを読むことです。今回の架空例は800時間と840時間へ換算できても、データ移行と試用支援の範囲がそろっていません。そのため、費用・品質・納期の優劣や採用先はまだ決められません。
見積書を比べるときの4つの確認
- 単位を確かめる人月の時間定義を聞く。分かるものだけ時間へ換算。
- 仕事をそろえる含む・含まない・未記載を分け、完成条件を相談。
- 金額と予定を照合する単価・別途費用・体制・自社の準備と回答日を確認。
- 質問して更新する同じ条件で尋ね、回答を比較表と見積書へ反映。
まずは二つの見積書で説明が違う仕事を一つ選び、「業務担当へ何を確認するか」「開発会社へ何を尋ねるか」を書いてください。違いの理由が分かれば、範囲をそろえて再見積もりを依頼する、自社の担当を決める、利用開始までの計画を相談するなど、次の行動を具体的に選べます。
参照した一次資料
- IPA「ソフトウェア開発データ白書 FAQ」:工数の対象と、人月から人時への換算定義。
- IPA「情報システム導入時の価値評価と合意形成に関する調査」:冊子235〜236ページの、見積もりを複数の根拠で比較する考え方。
本記事の会社の場面、二つの見積もり、作業範囲、完成条件と工程の例は説明用です。実際の見積もり・測定・合意・開発の結果を示しません。
一次資料確認:2026年10月16日。一般の見積もりの読み方として整理したもので、特定の案件の工数・金額・契約条件を保証するものではありません。
仕事の流れから、顧客との接点まで。
一体で見直す、最初の一歩を。


