外注の仕様書の書き方｜発注ミスを防ぐテンプレートと具体例【2026年版】

2026年1月18日

前田壮一

この記事のポイント

✓外注の仕様書の書き方を具体例つきで解説
✓デザインなど業務別のテンプレートと
✓発注ミスを防ぐためのポイントを現役PMが紹介します

外注先に「思っていたものと違う」と言われた経験はありませんか。プロジェクトマネージャーとして12年間、数百件の外注案件を回してきた私の結論は明確です。トラブルの原因はほぼ100%、仕様書にあります。

「仕様書なんて面倒」「口頭で伝えれば十分」。そう思っていた時期が私にもありました。しかし、仕様書を疎かにした結果、納期が3ヶ月遅延し、追加費用として150万円を支払う羽目になった苦い経験があります。その失敗を経て、仕様書を「誰が読んでも一つの解釈にしかならないレベル」まで書き込むようになってから、修正依頼の回数は3分の1に減り、プロジェクトの平均完了期間も2週間短縮されるようになりました。

仕様書は単なる「指示書」ではありません。発注者と受注者の間にある「認識の壁」を取り除き、プロジェクトを成功へと導くための「地図」なのです。

なぜ仕様書が必要なのか

口頭説明の限界と「認識のズレ」

人間は思っている以上に、自分の都合の良いように言葉を解釈します。たとえば、Webサイト制作で「シンプルなデザインで」と伝えたとしましょう。発注者が想像しているのは、Appleのような極限まで情報を削ぎ落としたミニマルデザインかもしれません。しかし、受注者が想像したのは「凝った装飾がない、制作工数の少ないスカスカのページ」である可能性があります。

このように、同じ言葉を使っていても、頭の中にあるイメージは180度異なることが珍しくありません。仕様書は、こうした「形容詞」による曖昧な表現を排除し、具体的な「数値」や「図解」に落とし込むことで、双方の認識を完全に一致させるための道具です。

仕様書がないことで発生する「4つの損失」

仕様書なしでプロジェクトをスタートさせることは、設計図なしで家を建てるのと同じです。その結果、以下のような深刻な損失が発生します。

経済的損失: 完成品が期待と異なれば、作り直し（手戻り）が発生します。開発フェーズ後半での手戻りコストは、初期段階の10倍〜100倍に跳ね上がると言われています。
時間的損失: 「これは仕様変更か、当初の仕様内か」という議論に膨大な時間を取られます。プロジェクトの会議時間の40%が、こうした不毛な押し問答に費やされるケースもあります。
精神的損失: 認識の相違は、不信感を生みます。「言った・言わない」のトラブルは、プロとしての信頼関係を破壊し、チームの士気を著しく低下させます。
品質の損失: 継ぎはぎの修正を繰り返したシステムやデザインは、構造的に脆くなります。結果として、納品後のバグ発生率が2倍以上に高まるリスクがあります。

仕様書に盛り込むべき7つの要素

質の高い仕様書を作成するために、最低限含めるべき7つの要素を解説します。

1. プロジェクトの背景と目的（背景を共有する）

「何を作るか」の前に、「なぜ作るか」を言語化することが最も重要です。受注者がビジネスの全体像を理解することで、指示待ちではなく「目的を達成するための最適な提案」を引き出すことが可能になります。

NG例:

Webサイトをリニューアルしてください。

OK例:

現行サイトは5年前に構築され、スマートフォン対応が不十分です。現在、モバイルからのアクセスが全体の70%を占めていますが、モバイルユーザーの直帰率は78%と非常に高い状態です。今回のリニューアルでは、モバイルファーストのUIに刷新することで、月間の問い合わせ件数を現在の20件から50件へと引き上げることを目標とします。

2. ターゲットユーザー（ペルソナの明確化）

誰がそのサービスを使うのかを具体的に定義します。ターゲットが変われば、適切なUI（ユーザーインターフェース）やトーン＆マナーもガラリと変わります。

属性: 年齢層（例: 30代後半〜40代）、性別、職業、年収層
ITリテラシー: スマートフォンの操作に慣れているか、PCでの業務が中心か
利用シーン: 通勤中の電車内（片手操作）、オフィス（集中環境）、自宅のソファ（リラックス時）
抱えている課題: 「探したい情報がすぐに見つからない」「入力フォームが長すぎて途中で諦めてしまう」など

3. 機能要件（「何ができるか」の定義）

システムが備えるべき機能をリストアップします。ここでのポイントは、機能の「優先度」をつけることと、「やらないこと（除外スコープ）」を明記することです。

機能	詳細仕様	優先度
ユーザー登録	メールアドレス認証に加え、Google・LINE連携を必須とする。	高
商品検索	キーワード検索（部分一致）、カテゴリ絞り込み、価格帯指定。	高
レビュー機能	星5段階評価とテキスト（最大400文字）。画像添付は今回見送り。	中
チャットボット	外部APIを利用した自動応答。複雑なシナリオは対象外。	低

「やらないこと」の例：「多言語対応は行わない」「Internet Explorerはサポート対象外とする」など。

4. 非機能要件（品質の定義）

目に見える機能以外の、性能やセキュリティに関する要件です。エンジニアへの外注では、ここが最もトラブルになりやすい箇所です。

パフォーマンス: 同時接続100人時でも、ページ読み込みを3秒以内に抑えること。
セキュリティ: 常時SSL化、IPAの「安全なウェブサイトの作り方」に基づいた脆弱性対策。
保守性: ソースコードには適切なコメントを付与し、GitHub等でバージョン管理を行うこと。
可用性: 月間稼働率99.5%以上（メンテナンス時間を除く）を目標とする。

5. デザイン要件（視覚的な方向性）

デザインの好みは主観に左右されます。言葉ではなく「視覚的な資料」で伝えるのが鉄則です。

参考サイトの提示: 競合他社や、理想に近いサイトを3〜5件ピックアップします。「このサイトの清潔感は取り入れたいが、フォントの太さはもっと細くしたい」といった具体的なコメントを添えます。
ブランドカラーの指定: メインカラー、アクセントカラー、ベースカラーをカラーコード（例: #2563eb）で指定します。
ワイヤーフレーム: 画面のどこに何を配置するか、手書きのスケッチやPowerPoint、Figmaなどで作成した構成案を用意します。

6. 納品物の定義（ゴールを明確にする）

「何を」「どのような形式で」受け取ればプロジェクト完了とするかを定義します。

プログラムコード: ソースコード一式、READMEファイル。
ドキュメント: 設計書、API仕様書、ER図、テスト報告書。
マニュアル: 管理画面の操作マニュアル（PDFまたは動画）、環境構築手順書。
デザインデータ: Figmaの編集権限、またはレイヤーが保持されたPSD/AIファイル。

7. スケジュールとマイルストーン

最終納期だけでなく、中間目標（マイルストーン）を設定します。これにより、進捗の遅れを早期に発見できます。

フェーズ	完了目安	成果物・確認内容
要件定義完了	1週目末	最終仕様書への合意
デザインFIX	3週目末	主要画面のデザインカンプ承認
開発・アルファ版	7週目末	基本機能が動作する環境での確認
テスト・ベータ版	9週目末	全機能の動作確認とバグ修正
最終納品	10週目末	本番環境へのデプロイと検収

発注側による確認期間（フィードバック期間）として、各マイルストーンごとに2〜3営業日のバッファをあらかじめ組み込んでおくのがプロジェクト管理のコツです。

【新設】仕様書作成を効率化するおすすめツール

文章だけで仕様書を書く時代は終わりました。現在は、非エンジニアでも直感的に使えるツールが豊富にあります。

Notion（ノーション）: テキスト、テーブル、画像、タスク管理を一元管理できます。仕様書のテンプレートを作成しやすく、受注者との共同編集もスムーズです。
Figma（フィグマ）: デザインやワイヤーフレーム作成のデファクトスタンダードです。ブラウザ上で動作し、受注者がリアルタイムでデザインを確認・コメントできます。
Miro（ミロ）: オンラインホワイトボードツールです。画面遷移図（ユーザーフロー）やサイトマップ、ブレインストーミングのアイディアを視覚的にまとめるのに最適です。
Googleドキュメント/スプレッドシート: 常に最新版を共有でき、「誰がいつ変更したか」の履歴が残るため、初歩的な「言った・言わない」を防げます。

業務別の仕様書テンプレート：さらに深掘りすべきポイント

職種によって、仕様書に書くべき「急所」は異なります。

Web制作（コーポレート・LP）の場合

サイトマップ: 全ページの一覧図。どのページからどのページへリンクを貼るか。
ドメイン・サーバー: 既存のものを使うのか、新規取得するのか。サーバーのスペックやOS、PHPのバージョン指定。
SEO要件: タイトルタグ、ディスクリプション、Hタグのルール。ページ表示速度の目標値（Google PageSpeed Insightsで80点以上など）。
CMS指定: WordPressを使う場合、テーマの自作か既存テーマのカスタマイズか。管理画面でどの項目を更新できるようにするか。

システム開発（アプリ・業務システム）の場合

技術スタック: 言語（PHP, Python, TypeScript等）、フレームワーク（Laravel, React等）、データベース（PostgreSQL, MySQL等）の指定。
外部連携: クレジットカード決済（Stripe等）、メール配信サービス（SendGrid等）、SNSログイン（Google, LINE）などのAPI詳細。
画面遷移図: ログイン前、ログイン後、エラー時など、ユーザーがどのように画面を移動するか。
ER図（データベース設計）: どのようなデータを保持し、データ同士がどう関連し合っているか。

デザイン・イラスト制作の場合

使用媒体: Webサイト、SNS広告、名刺、大型看板など。媒体によって解像度やカラーモード（RGB/CMYK）が変わります。
サイズ指定: ピクセル単位（例: 1200 x 630px）またはミリ単位。
フォント指定: 商用利用可能なフォント、または指定のブランドフォントの使用。
素材の有無: 写真素材は発注者が提供するのか、クリエイター側がストックフォト等から選定するのか。

仕様書を書く際の絶対的な注意点

曖昧な表現を徹底的に排除する

仕様書内に以下の表現が出てきたら、それは「トラブルの種」です。すぐに具体的な数値や定義に置き換えてください。

曖昧な表現（NG）	具体的な表現（OK）
見やすいデザイン	フォントサイズ16px以上、行間1.6以上。
大量のデータを処理	1時間あたり1万件のCSV取り込み。
早めに対応	3月15日（金） 18:00までに初稿提出。
適宜、いい感じに	参考URL：〇〇サイトのボタン配置とアニメーションを模倣。
なるべく軽くする	画像ファイル1枚あたり200KB以内、ページ総計2MB以内。