発注書がないと開発がブレる理由｜最小限の仕様書テンプレで手戻りを防ぐ

「お願いしたものと、上がってきたものが違う」。外部のフリーランスや業務委託エンジニアに開発を頼んだとき、こんな経験はないでしょうか。チャットや打ち合わせで丁寧に伝えたつもりなのに、完成品を見ると想定とズレている。修正を依頼すると「それは最初の依頼に含まれていません」と言われ、追加費用が発生する。気づけば当初の見積もりを大きく超え、納期も後ろにずれていた——。

非エンジニアの発注者にとって、これは決して珍しい話ではありません。やっかいなのは、原因が「自分の伝え方が下手だったから」のように感じてしまい、次の発注でも同じ不安を抱えたまま進めてしまうことです。とはいえ、自分は詳細な仕様を書けるほどの技術知識があるわけではないし、毎回かっちりした要件定義書を作る時間の余裕もありません。

実は、こうした「開発のブレ」の多くは、伝え方のうまさの問題ではありません。「発注書」と「最小限の仕様書」という2つの書面が欠けているために、合意が記録として残らず、解釈の余地が生まれてしまうことが本当の原因です。逆にいえば、この2つを最小限だけ整えるだけで、手戻りと追加費用は大きく減らせます。

しかも2024年11月に施行されたフリーランス新法により、フリーランスへの発注では取引条件を書面で明示することが法律上の義務になりました。発注書を整えることは、もはや「やったほうがいい」ではなく「やらなければならない」ことになっています。

本記事では、発注書と仕様書がそれぞれ何を防ぐのか、法的に最低限どこまで必要なのか、そして非エンジニアの発注者でも次の発注ですぐ使える「最小限の仕様書テンプレート」を、具体的にお伝えします。読み終えたときには、「この項目さえ押さえればブレない」という現実的な基準を手にしているはずです。

「発注書がないと開発がブレる」のはなぜか

システム開発の発注でブレが起きるとき、多くの発注者は「もっと細かく説明すればよかった」と感じます。しかし問題の本質は、説明の細かさではなく、合意が記録に残っていないことにあります。まずは、なぜブレるのかを構造で理解しておきましょう。

外部発注でズレが起きる典型シナリオ

ズレが起きるとき、現場ではたいてい次のような流れをたどっています。

発注者は「こういう業務を楽にしたい」という要望を、チャットや打ち合わせで伝えます。ここで伝えているのは多くの場合「要望」、つまり「何のために・どうなってほしいか」というゴールのイメージです。一方、エンジニアが実際に手を動かすには「要件」、つまり「どんな機能を・どう動かすか」という具体的な仕様が必要になります。

この「要望」と「要件」が混ざったまま依頼が進むと、要件として確定していない部分をエンジニア側が自分の解釈で埋めることになります。悪気があるわけではなく、手を動かすためには何かしら判断するしかないからです。その解釈が発注者のイメージと一致していればよいのですが、書面で擦り合わせていない以上、ズレる確率は高くなります。実際に「外注した側の要望と、受注側が読み取った要件が食い違う」ことが、トラブルの典型的な入口になります。

「言った／言わない」が生む手戻りと追加費用の連鎖

完成品を見て「これは思っていたのと違う」と気づいたとき、発注者は修正を依頼します。ところがここで「言った／言わない」の問題が起きます。

発注者は「そう伝えたはず」と思っていても、口頭やチャットの断片的なやり取りの中に埋もれていれば、明確な合意とは見なされません。受注側からすれば「依頼書や仕様書に書かれていなかった追加機能」となり、当然ながら追加の作業として費用が発生します。

そして一度この食い違いが起きると、連鎖的に悪化していきます。修正のために作り直しが発生し、納期が後ろにずれ、その分のコストが積み上がる。仕様変更によって追加費用が発生する構造そのものについては、仕様変更で追加費用が発生する構造と予防でも詳しく整理しています。本記事では、その手前にある「発注時の書面整備」に焦点を当てます。

ブレの正体は「合意の不在」ではなく「合意の未記録」

ここで押さえておきたいのは、ブレの原因は「発注者と受注者が合意していなかったこと」ではない、という点です。多くの場合、口頭やチャットでは一定の合意があったはずなのです。問題は、その合意が記録として残っていないこと、つまり「合意の未記録」にあります。

記録がないと、後から「どこまでが依頼範囲だったか」を確認するすべがありません。だからこそ、解釈の余地が生まれ、追加費用や手戻りをめぐる対立につながります。

つまり、ブレを防ぐ鍵は「もっと上手に伝えること」ではなく「合意を書面に残すこと」です。そして、その書面の役割を担うのが「発注書」と「仕様書」です。この2つは似ているようで役割がまったく違うため、次の章で整理していきます。

発注書と仕様書は役割が違う（混同するとブレる）

「発注書を作ればいいのか、仕様書を作ればいいのか、結局どっちなの？」——これは多くの発注者がつまずくポイントです。結論からいえば、両方が必要で、それぞれ防げるブレが異なります。混同すると、片方しか整えていないつもりで肝心の部分が抜け落ちてしまいます。

発注書がカバーする範囲（取引条件・金額・納期）

発注書は、ひとことでいえば「誰に・何を・いくらで・いつまでに頼むか」という取引条件を記録する書面です。注文書と呼ばれることもありますが、実務上はほぼ同じものを指します。

発注書がカバーするのは、業務の件名、報酬の金額、納期（完了予定日）、支払期日、発注者と受注者の名称といった取引の枠組みです。これらは「いくら払うのか」「いつまでに納品されるのか」という、お金と時間に直結する条件です。ここが曖昧だと、報酬や支払いタイミングをめぐるトラブルに発展します。

一方で、発注書は「何を作るか」の中身までは細かく書きません。「会員管理機能の開発 一式」とだけ書かれていても、それが具体的にどんな機能なのかは発注書だけでは分からないのです。

仕様書がカバーする範囲（成果物の中身・受け入れ基準）

仕様書は、発注書が扱わない「何を・どう作るか」という成果物の中身を記録する書面です。どんな機能が必要か、どんな画面やデータを扱うか、そして「何をもって完成とするか」という受け入れの基準を明文化します。

開発の現場では、この仕様書の理解が発注側・受注側双方にとって重要だと指摘されています。仕様書があることで、受注側は解釈で埋める部分が減り、発注側は「これが完成形だ」と合意した状態を持てます。

逆に仕様書がないと、たとえ発注書で金額と納期が決まっていても、肝心の「中身」がブレます。「会員管理機能 一式」が、発注者の頭の中では検索機能つきだったのに、受注者は一覧表示だけと解釈していた、というズレはここで生まれます。なお、仕様書とよく混同される要件定義書との違いについては、仕様書と要件定義書の違いで整理しています。

発注書と仕様書の役割分担早見表

2つの書面の違いを整理すると、次のようになります。

ここで大切なのは、「両方が必要だが、それぞれ最小限でよい」という点です。発注書には法律で定められた項目を、仕様書にはブレを防ぐ最小限の項目を入れれば十分です。完璧な書類を作る必要はありません。

まず、発注書の側で「最低限これだけは必要」とされる項目を、法律の観点から確認しておきましょう。

フリーランス・業務委託への発注書は「フリーランス新法」で必須に

発注書を整えるべき理由は、ブレ防止だけではありません。フリーランスや個人の業務委託エンジニアに発注する場合、取引条件を書面で示すことは法律上の義務になっています。これは「やったほうがいい」ではなく「やらなければならない」決定的な理由です。

フリーランス新法で発注者に課される取引条件の明示義務

2024年11月1日に「フリーランス・事業者間取引適正化等法」（通称フリーランス新法）が施行されました（政府広報オンライン）。この法律は、フリーランスが安心して働ける環境を整えることを目的とし、発注事業者にいくつかの義務を課しています。

その中でも発注者がまず押さえるべきなのが、取引条件の明示義務です。フリーランスに業務委託をした場合、発注者は直ちに、書面または電磁的方法（メールやメッセージ等）で取引条件を明示しなければなりません（政府広報オンライン）。つまり、口頭だけで依頼を済ませることは法律上認められないということです。

ここで重要なのは、この義務が「ブレ防止のために発注書を作りましょう」という推奨ではなく、法的な義務だという点です。発注書を整えることは、実務上のリスク管理であると同時に、法令を守るための対応でもあります。

発注書に最低限書くべき法定の明示事項

フリーランス新法で明示が求められる主な事項は、次のとおりです（政府広報オンライン）。

• 発注事業者・フリーランスそれぞれの名称
• 業務委託をした日
• 業務の内容
• 報酬の額
• 支払期日
• 給付（成果物）を受け取る日・場所
• （検査を行う場合）検査を完了する日
• （金銭以外で支払う場合）その方法に関する事項

さらに、報酬の支払期日についてもルールがあります。発注した成果物を受け取った日から数えて60日以内の、できる限り早い日に支払期日を設定し、その期日内に支払う必要があります（政府広報オンライン）。

これらの項目を見ると、先ほどの章で整理した「発注書がカバーする範囲」とほぼ重なっていることが分かります。つまり、法律が求める明示事項を満たす発注書を作れば、それがそのまま取引条件のブレ防止にもなる、というわけです。

明示方法は発注書・メールでも可（契約書である必要はない）

「義務」と聞くと、立派な契約書を作らなければならないと身構えてしまうかもしれません。しかし、明示の方法は契約書に限られません。書面のほか、メールやメッセージといった電磁的方法でも認められています（政府広報オンライン）。

つまり、必須事項さえ漏れなく記録すれば、発注書という形でも、メールに条件を箇条書きで明示する形でも、法律上の明示義務を満たせます。大切なのは形式の立派さではなく、必要な項目が後から確認できる形で残っていることです。

このように、発注書の側は「法定の明示事項を満たすこと」が最低ラインの基準になります。次は、もう一方の柱である「ブレを防ぐ最小限の仕様書」を、非エンジニアでもすぐ埋められるテンプレートとして見ていきましょう。

ブレを防ぐ「最小限の仕様書」テンプレート

ここからが本題です。「自分は細かい仕様を書けない」という発注者でも、次の発注ですぐ埋められる「1枚仕様書」のテンプレートをお伝えします。完璧な仕様書を目指す必要はありません。むしろ、最小限の項目を埋めるだけで手戻りは大きく減ります。

最小限の仕様書に必要な6項目

最小限の仕様書は、次の6項目で構成します。それぞれに「なぜブレ防止になるか」を添えました。

すべてをびっしり埋める必要はありません。箇条書きや手書きのラフで十分です。重要なのは、この6つの観点が抜け落ちないことです。

「やらないこと（スコープ外）」を書くだけで手戻りが減る理由

6項目の中でも、特に効果が大きいのが②の「やらないこと（スコープ外）」の明記です。多くの仕様書は「やること」だけを書きますが、ブレの多くは「書かれていなかったこと」をめぐって起きます。

たとえば「会員管理機能を作る」とだけ書くと、検索機能やCSV出力、権限管理などが含まれるのかどうかが曖昧なまま残ります。発注者は当然含まれると思い、受注者は別途依頼だと考える。この食い違いが手戻りと追加費用の温床です。

ここで「今回は検索機能とCSV出力は対象外とする」と一文書いておくだけで、認識の境界がはっきりします。やらないことを明記することは、受注者を縛るためではなく、お互いが「ここまでが今回の範囲」と安心して進めるための線引きです。これだけで、後の「言った／言わない」のかなりの部分を未然に防げます。

受け入れ基準（完成の定義）を決めておく効果

もう一つ効果が大きいのが、④の「受け入れ基準（完成の定義）」です。これは「何ができていれば、この発注は完了と見なすか」を、あらかじめ言葉にしておくものです。

受け入れ基準がないと、納品の段階で「まだここが足りない」「いや、これで依頼どおりだ」という対立が起きがちです。基準を先に決めておけば、受注者はそこを目指して作れますし、発注者も検収のときに迷いません。

たとえば「会員が自分の情報を登録・編集・削除でき、管理者が一覧で確認できること」のように、動作レベルで書けると理想的です。技術的に詳しく書く必要はなく、「利用者が何をできれば完成か」を発注者の言葉で書けば十分です。

記入例（簡単な業務システム発注を想定）

イメージをつかみやすいよう、小さな顧客管理システムを発注する場合の記入例を示します。

■ 1枚仕様書（記入例）

①目的・背景
　紙とExcelで管理している顧客情報を一元化し、
　担当者が外出先からも検索・確認できるようにしたい。

②機能一覧
　[やること]
　・顧客情報の登録／編集／削除
　・顧客名・電話番号での検索
　・スマートフォンからの閲覧
　[やらないこと（今回はスコープ外）]
　・他システムとのデータ連携
　・帳票（PDF）の出力
　・複数拠点の権限分け

③画面・データの簡易イメージ
　・一覧画面：顧客名／電話番号／担当者を表示
　・詳細画面：上記＋住所／メモ
　（手書きのラフを別紙添付）

④受け入れ基準（完成の定義）
　・担当者が顧客を登録・編集・削除できる
　・顧客名／電話番号で検索し、該当顧客を表示できる
　・スマートフォンのブラウザで上記が操作できる

⑤前提・制約
　・利用環境：社内10名、スマホ・PC併用
　・希望納期：2026年8月末
　・既存Excelデータの移行は初期登録分のみ

⑥変更時の扱い
　・仕様変更が必要になった場合は、着手前にチャットで相談し、
　　費用・納期への影響を確認してから合意する

このように、技術的な詳細を書き込まなくても、発注者の言葉で「何を・どこまで・どうなれば完成か」を整理するだけで、ブレを防ぐ仕様書になります。もしこれより踏み込んだ要件をまとめたい場合は、要件定義書の書き方とテンプレートもあわせて参考にしてください。

発注書・仕様書をセットで運用するときの注意点

発注書と仕様書を作っても、作って終わりにしてしまうと、せっかくの書面が形だけになり、再びブレが起きます。2つの書面を「運用」するための注意点を押さえておきましょう。

発注書と仕様書を相互参照でひもづける

発注書と仕様書は別々の書面ですが、内容はつながっています。発注書には「業務の内容」を簡潔に書きますが、その詳細は仕様書に記載することになります。そこで、発注書の業務内容欄に「詳細は別紙仕様書のとおり」と書き、仕様書の側にも対応する発注の件名を記しておくと、2つの書面が1つの合意として結びつきます。

こうしておくと、後から「この発注で合意した内容は何だったか」をたどるときに、発注書から仕様書へ、仕様書から発注書へとすぐに参照できます。書面がバラバラに存在するより、相互参照させておくほうが、合意の記録として強くなります。

仕様変更が出たら書面を更新して合意を記録する

開発を進める中で、仕様変更が出ることは珍しくありません。ここで大切なのは、変更が出たときに「口頭やチャットで済ませず、必ず書面（メールでも可）で更新して合意を残す」ことです。

最初にきちんと仕様書を作っても、その後の変更を記録しなければ、結局「言った／言わない」が再発します。変更が出たら、何をどう変えるのか、費用や納期にどう影響するのかを書き、双方が合意した記録を残しましょう。最小限の仕様書テンプレートの⑥に「変更時の扱い」を入れておいたのは、このためです。

書面で埋まらない部分はキックオフで擦り合わせる

書面はブレを防ぐ強力な道具ですが、すべてを文字で表現できるわけではありません。とくに非エンジニアの発注者が書く最小限の仕様書では、ニュアンスや優先順位までは伝わりきらないことがあります。

そこで、発注の最初にキックオフの打ち合わせを設け、書面に書ききれなかった意図や、曖昧に感じる箇所を口頭で擦り合わせておくと安心です。書面で大枠を固め、対話で細部を補う。この組み合わせが、ブレない発注の現実的なやり方です。

なお、発注を「準委任」と「請負」のどちらの契約形態にするかによって、仕様書の位置づけや成果物の責任範囲は変わってきます。契約形態の選び方そのものは奥が深いテーマのため本記事では詳しく扱いませんが、いずれの形態でも「発注書で取引条件を、仕様書で成果物の中身を記録する」という基本は変わりません。まずはこの2つを整えることから始めるとよいでしょう。

よくある質問（FAQ）

最後に、実際の発注を前にして発注者が抱きやすい疑問に、Q&A形式で答えます。

発注書と注文書は違うものですか？

実務上は、ほぼ同じものと考えて差し支えありません。「発注書」「注文書」はいずれも「誰に・何を・いくらで・いつまでに頼むか」という取引条件を発注者側から示す書面です。会社や取引先によって呼び方が異なるだけで、果たす役割は同じです。受注者がそれを承諾する書面を「注文請書（発注請書）」と呼ぶことがあります。

発注書は仕様書とまとめて1枚にしてもいいですか？

物理的に1枚にすることは可能ですが、おすすめは「発注書」と「仕様書」を分け、発注書から「詳細は別紙仕様書のとおり」と参照する形です。理由は、両者の役割が違うからです。取引条件（金額・納期）と成果物の中身（機能・受け入れ基準）を1枚に混在させると、どちらかが手薄になりがちで、ブレの原因になります。役割ごとに分けておくほうが、変更時の更新もしやすくなります。

小さな依頼でも発注書は必要ですか？

フリーランスや個人事業主に業務委託をする場合、依頼の大小にかかわらず、フリーランス新法によって取引条件の明示が求められます（政府広報オンライン）。小さな依頼だからと口頭だけで済ませるのは避け、最低限の取引条件はメールなどで明示しておきましょう。明示は契約書である必要はなく、メールでの箇条書きでも認められます。

仕様書はどこまで細かく書けばいいですか？

非エンジニアの発注者であれば、本記事で示した6項目（目的・機能一覧・画面イメージ・受け入れ基準・前提制約・変更時の扱い）を、自分の言葉で埋める粒度で十分です。技術的な実装の詳細まで書く必要はありません。むしろ「やらないこと（スコープ外）」と「受け入れ基準（完成の定義）」を明記することのほうが、手戻り防止には効果的です。より踏み込んだ要件をまとめたい場合は、要件定義書の作成を検討するとよいでしょう。

仕様変更が起きたら発注書も作り直しですか？

必ずしも一から作り直す必要はありません。変更によって報酬額や納期といった取引条件が変わる場合は、その点を書面（メール可）で改めて明示し、双方の合意を記録します。仕様の中身が変わる場合は、仕様書の該当箇所を更新します。重要なのは「変更内容と、それによる費用・納期への影響を、記録として残す」ことです。これを徹底すれば、変更があっても「言った／言わない」のトラブルは防げます。

まとめ — 最小限の書面で「ブレない発注」を仕組みにする

外部のフリーランスや業務委託エンジニアへの発注でブレが起きるのは、伝え方が下手だからではありません。合意が書面として記録されておらず、解釈の余地が残ってしまうことが本当の原因です。

これを防ぐ柱が2つあります。1つは「発注書」。誰に・何を・いくらで・いつまでに頼むかという取引条件を記録し、フリーランス新法で義務化された明示事項にも対応します。もう1つは「最小限の仕様書」。何を・どう作るか、そして何をもって完成とするかを記録し、成果物のブレを防ぎます。

大切なのは、完璧な書類を作ることではありません。発注書には法律が求める項目を、仕様書には本記事で示した6項目を、自分の言葉で埋める。たったこれだけの「最小限」を毎回整える仕組みを持つことが、手戻り・追加費用・法令違反リスクを同時に下げる、もっとも現実的な近道です。

次の発注では、ぜひ「発注書＋1枚仕様書」を試してみてください。一度テンプレートを作ってしまえば、二回目以降は埋めるだけです。最小限の書面を整えるだけで、これまで悩まされてきた「思っていたものと違う」というズレは、確実に減らせるはずです。

Sources:

• フリーランスが安心して働ける環境づくりのための法律、2024年11月からスタート！（政府広報オンライン）