開発会社に依頼する前に作るべき "1 枚設計書"
要件定義の前に、目的・業務・画面・データ・運用を 1 枚に整理する。
この記事の結論
- 完璧な要件定義書はいりません。1 枚で 7 項目 (目的・ユーザー・業務フロー・画面/機能・データ・権限・運用責任) が揃っていれば、相談の質が変わります。
- 1 枚設計書を作る目的は、外注先の提案の幅を広げることです。「決まっていることを伝え、決まっていないことを共有する」 ためのツール。
- AI 時代の開発では、コードよりも前に 「プロジェクトの地図」 を作っておくと、AI と人間の両方が最初から同じ方向に進めます。AGENTS.md や CLAUDE.md のような開発文脈ファイルと同じ役割を、発注前段階で果たします。
- 「仕様が固まっていないと相談できない」は誤解です。1 枚設計書の目的は、むしろ固まっていないことを共有するため です。
「仕様が固まっていないのですが、相談していいですか」
min's への相談で、最も多い前置きです。答えは、仕様が固まっていない段階こそ、相談してください です。
ただし、完全に手ぶらで来ると、相談時間の大半が「現状を聞き出す」ことに使われてしまい、外注先の提案を聞く時間が残りません。そこで、相談前に揃えておくと相談の質が変わる「1 枚設計書」のテンプレートを公開します。
完璧でなくてかまいません。むしろ、1 枚に収まる程度の情報量 を意識して書くことが、相談の質を上げます。
なぜ「1 枚」なのか
1 枚設計書には 3 つの効果があります。
1. 外注先の提案の幅を広げる
詳細な仕様書を渡すと、外注先は「指示通りに作る」モードになります。1 枚に絞ると、「もっと安く / 速く / 上手く実現する方法」を提案する余地 が残ります。
2. 認識ズレを早期に発見する
社内で 1 枚を書くプロセスそのものが、社内の認識合わせ になります。経営・現場・IT 担当で「何を作りたいか」が食い違っているケースは多くあり、1 枚設計書を書く過程でそれが顕在化します。
3. 見積もり精度が上がる
1 枚に必要な情報が揃っていれば、外注先は「同じ前提」で見積もりを出せます。複数社に同じ 1 枚を渡せば、見積もり比較が意味を持ちます。
OpenAI のドキュメントでは、Codex に渡す AGENTS.md という設定ファイルが説明されています。これは作業を始める前に Codex に読ませる「プロジェクト固有の指示・標準・制約」をまとめたファイルです (Custom instructions with AGENTS.md / OpenAI Developers)。Anthropic の CLAUDE.md も同様で、コードベース固有の構造・規約・ワークフローを記述し、毎回の対話で読み込ませる仕組みです (Using CLAUDE.md files / Anthropic)。
「AI に作業を始めさせる前に、プロジェクトの地図を渡す」 という発想は、外注に発注する前の 1 枚設計書とまったく同じ役割を果たしています。
1 枚設計書に入れる 7 項目
A4 縦 1 枚、または横長スプレッドシート 1 シートに収まる量で、以下の 7 項目を埋めます。
1. 目的
「何のために作るか」を 1 段落で。
店舗の予約管理を、紙と電話から SaaS に移すことで、予約取りこぼしを減らし、複数店舗での状況共有を可能にする。
2. ユーザー
「誰が使うか」を、人数規模と利用頻度まで。
- 店舗スタッフ: 50 人、iPad で 1 日 30 回触る
- 本社管理者: 5 人、PC で月数回、レポートを見る
- 顧客: 月 1 万人、スマホで予約のみ
3. 業務フロー (現状)
いま、どうやっているかを正直に。
- 受注: 電話 + 店舗での飛び込み
- 確認: FAX + LINE で本社に転送
- ステータス: 担当者の頭の中で管理 (「未着手」「対応中」「完了」)
- 集計: 月末に Excel で手集計
4. 画面 / 機能の優先順位
Must / Should / Later / Never の 4 段階で、機能を仕分け。
| 区分 | 内容 |
|---|---|
| Must | ログイン、予約一覧、予約作成、ステータス変更 |
| Should | 月次レポート、店舗別の集計、顧客マスター |
| Later | スマホ通知、自動キャンセル、AI による予測 |
| Never | チャット機能、SNS シェア |
5. データ
主要なデータと、その項目を 1 行ずつ。
- 顧客 (名前、電話、メール、登録日)
- 予約 (日時、店舗、顧客、ステータス、備考)
- 店舗 (名前、住所、営業時間、担当者)
6. 権限
役割と、見える / 編集できる範囲のマトリクス。
| ロール | 自店舗予約 | 他店舗予約 | 顧客情報 | レポート |
|---|---|---|---|---|
| 店舗スタッフ | 閲覧・編集 | × | 閲覧 | × |
| 本社管理者 | 閲覧 | 閲覧 | 閲覧・編集 | 閲覧・編集 |
| 経理 | × | × | × | 閲覧 |
7. 運用責任
リリース後、誰が何をやるか。
- 不具合の窓口: 本社 IT 担当 (営業時間内)
- 営業時間外の障害: 開発会社が一次対応 (SLA は別途協議)
- 軽微な改修 (文言、項目追加): 開発会社に月額契約で依頼
- ユーザー追加・店舗追加: 本社管理者が画面から操作
悪い依頼文と良い依頼文
悪い依頼文
予約管理システムを作ってください。よくある予約システムです。予算は応相談、納期も応相談です。
これだと、提案も見積もりも出せません。
良い依頼文
上記の 1 枚設計書のとおり、店舗予約システムを構築したい。重要なのは「店舗スタッフが iPad で 1 日 30 回触っても疲れない UI」と「複数店舗の本社集計」です。AI / SaaS の活用提案も歓迎です。予算は構築 300〜500 万円、月額運用 30〜50 万円のレンジで検討しています。希望リリースは 6 月、絶対の締め日は 9 月の繁忙期前です。
ここまで渡せば、外注先は「どう作るか」「どう削るか」「AI でどう短縮するか」を含めて、提案できる状態になります。
1 枚設計書の使い方
実際の進め方は以下のとおりです。
- 社内で 1 枚を書く (経営・現場・IT 担当の 3 人で 2 時間ほど)
- 複数の開発会社に同じ 1 枚を渡す (相見積もりを取る場合)
- 30 分〜1 時間の相談で、外注先からの質問に答える
- 提案・概算見積もりを受け取り、比較する
- 詳細な要件定義は、契約後の最初のフェーズで一緒に進める
このプロセスだと、外注先選定にかかる時間は 2〜4 週間程度で済みます。1 枚もない状態で問い合わせると、各社で「現状ヒアリング」だけで 2〜3 時間かかり、選定に 2 ヶ月かかることがあります。
ここまで読んで「1 枚を書くのも難しい」と感じたら、min's では 1 枚設計書のたたき台を一緒に作るスポット相談 を行っています。
min's での実際の進め方
min's では、相談時に 1 枚設計書がなくても問題ありません。30 分の相談時間で、
- 「目的」と「ユーザー」だけ口頭でヒアリング
- 残りの 5 項目は、その場で min's 側がたたき台を作成
- 終了時に「1 枚設計書」のドラフトを共有
という形で、相談の場で 1 枚を一緒に組み上げます。社内に持ち帰り、関係者でレビューしてから、本見積もりの依頼につなげるのが典型的な流れです。
発注前の整理から相談したい方へ
min's では、開発外注を検討中の方向けに、1 枚設計書のたたき台作成から、概算見積もり、外注先選定までを支援しています。
以下のような状態であれば、ご相談ください。
-
仕様が固まっていない段階で、何から準備すればいいか分からない
-
1 枚設計書のテンプレートが欲しい
-
複数社に同じ条件で見積もり依頼したい
-
社内の認識合わせから外部の手を借りたい
次に読む記事
参考
- Custom instructions with AGENTS.md / OpenAI Developers — Codex に渡すプロジェクト固有指示の階層と運用
- Using CLAUDE.md files / Anthropic — CLAUDE.md でコードベースの構造・規約・ワークフローを Claude に渡す仕組み