外注で失敗しない発注書の書き方。悪い例と良い例

開発を外注したあとに「思っていたものと違う」という行き違いが起きる原因の多くは、発注書の書き方にあります。目的・範囲・検収条件・変更時のルールという4つの項目を、具体的な行動や数値で書いているかどうかで、後からのトラブルの量が変わります。この記事では、行き違いが起きやすい書き方と、うまくいく書き方を対比表で示します。

発注書のどこで行き違いが起きるか

発注書に「業務を効率化したい」「使いやすくしてほしい」という表現しかない場合、何をもって完成とするかの基準が、依頼主と開発会社の間で別々に決まってしまいます。開発会社は自分の判断で機能や画面を決めて作り、納品時に「思っていたものと違う」という指摘を受けます。これは開発会社の技術不足ではなく、発注書の段階で基準をそろえていなかったことが原因です。

悪い例と良い例の対比

以下は、発注書に書く項目ごとの、避けたい書き方と推奨する書き方の一般的な例です。実際の企業名や事例ではなく、書き方の違いを示すための例文です。

項目	避けたい書き方	推奨する書き方
目的	業務を効率化したい	受注入力にかかる時間を、入力担当者の作業時間として計測できる状態にする
対象範囲	在庫管理システムを作ってほしい	在庫の入庫・出庫・棚卸の3機能を対象とし、発注機能は対象外とする
検収条件	使えるようになったら完了とする	指定した5つのテストケースがすべて通過した時点を検収完了とする
変更時のルール	特に決めていない	要件変更が発生した場合は都度見積を提示し、双方合意後に着手する
納期の表現	できるだけ早く	初回納品を〇月〇日、本番運用開始を〇月〇日とする

要件を書くときの粒度

「在庫管理システムを作ってほしい」という書き方では、在庫の何を管理するのか、どの業務を対象にするのかが開発会社に伝わりません。「入庫時にロケーションを登録し、出庫時に数量を減算し、月末に棚卸差異を一覧で出す」のように、業務の流れに沿って書くと、開発会社が見積もる範囲と依頼主が想定する範囲がそろいます。

検収条件の書き方

検収条件を「使えるようになったら完了」と書くと、何をもって「使える」と判断するかが曖昧になります。発注前に、検収のためのテストケースを依頼主側で用意し、「このテストケースが通過した時点で検収完了とする」と発注書に明記します。テストケースを先に用意することで、開発会社が目指すべき完成の基準が明確になります。

発注書を具体的に書くと、開発会社の見積も精度が上がる

発注書の記述が具体的になるほど、開発会社は要件を自分たちで仮置きする必要がなくなります。仮置きが減ると、見積の前提が依頼主の想定とそろいやすくなり、契約後に「それは別途費用です」という指摘を受ける場面も減ります。発注書を具体的に書く作業は、依頼主にとっての負担に見えますが、後から発生する確認作業や追加費用のやり取りを減らす効果があります。

検収テストケースの作り方

検収条件を具体的にするには、依頼主側でテストケースを用意します。テストケースには「誰が、何を入力し、どう表示されれば正しいか」を書きます。

入力条件: どの画面で、どの項目に、どの値を入れるか
操作: ボタンを押す、登録する、検索するなど、行う操作
期待する結果: 画面に表示される内容、保存されるデータの内容
異常時の確認: 必須項目が未入力のとき、不正な値を入れたときの挙動

このテストケースを5件から10件程度用意し、発注書に添付します。開発会社がテストケースに沿って動作確認を行い、すべて通過した時点を検収完了とすることで、「使えるようになった」という感覚的な判断を避けられます。

変更が出たときのルールを先に決める

開発中に「これも入れてほしい」という要望が出るのは自然なことです。問題は、そのときのルールを決めていないまま進めてしまうことです。変更が出た場合は都度見積を提示し、金額と納期への影響を確認したうえで、依頼主が合意してから着手するというルールを、発注書に先に書いておきます。

発注後に認識のズレを確認するタイミング

発注書を具体的に書いても、開発が進む中で認識のズレが見つかることがあります。ズレを早く見つけるために、開発の節目ごとに依頼主側で確認する機会を設けます。画面のレイアウトが固まった時点、主要な機能が動く状態になった時点、検収テストケースを実施する前の時点の3つの節目で、依頼主が実際の画面や動作を確認し、発注書に書いた内容と合っているかを確かめます。

節目を納品直前の1回だけにすると、ズレが見つかったときの修正範囲が大きくなり、納期にも影響します。節目を複数回に分けておくことで、ズレを小さい範囲で見つけ、修正の手間を抑えられます。

発注書と契約書の役割の違い

発注書と契約書は役割が異なります。契約書は委託の条件（金額、支払い時期、責任の範囲、知的財産権の扱いなど）を取り決めるもので、発注書は何を作るか、何をもって完了とするかを具体的に書くものです。契約書だけを交わして発注書を作らないまま開発を進めると、要件や検収条件の基準が文書として残らず、行き違いが起きたときに確認する手段がなくなります。

契約書の内容と発注書の内容が矛盾しないよう、発注書を作成した時点で、契約書に書かれている検収や支払いの条件と合っているかを確認します。小規模な開発では契約書と発注書を1つの文書にまとめることもありますが、その場合も目的・対象範囲・検収条件・変更時のルール・納期の5項目は必ず具体的に書きます。

発注書に入れておきたい項目チェックリスト

ここまでの内容を踏まえ、発注書に書くべき項目をチェックリストにまとめます。発注前にこのリストと照らし合わせ、抜けている項目がないかを確認します。抜けている項目があれば、発注書を提出する前に追記するか、開発会社に質問して回答を文書で残しておきます。

目的（何を測定可能な状態にするか）
対象範囲（含むものと含まないもの）
検収条件（テストケースまたは具体的な完了基準）
変更時のルール（都度見積、承認の経路）
納期（初回納品と本番運用開始を分けて書く）
データの扱い（既存データの移行をどちらが担当するか）

あわせて読みたい記事として、「開発の見積額に幅が出る理由。要件のどこで工数が膨らむか」と「Excel出荷指示を、WMSを入れずにWebアプリへ置き換える手順」も参考にしてください。

PT に相談するなら

発注書を書く前に業務の範囲を整理したい場合は、PT DISCOVERY（10万円〜、税込11万円〜）で課題整理から始められます。1テーマを絞って簡易実装まで確認し、発注書に書く範囲を具体化したい場合はPT WORKS（30万円〜、税込33万円〜）が入口になります。本開発そのものを依頼する場合はPT BUILDで個別見積になります。発注書の項目に沿って自社の条件を整理したい場合は、概算見積から確認してください。

料金は参加人数、テーマ数、事前調査の量、開発範囲で変わります。出張を伴う場合の交通費・宿泊費は実費です。