要件定義書の書き方：AIに伝わる「目的・スコープ・やらないこと」

個人開発の要件定義書は、分厚い文書である必要はありません。次の4項目を1〜2ページにまとめるだけで、AIへの実装依頼の精度が大きく変わります。

• 目的：何のために作るか、解決したい課題は何か
• 想定ユーザー：誰が、どんな場面で使うか
• スコープ：今回実装する機能の範囲
• やらないこと：検討したが今回は実装しない機能

目的の書き方

「〔誰が〕〔どんな場面で〕〔何に困っていて〕、このアプリで〔どう解決したいか〕」という形で1〜2文にまとめます。MVPとして検証したい仮説をそのまま流用できる場合が多く、個人開発MVPの作り方で扱った仮説の1文がここに対応します。

想定ユーザーの書き方

年齢や職業などの属性よりも「どんな状況で困っているか」を具体的に書くほうが、AIへの実装指示にも活かしやすくなります。

スコープの書き方

画面単位・機能単位で「実装する／実装しない」を明確に分けます。あいまいな表現（「必要に応じて」など）を避け、判断に迷わない粒度で書くのがポイントです。

「やらないこと」の書き方

検討はしたが今回は含めない機能を明示します。書いておくことで、後から「なぜこの機能がないのか」と混乱するのを防げます。

要件定義書は「何を・誰のために・なぜ作るか」を扱う文書です。それをどう実現するかという実装方針は、仕様駆動開発とはで扱う仕様書の役割になります。さらに画面構成やデータ構造まで具体化したい場合はDESIGN.mdテンプレート実例を参考にしてください。要件定義書→仕様書という順に文書を分けることで、AIに渡す情報の粒度が整理しやすくなります。

国内のシステム開発では、要件定義プロセスの標準的な進め方としてIPAが公開している共通フレーム2013（新しいタブで開きます）が参考にされています。個人開発でここまで厳密に従う必要はありませんが、「発注者と開発者の認識をそろえる」という考え方は、AIに実装を依頼する場面にもそのまま当てはまります。

要件定義書と仕様書は何が違いますか？

要件定義書は「何を・誰のために・なぜ作るか」という目的とスコープを扱うのに対し、仕様書はそれを実現するための画面構成やデータ構造など、より実装に近い内容を扱います。役割が異なるため、両方を書くと認識のズレを防ぎやすくなります。

個人開発でも要件定義書は必要ですか？

チーム開発でなくても、AIに実装を依頼する場合は要件定義書があると効果的です。AIは前提を推測で補うため、目的やスコープが文書化されていないと、意図と異なる範囲まで実装してしまうことがあります。

「やらないこと」はどこまで書けばいいですか？

検討はしたが今回のスコープには含めない機能を中心に書きます。すべての可能性を網羅する必要はなく、後で「なぜこの機能がないのか」と迷いそうな項目を優先して書いておくと役立ちます。