変更管理でコンプライアンスを維持する：スプリント運用ガイド
リーガル要件を「レビューのための最後の工程」にしない。スプリントの設計図として落とし込み、変更が起きるたびにリスクを可視化し、意思決定の速度を落とさずに統制を効かせます。
ゴールは「守り」と「前進」を同時に満たすこと
プロダクトの変更管理は、仕様差分だけを追う作業ではありません。データの取り扱い、権限、保存期間、委託先や連携、ログ方針など、コンプライアンスに直結する前提が変わるたびに、影響範囲を特定し、承認可能な判断に落とす必要があります。
このガイドでは、アジャイルのスプリント運用に「法務・セキュリティ・プロダクト」の共同責任を埋め込み、変更が入ってもリリースを止めない運用を目指します。
スプリント前に決めるべき4つの前提
-
変更の「影響分類」を固定する
例：データ対象（個人データ/非個人データ相当）、処理目的、保管・削除、共有範囲、第三者提供/委託、国外連携、権限設計。分類がブレると、承認判断が毎回迷子になります。
-
リーガル要件を「受け入れ基準」に翻訳する
要件を「法務コメント待ち」にしない。ユーザーストーリーや技術タスクの定義（例：同意取得の条件、削除要求の到達条件、ログ保持の条件）に落とします。
-
レビュー対象の閾値を合意する
すべてを法務レビューに回すと速度が落ちます。影響分類×変更規模×既存の承認済み範囲で「必要なレビューだけ」を通します。
-
証跡（エビデンス）の最小単位を定義する
PR、設計メモ、データフロー更新、権限表、第三者一覧、変更ログ。必要なのは“重い資料”ではなく、監査や再評価に耐える最小セットです。
スプリント運用：Change Control Loopを回す
変更管理を「1回の審査」ではなくループとして設計します。スプリント内に次のサイクルを組み込み、変更が入るたびに影響が繰り返し評価される状態を作ります。
-
1
変更の起点を特定
要求変更、仕様の揺れ、外部連携の追加、データ項目の増減など、何が“前提を変えたか”を言語化します。
-
2
影響分類とリスクの方向性を更新
“どの要件が影響を受けるか”を明確にし、リスクの方向（増える/減る/変わる）を記録します。ここで変更管理の速度が決まります。
-
3
受け入れ基準と設計を整合させる
実装に入る前に、受け入れ基準（仕様/UX/データ処理/権限/ログ）と設計が一致しているか確認します。
-
4
承認と証跡を“スプリント内”で完結
承認は外出しにせず、PRや設計メモ、データフロー更新などの証跡を所定の場所に残します。
変更管理と監査対応を「前倒し」でつなぐ
監査で問われるのは、結論の正しさだけではなく、意思決定がどう形成されたかです。スプリント中に証跡を揃えると、監査や再評価の負担が小さくなります。特に、データ移転や国外連携、サードパーティSDKの導入などは変更頻度が上がるほど見落としが増えるため、運用で吸収します。
- データフロー図は「更新が必要な条件」を明記する
- 契約・約款の反映は「仕様の差分」とセットで扱う
- リスク評価はスプリント内で“次のアクション”まで結びつける
スプリント内のおすすめ運用（最小セット）
運用を増やしすぎないことが重要です。次の最小セットをベースに、チーム成熟度に応じて拡張してください。
変更チケットのテンプレ
影響分類、該当データ、目的/権限/保管、第三者、承認が必要な理由、証跡リンク。
週次の合意時間
“レビューが必要な変更だけ”を15〜30分で確認し、次スプリントの受け入れ基準に反映。
スプリント終わりの照合
実装の完了条件が受け入れ基準と一致しているか、差分の有無を記録。
アラート条件の明文化
個人データの新規処理、国外連携、委託先変更、保存期間の変更などを“必ず差し戻し”に。
まとめ：コンプライアンスは後追いではなく運用で作る
変更管理（Change Management）は、スプリントのスピードを落とすための仕組みではありません。影響分類と受け入れ基準を整え、承認と証跡をスプリント内で完結させることで、リーガル要件をプロダクトの意思決定に組み込みます。
次の一手として、まずは影響分類の固定と、証跡の最小セットから始めてください。そこから先は、あなたのチームのスプリント運用に合わせて改善できます。