CRUDマトリクス(CRUD Matrix)
1. 概要
A. 定義
情報システムのプロセス(機能)とエンティティ(データ)の間の生成(Create)・参照(Read)・更新(Update)・削除(Delete)の関係を行列で交差表現し、データモデルとプロセスモデルの整合性を点検する相関分析(Correlation Analysis)ツールである。
CRUDマトリクスは単なる一枚の表ではなく、異なる二つの設計視点を強制的に一つの平面上に重ねて見せる検証装置である。データ観点(何を保存するか)と機能観点(何を処理するか)は開発初期にはそれぞれ自然に見えても、いざ噛み合って動く段になって初めて食い違いが露呈する。CRUDマトリクスは、この食い違いをコードが書かれる前、分析・設計段階であらかじめ露出させる点に価値がある。
B. 登場背景および必要性
情報工学(IE, Information Engineering)方法論において、データモデル(ERD)とプロセスモデル(DFD・機能分解図)は別々の成果物であり、しばしば異なる担当者が独立して作成する。問題は、二つの成果物が論理的には必ず噛み合わねばならない点にある。あるエンティティに値を入れてくれるプロセスが一つもなければそのデータは永遠に空のまま残り(生成漏れ)、逆にあるプロセスが存在しないデータを参照するよう設計されていれば実行自体が不可能である(参照整合性の崩壊)。
このようなデータと機能の間の整合性の穴は、文書をいくら精読しても人間の目では見落としやすい。エンティティが数十個、プロセスが数百個に増えると組み合わせの数が爆発するからである。CRUDマトリクスは、この関係を行列という一目で見える格子形態に強制整列させることで、漏れ(空セル)・重複(過多表記)・孤立(全部空の行/列)を視覚的に露出させる。さらに、一度作成されたマトリクスは検証で終わらず、トランザクション境界設定、DB分散設計、アクセス権限(RBAC)設計、アーカイビング・保存方針の共通入力資料として再活用される点で、分析成果物の中でも再利用性が高い。
C. 特徴
CRUDマトリクスの特徴は三点に要約される。第一に、対称的検証である。データ側(エンティティがライフサイクルを完全に持つか)と機能側(プロセスが実データを扱うか)を同時に点検する。第二に、静的成果物でありながら動的含意を持つ。表自体は静的だが、複数のプロセスが同じエンティティにUを行うという事実は、そのまま同時性・ロック設計というランタイムの課題につながる。第三に、方法論中立的である。情報工学から出発したが、オブジェクト指向・マイクロサービス設計でもアクセスパターン分析ツールとしてそのまま応用される。
2. CRUDマトリクスの全体構造と位置づけ
CRUDマトリクスがどこから入力を受けてどこへ出力を送り出すかをまず理解すれば、なぜこのツールが分析段階の「ハブ」と呼ばれるかが明確になる。以下の構造図は、データモデルとプロセスモデルがCRUDマトリクスへ収束した後、再び複数の設計活動へ発散する流れを表す。
flowchart LR
ERD["データモデル(ERD・エンティティ)"] --> CM["CRUDマトリクス"]
DFD["プロセスモデル(DFD・機能)"] --> CM
CM --> V["整合性検証(漏れ・孤立・虚数)"]
CM --> TX["トランザクション境界設計"]
CM --> DIST["DB分散・分割設計"]
CM --> AUTH["アクセス権限(RBAC)設計"]
CM --> ARC["アーカイビング・保存方針"]
構造図で見るように、CRUDマトリクスの入力は二つの異なるモデルであり、出力は五つの後続設計活動である。ここで核心は、二つの入力が「独立して作られた」という事実である。もし一つの統合モデルから自動生成されたなら整合性検証の意味がない。異なる視点から独立して作った二つのモデルを事後に重ねて見るからこそ、人が意識できなかった不一致が表面化するのである。
行列の座標系も明確な規則に従う。慣例的に行にはプロセス(機能)、列にはエンティティ(データ)を配置する。こうすれば、一つの行を横に読んだとき「このプロセスがどのデータをどう扱うか」というトランザクションのデータアクセス範囲が現れ、一つの列を縦に読んだとき「このデータが誰によってどう扱われるか」というデータのライフサイクルが現れる。横読みは機能設計に、縦読みはデータガバナンスにそれぞれ対応する。
3. 表現方法と作成手順
各交差セルには、そのプロセスが当該エンティティに行う操作をC/R/U/Dで表記し、一つのプロセスが複数の操作を行えば併記する。例えば「注文取消」は注文を更新し最終的に削除するのでUDと表記する。以下のショッピングモール例で「注文登録」行を横に読むと、この機能が会員・商品を参照(R)し注文を生成(C)する複合トランザクションであることが一行にそのまま現れる。
| プロセス \ エンティティ | 会員 | 注文 | 商品 |
|---|---|---|---|
| 会員登録 | C | ||
| 商品参照 | R | ||
| 注文登録 | R | C | R |
| 注文取消 | UD |
作成はやみくもにセルを埋めるのではなく、定められた手順に従う。以下の手順図は、エンティティ・プロセス導出から検証・再活用までの流れを表す。
flowchart TD
A["1. エンティティ一覧の導出(ERD基盤)"] --> B["2. プロセス一覧の導出(機能分解基盤)"]
B --> C["3. 行列枠の構成(行=プロセス、列=エンティティ)"]
C --> D["4. 各セルにC/R/U/Dを表記"]
D --> E["5. 行・列の整合性検証"]
E --> F{"漏れ・孤立・虚数が存在?"}
F -->|"はい"| G["モデル補完後に再作成"]
G --> D
F -->|"いいえ"| H["後続設計へ再活用"]
第一段階であるエンティティ・プロセスの導出は、マトリクス品質の8割を左右する。エンティティ一覧は正規化されたERDから、プロセス一覧は機能分解図の最下位(原子)プロセスから取るのが原則である。このとき、エンティティ定義水準(概念/論理/物理)とプロセス定義水準(大機能/単位業務)の粒度(granularity)を一致させなければ、マトリクスが過度に粗くなるか、逆に過密になり検証が無意味になる。実務では論理エンティティと単位プロセス(一つの画面・APIに対応)水準に合わせる場合が多い。
第二に、セル表記段階では「何をRと見るか」に関するチーム内の合意が必要である。例えば外部キー検証のための存在確認参照をRと表記するか、画面表示用の参照のみをRと見るかによってマトリクスの密度が変わる。この規則が不明確なら、同じシステムを二人が描いても互いに異なるマトリクスが出る。
第三に、検証と反復である。検証で欠陥が発見されたら、マトリクスだけを直すのではなく元のモデル(ERD・DFD)へ戻って補完するのが核心である。マトリクスは欠陥の兆候を見せるだけで、本当の問題はデータモデルやプロセスモデルにあるからである。このフィードバックループがCRUDマトリクスを単なる文書ではなく検証プロセスにする。
4. 整合性検証規則
検証の核心は「すべてのエンティティがライフサイクル全体を持つか」と「すべてのプロセスが実データを扱うか」を対称的に確認することである。各規則には違反時に疑うべき具体的欠陥が対応する。
各エンティティ列には最低一つのCがなければならない。生成プロセスがないエンティティはデータが流入する経路がないので、バッチ積載・外部連携のような別途の流入経路が明示されていなければ明白な設計漏れである。先の例で商品列にCがないという事実は、すなわち「商品登録」プロセスが漏れていることを教えてくれる。
各エンティティ列には最低一つのRがなければならない。誰も参照しないデータは保存する理由のない不要データである可能性が高い。ただしログ・監査データのように「今は読まなくても後のために貯める」場合があるので、Rがないからと直ちに削除決定を下すより、保存目的を再確認する検討シグナルとする。
U/Dの有無は管理プロセスの必要性を点検する。Uがまったくないエンティティは不変(immutable)データかもしれず、Dがないエンティティは物理削除なく状態フラグのみで管理(論理削除)する方針かもしれない。すなわちU/Dの不在は欠陥ではなく、方針的選択か漏れかを区別させる問いである。
すべての行・列は最低一つの表記を持たねばならない。表記がまったくない列はどの機能も使わない孤立エンティティ、表記がまったくない行はデータに触れない空(虚数)プロセスで、いずれも誤り候補である。孤立エンティティは過設計あるいはプロセス漏れを、虚数プロセスは実際には動作しない殻の機能を疑わせる。
| 点検規則 | 意味 | 違反時に疑う事項 |
|---|---|---|
| 各エンティティにC存在 | データ流入経路の確保 | 生成プロセスの漏れ |
| 各エンティティにR存在 | データ活用可否の確認 | 不要データまたは保存目的の再検討 |
| U/Dの存在可否 | 状態変更・削除方針の確認 | 管理プロセスの漏れ vs 不変/論理削除方針 |
| すべての行・列に最低1個 | 孤立・虚数の防止 | 孤立エンティティ・空(虚数)プロセス |
5. 活用分野と実際の事例
CRUDマトリクスは整合性検証にとどまらず、後続設計の入力として広く使われる。トランザクション分析では、一つの行(プロセス)が複数のエンティティにわたってC/U/Dを行えば、その範囲が一つの論理的作業単位、すなわちトランザクション境界となる。例えば「注文登録」行が注文Cと在庫Uを共に含むなら、これらは原子的にコミットされねばならないので、一つのトランザクションにまとめるべきという設計根拠が表からそのまま出る。
同時性制御設計の根拠も列から読める。特定のエンティティ列に複数のプロセスのUが集中していれば、そのデータは競合(contention)の高いホットスポットなので、ロック戦略・楽観的同時性制御の可否を決めねばならない。実務で在庫・残高のようにUが集中するエンティティが代表的事例で、この点を見逃すと運用中に更新喪失(lost update)やデッドロックが発生する。
DB分散・分割設計では、アクセスパターンの局所性が核心の手掛かりである。特定のエンティティ群を特定のプロセス群のみがアクセスするなら、その境界に沿ってDBを分割(シャーディング・パーティショニング)したときトラフィック局所性が高まり性能が改善する。逆に複数のプロセスが複数のエンティティに広範にわたっていれば、分割時に分散トランザクションのコストが大きくなるので慎重を要する。アクセス権限設計では、ロール(Role)別にどのエンティティにどのCRUD権限を付与するかをこのマトリクスから出発してRBAC権限マトリクスへ拡張する。例えば「一般会員」ロールは注文にC/Rのみ、「管理者」ロールはU/Dまで持つようマッピングする具合である。
| 分野 | 活用方式 | 表から読む手掛かり |
|---|---|---|
| 業務・データ検証 | 要求-データ整合性の点検 | 空セル・孤立行・列 |
| トランザクション分析 | トランザクション境界・同時性設計 | 一行のC/U/D範囲、一列のU集中 |
| DB分散設計 | アクセスパターン基盤の分割・配置 | プロセス群-エンティティ群のアクセス局所性 |
| アクセス権限設計 | ロール別CRUD権限マトリクスの基礎 | ロール×エンティティ×操作のマッピング |
6. 類似技法との比較
CRUDマトリクスは他の相関分析ツールと目的が異なる。これを区別してこそ試験答案で混同なく叙述できる。エンティティ-機能相関表(E-F Matrix)はCRUDの区分なく単純な関係の有無のみを表記し導出段階で使われる一方、CRUDマトリクスは操作種別まで細分し整合性・トランザクション設計に使われる。DFDはデータの流れ(どこへ移動するか)に焦点を当てるが、CRUDマトリクスはデータに対する操作(何をするか)に焦点を当てる点で相互補完的である。
この違いが生じる理由は、各ツールが狙う設計上の問いが異なるからである。E-F Matrixは「関係があるか」という存在可否を、DFDは「どう流れるか」という移動経路を、CRUDマトリクスは「ライフサイクルが完結するか」という整合性を問う。したがって実務では三つのツールを排他的に選ぶのではなく、分析段階に応じて順次一緒に使う。導出初期にはE-F Matrixで大きな関係を捉え、詳細化段階でCRUDで操作を埋めて検証し、DFDで流れを確認する具合である。
7. 深化 — MSA時代のCRUDマトリクスと予想出題方向
CRUDマトリクスの現代的再解釈はマイクロサービスアーキテクチャ(MSA)で際立つ。モノリシックシステムでCRUDパターン分析がDB分割の根拠だったなら、MSAでは同じ分析がサービスが所有すべきデータ境界、すなわちバウンデッドコンテキスト(Bounded Context)を定義する根拠となる。「データを所有したサービスのみがそのデータを変更(C/U/D)する」というデータ所有権原則を守るには、どのプロセスがどのエンティティに書き込み(C/U/D)を行うかをまず把握せねばならない。CRUDマトリクスはまさにその書き込みパターンの地図なので、複数のサービスが一つのエンティティに書き込みを行うセルが発見されれば、それはサービス境界が誤って引かれたという警告シグナルである。
ここからCQRS・イベントソーシングとの連携も自然に導出される。参照(R)が複数のサービス・プロセスに広範にわたり書き込み(C/U/D)は少数に集中するなら、参照モデルと書き込みモデルを分離するCQRSが有利である。すなわちCRUDマトリクスのRとC/U/Dの分布自体がCQRS適用可否の判断根拠となる。最近はデータガバナンス観点でCRUDマトリクスをデータ系譜(Data Lineage)・個人情報処理台帳と連結し、「どの個人情報エンティティがどの機能によって収集(C)・利用(R)・訂正(U)・破棄(D)されるか」を究明するコンプライアンス根拠資料へ拡張する流れもある。
技術士試験の観点でこの主題は単独略述だけでなくデータモデリング・トランザクション・MSA設計問題の部分論拠として頻繁に活用される。答案構成時には、(1)定義と表現方法を例示マトリクスで提示し、(2)整合性検証規則の四つを違反事例と共に叙述した後、(3)トランザクション・分散・権限・MSAへつながる活用を段階的に拡張する展開が採点者に完結性を与える。特に「表のみを羅列」せず各規則に違反時の疑い事項を付けて叙述すれば弁別力が高い。
8. 考慮事項および示唆点
- 自動化・ツール化の必要: エンティティ・プロセスが数百個の大規模システムでは手作業管理が不可能である。CASEツール・メタデータリポジトリ基盤の自動生成を活用してモデル変更とマトリクスを同期し、モデルが変わればマトリクスが自動更新されるようにするのが整合性維持の要点である。
- 粒度一致と表記規則の標準化: エンティティとプロセスの定義水準を合わせ、「何をRと見るか」のような表記規則をチーム標準として明文化してこそ再現性あるマトリクスが出る。規則なしでは人ごとに異なる表が作られ、検証の信頼性が崩れる。
- データガバナンス・コンプライアンスの基礎成果物: データ所有権・品質・寿命周期管理の出発点であり、個人情報処理台帳・データ系譜管理と連結してGDPR・個人情報保護法対応の根拠資料として活用できる。
- MSA・CQRS設計への拡張: CRUDパターン分析はサービスのバウンデッドコンテキストと参照・書き込み分離(CQRS)可否を判断する根拠となる。ただしMSAでは一つの物理マトリクスではなくサービス別に所有データを分けて管理せねばならないので、全社統合マトリクスとサービス別マトリクスの階層的管理が必要である。
- 静的検証の限界の認識: CRUDマトリクスは設計時点の静的整合性のみを検証するだけで、実際のランタイムの負荷・競合・性能は保証しない。したがってU集中エンティティに対する負荷テスト、トランザクション隔離水準の検証など動的検証と必ず並行せねばならない。
一言まとめ: CRUDマトリクスはプロセスとエンティティの生成・参照・更新・削除の関係を行列で交差表現してデータと機能の整合性(漏れ・孤立・虚数)を対称的に検証し、トランザクション・同時性・分散・アクセス権限設計はもちろんMSAのバウンデッドコンテキストとCQRS判断根拠まで拡張される相関分析ツールである。