前回との接続——画面の次は、その裏のデータ
前回のN-02では、1画面ごとに目的や表示情報など6項目を決める、画面設計書の書き方を学びました。画面の裏側では、そこで表示したり入力したりしたデータが、必ずどこかに保存されています。この講義では、そのデータをどう保存するかを、設計書として1枚にまとめる方法を扱います。N-01で挙げた設計の6決定事項のうち、4つ目のデータを深掘りする回にあたります。
このスライドのポイント
- N-02では、1画面ごとに6項目を決める画面設計書の書き方を学んだ
- 画面の裏側では、そこで表示・入力されたデータが保存されている
- この講義の役割: そのデータをどう保存するかを、設計書として1枚にまとめる
- N-01で挙げた設計の6決定事項のうち、④データを深掘りする回
データ設計の定義——決めるべき6項目
データ設計とは、データの保存方法を6つの項目で決める活動です。最初の4項目はL章の復習です。保存対象は何をひとまとまりのテーブルにするか、属性はその列と型、関係はテーブル同士の紐づけ、制約は許さない値の線引きでした。残る2項目が新しい論点です。履歴とは、変更の記録を残すかどうか、つまり誰がいつ何を変えたかを残すかの判断です。削除方針とは、データを消す方式のことで、行そのものを消す物理削除と、削除フラグを立てて消えたことにする論理削除の2つがあります。
このスライドのポイント
- データ設計 = データの保存方法を6項目で決める活動
- 保存対象（何のテーブルか=L-03）・属性（列と型=L-03）・関係（テーブル間の紐づけ=L-04/05）・制約（許さない値の線引き=L-09）
- 履歴 = 変更の記録を残すかどうか（誰がいつ何を変えたか）
- 削除方針 = データを消す方式。物理削除は行そのものを消す／論理削除は削除フラグで消えたことにする
- 前半4項目はL章の復習、後半の履歴と削除方針がL章になかった新しい論点
なぜ必要か——業務アプリは「説明責任」を求められる
なぜこの2項目が肝なのでしょうか。履歴を設計しないと、誰がいつ承認したかが記録に残らず、後から確認できません。削除方針を決めずに行をそのまま消していると、消した申請を監査で求められたときに、もう取り出せなくなります。業務アプリはお金や承認、個人情報を扱うため、説明責任という固有の要求を負っています。ただ動くだけでは足りず、後から辿れることまで設計に織り込む必要があるのです。ここを見落とすと、動いているのに監査で詰む、という事態を招きます。
このスライドのポイント
- 履歴を設計しないと「誰がいつ承認したか」が残らず、後から確認できない
- 削除方針を決めないと、消した申請を監査で求められたときに取り出せない
- 業務アプリはお金・承認・個人情報を扱うため、説明責任という固有の要求がある
- 動くだけでは足りず、「後から辿れること」まで設計に織り込む必要がある
構造——6項目の設計書テンプレートと判断基準
データ設計書は、6項目を上から順に埋めるテンプレートとして持っておきます。前半4項目はL章の観点で埋められます。判断が要るのは後半2項目です。判断基準はシンプルで、お金・承認・個人情報が絡むデータなら、履歴を残し、削除は論理削除を基本にします。逆に、絡まない一時的なデータなら、履歴を省略し、物理削除でもかまいません。これは、A-09で学んだ「戻せない変更を避ける」という考え方を、データの保存方法という設計に当てはめた形です。
このスライドのポイント
- データ設計書は6項目を上から埋めるテンプレートとして持つ
- 履歴と削除方針には判断基準がある
具体例——経費データの設計判断
経費データで具体的に考えてみます。まず、申請の変更履歴を残したいので、変更の記録を残す別のテーブル、ここでは expense_histories と呼ぶものを追加します。次に削除方針です。行をそのまま消すのではなく、論理削除にします。具体的には、削除した日時を記録する deleted_at という列を持たせ、そこに日時が入っていれば消えたものとして扱います。こうしておけば、監査、つまり誰が何をしたかの記録を求められたときに、消した申請でも取り出して説明できます。お金と承認が絡む経費データだからこその判断です。
このスライドのポイント
- 申請の変更履歴を残すため、変更の記録を別テーブル expense_histories として追加する
- 削除は論理削除にし、削除した日時を記録する deleted_at 列で「消えたことにする」
- こうすると、監査（誰が何をしたかの記録）で「消した申請」も取り出して説明できる
- お金と承認が絡む経費データだからこそ、履歴あり・論理削除を選ぶ
技術サンプルカード——経費データ設計書の記入例
データ設計書は、6項目に根拠の列を足した表で書くと扱いやすくなります。経費データの例では、保存対象や属性、関係、制約を、L章の観点で上から埋めます。要になるのは下の2行です。履歴は変更を別テーブルに記録し、削除方針は論理削除を選び、それぞれ根拠まで書きます。AIにDB設計を頼んだあとは「このデータ設計に、履歴と削除方針の観点は含まれていますか。監査で誰がいつ何を変えたかを出せますか」と確認しましょう。
このスライドのポイント
- 種別: table
- 目的: 経費データの設計を6項目＋根拠で書き、履歴と削除方針の抜けを防ぐ
混同しやすい概念——物理削除と論理削除の使い分け
混同しやすいのが、物理削除と論理削除です。物理削除は行そのものが消え、元に戻せません。これはA-09で学んだ、戻せない高リスクな変更にあたります。論理削除は削除フラグを立てて消えたことにするだけなので、後から戻せますが、データ量はそのまま残ります。使い分けの原則はこうです。お金や承認が絡む業務データは、後から辿れる論理削除を基本にします。ただし、個人情報の完全な削除を求められた場合は、本当に消す物理削除が必要になります。どちらか一方が正解ではなく、状況に応じて選び分けること自体が、データ設計の判断なのです。
バイブコーディングでの確認点——履歴と削除をAIに問う
確認点です。AIが作ったデータベース設計には、履歴と削除方針が抜けやすい傾向があります。特に指定がないと、AIは最も単純な、行をそのまま消す物理削除で作りがちです。ですから、生成された設計に対して2つを必ず確認します。1つは「履歴はどう残りますか」、もう1つは「削除は物理と論理のどちらですか。その根拠は」です。迷うときは「この経費アプリのデータ設計で、変更履歴の残し方と削除方式を、根拠つきで説明してください」と頼むとよいでしょう。
このスライドのポイント
- AIが作ったDB設計には、履歴と削除方針が抜けやすい（指定がないと最も単純な物理削除になりがち）
- 生成された設計に対し「履歴はどう残りますか」を必ず確認する
- 「削除は物理と論理のどちらですか。その根拠は」を必ず確認する
- AIへの質問例: 「この経費アプリのデータ設計で、変更履歴の残し方と削除方式を、根拠つきで説明してください」
一問一答とまとめ
最後に一問一答です。削除フラグを立てて、消えたことにする方式を何と呼ぶでしょうか。少し考えてみてください。答えは、論理削除です。30秒のまとめです。データ設計は、保存対象から削除方針までの6項目で決めます。とりわけ履歴と削除方針を織り込むことで、誰がいつ何をしたかを後から辿れる、業務アプリの説明責任に応える設計になります。次回のN-04では、部品同士の接続の設計書、すなわちAPI設計へ進みます。関連資料は「業務アプリDB設計パターン50」「監査ログと変更履歴入門」「DB設計チェックリスト50」です。
このスライドのポイント
- 一問一答: 削除フラグを立てて消えたことにする方式は何か
- 答え: 論理削除
- 30秒まとめ: データ設計は6項目で決める。履歴と削除方針を織り込むと、業務アプリの説明責任に応えられる
- 次回N-04: 部品同士の接続の設計書＝API設計へ
- 関連資料: 「業務アプリDB設計パターン50」「監査ログと変更履歴入門」「DB設計チェックリスト50」
