仕事を計画する前に、スタートとゴールを知りましょう。

滑り出しは重要です。本当に、今から要件定義を始めてよいでしょうか？

サンエム標準では、要件定義工程の開始条件を定めていません。しかし、要件定義工程を「ステークホルダーの要望を、制約の下で要件に変換し、合意して、要件定義書として文書化する」工程と定めています（⇒ 🚧要件定義工程とは？ ）。

要件定義工程を開始するタイミングとして、以下の条件を満たしていることを推奨します。

これらが不明確なまま始めると「要望の空中戦」に陥るリスクが高く、要件定義書の品質にも大きく悪影響を及ぼします。

今、自分がしていること、しようとしていることは、ゴールに近づくことでしょうか？　ゴールを知り、それを狙い続けることで、プロジェクトとチームを遭難させないようにできます。

要件定義のゴールは、サンエム標準に定められています。

• 品質チェック完了:各要件に対して、🚧要件の品質特性のチェックリストを用いて評価が完了している
• 具体的な記述:曖昧な表現(「適切に」「柔軟に」など)が排除され、具体的な数値や条件で記述されている
• 矛盾・重複の解消:要件間の矛盾や重複がレビューによって検出・解消されている

• レビュー実施:ステークホルダーによるレビュー会議が実施され、議事録に承認記録が残されている
• トレーサビリティ確保:要件と目的の対応表(トレーサビリティマトリクス)が作成されている
• 網羅性確認:要望漏れがないことを確認するチェックリストが完了している

• 技術検証:技術的実現可能性について、技術検証(PoC)が実施されている
• 予算・スケジュール承認:予算とスケジュールの妥当性が見積もられ、承認されている
• 法令適合確認:法規制・セキュリティ基準への適合が法務部門またはコンプライアンス担当者により確認されている

• ID付与:各要件に「REQ-001」「REQ-002」のような一意のIDが付与されている
• 対応表作成:要件IDと設計書の設計項目IDの対応表が存在する
• ツール管理:要件管理ツール(JIRAやBacklogなど)で要件が管理され、IDで検索・参照できる

• 詳細な記述:「ユーザーは商品を検索できる」ではなく「ユーザーは商品名・カテゴリ・価格帯で商品を検索でき、検索結果は10件ずつ表示される」といった具体的な記述になっている
• 視覚資料添付:画面イメージやデータフロー図など、視覚的な補助資料が添付されている
• 理解可能性確認:開発者が読んで、何を実装すべきか理解できることがレビューで確認されている

• 受入基準明記:各要件に対して、受入基準(Acceptance Criteria)が明記されている
• 検証可能な条件:「システムは高速に動作する」ではなく「検索処理は2秒以内に完了する」のような検証可能な条件が記載されている
• テストケース作成可能:テスト担当者が要件からテストケースを作成できることが確認されている

• 承認取得:承認者(プロジェクトオーナー、技術責任者など)の署名または電子承認が取得されている
• 承認日記録:承認日が記録され、その日付以降の変更は変更管理プロセスに従うことが明記されている
• ベースライン確定:承認された版がベースライン版として確定され、関係者に配布されている

• 版番号管理:文書に「バージョン1.0」「バージョン1.1」などの版番号が明記されている
• バージョン管理システム:Gitやバージョン管理システムで各版が管理され、過去の版を取り出すことができる
• 作成履歴記録:各版の作成日時と作成者が記録されている

• 履歴表作成:文書内に改訂履歴表があり、「版数・改訂日・改訂者・改訂内容・承認者」が記載されている
• 変更箇所の可視化:変更箇所がハイライトや変更履歴機能で視覚的に分かるようになっている
• 改訂理由記録:改訂理由(顧客要望変更、技術的制約の判明など)が記録されている

• 手順文書化:変更要求の受付から承認・反映までの手順がフローチャートや手順書として文書化されている
• 影響評価方法:変更の影響範囲(スケジュール・コスト・品質)を評価する方法が定義されている
• 承認基準明確化:変更の承認者と承認基準(軽微な変更は担当者承認、重大な変更はステアリングコミッティ承認など)が明記されている