更新日：
要件定義は、リーガルを「後付け」ではなく「前提」にする
日本の個人情報・データ取り扱いに関する要件は、単に条文を読んで仕様書に貼り付けるだけでは運用で破綻しやすいです。アジャイルでは変更が前提なので、リーガル観点をプロダクト要件に組み込み、意思決定の手戻りを減らす設計が要になります。
1. 「リーガルの論点」をユーザーストーリーに分解する
まずは、データ取り扱いの論点を「いつ、誰が、何を、どこで、どの根拠で、どう記録し、どう変えるか」に落とします。ここをストーリーとして分解すると、スプリント内で判断と検証が回せるようになります。
- 取得：同意/通知/利用目的の整合性を満たす入力・表示要件
- 利用：目的外利用の抑制と、判断ログの残し方
- 共有：第三者提供・委託の切り分けと契約・仕様の紐付け
- 保存：削除・保管期間・アーカイブの運用パターン
- 移転：国外連携の要否と評価観点（必要な場合）
2. 「Definition of Ready/Done」をコンプライアンスに拡張する
アジャイルで最も効くのは、作業の入口（Ready）と出口（Done）を明文化することです。リーガル観点も同じで、要件が実装・テスト・運用に耐えるかをチェック項目として組み込みます。
例：Ready
- データ分類（個人データ/非個人データ相当）の前提が明確
- 目的、根拠、通知文言がプロダクト文面として確定
- 例外時の挙動（拒否・訂正・削除・停止）の要件が定義
例：Done
- 実装がUI/API/バッチの全経路で目的と整合
- 運用で必要なログ・監査手順が手順書に反映
- テスト観点（入力・同意/通知・例外・データライフサイクル）が整理済み
3. リスク評価を「意思決定のテンプレ」にする
たとえばデータ移転や国外連携は、単発のチェックではなく意思決定プロセスが必要になります。ここをテンプレ化し、関係者（プロダクト、エンジニア、法務/コンプライアンス）が同じ軸で判断できるようにします。そうすると、スプリントの途中でも前に進めながら、必要な確認が遅れにくくなります。
具体的には、リスク評価の観点を「データの性質」「送信形態」「受領側の統制」「契約・技術的保護」「運用と更新頻度」に分け、決裁者が判断しやすい粒度で出力します。これにより、法務が最終段で巻き戻す形から脱却できます。
4. 仕様と運用ルールを同じ言語で管理する
要件定義の落とし穴は、UIやAPIの仕様ができても、運用ルール（監査ログ、問い合わせ対応、削除・保管の実行）と分離してしまう点です。そこで、要件定義の成果物を「仕様（実装対象）」と「運用（実行対象）」に並べて管理します。アジャイルでは更新が速いので、運用手順も差分で追える形にしておきます。
5. リーガル観点をスプリント計画に取り込む最短ルート
- 次スプリントのバックログを「データ取り扱いの論点」でタグ付け
- Ready条件を満たすための調査タスクを先に入れる
- レビューではコードだけでなく、要件の整合（目的・根拠・例外）を確認
- 運用手順の追記が間に合うよう、完了条件に組み込む
この考え方をベースにすると、法務・コンプライアンスがボトルネックではなく、製品のリリース速度を支える仕組みになります。
関連：同じ発想で次に読む
次の一歩を決めるための提案
要件定義の段階で、リーガル観点を「バックログ」と「完了条件」に落とし込む支援を行います。プロダクトチームの進行を止めず、必要な確認を最短で回す設計を一緒に作ります。
案件相談の入口を見る