企画と機能を小さく決める

この章で学ぶこと

• アイデアを利用者の課題と利用場面に結び付ける
• MVP（最小限の価値を確かめる版）の範囲を決める
• 生成AIと相談するときに、判断材料が残る仕様を書く

1. 課題から始める

「AIを使いたい」「アプリを作りたい」だけでは機能を決められません。まず、誰が、いつ、何に困っているかを書きます。

項目	Idea Pocketの例
利用者	小さな開発チームのメンバー
場面	会議前後に思いつきを忘れたくないとき
現在の困りごと	チャットに流れて後から見つけられない
最も大切な行動	アイデアを短いカードとして保存する
成功の判断	初めての人が1分以内に1件保存できる

生成AIには「良さそうな機能」ではなく、反対意見も求めます。

次のアプリ案を評価してください。
対象者、利用場面、現在の代替手段、最小の価値、作らない機能、
失敗する理由を表にしてください。
前提が足りない箇所は、推測と明記してください。

2. Must / Later / Not nowに分ける

最初の版で必要な機能をMust、価値を確認してから追加するものをLater、当面作らないものをNot nowに分けます。

Must	Later	Not now
ログイン	画像添付	独自SNS
カードの作成・一覧・削除	共同編集	複雑な権限階層
入力エラー表示	プッシュ通知	全機能のオフライン同期
データ削除方法	AIによる要約	広告の最適化実験

生成AI機能そのものをアプリへ組み込む場合も、最初は「1つの入力から1つの下書きを作る」程度に絞ります。APIキーをアプリへ直接埋め込まず、呼び出し回数の制限、費用上限、不適切入力、生成結果の表示方法を設計します。

3. 利用者の操作をシナリオにする

機能名だけでは完成を判定しにくいため、利用者の操作と期待結果を書きます。

シナリオ: アイデアを保存する
前提: 利用者はログイン済み
操作:
  1. 「新規」ボタンを押す
  2. タイトルと本文を入力する
  3. 「保存」を押す
期待結果:
  - 保存中は二重送信できない
  - 成功後に一覧へカードが表示される
  - タイトルが空なら保存せず理由を表示する
  - 通信失敗時は入力内容を残して再試行できる

この形式は、そのまま実装依頼とテスト項目に使えます。

4. 画面とデータを決める

Idea Pocketの最初の版は3画面です。

ログイン画面 → カード一覧 → 作成画面
                    └→ 削除確認

Firestoreを使う場合のデータ例です。

users/{uid}
  displayName
  createdAt

users/{uid}/ideas/{ideaId}
  title
  body
  createdAt
  updatedAt

uidはFirebase Authenticationが発行する利用者IDです。保存先をusers/{uid}の下にすると、本人のデータだけを許可するSecurity Rulesを考えやすくなります。ただし、パス設計だけで保護されるわけではありません。ルールとテストが必要です。

5. 非機能要件も最初に書く

画面に見えない条件もあります。

• 対応OS・ブラウザーと、古い端末をどこまで支えるか
• 読み込み中、通信なし、権限拒否、空データの表示
• 保存する個人情報と、保存期間・削除方法
• 1日あたりの利用者数、保存件数、予算上限
• アクセシビリティ、文字サイズ、色のコントラスト
• 問い合わせ先、障害時の告知方法
• 広告を出すか、子ども向けか、対象地域はどこか

6. 1ページ仕様書を作る

リポジトリのdocs/product-brief.mdなどに、次を1ページ程度で保存します。

# アプリ名
## 解決する課題
## 対象利用者と利用場面
## 最初の版に含める機能
## 含めない機能
## 画面遷移
## データと外部サービス
## 完了条件
## 未決定事項・リスク

生成AIとの会話だけに仕様を残すと、次の作業で前提が失われます。採用した内容をリポジトリへ書き、変更時はコードと一緒に更新します。

やってみよう

1. 自分のアプリについて1ページ仕様書を書く。
2. 生成AIに「最初の版として大きすぎる点を3つ指摘して」と依頼する。
3. Must機能を3〜5個に減らす。
4. Must機能ごとに、成功・入力ミス・通信失敗の完了条件を書く。