仕様書の読み方・確認ガイド
AIとの対話後に生成される仕様書は、アプリの設計図です。ビルド前に内容を確認することで、意図と異なる実装を防げます。このガイドでは、非エンジニアの方でも仕様書を理解できるよう解説します。仕様書の構成
仕様書は以下のセクションで構成されています。| セクション | 内容 | 確認の重要度 |
|---|---|---|
| データモデル | アプリで扱うデータの構造 | ⭐⭐⭐ 高 |
| ルーティング | 画面の一覧と遷移 | ⭐⭐⭐ 高 |
| コンポーネント | 画面の部品定義 | ⭐⭐ 中 |
| ワークフロー | 処理の流れ(API) | ⭐⭐ 中 |
| テーマ | デザイン設定 | ⭐ 低 |
| 言語・地域 | 多言語設定 | ⭐ 低 |
各セクションの読み方
データモデル(最重要)
データモデルは、アプリで扱うデータの構造を定義します。Excelの表をイメージすると分かりやすいです。 例:顧客データモデル確認ポイント1:必要な項目が揃っているか
確認ポイント1:必要な項目が揃っているか
伝えた要件に含まれる項目がすべて定義されているか確認しましょう。チェック例:
- ✅ 会社名がある
- ✅ 担当者名がある
- ❌ 住所がない → 必要なら追加を依頼
確認ポイント2:必須/任意が正しいか
確認ポイント2:必須/任意が正しいか
必須項目(入力しないと登録できない)と任意項目(空でもOK)の設定を確認しましょう。よくある修正:
- 「電話番号は任意にして」
- 「メールアドレスは必須にして」
確認ポイント3:選択肢が正しいか
確認ポイント3:選択肢が正しいか
ステータスやカテゴリなどの選択肢が、実際の業務フローと合っているか確認しましょう。修正例:
「ステータスに『保留』を追加して」
ルーティング(画面一覧)
ルーティングは、アプリにどんな画面があり、どのURLでアクセスできるかを定義します。 例:| パス | 画面名 | 説明 |
|---|---|---|
/ | ダッシュボード | トップページ |
/customers | 顧客一覧 | 顧客の一覧表示 |
/customers/new | 顧客登録 | 新規顧客の登録 |
/customers/:id | 顧客詳細 | 顧客の詳細表示 |
/customers/:id/edit | 顧客編集 | 顧客情報の編集 |
確認ポイント:必要な画面があるか
確認ポイント:必要な画面があるか
要件で伝えた機能に対応する画面がすべてあるか確認しましょう。チェック例:
- ✅ 一覧画面がある
- ✅ 登録画面がある
- ❌ レポート画面がない → 必要なら追加を依頼
ワークフロー(処理の流れ)
ワークフローは、データの登録・更新・削除などの処理を定義します。APIとも呼ばれます。 例:顧客登録ワークフロー確認ポイント:必要な処理があるか
確認ポイント:必要な処理があるか
- 登録、編集、削除の処理があるか
- 検索やフィルターの処理があるか
- 集計やレポートの処理があるか
コンポーネント(画面部品)
コンポーネントは、画面を構成する部品(ボタン、入力フォーム、テーブルなど)を定義します。 例:顧客一覧テーブル確認ポイント:表示項目が正しいか
確認ポイント:表示項目が正しいか
一覧画面やテーブルに表示される項目が、必要なものになっているか確認しましょう。
ビルド前の確認チェックリスト
以下のチェックリストを使って、ビルド前に仕様書を確認しましょう。修正の依頼方法
仕様書に問題を見つけたら、AIに修正を依頼しましょう。修正依頼の例
- 項目の追加
- 選択肢の変更
- 画面の追加
- 機能の変更
よくある質問
技術用語がわからない
技術用語がわからない
用語集で、仕様書に出てくる技術用語を解説しています。参照しながら確認してください。
どこまで細かく確認すべき?
どこまで細かく確認すべき?
最低限確認すべき:
- データモデルの項目
- 画面の一覧
- ワークフローの処理内容
- コンポーネントの表示項目
確認に時間がかかりすぎる
確認に時間がかかりすぎる
まずはデータモデルと画面一覧だけ確認してビルドし、プレビューで動作を見てから修正する方法もあります。ただし、データモデルの大きな変更はビルドし直しになるため、データモデルは最初に確認することをおすすめします。