DESIGN.mdテンプレート実例：仕様書の章立てと書き込み例

個人開発のMVP規模であれば、仕様書は次の6章で十分に機能します。既存プロジェクトのREADMEやアーキテクチャ文書のテンプレートとして知られるarc42（新しいタブで開きます）の考え方をベースに、個人開発向けに章を絞り込んだ構成です。

1. 概要（目的・対象ユーザー）
2. スコープ（やること・やらないこと）
3. 画面・機能一覧
4. データ構造
5. 非機能要件
6. 未決事項・今後の課題

1. 概要

要件定義書で決めた目的の1文をそのまま転記します。要件定義書の書き方で整理した内容をここに集約すると、DESIGN.mdだけを見ればアプリの目的がわかる状態になります。

2. スコープ

「実装する画面・機能」と「今回は実装しない機能」を箇条書きで対比させます。AIに実装を依頼する際、この章をそのままプロンプトの前提として渡せます。

3. 画面・機能一覧

画面ごとに「表示する情報」「できる操作」を短く書きます。詳細なUIデザインは含めず、AIが実装に必要な情報だけに絞ります。

4. データ構造

保存するデータ項目と、それぞれの型・必須／任意を一覧化します。ここが曖昧だと、AIが実装するデータベース設計にばらつきが出やすくなります。

5. 非機能要件

想定する同時利用人数、レスポンス速度の目安、データの保存期間など、機能そのものではない条件を書きます。日本国内では、非機能要件を体系的に整理したものとしてIPAが公開している非機能要求グレード（新しいタブで開きます）が参考になります。個人開発のMVPでは、この中から必要な項目だけを抜き出して書けば十分です。

6. 未決事項・今後の課題

今回のスコープでは判断を保留した項目を書いておきます。次のバージョンで再検討する際の起点になります。

DESIGN.mdはどのタイミングで書けばいいですか？

要件定義書で目的とスコープを固めたあと、実装をAIに依頼する前に書くのが基本です。実装が進んでから書き始めると、実際のコードと文書がずれやすくなります。

章立ては全部埋めないといけませんか？

小さなMVPであれば、該当しない章は「対象外」と一言書くだけで問題ありません。無理にすべての章を長文で埋める必要はなく、判断に迷う箇所だけ厚めに書くくらいで十分です。

非機能要件は個人開発でも書く必要がありますか？

個人開発の小規模なMVPであっても、想定する同時利用人数やデータの保存期間など最低限の項目は書いておくと、後から仕様変更するときの判断基準になります。すべてを厳密に定義する必要はありません。