見積書の作り方｜請負案件で工数を積み上げる手順と前提条件の書き方

請負案件の見積書は、作業を細かく分けて工数を積み上げ、その金額がどんな前提で成り立っているかを書き添えた書類です。金額だけを出すのではなく、「何を作るか」「何は含まないか」「前提が変わったらどうするか」まで書いておくと、仕様の追加や手戻りが起きたときに話し合いの土台になります。

請負は仕事の完成に対して報酬が支払われる契約で、完成までにかかった手間が見積もりを超えても、合意がなければ報酬は増えません。この記事では、工数の見積もり方と前提条件の書き方を、仮の数字を使って説明します。単価の水準は案件や役割によって大きく変わるため、ここでは扱いません。

請負の見積もりが準委任より重い理由

民法第632条は、請負を「仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約する」契約としています。報酬は原則として目的物の引渡しと同時に支払われます（第633条）。

月額で稼働する準委任では、作業が増えれば稼働時間の精算で調整される余地があります。これに対して請負では、見積もった金額で完成させることを約束するため、見積もりの誤差はそのまま自分の負担になります。完成前に契約が解除されたときは、すでに行った仕事のうち注文者が利益を受ける部分について、その割合に応じて報酬を請求できる定めもあります（第634条）が、どの部分が「可分」かで争いになりやすいところです。契約の型の違いは準委任と請負の記事で整理しています。

見積書に入れる項目

見積書の書式に法律上の決まりはありません。ただ、後から読み返して条件が分かるように、次の項目をそろえておくと安心です。

税込・税抜の書き方は税込・税抜の記事で詳しく扱っています。

工数を積み上げる5つの手順

1. 成果物から作業を分解する

「ECサイトの改修一式」のような大きな単位のままでは、見積もりの誤差が大きくなります。作るもの（成果物）を列挙し、それぞれを「調査」「設計」「実装」「テスト」のような作業に分けます。目安として、1つの作業が1〜2日程度に収まるまで分けると、見積もりの根拠を説明しやすくなります。

2. 作業ごとに幅を持たせて見積もる

1つの数字で見積もると、楽観的な値に寄りがちです。作業ごとに「うまくいった場合」「普通の場合」「手間取った場合」の3つを考えると、どこに不確実さがあるかが見えます。3つの値から平均を取る三点見積もりという手法もあります。過去に似た作業をしたときの実績を記録しておくと、次の見積もりの精度が上がります。

3. 見落としやすい作業を足す

実装そのもの以外の作業は、見積もりから抜けやすい部分です。

• 打合せ・進捗報告・質問への回答
• 仕様の確認と、確認待ちの間の手戻り
• テストデータの準備、テスト結果の記録
• レビュー指摘への対応
• 環境構築、デプロイ、リリース作業
• 納品物の説明資料、操作手順書
• 検収のための受入テストの支援と修正

4. リスクの分を上乗せする

初めて使う技術、発注者側の体制が見えない、既存のコードの品質が分からない、といった不確実さがある場合は、その分を上乗せします。上乗せした理由を前提条件の欄に書いておくと、発注者にも説明しやすくなります。

5. 工数に単価を掛けて金額にする

最後に、合計の工数に自分の単価を掛けます。単価をどう決めるかは報酬の決まり方の記事を参考にしてください。

仮の数字で見る見積もりの例

以下は、管理画面に検索機能を追加する案件を想定した仮の数字です。

金額は「合計工数×単価」で出します。たとえば実装だけを見積もって6人日で出していたら、実際の作業量の3分の1ほどしか金額に入っていないことになります。

前提条件の書き方

前提条件は、「この条件が崩れたら金額と納期を見直します」という合意の材料です。抽象的な一文ではなく、確かめられる形で書きます。

あわせて、範囲外も箇条書きで書いておきます。データ移行、本番環境での運用、保守、ほかのシステムとの連携、マニュアルの作成などは、発注者が「当然含まれる」と考えていることがあるため、含まないなら明記します。

前提が変わったときの扱いは、「前提条件に変更が生じた場合は、作業内容・金額・納期を協議のうえ再見積もりします」のように一文入れておきます。実際に範囲が広がったときの進め方は作業範囲が広がったときの記事をご覧ください。

不確実さが大きいときは工程を分けて見積もる

要件が固まっていない段階で、完成までを一括で見積もるのは難しいものです。その場合は、次のように分ける方法があります。

1. 要件の整理や調査を、まず準委任や小さな請負として切り出す
2. 要件が固まった時点で、設計・実装・テストを改めて見積もる
3. 大きな案件は、マイルストーンごとに検収と支払いを分ける

情報処理推進機構（IPA）の「情報システム・モデル取引・契約書（第二版）」でも、見直しのポイントの一つに「システム開発における複数契約の関係」が挙げられています。工程ごとに契約を分けるときは、前の工程の成果物が次の見積もりの前提になることを書いておきます。検収の条件は検収の記事、引き渡した後の責任は契約不適合責任の記事で確認してください。

見積もりの段階で気をつけたいこと

見積もりの作業そのものの扱い

詳しい見積もりには、既存コードの調査など、それ自体に工数がかかることがあります。調査に数日かかる規模なら、調査を有償の作業として切り出せないか相談する方法もあります。

報酬を一方的に決められそうなとき

フリーランスガイドラインは、取引上の地位が優越している発注事業者が、自ら金額まで書いた見積書を用意し、フリーランスが協議を求めたのにサインさせて、通常より著しく低い報酬を一方的に定めることを、優越的地位の濫用として問題となり得る例に挙げています。判断の考え方は優越的地位の濫用の記事で解説しています。

金額を決めきれない部分があるとき

公正取引委員会のフリーランス法Q&Aでは、業務委託の時点で費用の有無や額が分からない諸費用について、別途協議して定める旨を書くことが認められる場合があるとしています。ただし、決められない事情がなくなったら速やかに協議して決め、直ちに明示する必要があるとされています。交通費などの実費を見積もりに含めるか別に請求するかも、見積書に書いておきましょう。

よくある質問

見積もりより工数がかかってしまいました。追加で請求できますか？

前提条件が変わったことによる増加なら、見積書の前提条件と変更の経緯を示して、追加の報酬を相談する余地があります。一方、前提が変わっていないのに自分の見込み違いで工数が増えた場合は、請負では原則として当初の金額で完成させることになります。次の見積もりに実績を反映させることが大切です。個別の事情で判断が分かれる場合は、弁護士などの専門家にご相談ください。

見積書は無料で出すものですか？

一般的には無料で出すことが多いものの、決まりがあるわけではありません。詳しい見積もりのために既存システムの調査などが必要な場合は、その調査を有償の作業として切り出せないか相談できます。どこまでを無料の見積もりとするかは、最初に伝えておくと誤解を防げます。

見積書に印紙は必要ですか？

印紙税は、文書の名称ではなく記載の内容と、何を証明する目的で作った文書かで判断されます。金額を提示するだけの見積書は、一般に契約の成立を証明するために作るものではありません。一方、見積もりの後に作る注文請書や請負の契約書は、内容によって課税文書になります。詳しくは業務委託契約書の印紙税の記事をご覧ください。判断に迷う場合は税務署にご確認ください。