「仕様書なしでシステム開発を発注したい」と検索されたあなたは、おそらくこんな状況ではないでしょうか。新規事業や業務改善が急がれていて、開発会社からは「仕様書を作りましょう」と提案されたものの、「そんな時間はない」「打ち合わせと資料で十分伝わるはず」と感じている——。
このお気持ちは多くの発注者が抱くものです。仕様書という言葉には「大量のドキュメントを何週間もかけて書く」というイメージがつきまといます。事業のスピードを優先したい立場からすれば、できれば省きたいと考えるのは自然です。
ただ、「仕様書を省く判断」は、結果として何倍もの時間とコストを発注者に押し付けてしまいます。経済産業省の取引トラブル事例集でも、口頭合意の曖昧さがプロジェクト失敗の主因として繰り返し指摘されてきました（情報システム・ソフトウェア取引トラブル事例集）。
本記事では、仕様書なしで発注した場合に発生する典型的なトラブル5つ、契約・法的リスクへの発展シナリオ、そして「時間がない」発注者でも1〜2時間で作れる「1枚仕様書」のフォーマットまでを順に解説します。「仕様書を作る時間を惜しんで、その何倍もの時間を後始末に使う」という最悪のパターンを避ける、現実的な打ち手をお持ち帰りください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
仕様書なしで発注したくなる発注者の心理
まずは、仕様書を省きたいと考える発注者の心理を整理しておきます。「省きたい気持ち」を否定するのではなく、なぜそう感じるのかを言語化することで、その先の意思決定がしやすくなります。
「打ち合わせと資料で伝わるはず」という思い込み
最大の思い込みは、「これだけ詳しく打ち合わせをすれば仕様書を作らなくても伝わるだろう」というものです。確かに対面の打ち合わせでは、その場では「全員が同じ理解をしている」と感じやすいものです。
ところが、打ち合わせから1週間も経つと、発注者と開発者の頭の中のイメージは少しずつズレていきます。「あの画面の上部にこのボタンを置く」という話が、発注者の中では「右上」、開発者の中では「左上」になっている。「進めながら詰めればいい」と言った詳細部分が、開発者側では「発注者から後で具体的な指示が来るだろう」と棚上げされたまま放置される。こうしたズレは、コードが書かれ始めてから初めて表面化します。
口頭の合意は人の記憶に依存します。記憶は時間が経つほど自分に都合よく書き換わるため、発注者は「最初からそう言っていたはずだ」と思い、開発者は「そんな話は聞いていない」と返します。議事録もない状態では、どちらの言い分が正しいかを後から検証する手段がありません。
仕様書作成に「時間とコストがかかる」という誤解
もうひとつの典型的な誤解は、「仕様書を作ると何週間も時間がかかるし、お金もかかる」というものです。確かに、大規模なエンタープライズシステム開発では要件定義書・基本設計書・詳細設計書と段階を踏み、合計で数か月分のドキュメント工数を投じるのが一般的です。
しかし、中小規模のプロジェクトではそれほど厚い仕様書は不要です。後述のとおり「目的・主要機能・やらないこと」を整理した1枚の文書を1〜2時間でまとめるだけでも、発注後のトラブルの大半は予防できます。「仕様書 = 数百ページの分厚いドキュメント」という思い込みが、最も軽量で効果の高い打ち手まで遠ざけているのです。
仕様書の概念や発注者が押さえるべき確認ポイントはシステム開発の仕様書とは？発注者が押さえるべき確認ポイントで体系的に整理しています。
仕様書なしを選ぶ前に知っておくべきこと
省くという判断をする前に、次の事実だけは押さえておいてください。仕様書なしで発注した結果、認識齟齬・追加費用・納期遅延・関係悪化・法的紛争が連鎖的に発生するケースが多数報告されています。仕様書作成にかかる時間が「数時間〜数日」であるのに対し、トラブル発生後の手戻りには「数週間〜数か月」を要するのが通例です。時間を節約するつもりが、結果として何倍もの時間を消費してしまうわけです。
仕様書なし発注で起きる典型的なトラブル5つ
ここからは、仕様書なしで発注した場合に発生しやすいトラブルを5つに整理します。それぞれ「症状」「発生メカニズム」「被害規模」をセットで解説します。
認識齟齬で開発が止まる
最も頻発するのが、発注者と開発者の間で「機能の解釈」がズレるパターンです。
たとえば「会員登録機能を作ってほしい」という指示ひとつでも、発注者は「メール認証ありの会員登録」を想定し、開発者は「認証なしのシンプルな会員登録」を想定する、というすれ違いが起きます。発注者の中では「会員登録に認証があるのは当たり前」、開発者の中では「指示に書かれていないものは作らない」というのが、双方とも自然な前提だからです。
書面で「メール認証あり」と一行書いてあれば防げたはずのズレが、口頭ベースで進めるとほぼ確実に発生します。コードが書かれ始めてからこの食い違いに気づくと、既に作ったロジックを大きく書き直す必要があり、1〜2週間の手戻りは珍しくありません。
仕様変更が頻発し、見積もりが2〜3倍に膨らむ
仕様書がない状態で見積もりを取ると、開発会社は「想定される範囲」で金額を出すしかありません。発注者の頭の中にある要件が後から追加で出てくるたびに「これは追加作業です」という扱いになり、追加見積もりが積み上がっていきます。
問題は、追加見積もりの妥当性を発注者が判断する材料がないことです。「あれは含まれているはず」と思っていた機能が「含まれていない」と言われたとき、契約書にも仕様書にも書かれていなければ立証する手段がありません。結果として当初の見積もりの2〜3倍まで膨らむケースは珍しくなく、予算オーバーのために事業計画そのものを見直さざるを得なくなることもあります。
追加費用の発生原因と発注者として取れる回避策はシステム開発で追加費用が発生する原因と回避策で詳しく解説しています。
納品物が「期待と違う」ものになる
3つ目は、納品時に「思っていたものと違う」となるケースです。
たとえば、発注者が「使いやすい管理画面」を期待していたのに、納品されたのは機能は満たすものの操作が分かりにくいUIだった、というパターン。発注者の頭の中の「使いやすさ」は明文化されないまま開発が進み、開発者は機能要件だけを満たしたものを納品します。
「使いやすさ」「見やすさ」「分かりやすさ」のような感覚的な要件こそ、最低限の仕様書で「具体的にどう実現するか」を言語化しておく必要があります。これを省略すると、納品物への不満が爆発し、再制作の交渉に長い時間を費やすことになります。
テストが不十分でリリース後に不具合が頻発する
4つ目はテスト工程の問題です。仕様書がないと、開発者は「何をもって完成とするか」の基準を持たないままテストを行うことになります。
テストとは本来「この機能はこう動くべき」という期待動作と実装結果を突き合わせる作業です。期待動作が文書化されていないと、開発者は自分の頭の中の期待動作に照らしてテストするしかなく、発注者が想定していたケース、特に例外系・エラー系が漏れてしまいます。
結果として、リリース後に「特定の操作をするとエラーが出る」「特定の組み合わせでデータが壊れる」といった不具合が次々に発覚し、発注者は対応に追われます。リリース直後のクレーム対応・緊急修正・ユーザー離反といった二次被害は、最初の開発費用を大きく上回ることもあります。
開発会社との関係が悪化し、途中で頓挫する
最後のトラブルは人間関係の悪化です。
仕様書なしで進めると、追加費用・納期遅延・品質不満の3つが同時に起きやすく、発注者は「想定より高くつき、遅れ、品質も悪い」と感じます。一方の開発会社は「指示が曖昧で何度も作り直しさせられている」と感じます。双方が相手を「無理を言ってくる側」と認識し、コミュニケーションが事務的・敵対的になっていきます。
最悪のケースでは関係修復が不可能になり、プロジェクトが途中で頓挫します。発注者は支払った費用の一部しか成果物を得られず、開発会社は損失を出し、両者ともに新しいパートナーを探し直すことになります。仕様書という「共通の参照点」がないことが、双方が「自分は正しい」と主張し続ける構造を作ってしまうわけです。
契約・法的リスクと「言った・言わない」問題
トラブルの中でも特に深刻なのが、契約・法的な紛争に発展するケースです。仕様書なし発注は、お金と時間の損失だけでなく、訴訟という極めて重いコストにつながる可能性があります。
契約書と仕様書の関係（「別紙仕様書に準ずる」の落とし穴）
システム開発の契約書には、「開発範囲は別紙仕様書に準ずる」という条項が含まれていることがよくあります。契約書本体には開発対象を細かく書かず、別紙として添付される仕様書で範囲を定義するという意味です。
ところが現場では、「別紙仕様書」が存在しないまま契約書だけが交わされるケースが少なくありません。発注者は「あとで仕様書を作ればいい」と考え、開発会社も「打ち合わせを進めながら作りましょう」と引き受けてしまう。そして、トラブルが発生してから契約書を見直したとき、「別紙仕様書に準ずる」と書かれているのに別紙仕様書が存在しない、という状態が発覚するのです。
この場合、何が「契約の対象」だったかを客観的に証明する手段がなくなります。発注者は「契約に含まれているはずだ」と主張し、開発会社は「契約書に書かれていない、追加作業だ」と反論する。互いに証拠を持ち寄れないため、話し合いでの解決が極めて難しくなります。
検収・追加費用・損害賠償に発展する典型パターン
仕様書がない状態でトラブルが進行すると、次のような典型的なパターンで法的紛争に発展します。
第一に、検収を巡る争いです。発注者が「期待と違う」として検収を拒否し、開発会社が「契約上の義務は果たした」として代金支払いを請求します。仕様書がなければ「期待」と「義務」のどちらが正しいかを判定できず、双方が法的手段に訴える流れになります。
第二に、追加費用の請求を巡る争いです。開発会社が「指示にない作業を多数行ったので追加料金を払ってほしい」と請求し、発注者が「最初から含まれているはずだ」として支払いを拒否するケース。仕様書がないと、何が「最初から含まれていたか」を客観的に示せません。
第三に、損害賠償請求への発展です。プロジェクトが頓挫した場合、発注者は「未完成のシステムへの支払い損害」を主張し、開発会社は「協力義務違反による損害」を主張することがあります。実際の裁判例では、発注者側の協力義務違反（仕様提示が遅れた、決定を引き延ばしたなど）が認定され、発注者に多額の賠償が命じられたケースも報告されています（システム開発訴訟の事例と原因 発注側ができる対策）。
訴訟になった場合の負担
仕様書省略による紛争が裁判にまで発展した場合、発注者には次のような負担がのしかかります。
時間面では、訴訟の解決まで一般的に1年以上、長いケースでは数年単位の時間がかかるとされており、本来取り組むべき事業活動の時間が大きく削られます。費用面では、弁護士費用・鑑定費用・裁判費用などで、争点の規模によっては数百万円規模の支出が発生し得ます。関係性の面では、訴訟になった開発会社とは継続取引が不可能になり、新しい開発会社を探すコストもかかります。
これらの負担は、仕様書を1枚作っておけば多くのケースで予防できたものです。
最低限作るべき「1枚仕様書」のつくり方
ここまでで、仕様書なし発注のリスクが具体的にイメージできたかと思います。とはいえ、「やっぱり分厚い仕様書を時間をかけて作るしかないのか」と感じている方もいらっしゃるかもしれません。
ご安心ください。中小規模のプロジェクトであれば、A4で1〜2枚程度の「1枚仕様書」を1〜2時間でまとめるだけで、本記事で挙げたトラブルの大半は予防できます。フル仕様書 vs 1枚仕様書という二択ではなく、「最低限これだけは書く」という現実的な落としどころを取りに行きましょう。
1枚仕様書に書くべき6項目
1枚仕様書には、以下の6項目を盛り込むことを推奨します。
- 目的・成果定義: このシステムを作ることで何を実現したいか。1〜2文で言語化。例:「店舗の在庫を本部から一元管理できるようにし、棚卸し作業の時間を半減させる」
- 主要機能リスト: 必要な機能を箇条書きで5〜15項目程度に整理。網羅性より「優先度の高い機能を漏らさない」ことを優先
- 画面・操作の概要: 主要機能ごとに想定する画面や操作の流れを2〜3行で記述。手書きの簡易ワイヤーフレームを添付できればなお良い
- やらないこと（スコープ外）: 後述のとおり最重要項目。「今回は扱わない機能・対象」を明示
- 優先順位: 主要機能リストに「必須／重要／余裕があれば」の3段階で優先順位を付与。予算・期間の制約が出てきたときに何を諦めるかの基準になる
- 変更管理ルール: 仕様変更が発生した場合に「誰が、どのタイミングで、どう合意するか」を1〜2行で決めておく。例:「仕様変更は必ずメールで依頼し、追加見積もりを発注者が承認してから着手する」
これらを箇条書き中心でまとめれば、A4で1〜2枚に収まります。文章として整える必要はなく、要点が伝わる粒度で十分です。
「やらないこと」を明示することの効果
6項目の中でも特に効果が高いのが「やらないこと（スコープ外）」の明示です。
仕様書というと「何を作るか」を書くものというイメージが一般的ですが、実は「何を作らないか」を明示することのほうがトラブル予防効果は高いと言えます。トラブルの多くは「作ってもらえると思っていた機能が含まれていなかった」という認識ギャップから始まるからです。
たとえば「会員登録機能を作る」と書いてあるとき、発注者の頭の中には「パスワードリセット機能」「会員退会機能」「メール通知機能」など、関連する周辺機能が暗黙のうちに含まれていることがあります。一方の開発者は、書かれていない機能は作らないのが原則です。
ここで「今回はパスワードリセット機能は実装しない」「メール通知機能は次フェーズで対応する」と書いておけば、お互いに「あれは含まれていない」という共通認識を最初から持てます。トラブルが起きてから「あれは入っているはず」「いや、入っていない」と言い争う事態を、最も少ない労力で予防できる項目です。
1枚仕様書をベースに開発会社と共有する手順
1枚仕様書を作ったら、次の手順で開発会社と共有してください。
まず、発注者側で1枚仕様書のドラフトを作成します。完璧でなくて構いません。「自分の頭の中にあるものを、不完全でもいいので文字にする」ことが目的です。
次に、開発会社にドラフトを共有し、ミーティングで読み合わせを行います。開発会社の視点から「ここの解釈は2通りある」「この項目だと作業範囲が広すぎる」「ここはもう少し具体化が必要」といったフィードバックが必ず出てきます。このやり取り自体が、認識ギャップを早期に解消する貴重な作業です。
最後に、開発会社のフィードバックを反映して1枚仕様書を更新し、双方が確認した最終版を契約書の別紙として添付します。これで「別紙仕様書」が実体を持ち、契約の対象範囲が明確になります。
この一連の作業に必要な時間は合計で2〜3時間程度です。仕様書省略により発生し得る数週間〜数か月の手戻り、あるいは訴訟リスクと比較すれば、極めて費用対効果の高い投資と言えます。
それでも時間がない場合の代替手段
本セクションは、前章の1枚仕様書すら作る時間がない発注者に向けた最終手段としてお読みください。「ゼロよりは大幅にマシ」な現実的な選択肢を3つ紹介します。
議事録・チャットログを「準仕様書」化する
打ち合わせの議事録や、開発会社とのチャットツール（Slack・Teams・メールなど）のログは、適切に運用すれば「準仕様書」として機能します。
ポイントは、打ち合わせ後に必ず議事録を作成し、発注者と開発会社の双方で「この内容で合意した」という確認を残すことです。「言った・言わない」問題の多くは、合意内容を後で確認できる形に残していないことから発生します。議事録が双方で承認された記録として残っていれば、契約書の別紙ほど厳密ではないにせよ、合意の証拠として相当の重みを持ちます。
具体的には、毎回の打ち合わせ後に発注者または開発会社のどちらかが議事録案を作成し、24時間以内にメールやチャットで「この内容で問題なければ既読確認をお願いします」と送る運用を徹底してください。返信や既読を持って合意とみなす、というルールを最初に握っておけば、議事録が法的にも一定の効力を持ち得ます。
画面イメージ・既存システムを共有する
仕様を言葉で表現するのが難しい場合、画面イメージや既存システムのスクリーンショットを共有することも有効な代替手段です。
「こういう管理画面が欲しい」と言葉だけで伝えるより、参考にしたい既存サービスのスクリーンショットを示して「このような構成で、この部分をこう変更したい」と伝えるほうが、開発者にとってはるかに理解しやすくなります。手書きのスケッチでも構いません。発注者の頭の中にある「使いやすさ」「見やすさ」を視覚化することが、認識ギャップ予防の第一歩です。
参考画像を共有する際は「全体構成は参考にするが、色やロゴは独自にする」「この機能は不要」など、何を真似て何を変えるのかを必ず明示してください。参考画像を「そのままコピーする指示」と誤解されると、別の問題（著作権・商標の問題）が発生する可能性があります。
開発会社に「合意確認書」を作ってもらう
第3の代替手段として、開発会社に「合意確認書」を作成してもらう方法があります。これは、打ち合わせ内容を基に「今回の開発範囲は以下と理解しました」という1枚の確認書を、開発会社側で発注者向けに作成してくれるものです。
すべての開発会社がこの作業を無償で引き受けてくれるわけではありませんが、相談すれば「初期費用の一部として簡易な確認書を作成する」という形で対応してくれる会社もあります。発注者側で1枚仕様書を作る時間が確保できない場合、最初の打ち合わせで「合意確認書を作ってもらえるか」を打診してみてください。
この場合、合意確認書の内容に発注者が責任を持って目を通し、漏れや誤解がないかをチェックすることが重要です。開発会社が用意した文書だから安心、ではなく「自分の頭の中の要件と一致しているか」を必ず確認してから署名・承認してください。
まとめ — 仕様書は「時間を節約する道具」
仕様書を作る時間は、「節約できる時間」ではなく「節約するための投資」です。
仕様書なしで発注すると、認識齟齬・コスト膨張・期待外れの納品物・品質低下・関係悪化という5つの典型的なトラブルが発生しやすく、最悪の場合は契約・法的な紛争にまで発展します。発生してしまったトラブルの解消には、仕様書作成にかかる時間の何倍もの時間と費用がかかり、特に訴訟に至った場合の負担は計り知れません。
一方で、A4で1〜2枚程度の「1枚仕様書」を1〜2時間でまとめておけば、本記事で挙げたトラブルの大半は予防可能です。「目的・主要機能・画面概要・やらないこと・優先順位・変更管理ルール」の6項目を箇条書きで整理するだけで十分な効果があります。それすら難しい場合でも、議事録・チャットログの活用、画面イメージの共有、合意確認書の作成という代替手段があります。「完全な仕様書か、何もしないか」の二択ではなく、「ゼロよりは大幅にマシ」な選択肢を必ずひとつは選んでください。
仕様書の概念や発注者が押さえるべき確認ポイントを体系的に理解したい方はシステム開発の仕様書とは？発注者が押さえるべき確認ポイントを、追加費用の発生原因と回避策の全体像を把握したい方はシステム開発で追加費用が発生する原因と回避策を、それぞれあわせてお読みください。仕様書を「省くべきコスト」ではなく「最小コストで最大の安心を買う道具」として捉え直すことが、発注プロジェクトを成功に導く第一歩となります。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
