要件定義は、欲しい機能を並べる作業ではありません。
誰のどの業務や生活をどう変えるかを決め、その結果を確認できる機能、品質、データ、運用、受け入れ条件へ落とす工程です。
「何を作るか」と同じ強さで「今回は作らないもの」を合意すると、設計と見積もりの前提が安定します。
アプリ開発の目的に合う相談先は、外注と学習を目的別に分けた相談ガイドにまとめています。
| 要件の層 | 答える問い | 成果物の例 |
|---|---|---|
| 目的 | なぜ作るか | 解決したい課題、成果指標 |
| 利用者 | 誰がどこで使うか | ペルソナ、利用場面 |
| 機能 | 何ができるか | ユーザーストーリー、業務ルール |
| 品質 | どの水準で動くか | 性能、可用性、安全性、アクセシビリティ |
| 運用 | 誰が維持するか | 権限、問い合わせ、監視、更新 |
| 受け入れ | 何をもって完成か | テスト可能な条件 |
要件を六つの層へ分けて混同を防ぐ
「予約アプリを作る」は企画の方向であり、テストできる要件ではありません。
利用者が空き枠を選び、予約を確定し、管理者が変更を確認できるところまで分解します。
| 層 | 予約アプリの例 | 確認方法 |
|---|---|---|
| 目的 | 電話受付の重複を減らす | 重複件数を比較 |
| 利用者 | 来店者と受付担当者 | 利用場面を観察 |
| 機能 | 空き枠表示、予約、変更 | 操作テスト |
| 品質 | 受付時間中の応答と障害時対応 | 性能、復旧テスト |
| 運用 | 枠の登録者と問い合わせ先 | 権限と手順を確認 |
| 受け入れ | 同じ枠を二人へ確定しない | 競合テスト |
ISO/IEC/IEEE 29148の案内は、要求工学のプロセスと要求情報項目を扱う国際規格の一次情報です。
規格名だけを文書へ貼るのではなく、目的、利害関係者、制約、検証可能性という観点を自社の要件表へ変換します。
品質要件を「速い」「安全」とだけ書くと、発注者と開発者で完成像がずれます。
対象操作、条件、測定方法、合格値、例外時の扱いを一組にしてください。
現場の観察から受け入れ条件までを六段階で進める
要望を聞いた直後に画面一覧を確定せず、現在の業務と例外を先に確認します。
- 現在の作業、待ち時間、二重入力、問い合わせを観察する
- 利用者、管理者、承認者、運用担当者を分ける
- 解決したい状態と測定方法を一つの文章にする
- ユーザーストーリーと業務ルールへ分解する
- 品質、データ、権限、運用、対象外を決める
- 正常、例外、権限違いを含む受け入れ条件を書く
デジタル庁の利用者中心ガイドブック実践編は、利用者を理解し、検証しながらサービスを作る実践を整理しています。
会議室の想像だけでペルソナを作らず、観察やインタビューから利用場面と制約を得ることが重要です。
要件文の強さも統一します。
RFC 2119とRFC 8174は、MUSTやSHOULDなどの規範語を解釈する条件を示しています。
日本語でも「必須」「推奨」「任意」を定義し、同じ文書内で意味を変えません。
三十要件を三回へ分ける優先順位の計算例
次の数字は、初回リリースへ要件を詰め込みすぎないための仮定です。
候補が30件あり、利用者の主要動線に必要な要件が12件、運用に必要な要件が6件、改善要件が12件あるとします。
初回へ主要動線12件と運用6件をすべて入れると18件です。
初回の上限を15件にするなら3件を検証版または次回へ移す必要があります。
| 区分 | 候補数 | 初回案 |
|---|---|---|
| 主要動線 | 12 | 12 |
| 運用 | 6 | 3 |
| 改善 | 12 | 0 |
| 合計 | 30 | 15 |
件数だけで優先順位を決めず、一件を外すと主要動線が成立しない依存関係も確認します。
初回から外した要件には、却下ではなく再判断する条件と時期を記録してください。
PoCと画面試作と本番開発を使い分ける
PoCは、技術的または業務的な不確実性を小さく検証する活動です。
「Bluetooth機器から必要精度でデータを取得できるか」や「画像判定が現場の照明で使えるか」のように、合否を一つへ絞ります。
画面試作は、操作順や言葉、情報量を利用者と確認するために使います。
見た目が本物に近くても、性能、セキュリティ、データ整合性が実装済みとは限りません。
| 手段 | 主な問い | 成果物 | 本番へ流用する前の注意 |
|---|---|---|---|
| PoC | 難所が成立するか | 実験結果と合否 | 品質と保守を作り直す |
| 画面試作 | 操作を理解できるか | 遷移と評価記録 | 実データと例外を設計する |
| 本番開発 | 継続運用できるか | コード、テスト、運用手順 | 受け入れ条件で確認する |
PoCの期限と終了条件を決めないと、試作品へ本番機能を継ぎ足し続けます。
検証後は「採用」「条件付き採用」「不採用」を記録し、採用時も本番設計へ移し替えます。
要件定義書を変更判断の基準として使う
要件定義書は、作業開始時に一度だけ承認する文書ではありません。
新しい要望が出たときに、目的、対象利用者、初回範囲、費用、日程、品質へ与える影響を判断する基準です。
要件ID、理由、受け入れ条件、優先度、依存関係、決定者、変更履歴を残します。
「関係者と相談して決める」という未決事項には、決定期限と選択肢を付けてください。
安全性に関わる要件は、開発後の診断だけへ回しません。
NIST Secure Software Development Frameworkは、安全な開発活動を準備、保護、生成、脆弱性対応の領域で扱っており、環境や工程の要件も早期に含める根拠になります。
アプリ開発の要件定義でよくある質問
要件定義書には画面デザインまで必要ですか？
色や装飾を完成させる必要はありませんが、主要な情報、操作、遷移、エラー、権限違いを確認できる資料は役立ちます。
要件文書の構成を考える際はISO/IEC/IEEE 29148の規格情報も参照し、検証可能な要求と補助的な画面資料を区別してください。
ペルソナは想像で作ってもよいですか？
仮説として置くことはできますが、観察やインタビューで更新する前提にします。
デジタル庁の利用者中心の実践資料を参考に、実在利用者の目的、環境、困りごとから判断材料を集めてください。
PoCはそのまま本番アプリへ使えますか？
使えるコードが含まれる場合もありますが、PoCは不確実性の検証が目的です。
性能、安全性、テスト、監視、保守性、権利条件を本番基準で再評価し、流用部分と作り直す部分を決めます。
受け入れ条件と対象外を合意して要件定義を終える
要件定義の完了は、要望を漏れなく書いた状態ではありません。
目的に必要な範囲が選ばれ、正常と例外の受け入れ条件、運用担当、今回は作らないものを関係者が説明できる状態です。
- 要件の六層は目的、利用者、機能、品質、運用、受け入れ
- 検証可能な要件に必要な対象操作、条件、測定方法、合格値
- PoC、画面試作、本番開発で異なる問いと完成条件
- 変更判断を支える要件ID、理由、依存関係、決定者、履歴
要件の範囲が固まったら、UIデザインの画面設計と評価手順で主要動線を可視化し、言葉だけでは見つからない不足を確認できます。
