システム開発の発注書・注文書とは｜記載項目と作り方を発注者向けに解説

「システム開発を頼むことになったが、発注書には何を書けばいいのか分からない」——初めて発注を任された担当者にとって、書面まわりは意外とつまずきやすいポイントです。この記事では、発注書・注文書とは何か、なぜ必要なのか、そしてそのまま使える記載項目のテンプレまでを、発注者の目線でやさしく整理します。見積書・注文請書・契約書との関係や、電子発注の一般的な話も押さえておきましょう。

なお、下請法や税務・電子帳簿保存法にかかわる部分は制度が細かく、個別の判断は専門家の領域です。本記事は一般的な考え方の整理にとどめ、実際の対応は税理士・弁護士など専門家に確認する前提でお読みください。

発注書・注文書とは？まず言葉を整理する

発注書とは、「この内容・この条件で発注します」という発注者側の意思を示す書面です。注文書と呼ばれることもありますが、実務では両者はほぼ同じ意味で、様式名が違うだけと考えて差し支えありません。

システム開発では、口頭やメールのやり取りだけで作業が始まってしまうこともあります。しかし「何を・いくらで・いつまでに作るか」を書面にしておかないと、後から認識のズレが表面化し、トラブルの火種になります。発注書は、その合意を証拠として形に残す役割を担います。

書面	出す人	役割
見積書	受注者（開発会社）	いくらでできるかの提示
発注書・注文書	発注者（あなた）	この内容で発注しますという意思表示
注文請書	受注者（開発会社）	その内容で請けますという応諾
契約書	双方	権利・責任・検収などの詳細な取り決め

まず押さえたいのは、発注書は発注者が出す書面だということです。見積書を受け取ったら受け身で待つのではなく、発注者側から「この内容で正式にお願いします」と書面を出す——この一往復が、後の安心につながります。

「発注書」「注文書」「注文依頼書」など、会社によって様式の名前はさまざまですが、名称の違いを気にする必要はありません。大事なのは呼び方ではなく、範囲・金額・納期・検収条件といった中身が漏れなく書かれているかどうかです。相手の会社が独自の様式を持っている場合は、それを使わせてもらっても構いません。自社に決まった様式がなくても、この記事の目次テンプレをそのまま項目立てに使えば、過不足のない発注書を作れます。

なぜ発注書が必要なのか（3つの理由）

「小さな開発だから口頭で十分」と考えたくなる場面もありますが、発注書を交わす意味は主に3つあります。

• 言った・言わないを防ぐ：範囲や金額、納期を書面化しておけば、後から「その機能も込みだと思っていた」という食い違いを避けられます。システム開発は成果物が目に見えにくく、認識のズレが起きやすい取引です。
• 下請法などへの対応：取引条件によっては、発注者（親事業者）に発注内容を記した書面の交付義務が生じる場合があります。自社が該当するかは一般論では判断しきれないため、専門家への確認が必要です。
• 税務・経理上の証憑になる：発注書や注文請書は、取引の実在を示す証憑として経理・税務の場面で役立ちます。保存の要否や方法は制度に沿った対応が求められます。

とくにシステム開発で効いてくるのが1つ目です。形のあるモノの売買と違い、ソフトウェアは「どこまでが今回の範囲か」が曖昧になりがちです。発注書で範囲を言葉にしておくことが、そのままトラブル予防になります。

下請法にふれておくと、これは発注側の立場が強くなりやすい取引で、発注を受けた側が不利にならないよう、発注内容を書面（または電子データ）で明確に示すことを求める趣旨の制度です。自社と相手の資本金の関係や取引の種類によって適用の有無が変わるため、「うちは対象か」は一般論では言い切れません。ただ、対象かどうかにかかわらず、発注内容を書面で残しておくこと自体は双方にとってメリットがあります。適用の判断が必要な場合は、必ず専門家に確認してください。

税務・経理の面でも、発注書や注文請書は「その取引が実際に行われた」ことを裏づける資料になります。金額の大きいシステム開発では、後から経費として説明を求められる場面も想定されます。書面を残しておけば、いつ・誰に・何を・いくらで発注したかを客観的に示せます。保存の要否や年数は制度に沿った対応が必要なので、こちらも自己判断せず専門家に相談するのが安全です。

下請法・税務・電子帳簿保存法にかかわる判断は、必ず税理士・弁護士など専門家に確認してください。本記事の説明は一般的な整理です。

発注書に記載する項目（そのまま使える目次テンプレ）

では、システム開発の発注書には何を書けばよいのでしょうか。最低限おさえたい項目を、そのまま目次として使えるテンプレの形でまとめます。

記載項目	書く内容の例	なぜ必要か
発注内容・件名	「◯◯管理システム開発一式」	何の発注かを特定する
発注範囲（スコープ）	対象機能・画面・対応環境	「どこまでが今回か」を確定する
金額	税抜・税込・消費税額	総額の認識をそろえる
納期・納品方法	納品日・引き渡し方法	いつ・どう受け取るかを決める
支払条件	支払時期・回数・振込先	入金トラブルを防ぐ
検収条件	何をもって合格とするか	受け取り基準を明確にする
成果物の権利	ソースコードの権利の扱い	将来の改修先を縛られないため
発注日・双方の名義	会社名・担当者・押印等	取引の当事者と時点を示す

このなかで、システム開発でとくに軽視できないのが**「発注範囲」と「成果物の権利」**の2つです。

• 発注範囲：曖昧なまま進めると、追加機能の依頼が出るたびに「これは範囲内か・追加費用か」で揉めます。対象の機能・画面・想定する利用環境（スマートフォン対応の有無など）まで、できるだけ具体的に書きます。
• 成果物の権利：ソースコードの権利が発注者に渡らないと、将来ほかの会社に改修を頼めず、ベンダーロックインにつながることがあります。誰に権利が帰属するかは発注段階で明確にしておきましょう。

残りの項目についても、書くときのコツを補足しておきます。

• 金額：税抜・税込・消費税額を分けて書くと、後の請求時に食い違いません。分割で支払う場合は、各回の金額と時期も添えます。
• 納期・納品方法：日付だけでなく「どういう状態で・どうやって引き渡すか」まで書くと親切です。データでの納品か、サーバーへの設置まで含むのかを明確にします。
• 支払条件：入金トラブルを避けるため、支払いの時期（例：検収後◯日以内）と回数、振込先を記します。
• 検収条件：ここが抜けると「完成した／していない」で揉めます。「何をもって合格とするか」を、できれば数値や具体的な状態で書いておきます。

これらは、あとで紹介する目次テンプレの順に埋めていけば、初めてでも漏れなく作れます。難しく考えず、見積書の内容を土台に一項目ずつ写し取るイメージで進めれば十分です。

見積書・注文請書・契約書との関係と流れ

発注書は単独で存在するのではなく、一連の書面の流れの一部です。典型的な順番は次のようになります。

順番	書面・工程	誰が主体か
1	見積書の受領	開発会社が提示
2	発注書・注文書の発行	発注者が発行
3	注文請書の受領	開発会社が応諾
4	契約書の締結（必要に応じて）	双方
5	開発・納品	開発会社
6	検収・請求・支払	双方

見積もりの内容に納得したら、その見積書の内容を土台に発注書を作るのが基本です。見積書と発注書の金額・範囲がズレていないかは必ず突き合わせましょう。見積もりの読み方や確認ポイントは見積書の見方にまとめています。

この流れのなかで、発注者が主体的に動くのは主に「発注書の発行」です。ほかの書面は開発会社が用意してくれることが多いため、発注者としては「見積もりに納得したら発注書を出す」「注文請書を受け取る」「必要に応じて契約書を結ぶ」という3点を押さえておけば十分です。書面のやり取りは面倒に感じられますが、一つひとつが後のトラブルを防ぐ保険になります。とくに初めての取引や、金額の大きい開発ほど、この流れを省かずに踏むことをおすすめします。

発注書と注文請書のやり取りだけでも契約は成立し得ますが、システム開発では検収基準や成果物の権利など細かな取り決めが多いため、別途、契約書を交わすのが一般的です。契約書で見るべき条項はシステム開発の契約で確認すべきことで解説しています。発注そのものの全体像はシステム開発の発注の流れもあわせてどうぞ。

注文請書をもらう意味

発注書を出したら、開発会社から注文請書を受け取っておくことをおすすめします。発注書はあくまで発注者側の一方的な意思表示ですが、注文請書は受注者が「その内容で請けます」と応じた証拠になります。

• 発注書だけだと「発注者が出した」事実しか残らない
• 注文請書がそろって初めて、双方が同じ内容で合意したことが書面で確認できる
• 金額が小さい取引でも、省略せずもらっておくと後々の安心につながる

実務では、発注書と注文請書がセットで交わされて初めて「取引の合意が固まった」と扱われる場面が多くあります。開発会社から自動的に送られてこない場合は、発注者側から「注文請書もお願いします」と一声かけておくとよいでしょう。

発注書と注文請書の内容は、当然そろっている必要があります。発注書に書いた金額・範囲・納期と、返ってきた注文請書の内容が食い違っていないかは、受け取ったときに必ず確認してください。もし違いがあれば、それは相手の認識がこちらと違うサインです。書面が出そろった段階でズレを見つけられれば、開発が始まる前に直せます。逆に、中身を確認せずファイルするだけだと、せっかくの書面が意味を持ちません。

電子発注と電子帳簿保存法の一般論

近年は、紙ではなく電子データ（PDFなど）で発注書をやり取りする電子発注が広がっています。メールやクラウド上のサービスで発注書を送受信するケースです。ただし、電子でやり取りした取引書類の保存には、電子帳簿保存法という制度上のルールがかかわってきます。

• 電子でやり取りした発注書・注文請書は、一定の要件を満たして電子データのまま保存することが求められる場合がある
• 保存の要件（改ざん防止や検索性など）は制度で細かく定められている
• インボイス制度など、ほかの制度との兼ね合いもある

ここは制度の詳細が頻繁に見直される領域であり、自社がどう対応すべきかは一般論では判断できません。電子発注を本格導入する際は、必ず税理士など専門家に確認し、自社の会計・保存の運用に合わせて設計してください。本記事では「電子でやり取りする場合は保存ルールがある」という点だけ押さえておけば十分です。

電子発注には、紙の郵送や押印の手間が減る、書類を探しやすい、送付の記録が残るといった利点があります。一方で、「メールで送っただけの発注書を、そのまま印刷して紙で保存すればよい」とは限らない点に注意が必要です。電子でやり取りしたものは電子のまま、一定のルールで残すことが求められる場合があるためです。小規模な取引でも、いったん運用のルールを決めてしまえば負担は大きくありません。導入の初期に、自社の経理担当や顧問の専門家と「どのフォルダに・どんな名前で・何年残すか」を決めておくとよいでしょう。

中小企業がつまずきやすいポイント

初めての発注で、中小企業の担当者がとくにつまずきやすいのは次の2点です。

• 発注範囲があいまい：「◯◯システム一式」とだけ書いて、対象機能や対応環境を書かないケース。これだと開発が進んでから「この画面も入っていると思った」という食い違いが起きます。
• 口頭やメールだけで発注してしまう：忙しさや相手との距離の近さから、書面を省いて作業を始めてしまうケース。トラブルが起きたときに、合意内容を示すものが何も残りません。

このほか、次のような点も見落とされがちです。

• 検収の合格基準を決めていない（何をもって「完成」とするかが曖昧）
• 成果物の権利の扱いを書いていない
• 追加費用が発生する条件を握っていない

これらはすべて、「範囲と条件を先に言葉にしておく」ことで防げます。とくに発注範囲の曖昧さは、システム開発でもっとも揉めやすい部分です。当社のように一律料金（スタンダード100万円／プロ200万円）で追加費用なし・着手前に総額が確定する仕組みなら、「どこまでが範囲か」を発注段階で明確にするため、進行中に金額で揉めることを避けやすくなります。総額が先に固定されていれば、発注書の金額欄で悩む必要もありません。

ミニ事例で見てみましょう。 例：ある小売業の担当者が「在庫管理システム開発一式」とだけ書いた発注書で発注しようとしていたとします。ここで開発会社と読み合わせをしたところ、「スマートフォンからの入力に対応するか」「既存のExcelデータを移行するか」が発注書に書かれていないことに気づきました。

そこで、発注範囲の欄に「対象：入出庫の登録・在庫一覧・棚卸し機能／スマートフォン対応あり／既存Excelからのデータ移行を含む」と具体的に書き足し、検収条件として「実際の在庫データを入れて1週間、業務を止めずに運用できること」を追記しました。結果として、開発中に「これは範囲内か」で立ち止まることがなくなり、検収もスムーズに進みました。発注書に一行加えるだけで、後の手戻りを大きく減らせた例です。

発注書を交わす前のチェックリスト

最後に、発注書を出す前に確認したい項目を一覧にまとめます。印刷して読み合わせに使ってください。

• 発注内容・件名が、何の開発かを特定できるか
• 発注範囲（機能・画面・対応環境・データ移行の有無）が具体的か
• 金額（税抜・税込・消費税額）が見積書と一致しているか
• 納期と納品方法が書かれているか
• 支払条件（時期・回数・振込先）が明確か
• 検収条件（何をもって合格とするか）が決まっているか
• 成果物（ソースコード）の権利の扱いが書かれているか
• 追加費用が発生する条件を、事前に握れているか
• 開発会社から注文請書を受け取る段取りになっているか

検収の考え方や進め方は検収とはで詳しく解説しています。あわせて確認しておくと、受け取りの基準づくりで迷いません。

まとめ

システム開発の発注書・注文書は、「何を・いくらで・いつまでに・どこまで作るか」を書面で残し、言った・言わないのトラブルを防ぐための大切な書類です。とくに発注範囲と成果物の権利、そして検収条件は、システム開発でつまずきやすいポイントなので、発注段階で言葉にしておきましょう。発注書を出したら注文請書をもらい、必要に応じて契約書も交わすのが基本の流れです。下請法・税務・電子帳簿保存法にかかわる部分は、必ず専門家に確認してください。「範囲や金額の確定に不安がある」「総額を先に固めて安心して発注したい」という方は、まずお気軽に無料相談へどうぞ。