ここまで整理してきたビジネス要件、機能要件、非機能要件、データ要件、UI/UX要件などを要件定義書としてまとめ、レビューによって完成度を高める段階です。要件定義書は、開発プロジェクトを正式に進めるための合意文書として位置付けられることが多いため、抜け漏れや曖昧さを可能な限り排除することが大切です。
7.1 シナリオ設定
- 要件を文書化する必要性
- プロジェクトのスコープや仕様を明示することで、開発チーム、サロン側（顧客）、他ステークホルダーとの認識を共有する。
- 不要な再作業や誤った実装を防ぎ、開発の効率化と品質向上を図る。
- レビューによる検証
- 要件定義書のレビューは、開発経験者や顧客代表、運用担当など、複数の観点から抜け漏れをチェックできる貴重な機会。
- 早期に指摘を受けることで、後工程（設計や実装）に入ってからの修正コストを大幅に削減できる。
7.2 演習タスク
- 要件定義書テンプレートの提示
- 新入社員に対し、一般的な要件定義書の構成（ビジネス要件、機能要件、非機能要件、データ要件、UI/UX要件、用語集、承認欄など）を示す。
- 既存のテンプレートやガイドラインがある場合は、取り入れて書式を統一させる。
- ドキュメント作成（ドラフト版）
- これまでの演習で作成した資料（機能一覧、ER図、画面遷移図、UI/UX要件一覧など）をもとに、要件定義書のドラフトを作成させる。
- セクションごとに担当を分担し、チームで編集作業を進める。
- レビュー（模擬顧客＆エンジニア）
- ロールプレイとして、別チームや先輩エンジニアが顧客役や運用担当役を務め、要件定義書をチェックする。
- 「ビジネスゴールが明確に反映されているか」「機能要件に重複や不足はないか」「非機能要件の数値根拠は現実的か」など、レビュー観点をあらかじめ整理して実施する。
- 修正・更新
- レビューで得た指摘や追加要望を集約し、**要件定義書を改版（ドラフト版→正式版）**する。
- バージョン管理を行い、修正履歴やコメントを残しておくと、後々のトラブルシュートや責任分担の明確化に役立つ。
7.3 成果物
- 要件定義書（ドラフト版 → 正式版）
構成例： - 概要
- 背景、目的、前提条件
- ビジネス要件
- ビジネスゴール、対象範囲、KPI
- 機能要件
- 機能一覧、ユースケース図、機能仕様
- 非機能要件
- パフォーマンス、可用性、セキュリティ、運用保守など
- データ要件
- ER図、テーブル定義、データ運用ルール
- UI/UX要件
- 画面一覧、画面遷移図、ワイヤーフレーム
- スコープ／リリース計画
- フェーズ分け、優先度、開発範囲
- リスク・懸念事項
- プロジェクトリスクや運用リスクの整理
- 承認欄
- サインオフ（サロンオーナー、店長、開発責任者など）
- レビュー指摘一覧／修正履歴
- 指摘内容、指摘者、修正対応策、対応日付などをまとめる。
- 過去のバージョンでどんな変更がなされたかを追えるよう、履歴管理を徹底する。
7.4 ポイント
- 目的を再確認: 要件定義書は「システム開発に必要な要件を確定させ、合意を得るための文書」。記載があいまいだと後工程での手戻りが大きい。
- レビューは厳しく: 実際の顧客折衝や開発現場では、要件が曖昧だと追加費用やスケジュール変更に直結する。模擬的な演習でも可能な限りリアルな指摘を行い、完成度を高める。
- ドキュメントの一貫性: ビジネス要件と機能要件、データ要件など、個別のセクションで矛盾が生じていないかをチェックする。
- 承認プロセスの明確化: どのタイミングで誰が承認し、正式に「要件が固まった」とみなすのか。承認者の責任範囲も明確にする。
要件定義書は、プロジェクトの要となる重要文書です。新入社員が一連の演習を通じて、要件定義書の目的や作成手順、レビューでの指摘対応、バージョン管理の必要性などを体験することで、実務への理解が深まります。
コメントを残す
コメントを投稿するにはログインしてください。