システム開発をフリーランスで受けるときの見積もりの出し方｜単価の決め方と注意点

システム開発をフリーランスとして受注するとき、見積もりは「作業範囲を決める」「工数を出す」「単価とリスクを掛ける」「契約形態に合わせて提示する」の4段階で組み立てると、根拠を説明できる金額になります。本記事は受注側の立場から、スコープと前提条件の書き方、作業分解による工数の出し方、単価とリスク係数の考え方、請負と準委任での見積もりの違い、よくある失敗、見積書の構成までを、架空の計算例を使って整理します。2026年10月時点の情報に基づいています。

見積もりの前に決めること

見積もりの前に決めるべきことは、作業の範囲（スコープ）と、見積額が成り立つ前提条件の2つです。金額の計算はその後で足ります。

スコープの範囲

スコープは「やること」と「やらないこと」の両方を書き出して初めて範囲として機能します。口頭で「いつもの管理画面くらい」と合意しただけでは、後から認識がずれても金額に反映できません。

最低限、次の項目は見積もりの時点で言葉にしておくと安全です。

• 対象とする機能と画面の一覧（追加が起きたときに差分を比べる基準になります）
• 対応する環境（ブラウザ、OS、端末の範囲）
• テストの範囲（単体、結合までか、総合テストの支援も含むか）
• データ移行、初期データ投入、運用マニュアルなど周辺作業の有無
• リリース後の保守や問い合わせ対応を含めるか
• 打ち合わせとレビューの回数や参加頻度

特に「やらないこと」は見落とされやすい項目です。たとえば「サーバー構築は含みません」「デザインは支給された画面設計に従い、新規のデザイン作成は含みません」のように、境界を一文で明示します。

前提条件の書き方

前提条件とは、その見積額が成り立つための条件のことです。条件が崩れたときに金額や納期を見直せるよう、見積書に明文化しておきます。

書き方のコツは、発注者側の行動に依存する項目を具体的な期限や回数で書くことです。

• 要件は着手前に確定し、確定後の変更は別途見積もりとします
• 発注者のレビューは提出後5営業日以内に行われるものとします
• 開発環境、既存システムの仕様書、連携先のAPI情報は着手時に貸与されるものとします
• 画面デザインの修正対応は2回までとします

数字は案件ごとに調整する例です。前提を並べておくと、後から要件が増えたときに「この前提が変わったので再見積もりです」と説明しやすくなります。編集部の整理では、前提条件を書かずに金額だけを提示した見積もりが、後のトラブルで受注側に不利になりやすい傾向があります。

工数の出し方

工数は、作業を細かく分けて積み上げる方法を主軸にし、過去の類似案件の実績で検算する形が現実的です。

作業分解からの積み上げ

作業分解からの積み上げとは、工程ごとに作業を分け、それぞれの人日（1人が1日働く量）を足し合わせる方法です。見積もりの根拠を説明しやすい点が強みです。

次の表は、社内の業務用Webアプリ（画面6つ、帳票出力2種類）を請負で受ける想定の架空の例です。数字はあくまで計算の流れを示すためのもので、実際の案件の目安ではありません。

積み上げのときは、実装だけでなく設計、テスト、打ち合わせ、リリース対応まで漏らさず入れるのがポイントです。実装工数だけを見積もって、テストや調整の時間が抜けるのは典型的な過小見積もりの原因です。

類似案件の実績の使い方

類似案件の実績は、積み上げた工数が極端にずれていないかを確かめる検算として使います。実績を単独の根拠にすると、条件の違いを見落としやすくなります。

使い方の例は次のとおりです。過去に「10画面の管理システム」を実測で60人日かけて作った記録があれば、画面1つあたりおよそ6人日という物差しができます。今回が画面6つなら36人日前後と見当がつき、積み上げた結果の実装・テスト部分と大きく食い違うときは、どちらかの前提を見直します。

実績を使うには、案件が終わるたびに工程別の実績工数を記録しておくことが前提です。記録が無い初期のうちは積み上げを主にし、案件ごとに実績を貯めていくと、見積もりの精度が少しずつ上がります。条件の違い（既存システムとの連携の有無、仕様の確定度合い、使う技術への習熟度など）は、実績をそのまま流用せず補正して見ます。

単価と見積額の決め方

見積額は「工数×リスク係数×日単価」で求めます。日単価は、必要な収入と実際に請求できる日数から逆算し、市場の水準で妥当性を確認します。

時間単価の考え方

時間単価（日単価）は、年間で必要な売上を、実際に請求できる日数で割って求めます。会社員の給与を時給換算するのとは違い、稼働しない日や経費、税金、社会保険の負担を織り込む必要があります。

請求できる日数は、年間フル稼働では見積もれません。年間のアベイラブル（案件の空白）期間を2か月とし、稼働率を約83%に置く試算が一般的とされています。月20日稼働として年間240日に83%を掛けると、請求できる日数は約200日です。

架空の例で計算します。年間に必要な売上を900万円（手取りの目標、経費、税金、社会保険などを合算した金額）と置くと、900万円÷200日で日単価は4.5万円になります。この日単価はあくまで計算の流れを示す例であり、実際の水準ではありません。

日単価を決めたら、市場の水準と照らして妥当性を確認します。システム・IT領域の単価は、同じ職種でも工程によって大きく開く点に注意が必要です。公開されている情報では、IT戦略のような上流の領域は月額150〜200万円、運用・保守寄りの案件は下限が50〜60万円台まで下がるとされています。自分の担当工程がどの位置にあるかを踏まえて、日単価が高すぎないか、安すぎないかを確認します。

エージェント経由で案件に参画する場合は、エージェントの手数料（中間マージン）が差し引かれた後の金額が実際の手取りに影響します。公開情報では、マージンは一般に20〜30%程度で、コンサル特化型は非公開のサービスが多いとされます。IT系では数値を公開している例もあります。エージェントを通すかどうかは、大手企業との取引では与信や請求処理の都合から、エージェント経由の3者間契約になるケースが多いことも踏まえて検討します。独立初期は2〜3社を併用し、相場感をつかむ進め方が定石です。エージェントの比較はフリーランスエンジニアのエージェント比較も参考になります。

課税事業者として取引する場合は、報酬に消費税を上乗せして請求します。法人のクライアントが中心の取引では、適格請求書発行事業者（インボイス）の登録を求められる場面が多く、免税事業者のままだと消費税分の値下げを打診される場合があります。見積書の金額は税別で書き、税区分を明記すると誤解が起きません。

リスク係数の入れ方

リスク係数とは、見積もりの不確実さを工数に上乗せする倍率のことです。仕様の固まり具合に応じて、積み上げた工数に1.1〜1.3程度を掛ける形が実務でよく見られる整理です。

次の表は、係数を決めるときの目安を整理した一例です。倍率は編集部が実務上の考え方として示す例であり、公的な基準ではありません。

積み上げた51人日に係数1.2を掛けると、見積もり工数は61.2人日です。これに日単価4.5万円を掛けると、61.2人日×4.5万円＝約275万円（税別）になります。この計算では、積み上げ51人日が「作業そのものに必要な時間」、係数による10.2人日が「不確実さへの備え」と読めます。

係数を使うときの注意点は、上乗せの根拠を前提条件に書き込むことです。「仕様が未確定のため係数1.2」と見積書に書くより、「仕様確定時期を着手後2週間以内と仮定した場合の金額です」のように前提条件で表現すると、発注者が条件を整えれば金額を下げられるという建設的な話になります。

契約形態別の見積もりの違い

請負は完成責任を見積額に織り込み、準委任は稼働の条件を見積もります。契約形態によって、見積もりで確かめるものが変わります。

請負契約の場合

請負契約では、成果物の完成に対して報酬が支払われるため、見積額は固定額になりやすく、完成させるリスクを受注側が負います。そのため、リスク係数を含めた金額を提示し、検収の条件まで先に固めておく必要があります。

民法632条は、請負を「当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約する」契約と定めています（e-Gov法令検索・2026-10-05参照）。仕事の完成が報酬の対価なので、何をもって完成とするか（検収基準）を曖昧にしたまま固定額で受けると、追加の修正作業が無償で積み上がりやすくなります。

請負で見積もるときは、次の点を確認します。

• 成果物の定義と検収基準（どの状態になれば完成とみなすか）
• 検収の期間と、検収後の不具合対応の範囲
• 仕様変更が起きたときの追加見積もりの手順
• リスク係数を含めた固定額が、想定外の作業に耐えられるか

準委任契約の場合

準委任契約では、業務を遂行すること自体に報酬が発生し、成果物の完成義務は原則として負いません。見積もりでは、完成までの総工数よりも、稼働の条件を中心に組み立てます。

民法643条は、委任を法律行為の委託と定め、656条は法律行為でない事務の委託にその規定を準用すると定めています。また、648条は、受任者は特約がなければ報酬を請求できないと定めています（e-Gov法令検索・2026-10-05参照）。つまり準委任では、報酬の額や支払い方を契約で明確に決めておく必要があります。

見積もりでは、月額を「日単価×稼働日数」で表す形が基本です。日単価4.5万円で月20日稼働なら、月額は90万円という計算になります。これも架空の例です。システム開発ではSES型のように、月140〜180時間といった範囲で時間精算する契約もあるとされます。見積もりのときは次の条件を書き出します。

• 稼働の日数や時間（週何日、月何時間）
• 精算の方法（固定の月額か、時間精算か、精算幅はどこまでか）
• 契約期間と更新の条件（3〜6か月ごとの更新が一般的とされます）
• 報告の方法と、成果物を求められる場合の扱い

フリーコンサルの案件では約70〜80%が準委任契約とされますが、システム開発の案件では請負で結ぶものも少なくありません。契約書の名称ではなく、報酬の決まり方や成果物の責任の範囲で形態を見分けることが大切です。契約形態の違いは業務委託・準委任・請負の違いで詳しく整理しています。契約書の確認ポイントは業務委託契約書の注意点も参考にしてください。個別の契約内容がどちらに該当するかは、弁護士など専門家への相談をおすすめします。

よくある見積もりの失敗

見積もりの失敗は、要件追加を無償で受けてしまうことと、検収の遅れで入金が後ろにずれることに集中します。どちらも見積もりの時点で手当てできます。

要件追加の扱い

要件追加で損をしないためには、変更が出たときの手順を最初に決めておくことが重要です。変更の都度、口頭で「ついでに対応します」と受けると、気づいたときには想定の数割増しの作業になっていることがあります。

決めておく内容は、次の3点です。

• 軽微な変更として無償で対応する範囲（例：文言の修正は月3回まで）
• 範囲を超える変更は、影響する工数を示した追加見積もりを出し、承認後に着手すること
• 変更の依頼と承認は、メールやチケットなど記録が残る方法で行うこと

これらを前提条件として見積書に書いておけば、変更が出たときに「ルールに沿った手続き」として話を進められます。個人の交渉力に頼らずに済む点がメリットです。

検収の遅れ

検収が遅れると、請負では報酬の確定が先送りになり、資金繰りに響きます。検収の期間と、期間を過ぎたときの扱いを契約や見積書に書いておくのが対策です。

見積もりのときに確認しておきたいのは、納品から検収までの期間（例：納品後10営業日以内）と、検収の結果を連絡する方法です。期間内に連絡がない場合の扱いは契約で調整する項目なので、書面で合意しておきます。

支払いのルールも法律で定められています。特定受託事業者に係る取引の適正化等に関する法律（フリーランス・事業者間取引適正化等法）の第3条は、業務委託事業者が、給付の内容、報酬の額、支払期日などを書面または電磁的方法で明示しなければならないと定めています。第4条は、報酬の支払期日を、給付を受領した日から起算して60日以内で、できる限り短い期間内に定めなければならないと定めています（e-Gov法令検索・2026-10-05参照）。実務では、月末締め翌月末払い（約40日）が標準的とされるので、見積書の支払条件とあわせて確認します。なお、法律の適用の有無は取引の相手や内容によって異なるため、個別の判断は専門家への相談をおすすめします。

見積書の構成と提示のコツ

見積書は、前提条件と内訳が読み取れる構成にし、有効期限と支払条件まで書いて初めて提示できる状態になります。

項目の並べ方

見積書の項目は、上から「何の見積もりか」「いくらか」「内訳」「前提条件」の順に並べると、読み手が判断しやすくなります。

基本の並べ方は次のとおりです。

1. 件名、宛先、見積もり日、見積書番号
2. 合計金額（税別と税込を分けて表示）
3. 内訳（工程または作業項目ごとの工数、単価、小計）
4. スコープ（含むもの、含まないもの）
5. 前提条件と、変更時の扱い
6. 契約形態（請負か準委任か）と、検収または精算の方法
7. 有効期限、支払条件、適格請求書発行事業者の登録番号

内訳は「開発一式」とまとめず、工程別に分けて示すほうが、発注者が金額の根拠を理解しやすく、値引き交渉でも「どの工程を削るか」という建設的な議論になります。ただし、リスク係数の上乗せ分を「リスク費」という別行で示すか、各工程の工数に含めるかは、発注者との関係や社内の稟議の通しやすさを見て判断します。

有効期限と支払条件

有効期限は、見積もりの前提が変わる前に回答をもらうために設定し、支払条件は締め日と支払日まで具体的に書きます。

有効期限は、案件の規模にもよりますが、発行日から1か月程度に設定する例が多く見られます。長すぎると、単価の変動や自分のスケジュールの変化に対応できなくなります。期限を過ぎた場合は、再見積もりになる旨も一言添えておきます。

支払条件には、締め日、支払日、振込手数料の負担、請求書の発行タイミングを書きます。請負で分割払いにする場合は、着手時、中間、検収後のように支払いの節目と割合を決めておくと、資金繰りが安定します。インボイス制度に対応する場合は、請求書に登録番号（Tに続く13桁）を記載します。税務の取り扱いの詳細は、税理士など専門家への相談をおすすめします。

見積もりの出し方は、システム開発の仕様書を書く場面にもつながります。仕様書の作り方はシステム開発の仕様書の書き方も参考にしてください。

出典・参考情報

1. e-Gov法令検索「民法」（明治二十九年法律第八十九号）第632条・第643条・第648条・第656条（2026-10-05参照）
2. e-Gov法令検索「特定受託事業者に係る取引の適正化等に関する法律」（令和五年法律第二十五号）第3条・第4条（2026-10-05参照）

本記事の計算例の金額、工数、リスク係数は、考え方を示すための架空の数値です。実際の案件の相場や基準を示すものではありません。単価・契約・税務の個別の判断は、弁護士や税理士など専門家への相談をおすすめします。本記事は2026年10月時点の情報に基づき作成しています。

最終更新日：2026年10月5日