設計対象:

システム全体で統一的に使用するデータの命名規則、ID生成ルール、マスタコードの体系を定義する。

具体例:

• テーブル名、カラム名の命名規則（スネークケース、キャメルケースなど）
• 主キー・外部キーの命名パターン（例: エンティティ名_id）
• 画面表示用IDの形式（例: プレフィックス + 日付 + 連番）
• システム内部IDの生成方式（UUID、連番など）
• 日時項目の命名（例: created_at, updated_at）
• フラグ項目の命名（例: is_deleted, is_active）
• ステータス・区分値のコード体系（桁数、採番ルール、列挙型定義）

設計原則:

• 一貫性の確保: システム全体で統一された命名規則を適用し、開発者間の認識のずれを防ぐ
• 可読性の重視: 命名から役割が直感的に理解できるようにし、コメントなしでも意図が伝わるようにする
• 拡張性の考慮: 将来の機能追加時にも命名規則が破綻しないよう、柔軟性を持たせる
• 技術スタックとの整合: 使用するプログラミング言語やフレームワークの慣習に合わせた命名を採用する
• 国際化対応: 多言語対応が必要な場合は、言語に依存しないコード体系を設計する

文書化の推奨表現:

• 命名規則一覧表の作成: 項目種別（テーブル、カラム、ID等）ごとに命名パターンと具体例を表形式で整理する
• ID生成ルールの明文化: 各エンティティのID生成ロジック、桁数、プレフィックスを明記する
• コード体系定義書: マスタコードの種別ごとに、コード値、桁数、採番ルール、列挙型定義を一覧化する
• 命名の良い例・悪い例: 適切な命名と不適切な命名の具体例を示し、判断基準を明確にする

設計対象:

データの保持期間、退避（アーカイブ）、削除のルールを定義し、法令要件と運用要件を満たすライフサイクル管理方針を決定する。

具体例:

• 各データ種別（トランザクション、マスタ、ログ等）の保持期間
• オンライン保持期間とアーカイブ保持期間の区分
• 論理削除と物理削除の使い分け基準
• データ退避のタイミングと方式（定期バッチ、外部ストレージへの移動）
• 履歴管理の方式（SCD Type 1/2、履歴テーブル、ステータス履歴など）
• データ廃棄時の監査ログ保持期間

設計原則:

• 法令準拠: 個人情報保護法、業界固有の法規制（金融、医療等）に準拠した保持・削除ポリシーを設定する
• ストレージコスト最適化: 参照頻度の低いデータは低コストなストレージに退避し、運用コストを削減する
• 監査対応: 法定保存期間経過後も、削除実行ログを残し、監査時に証跡を提示できるようにする
• 運用負荷の軽減: 手動運用に依存せず、自動化されたバッチ処理で退避・削除を実行できるようにする
• 復元可能性の担保: アーカイブデータは必要時に復元できる形式・手順を整備する

文書化の推奨表現:

• データ保持期間一覧表: データ種別ごとにオンライン保持期間、アーカイブ期間、廃棄タイミングを表形式で整理する
• ライフサイクル図の作成: データの生成から廃棄までの流れを視覚的に表現する
• 削除ポリシーの明文化: 論理削除・物理削除の使い分け基準と実行タイミングを明記する
• 法令根拠の記載: 各保持期間の設定根拠となる法令・規制を明示する

設計対象:

データの正確性、完全性、一貫性を担保するための品質基準、バリデーション方針、品質監視の仕組みを定義する。

具体例:

• 入力バリデーションの実施箇所（画面、API、バッチ）と二重チェックの方針
• 必須項目、データ型、値域、桁数等の制約定義
• データ品質KPI（重複率、NULL発生率、整合性エラー件数等）の設定
• 品質監視の頻度とレポーティング方法（日次、週次等）
• データクレンジングのルールと実施タイミング
• 参照整合性制約の設定方針（外部キー制約、アプリケーション制御）

設計原則:

• 多層防御: 画面・API・データベース層それぞれでバリデーションを実施し、不正データの混入を防ぐ
• 早期検出: データ品質の劣化を早期に検知し、影響が拡大する前に対処できる仕組みを設ける
• 可視化と改善: 品質KPIを定期的に計測・レポートし、継続的な品質改善に繋げる
• 制約の明文化: データベーススキーマ定義やフィールド定義に制約を明記し、実装時の見落としを防ぐ
• 例外処理の明確化: バリデーションエラー時の処理（リトライ、エラー通知、ログ記録等）を明確にする

文書化の推奨表現:

• バリデーションルール一覧: 項目ごとに必須チェック、形式チェック、値域チェック等のルールを表形式で整理する
• 品質KPI定義書: 測定指標、算出方法、目標値、監視頻度を明記する
• 品質監視フローの図示: データ品質チェックの実施タイミングと異常検知時の対応フローを図示する

設計対象:

複数ユーザーやプロセスが同時にデータを更新する際の競合を防ぐための排他制御方式を定義する。

具体例:

• 楽観ロック（タイムスタンプ、バージョン番号による競合検知）の適用範囲
• 悲観ロック（行ロック、テーブルロック）の適用範囲
• トランザクション分離レベル（READ COMMITTED、REPEATABLE READ等）の設定
• ロックタイムアウトとデッドロック時の対応方針
• 分散トランザクション時の一貫性担保方式（2フェーズコミット、Sagaパターン等）

設計原則:

• 性能とのバランス: 過度な排他制御は性能低下を招くため、業務特性に応じて楽観ロック・悲観ロックを使い分ける
• デッドロック回避: ロック取得順序を統一し、デッドロックの発生を予防する
• ユーザー体験の考慮: 楽観ロック使用時は、競合発生時にユーザーフレンドリーなエラーメッセージを表示する
• 重要トランザクションの保護: 金額計算、在庫更新等の重要なトランザクションには確実な排他制御を適用する

文書化の推奨表現:

• 排他制御方式一覧: エンティティ・処理ごとに採用する排他制御方式を表形式で整理する
• トランザクション境界の明示: どの処理単位でトランザクションを開始・コミットするかを明記する
• 競合時の処理フロー: 楽観ロック競合時、デッドロック発生時の処理フローを図示する

設計対象:

データの機密レベルに応じたアクセス制御、閲覧・更新・削除の権限管理、個人情報等の機密データ保護方針を定義する。

具体例:

• 採用する権限モデル（RBAC、ABAC等）
• ロール定義と各ロールに付与する権限（閲覧、更新、削除、エクスポート等）
• 個人情報等の機密データのマスキング・暗号化方針
• APIアクセス時のスコープ・権限チェックの実装方針
• データエクスポート時の制約（暗号化、ログ記録、承認フロー等）
• 操作ログ（誰が・いつ・何を操作したか）の記録方針

設計原則:

• 最小権限の原則: ユーザーには必要最小限の権限のみを付与し、過剰な権限付与を避ける
• 職務分掌: 重要データの更新・削除には承認フローを設け、単独での操作を制限する
• 監査証跡の保持: 全ての重要操作をログに記録し、不正アクセスや誤操作の追跡を可能にする
• 法令準拠: 個人情報保護法等に準拠し、本人同意なしの閲覧・提供を防ぐ仕組みを設ける
• セキュリティ多層化: 認証・認可・暗号化・マスキング等を組み合わせ、多層的にデータを保護する

文書化の推奨表現:

• ロール・権限マトリクス: ロールごとに各データ・機能へのアクセス権限を表形式で整理する
• 機密データ一覧: 個人情報等の機密データを列挙し、保護方式（マスキング、暗号化等）を明記する
• アクセス制御フロー図: 認証・認可の流れ、権限チェックのタイミングを図示する
• 操作ログ項目定義: ログに記録する項目（ユーザーID、操作種別、対象データ、タイムスタンプ等）を明記する

設計対象:

複数システム間でのデータ連携時の同期方式、マスタデータの一元管理方針、データ競合時の解決ルールを定義する。

具体例:

• マスタデータの管理主体（どのシステムがマスタを保持するか）
• データ同期の方式（リアルタイム同期、バッチ同期）とタイミング
• データ競合時の解決ルール（タイムスタンプ新旧比較、システム優先順位等）
• データ連携時のフォーマット・プロトコル（JSON、XML、CSV等）
• データ変換ルール（システム間のコード変換、項目マッピング）
• 連携エラー時のリトライ・エラー通知方針

設計原則:

• マスタの一元化: マスタデータは原則として単一システムで管理し、他システムは参照・同期する構成とする
• 競合解決ルールの明確化: データ競合が発生した場合の解決ルールを事前に合意し、文書化する
• 冪等性の確保: 連携処理が複数回実行されても結果が変わらないように設計し、リトライ時の副作用を防ぐ
• エラーハンドリングの徹底: 連携エラー時には確実にログに記録し、運用チームが対処できるようにする
• データ整合性の監視: 定期的にシステム間のデータ整合性をチェックし、不整合を早期検知する

文書化の推奨表現:

• システム連携図: データ連携の対象システム、連携方向、同期頻度を図示する
• マスタ管理一覧: マスタデータごとに管理主体システムと連携先システムを表形式で整理する
• 競合解決ルール定義書: データ競合パターンごとに解決ルール（優先システム、新旧比較等）を明記する
• データ変換マッピング表: システム間のコード変換ルール、項目マッピングを表形式で定義する