フリーランスエンジニアへの発注書｜良い発注に必要な4つの要素と新法対応

フリーランスエンジニアに開発や運用を発注するとき、「発注書はちゃんと出せているだろうか」と不安になったことはありませんか。社内の経理や法務から確認されたり、相手から「取引条件の書面をください」と求められたりして、自社のフォーマットで足りるのか自信が持てない、という発注担当者の方は少なくありません。

しかも2024年11月にフリーランス新法（フリーランス・事業者間取引適正化等法）が施行され、発注時に取引条件を書面などで明示することが義務になりました。発注書はもはや「出しておいたほうがよい任意の書類」ではなく、満たすべきルールが定められた書面になっています。

とはいえ、本当に怖いのは法令違反だけではありません。発注書が曖昧だと、「言った言わない」のすれ違い、想定外の追加費用、「納品物がイメージと違う」という手戻りが起きます。最悪の場合、優秀なフリーランスほど「この発注者とは進めにくい」と感じて離れていってしまいます。法令を満たすことと、相手に安心して受けてもらえることは、別の課題なのです。

そこで本記事では、フリーランスエンジニアへの発注書について、(1) フリーランス新法で義務付けられた必須記載事項という「最低ライン」と、(2) それに上乗せして認識齟齬を防ぎ、相手に信頼される「良い発注」にするための4つの要素を、悪い例・良い例の比較とともに解説します。読み終えたとき、自社の発注書を今日から点検できる状態を目指します。

フリーランスエンジニアへの発注書とは｜なぜ「良い発注書」が必要なのか

まず押さえておきたいのは、発注書が単なる事務手続きの紙ではなく、取引のトラブルを未然に防ぐための書面だということです。ここを軽く見ると、後工程で大きなコストを払うことになります。

発注書が果たす役割

発注書とは、発注者がフリーランスエンジニアに対して「何を・いくらで・いつまでに・どういう条件で依頼するか」という取引条件を確定させる正式な書面です。役割は大きく3つあります。

• 取引条件の確定: 業務内容・報酬・納期・支払条件といった合意内容を文字に残し、双方の認識を一致させます。
• トラブルの予防: 後から「そんな話は聞いていない」「これも含まれているはずだ」という食い違いが起きたときに、立ち返る基準になります。
• 相手への信頼の提示: 条件が整理された発注書は、「この発注者は仕事の進め方を分かっている」という安心材料になります。フリーランス側は受注前に発注書を見て、リスクを判断しているからです。

3つ目は見落とされがちですが、発注書の質はそのまま「発注者としての印象」になります。条件が明確な発注は、優秀な人ほど安心して受けられます。

曖昧な発注で起きる典型トラブル

発注書が曖昧だと、具体的には次のようなトラブルが起きます。

• 認識齟齬による手戻り: 「ログイン機能を作ってほしい」とだけ伝えた結果、想定していたパスワード再発行やソーシャルログインが含まれておらず、納品後に「これも入っていると思った」ともめる。
• 追加費用をめぐる対立: スコープ（作業範囲）の線引きが曖昧なため、追加依頼が「当然無料の範囲」なのか「別途見積もりの範囲」なのか判断できず、双方が不満を抱える。
• 相手の離脱: 条件が不明確で進めにくい発注が続くと、フリーランスは次の依頼を断る、あるいは単価を上げて自衛するようになる。継続的に良い人材に受けてもらえなくなる。

これらはどれも、発注書に「あと一文」あれば防げたものがほとんどです。だからこそ、法令を満たすだけでなく、認識齟齬を防ぐ視点で発注書を設計する価値があります。

発注書・見積書・契約書・仕様書の違い｜発注書が担う範囲を整理する

「発注書に何をどこまで書けばいいのか分からない」という悩みの多くは、書面ごとの役割を混同していることから生まれます。発注書に全部を詰め込もうとすると破綻しますし、逆に発注書で書くべきことを別の書類に任せきりにすると抜け漏れが起きます。まずは書類の役割分担という地図を持ちましょう。

書類の流れ（見積書→発注書→請書→契約書）

エンジニアへの発注では、一般的に複数の書類が組み合わさって取引が進みます。

実務では「見積書で金額を確認し、発注書で正式に依頼を確定し、請書で受注を確認する」という流れが基本です。継続的に発注する場合は、最初に基本契約書を結び、個別の案件ごとに発注書を発行する、という運用が効率的です。基本契約書が「取引全体の共通ルール」を定め、発注書が「今回の個別取引の中身」を定める、という役割分担になります。

発注書と仕様書（SOW）の役割の違い

混同しやすいのが、発注書と仕様書（SOW＝作業範囲記述書）の違いです。

• 発注書: 取引条件を確定させる書面。業務内容・報酬・納期・支払条件など、「取引としての約束」を定めます。
• 仕様書・SOW: 作業の中身を具体的に記述する文書。画面仕様・機能要件・技術要件・受入基準など、「作るものの詳細」を定めます。

両者は守備範囲が違います。発注書に技術仕様を細かく書き込もうとすると膨大になり、かえって読みにくくなります。逆に、仕様書だけ渡して発注書を出さないと、報酬や納期といった取引条件が宙に浮きます。実務では「発注書で取引条件を確定し、詳細は別添の仕様書・SOWで補う」という形が読みやすく、抜け漏れも防げます。発注書本文には「詳細は別紙仕様書のとおり」と書いて参照させるとよいでしょう。

仕様書・SOW に何を書くべきかは、別記事のフリーランスへの依頼書・SOWの書き方で詳しく整理しています。仕様書を出さないことで開発がブレてしまう問題については発注書と仕様書の役割分担も参考になります。

【前提】フリーランス新法で発注書に義務付けられた必須記載事項

良い発注書を考える前に、まず満たすべき「最低ライン」を確認します。2024年11月1日に施行されたフリーランス・事業者間取引適正化等法（通称フリーランス新法）では、発注事業者に対して取引条件を明示する義務が定められました。これがいわゆる「3条通知」です。

取引条件明示義務の対象と明示方法

フリーランス（特定受託事業者）に業務委託をした発注事業者は、直ちに取引条件を明示しなければなりません。明示の方法は書面または電磁的方法（メール、チャットツールのメッセージなど）が認められており、口頭だけで済ませることは認められていません（公正取引委員会パンフレット、厚生労働省 フリーランス法特設ページ）。書面でも電磁的方法でも、どちらを選ぶかは発注者側で決められます。

なお、発注時点で内容を定められない項目（未定事項）がある場合は、「定められない理由」と「いつ定めるかの予定期日」を明示し、内容が決まった段階で改めて明示する必要があります（出典: 公正取引委員会・中小企業庁、2024年）。「あとで決めるから空欄」のままにはできない点に注意してください。

必須記載事項チェックリスト

3条通知で明示が義務付けられている主な事項は、次のとおりです（公正取引委員会パンフレット）。

まずは自社の発注書がこの9項目を満たしているかを確認してください。これが法令上の最低ラインです。ただし、この一覧を見て気づくとおり、ここには「成果物の受入基準」「追加対応の扱い」「進め方」といった、エンジニア発注で実際にもめやすいポイントが含まれていません。次の章で、この最低ラインに上乗せすべき要素を整理します。

フリーランスエンジニアに良い発注書を出すための4つの要素

ここからが本記事の核です。前章の必須記載事項を満たしただけでは、認識齟齬や追加費用トラブルは防ぎきれません。法令という土台の上に、エンジニア発注で実際にもめやすいポイントを埋める4つの要素を上乗せすることで、発注書は「相手が安心して受けられる発注」に変わります。各要素について、「書かないと何が起きるか」と「どう書けばよいか」をセットで見ていきましょう。

要素1: 業務範囲と成果物の受入基準を具体的に定義する

最もトラブルになりやすいのが、業務範囲（スコープ）と「何をもって完了とするか」の曖昧さです。

「Webサイトの問い合わせフォームを作成」とだけ書くと、バリデーションの有無、自動返信メール、管理画面、スパム対策などが含まれるのかどうかが人によって解釈が分かれます。受入基準（何が満たされたら検収・支払いをするか）も曖昧だと、「終わったつもり」と「まだ終わっていない」がすれ違います。

発注書には、次のように具体化しましょう。

• 含む作業を箇条書きで明記する: 「入力フォーム実装／入力値バリデーション／自動返信メール送信／管理画面からの問い合わせ一覧表示」のように分解する。
• 含まない作業（スコープ外）を明記する: 「※デザイン制作、スパム対策（reCAPTCHA等）は本発注に含みません」と書くだけで、追加依頼の線引きが明確になる。
• 受入基準を書く: 「ステージング環境で発注者が動作確認し、報告した不具合の修正完了をもって検収とする」など、完了の定義を明文化する。

あわせて、この発注が準委任（作業の遂行に対して支払う）なのか請負（成果物の完成に対して支払う）なのかを明示しておくと、責任範囲が明確になります。完成させたい成果物と納期が決まっているなら請負、仕様が固まりきらず柔軟に進めたいなら準委任が向いています（レバテック 請負契約と準委任契約の違い）。どちらを選ぶかで受入基準の書き方も変わります。

要素2: 報酬・支払条件と追加対応の扱いを明確にする

法令上、報酬の額と支払期日は必須項目です。しかし「良い発注書」では、それに加えて追加対応・仕様変更が出たときの扱いまで書いておくことが重要です。

報酬まわりで書いておきたいのは次の点です。

• 報酬の額と内訳: 一括なのか、フェーズごとの分割なのか。工数ベースか成果物ベースか。
• 支払期日と支払方法: 「検収完了後、翌月末払い・指定口座への振込」など具体的に。
• 追加依頼・仕様変更時の精算ルール: 「スコープ外の追加作業が発生する場合は、着手前に別途見積もりのうえ合意する」と一文入れる。これがないと、追加作業が「無料サービス」と受け取られたり、逆に勝手に請求されたりして対立します。
• 経費・交通費の負担: 外部サービスの利用料、打ち合わせの交通費などを誰が負担するか。

特に「追加依頼が出たらどうするか」をあらかじめ決めておくことは、フリーランス側にとって大きな安心材料になります。スコープ外の対応を泣き寝入りで引き受けるリスクが減るからです。

要素3: 納期と中間マイルストーン・進め方を共有する

最終納期だけを書いた発注書は、実は危険です。納品直前になって初めて成果物を見たら想定と違っていた、という事態を招きやすいからです。

良い発注書では、最終納期に加えて中間の確認ポイント（マイルストーン）を共有します。

• 「○月○日: 設計レビュー」「○月○日: 主要機能のデモ確認」「○月○日: 最終納品」のように、節目を置く。
• 各マイルストーンでの確認方法（デモ、ステージング環境での確認、進捗報告の形式）を決めておく。

これにより、早い段階で認識のズレに気づいて軌道修正でき、手戻りを最小化できます。

ここで注意したいのが、指揮命令と受け取られる依頼の仕方を避けることです。準委任や請負で発注している場合、発注者には指揮命令権がありません。「毎日決まった時間に出社して常駐し、その場で逐一指示に従って作業する」といった働き方を求めると、実態として労働者と変わらず、偽装請負と判断されるリスクがあります（テックストック 準委任契約と偽装請負）。発注書では「いつまでに・何を・どの基準で」という成果と期限を共有し、「どう作業を進めるか・いつ働くか」はフリーランスの裁量に委ねる、という形が適切です。マイルストーンは「進捗を確認する節目」であって「作業を細かく管理する手段」ではない、と意識しましょう。

要素4: 連絡・確認の方法と前提情報を添える

最後の要素は、フリーランスが「すぐに動き出せる状態」を作ることです。条件は揃っていても、コミュニケーションの段取りや前提情報が欠けていると、立ち上がりでつまずきます。

発注書（または別添資料）に添えておきたいのは次の点です。

• 連絡手段と窓口: 主なやり取りはチャットツールかメールか、誰が窓口か。
• レスポンスの期待値: 「質問への回答は原則1営業日以内」など、双方の期待をすり合わせる。これは発注者側の確認スピードへのコミットでもあります。
• 進捗共有の頻度・形式: 週次report か、マイルストーンごとか。
• 前提情報・参照資料: 既存システムの構成、利用中のサービス、デザインガイドライン、アクセス権限など、作業に必要な情報の所在。

特に前提情報の提供は、優秀なフリーランスほど重視します。「何が分かっていて、何が決まっていないか」が明確な発注は、見積もりの精度が上がり、認識齟齬が減るからです。発注者が前提を整理して渡せるかどうかは、そのまま発注の質として伝わります。

悪い発注書と良い発注書の比較｜Before/Afterで見る書き方

ここまでの4要素を、実際の文面レベルで見比べてみましょう。「この一文があるかないか」で認識齟齬が起きるかどうかが変わります。

悪い発注書の例とそれが招くトラブル

業務内容: 問い合わせフォームの作成 報酬: 15万円 納期: 来月末 支払: 完了後

この発注書には法令上の項目も一部欠けていますが、それ以上に「実務でもめる火種」が詰まっています。

• フォームに何が含まれるか（自動返信、管理画面、バリデーション）が不明 → 納品後に「これも入っていると思った」ともめる。
• 受入基準がない → 「完了」の定義が共有されず、検収が長引く。
• 追加対応の扱いがない → 仕様変更が出たときに無料か有料かで対立。
• 中間確認がない → 納品直前まで成果物を見られず、手戻りが大きくなる。
• 前提情報・連絡手段がない → フリーランスが質問を繰り返し、立ち上がりが遅れる。

良い発注書の例（4要素を満たした記載）

業務内容: コーポレートサイトの問い合わせフォーム実装（準委任） ・含む作業: 入力フォーム実装／入力値バリデーション／自動返信メール送信／管理画面での問い合わせ一覧表示 ・含まない作業（スコープ外）: フォームのデザイン制作、reCAPTCHA等のスパム対策（必要時は別途見積もり） ・受入基準: ステージング環境で発注者が動作確認し、報告した不具合の修正完了をもって検収とする

報酬: 15万円（税別）。追加・仕様変更が発生する場合は着手前に別途見積もりのうえ合意する。 支払: 検収完了後、翌月末に指定口座へ振込。

スケジュール: 設計レビュー（○/10）→ 主要機能デモ確認（○/20）→ 最終納品（○/末） 進め方: 作業時間・進め方はご裁量にお任せします。進捗は週次でチャットにご共有ください。

連絡・前提: 主な連絡はSlack（窓口: △△）、質問への回答は原則1営業日以内。既存サイトの構成資料・テスト環境のアクセス権は発注時に共有します。

同じ「15万円・来月末」の発注でも、4要素を満たすだけで、フリーランス側は「何をどこまでやればいいか」「困ったときどうすればいいか」が分かります。これが「この発注者なら安心して受けられる」という印象につながります。

発注後の運用｜追加依頼・仕様変更が出たときの発注書の扱い

良い発注書は「出して終わり」ではありません。開発を進めれば、追加依頼や仕様変更はほぼ必ず発生します。ここでの対応の仕方が、トラブルを起こすか、信頼を積み重ねるかの分かれ目になります。

仕様変更・追加依頼が出たときの追補のしかた

開発中に「やっぱりこの機能も追加したい」「仕様を変えたい」という話が出たとき、口頭やチャットの一言で済ませてはいけません。スコープ・報酬・納期に影響する変更は、必ず書面で追補しましょう。

• 追加分の発注書（または変更合意書）を改めて出す: 「追加作業の内容・追加報酬・新しい納期」を明文化する。
• 当初発注書との関係を明記する: 「○月○日付発注書の内容に、以下を追加する」と書けば、何がベースで何が追加かが明確になる。

フリーランス新法の観点でも、業務委託の内容を変更する場合は改めて取引条件を明示することが求められます。口頭で追加を重ねると、後から「それは無料の範囲だと思っていた」という最も典型的なトラブルに発展します。少し手間でも書面に残すことが、結果的に双方を守ります。

継続発注で関係を育てる発注書運用

同じフリーランスに継続的に発注する場合は、最初に基本契約書を結び、案件ごとに発注書を発行する運用が効率的です。共通ルール（支払サイト、秘密保持、知的財産の帰属など）は基本契約書に集約し、発注書は「今回の業務内容・報酬・納期」だけを書けばよくなります。発注のたびに条件を一から確認する手間が減り、双方にとってスムーズになります。

基本契約書（業務委託契約書）に何を書くべきかは、業務委託契約書のテンプレート（発注者向け）で詳しく解説しています。

良い発注を積み重ねると、フリーランス側は「この発注者は条件が明確で進めやすい」と感じ、次の依頼を優先的に受けてくれるようになります。発注書の質は、単発のトラブル回避にとどまらず、優秀な人材を継続的に確保できるかどうかにも直結するのです。

よくある質問（FAQ）

発注書をめぐって発注担当者からよく寄せられる疑問に、簡潔にお答えします。

フリーランスへの発注は口頭やメールだけでも問題ない？

口頭だけで済ませることはできません。フリーランス新法では、業務委託をした際に書面または電磁的方法で取引条件を明示する義務があります。メールやチャットツールのメッセージは電磁的方法として認められるため、必ずしも紙の発注書である必要はありませんが、口頭のみは不可です（公正取引委員会パンフレット）。後から内容を確認できる形で残すことが重要です。

発注書と業務委託契約書は両方必要？

役割が異なるため、継続取引では両方あるのが望ましい形です。業務委託契約書（基本契約書）は「取引全体の共通ルール」を、発注書は「個別案件の業務内容・報酬・納期」を定めます。単発の取引であれば、必要事項をすべて盛り込んだ1通の書面（契約書を兼ねた発注書）で対応することもありますが、継続発注なら基本契約＋個別発注書の運用が効率的です。

準委任と請負はどちらで発注すべき？

簡単な判断軸は「完成させたい成果物と納期が明確かどうか」です。明確に完成させたい成果物があり納期が決まっている場合は請負、仕様が固まりきらず柔軟に進めたい・中長期で伴走してほしい場合は準委任が向いています（レバテック 請負契約と準委任契約の違い）。準委任では発注者に指揮命令権がないため、作業の進め方を細かく指示すると偽装請負と見なされるリスクがある点にも注意してください。

テンプレートをそのまま使えば「良い発注書」になる？

テンプレートは法令上の必須項目を漏れなく押さえるのに有効ですが、それだけでは「良い発注書」にはなりません。本記事で挙げた4要素（業務範囲と受入基準／追加対応の扱い／中間マイルストーン／連絡・前提情報）は、案件ごとに中身を埋める必要があります。テンプレートは土台として使い、案件固有の条件を具体的に書き込むことで、初めて認識齟齬を防ぐ発注書になります。

まとめ｜良い発注書はフリーランスとの信頼関係の入口

フリーランスエンジニアへの発注書は、フリーランス新法の必須記載事項（業務内容・報酬・支払期日など9項目）を満たすことが最低ラインです。しかし、それだけでは認識齟齬や追加費用トラブルは防ぎきれません。

法令の土台に、次の4つの要素を上乗せすることで、発注書は「相手が安心して受けられる良い発注」に変わります。

1. 業務範囲と成果物の受入基準を具体的に定義する（スコープ・スコープ外・完了の定義）
2. 報酬・支払条件と追加対応の扱いを明確にする（追加依頼・仕様変更時の精算ルール）
3. 納期と中間マイルストーン・進め方を共有する（指揮命令にならない形で）
4. 連絡・確認の方法と前提情報を添える（相手が動き出せる状態を作る）

これらは難しい法律論ではなく、「書かないと何が起きるか」を想像して一文を足すだけで実践できます。まずは自社の発注書をこの4要素で点検してみてください。曖昧だった部分が一つでも明確になれば、次の発注からトラブルは確実に減ります。

そして、良い発注書を積み重ねることは、優秀なフリーランスに継続して受けてもらえる関係づくりの入口です。発注の質は、外部人材を活用して成果を出せるかどうかを左右します。発注書という1枚の書面を整えることから、信頼される発注者への第一歩を踏み出しましょう。