MVP開発の仕様書は、「後から来た人が、なぜこう作ったのかを30分で理解できる範囲」まで書けば十分です。分厚い要件定義書や全画面の詳細設計書を先に完成させる必要はありません。一方で、何も残さずに作り始めると、検証の結果を受けて作り直すときや、開発チームが入れ替わるときに、誰も全体像を説明できない状態になります。書きすぎも書かなさすぎも、MVPのスピードを落とします。
この記事は、新規事業の担当者や、スタートアップでMVPを外注・内製しようとしているプロダクト責任者に向けて書いています。MVPで仕様書をどこまで書くかの判断基準、最低限残すべき6つの文書、書く順番、更新を止めない運用の工夫、よくある失敗までを整理しました。
読み終えるころには、自社のMVPについて「これだけは書く」「これは書かない」を決められ、検証後の作り直しや引き継ぎで困らない軽量な仕様の残し方が分かるはずです。
MVPの仕様書はどこまで書くか：結論は「判断の理由」と「境界」を残す
MVPの仕様書で最も大切なのは、画面や機能の細部ではなく、次の2つです。
- 判断の理由：なぜこの機能を作り、なぜあの機能を作らなかったのか
- 境界：どこまでが今回の範囲で、どこからが範囲外なのか
画面のボタン配置や文言は、実際に動くものを見れば分かります。ソースコードを読めば処理の流れも追えます。しかし「なぜそうしたのか」はコードにも画面にも残りません。検証の結果を受けて機能を削ったり作り直したりするとき、判断の理由が残っていないと、同じ議論を一からやり直すことになります。
また、MVPは意図的に作らない部分が多いプロダクトです。たとえば「パスワード再設定は手作業で対応する」「請求書払いは今回やらない」といった決定は、文書に残しておかないと、後から参加した人が不具合や作り忘れだと誤解します。範囲外を明記することは、範囲内を書くことと同じくらい重要です。
読む人を先に決めると、粒度が決まる
どこまで書くかに迷ったら、「この文書を誰が、どんな場面で読むのか」を先に決めます。MVPの仕様書を読む人は、主に次の4者です。
| 読む人 | 読む場面 | 必要な情報 |
|---|---|---|
| 後から加わる開発者 | 引き継ぎ、改修の着手前 | データ構造、外部サービス、範囲外とした事項 |
| 社内の決裁者 | 継続・撤退の判断 | 検証の目的、判断基準、結果 |
| 運用担当者 | 日々の問い合わせ対応 | 手作業で補う運用の手順 |
| 本開発の発注先 | 見積もり、要件定義 | 判断の記録、画面一覧、データの項目 |
この表で「誰も読まない」情報は、MVPの段階では書かなくて構いません。反対に、読む人がいるのに文書がない情報は、口頭の説明に頼ることになり、説明する人の時間を毎回奪います。特に、決裁者向けの情報と開発者向けの情報は、同じ文書の中でも章を分けておくと、それぞれが必要な部分だけを読めます。
仕様書そのものの一般的な位置づけは仕様書の用語解説でも整理しています。MVPではその中から、変わりにくく、かつ口頭では伝わりにくい情報だけを選んで残す、という考え方をとります。
書きすぎも書かなさすぎも失敗する理由
書きすぎると起こること
MVPは、作りながら学び、学んだことで作るものを変えていくための開発です。最初に詳細な仕様書を書き上げると、次のような問題が起こります。
- 仕様書の作成とレビューに時間がかかり、肝心の顧客検証が始まるのが遅れる
- 開発中に方針が変わるたびに文書の修正が必要になり、やがて更新が追いつかなくなる
- 更新されない仕様書と実際の動きが食い違い、どちらを信じればよいか分からなくなる
- 「仕様書に書いたから」という理由で、検証には不要な機能まで作ってしまう
特に最後の点は見落とされがちです。文書に書かれたものは、合意済みの約束のように扱われやすく、削る判断がしにくくなります。
書かなさすぎると起こること
反対に、何も書かずにチャットと口頭だけで進めると、短期的には速く感じますが、次の場面で大きな手戻りが生まれます。
- 開発会社やエンジニアが交代したとき、引き継ぎに何週間もかかる
- 検証で「この機能は使われていない」と分かっても、何を前提に作ったのかが分からず、削ってよいか判断できない
- 本開発に進むときに、MVPの仕様を一から調べ直す必要がある
- 社内の決裁者や投資家に説明する資料を、毎回ゼロから作ることになる
MVPを外注している場合は、成果物の範囲をめぐる認識違いの原因にもなります。何を作る約束だったのかが文書にないと、検収の場面で困ります。
MVPで最低限残す6つの文書
以下の6つを、それぞれ1〜2ページ程度の分量で残すのが目安です。すべてを別ファイルにする必要はなく、1つの共有ドキュメントに章として並べても構いません。
| 文書 | 書く内容 | 分量の目安 | 更新のタイミング |
|---|---|---|---|
| 検証の目的と仮説 | 誰のどんな課題を、何で確かめるか。成功・失敗の判断基準 | 1ページ | 仮説が変わったとき |
| 範囲表（作る・作らない） | 今回作る機能と、作らない機能・手作業で補う運用 | 1ページ | 範囲を変えたとき |
| 画面一覧と主要な流れ | 画面の名前と役割、利用者の代表的な操作の流れ | 1〜2ページ | 画面を追加・削除したとき |
| データの項目と関係 | 主なデータ（会員・注文など）の項目と関係 | 1ページ | テーブル構造を変えたとき |
| 外部サービスと環境 | 使っているクラウド・決済・メール配信などと、アカウントの管理者 | 1ページ | サービスを追加・解約したとき |
| 判断の記録 | いつ、何を、なぜ決めたか（または見送ったか） | 随時追記 | 判断のたびに |
検証の目的と仮説
MVPの仕様書の最初に置くべきは、機能ではなく目的です。「誰の、どんな課題を、どの行動を見て確かめるのか」を書きます。たとえば「中小の工務店が、職人の手配を電話でなくWebで依頼するか。2週間で依頼が一定件数以上あれば継続」のように、判断基準まで書いておくと、後から機能の取捨選択をするときの拠り所になります。
範囲表（作る・作らない）
機能を一覧にし、「今回作る」「今回は作らない」「手作業で補う」の3つに分けます。優先度の付け方はMVPの機能の絞り方で詳しく解説していますが、仕様書としては結果と理由を一行ずつ残せば十分です。手作業で補う項目には、誰がどうやって補うのかも書いておきます。
画面一覧と主要な流れ
全画面の詳細設計は不要ですが、画面の名前と役割の一覧、利用者が登録から主要な操作を終えるまでの流れは残しておきます。手書きの図やデザインツールの画面をそのまま貼るので構いません。画面同士のつながりを図にする方法は画面遷移図の作り方が参考になります。
データの項目と関係
データの構造は、画面よりも変更のコストが大きい部分です。会員、商品、注文、予約といった主なデータについて、どんな項目を持ち、どのデータとどう紐づくのかを簡単な図か表で残します。後から本開発に進むとき、データ移行の可否を判断する材料になります。
外部サービスと環境
MVPでは、クラウド、決済、メール配信、認証、分析ツールなど、多くの外部サービスを組み合わせます。どのサービスを、誰の名義のアカウントで使っているのか、請求先はどこかを一覧にしておかないと、担当者が抜けたときにアクセスできなくなる恐れがあります。あわせて、開発用・確認用・本番用といった環境がいくつあり、それぞれのURLと用途が何かも一行ずつ書いておくと、引き継ぎの初日に迷う時間が減ります。パスワードや秘密鍵そのものは仕様書に書かず、パスワード管理ツールなどに保管して「どこにあるか」だけを記します。
判断の記録
最も軽く、最も価値が高いのがこの文書です。日付、決めたこと、理由、検討した代替案を1〜3行で追記していきます。会議の議事録全体を残すよりも、結論と理由だけを抜き出した記録のほうが、後から読み返されます。
書かなくてよいもの・後回しにしてよいもの
MVPの段階では、次のものは書かなくても困らないことが多いです。
- 全画面の項目定義（入力桁数や表示文言の一覧）：実際の画面とコードが正となる
- 詳細な処理フロー図：主要な流れ以外はコードを読めば分かる
- 非機能要件の網羅的な一覧：ただし、後述する「妥協しない部分」だけは書く
- 運用マニュアルの完成版：運用が固まる前に作っても書き直しになる
- テスト仕様書の全件：重要な操作の確認手順だけを残せばよい
ただし、後回しにしたものは「後回しにした」と範囲表か判断の記録に書いておきます。書かなかったのか、書き忘れたのかを区別できるようにするためです。
判断に迷う項目は、「この情報が失われたら、取り戻すのにどれだけ時間がかかるか」で考えます。画面の文言はアプリを開けばすぐ分かるので書かなくてよい。一方、ある外部サービスを選んだ理由や、ある機能を見送った経緯は、関わった人がいなくなれば二度と取り戻せません。取り戻すコストが大きい情報から優先して残す、というのが軽量な仕様書の基本的な考え方です。
妥協しない部分だけは明文化する
個人情報の扱い、決済、データのバックアップなど、MVPでも妥協できない部分については、短くてもよいので方針を文書にします。「個人情報は氏名とメールアドレスのみ保存し、それ以外は保存しない」「決済情報は決済代行会社に預け、自社では保持しない」といった一文があるだけで、後から参加した開発者の判断がぶれにくくなります。MVPで品質をどこまで担保するかはMVPの品質基準で詳しく扱っています。
軽量な仕様書を作る手順
実際に仕様を残していく手順は次のとおりです。最初の版は半日から1日で作れる分量を目指します。
- 共有ドキュメントを1つ作り、6つの章の見出しだけを置く。置き場所は、社内と開発チームの両方が見られる場所にする
- 検証の目的と仮説を書く。成功・失敗の判断基準を、期間と行動の言葉で書く
- 機能を洗い出し、「作る」「作らない」「手作業で補う」に分けて範囲表を作る
- 画面一覧と主要な流れを、手書きの図やデザインツールの画像で貼る
- 主なデータの項目と関係を表にする。開発者がいれば、データベースの設計から書き起こしてもらう
- 使う外部サービスと、アカウントの名義・管理者・請求先を一覧にする
- ここまでの過程で決めたことを、判断の記録に日付つきで書き込む
- 開発チームと読み合わせをし、分からない点を質問してもらって追記する
- 開発中は、週に一度の定例の最後に5分だけ使って、変わった点を反映する
手順8の読み合わせが重要です。書いた本人には自明なことが、読む側には分からないことがよくあります。質問されたことは、そのまま文書に足すべき情報です。
更新が止まらない運用の工夫
軽量な仕様書の最大の敵は、更新されなくなることです。次の工夫で、更新の負担を小さく保ちます。
- 更新のタイミングを定例に組み込む：週次の定例の最後に、仕様書の変更点を確認する時間を固定で取る
- 判断の記録だけは即日書く：その他の章はまとめて更新してもよいが、判断の理由は時間がたつと思い出せない
- 書く人を一人決める：全員で書くと誰も書かない。プロダクト責任者か、開発側の窓口が担当する
- チケットやコードへのリンクを貼る：詳細は課題管理ツールやソースコードに任せ、仕様書からは参照するだけにする
- 古くなった記述は消さずに打ち消す：過去の判断の経緯が分かるよう、変更前の内容に取り消し線を引いたり「旧」と書いたりする
架空の例：検証中の方針転換
たとえば、飲食店向けの仕入れ発注サービスのMVPを作っている架空のチームを考えます。当初は「店舗が複数の卸業者にまとめて発注できる」ことを仮説にしていましたが、検証の結果、店舗が困っていたのは発注そのものより「毎日の発注量を決めること」だと分かりました。
このとき判断の記録に「3週目の検証で、店舗は発注の手間より発注量の判断に困っていることが分かった。複数業者への一括発注機能は保留し、過去の発注履歴から推奨量を表示する機能を優先する」と残しておけば、半年後に新しいメンバーが加わっても、なぜ一括発注機能が中途半端な状態で残っているのかを理解できます。逆にこの記録がなければ、作りかけの機能を「完成させるべきもの」と誤解して、時間を使ってしまうかもしれません。
よくある失敗と避け方
- 要件定義書のテンプレートをそのまま埋めようとする：本開発向けのテンプレートは項目が多く、MVPには過剰です。6つの章に絞り、空欄の項目は削除します。本格的な要件定義の書き方が必要になった段階で要件定義書の書き方を参照してください。
- 仕様書を開発会社に丸投げする：開発会社が書けるのは「どう作ったか」です。「なぜ作ったか」「検証で何を見るか」は発注側でしか書けません。目的と範囲と判断の記録は、事業側が責任を持ちます。
- チャットに決定事項が埋もれる：チャットで決まったことは、その場で判断の記録に転記するルールにします。転記する人を決めておくと漏れが減ります。
- 画面のデザインと仕様を混同する：デザインツールの画面は「見た目の案」で、仕様ではありません。どの画面が確定で、どれが案なのかを画面一覧に明記します。
- 外部サービスのアカウントを個人名義で作る：担当者の退職や契約終了で、ログインできなくなる事態が起こります。会社の共有アドレスで作り、一覧に管理者を書きます。
引き継ぎに耐える仕様書のチェックリスト
最初の版ができたら、次の項目を確認してください。
- 検証の目的、対象顧客、成功・失敗の判断基準が書かれている
- 作る機能と作らない機能、手作業で補う運用が分けて書かれている
- 手作業で補う部分について、担当者と手順が書かれている
- 画面の一覧と、利用者の主要な操作の流れが図か表で残っている
- 主なデータの項目と関係が分かる
- 外部サービスの一覧と、アカウントの名義・管理者・請求先が分かる
- 個人情報、決済、バックアップなど妥協しない部分の方針が書かれている
- 判断の記録に、日付・決めたこと・理由が残っている
- 開発チーム以外の人が読んで、30分程度で全体像を説明できる
- 更新の担当者とタイミングが決まっている
最後から2つ目の項目は、実際に試すのが確実です。プロジェクトに関わっていない社内の人に読んでもらい、どんなサービスで、何を確かめていて、どこまでできているのかを説明してもらいます。説明できなかった部分が、書き足すべき箇所です。
チェックが埋まらなかった項目は、そのまま次の定例で扱う議題になります。すべてを一度に埋めようとせず、引き継ぎの予定が近いもの、失われると取り戻せない情報に関わるものから順に補っていきます。
よくある質問
Q. MVPを外注する場合、仕様書は誰が書くべきですか？
検証の目的、範囲表、判断の記録は発注側が書きます。画面一覧、データの項目、外部サービスの一覧は開発会社に作成を依頼し、発注側が内容を確認する分担が現実的です。契約時に「どの文書を、どの粒度で納品物に含めるか」を合意しておくと、後からの認識違いを防げます。
Q. ノーコードツールでMVPを作る場合も仕様書は必要ですか？
必要です。ノーコードツールは設定画面を見れば動きが分かるように思えますが、なぜその設定にしたのか、どのデータがどこにあるのかは、作った本人以外には分かりにくいものです。特に本開発へ移行するときに、データ構造と判断の記録が役立ちます。
Q. 本開発に進むとき、MVPの仕様書はそのまま使えますか？
そのままでは足りないことが多いですが、出発点として大きな価値があります。目的と判断の記録は、本開発の要件定義の前提になります。画面一覧やデータ構造は、作り直すか引き継ぐかを判断する材料になります。MVPから本開発への進め方はMVPから本開発への移行で解説しています。
Q. 生成AIに仕様書を書かせてもよいですか？
会議のメモやソースコードから、画面一覧やデータ項目の下書きを作る用途には役立ちます。ただし、判断の理由や範囲外とした事項は、事業側が自分の言葉で確認して残す必要があります。社内の情報を入力してよいかは、自社の利用ルールに従ってください。
Otsumuに相談できること
検証したい仮説がはっきりしていて、社内にプロダクトの責任者と、文書を読み書きできる開発者がいる場合は、この記事の6つの章とチェックリストを使えば、外部の手を借りずに軽量な仕様を残していくことができます。まずは共有ドキュメントを1つ作り、目的と範囲表から書き始めてみてください。
一方で、何を検証すべきかがまだ定まっていない、作る機能と作らない機能の線引きに社内で合意できない、すでに作ったMVPの仕様が誰にも説明できない状態になっている、といった場合は、事業と開発の両方を見られる相手と整理したほうが早く進みます。仕様の書き方の問題に見えて、実は検証の設計の問題であることが少なくありません。
Otsumuは、自らも事業を手がける立場から、目的から逆算して必要な機能に絞り込み、AIを活用した少人数・短期間の開発でMVPを形にしています。新規事業の爆速MVPシステム開発では、検証の設計、範囲の決定、開発、引き継ぎに必要な文書の整備までを一気通貫で支援します。期間と範囲を決めて進めたい場合は、6週間を目安に設計するPoC / MVP Sprint（300万円〜、税別・参考価格）もご用意しています。
仕様をどこまで書けばよいか迷っている段階からでも構いません。30分の無料相談で、いまの状況をお聞かせください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01