システム開発や業務改善の現場では、「このデータは誰が登録するのか」「誰が閲覧できるのか」「誰が修正してよいのか」「削除してよいデータなのか」といった確認が必要になります。
たとえば、顧客情報、商品情報、注文情報、請求情報、社員情報などは、業務の中で多くの人が使います。しかし、誰がどのデータをどのように扱うのかが曖昧なままだと、入力漏れ、二重管理、誤更新、不要な削除、権限設定ミスなどが起きやすくなります。
そこで役立つのが、CRUDマトリクスです。
CRUDマトリクスは、データに対して「作成する」「参照する」「更新する」「削除する」という操作を整理するためのフレームワークです。システム開発ではもちろん、業務設計、権限設計、データ管理、内部統制、DX推進でも役立ちます。
初心者はまず、「CRUDマトリクスは、どの機能や担当者が、どのデータに何をするのかを整理する表」と理解すれば十分です。
この記事でわかること
・CRUDマトリクスとは何か
・CRUDマトリクスは何に使うのか
・CRUDマトリクスの基本的な考え方
・CRUDマトリクスの使い方
・CRUDマトリクスの具体例
・関連フレームワークとの違い
最初から完璧に使いこなす必要はありません。まずは「CRUDマトリクスはデータ操作の抜け漏れを確認するための型だ」とつかめれば十分です。
CRUDマトリクスとは？
CRUDマトリクスとは、業務やシステムで扱うデータに対して、どの機能や担当者がどの操作を行うのかを整理するためのフレームワークです。
CRUDとは、次の4つの英単語の頭文字を取ったものです。
・Create：作成する、登録する
・Read：読む、参照する、閲覧する
・Update：更新する、修正する
・Delete：削除する
たとえば、顧客管理システムで「顧客情報」というデータがあるとします。この顧客情報に対して、営業担当者は新規登録できるのか、閲覧だけできるのか、修正できるのか、削除できるのかを整理します。
また、管理者はすべての操作ができるが、一般ユーザーは参照だけできる、といった権限の違いも整理できます。
初心者向けに言い換えると、CRUDマトリクスは「データに対する操作権限と役割を整理するためのチェック表」です。
システムでは、データを登録するだけでなく、見る、直す、消すという操作が発生します。この4つを整理しておかないと、必要な機能が抜けたり、逆に危険な操作を誰でもできる状態になったりします。
一言でいうと、CRUDマトリクスは、データに対する作成・参照・更新・削除の関係を整理するためのフレームワークです。
CRUDマトリクスは何に使うのか
CRUDマトリクスは、システム設計や業務設計で、データと操作の関係を明確にするために使います。
主な用途は次のとおりです。
・必要な機能の抜け漏れを確認する
・データに対する操作権限を整理する
・誰がどのデータを扱うのかを明確にする
・登録、参照、更新、削除の責任を整理する
・システムの画面や機能設計に活用する
・業務フローとデータ操作の関係を確認する
・内部統制や監査対応の観点を整理する
・誤更新や誤削除のリスクを減らす
・外部ベンダーに仕様を説明しやすくする
・既存システムの権限や機能を見直す
たとえば、社員情報を扱うシステムで、一般社員が自分の住所情報を更新できるのか、人事部だけが更新できるのか、上司は部下の情報を閲覧できるのか、といったルールを整理する場合に使えます。
また、請求情報のように重要なデータでは、誰でも削除できる状態は危険です。CRUDマトリクスを使えば、削除権限を管理者だけに限定する、削除ではなく無効化にする、といった設計判断もしやすくなります。
どんな人に向いているか
CRUDマトリクスは、次のような人に向いています。
・システム開発や要件定義に関わる人
・業務システムの導入を担当している人
・業務改善やDX推進を進めている人
・データ管理や権限設計を整理したい人
・外部ベンダーにシステム開発を依頼する人
・業務フローとデータ操作の関係を確認したい人
・内部統制や監査対応を意識している人
・既存システムの権限を見直したい人
・RPAや自動化の対象業務を整理したい人
・プロジェクトマネージャーや業務担当者
特に、業務部門とIT部門の橋渡しをする人に向いています。
業務部門は「この情報を見たい」「この情報を修正したい」と考えます。一方、IT部門は「誰にどこまで操作させるべきか」「データの整合性をどう守るか」「誤削除をどう防ぐか」を考える必要があります。
CRUDマトリクスを使うことで、業務上必要な操作と、システム上守るべき制御を整理しやすくなります。
CRUDマトリクスの基本的な考え方
CRUDマトリクスの基本は、データと操作の関係を整理することです。
縦軸に機能、業務、担当者、画面などを置き、横軸にデータを置いて、それぞれの交点にC、R、U、Dを記入します。
Create
Createは、データを新しく作成する操作です。
たとえば、次のような操作です。
・顧客情報を新規登録する
・商品情報を登録する
・注文データを作成する
・申請書を作成する
・社員情報を登録する
・問い合わせ履歴を登録する
Createは、データの入口になる操作です。誰がどのタイミングでデータを作るのかを明確にしておくことが重要です。
Read
Readは、データを参照する操作です。
たとえば、次のような操作です。
・顧客情報を見る
・在庫数を確認する
・注文履歴を閲覧する
・申請状況を確認する
・売上レポートを見る
・社員情報を検索する
Readは、業務上よく発生する操作です。ただし、閲覧権限にも注意が必要です。
すべての人がすべてのデータを見られる状態が適切とは限りません。個人情報、給与情報、契約情報、機密情報などは、参照できる人を制限する必要があります。
Update
Updateは、既存のデータを更新する操作です。
たとえば、次のような操作です。
・顧客の住所を変更する
・案件のステータスを更新する
・商品価格を変更する
・申請内容を修正する
・在庫数を更新する
・問い合わせ対応状況を変更する
Updateは、データの正確性に大きく関わります。
誰でも自由に更新できると、誤った情報に書き換わるリスクがあります。一方で、更新できる人が少なすぎると、業務が滞ることもあります。
そのため、業務上必要な更新権限と、データ保護のバランスを考えることが重要です。
Delete
Deleteは、データを削除する操作です。
たとえば、次のような操作です。
・誤って登録した顧客情報を削除する
・不要な下書き申請を削除する
・古い一時データを削除する
・重複した商品情報を削除する
Deleteは、CRUDの中でも特に慎重に扱うべき操作です。
一度削除すると復元が難しい場合があります。また、監査や法令対応のために、削除してはいけないデータもあります。
実務では、完全に削除するのではなく、「無効」「取消」「非表示」「論理削除」といった形で扱うことも多くあります。
CRUDマトリクスの使い方
手順1 対象となる業務やシステムを決める
まず、CRUDマトリクスで整理する対象を決めます。
対象範囲が広すぎると、表が大きくなりすぎて使いにくくなります。最初は、1つの業務や1つのシステムに絞るのがおすすめです。
たとえば、次のような単位で考えます。
・顧客管理システム
・営業案件管理
・社内申請ワークフロー
・研修申込管理
・在庫管理
・問い合わせ管理
・経費精算
・社員情報管理
・商品マスタ管理
対象を決めたら、その業務で扱う主要なデータを洗い出します。
手順2 扱うデータを洗い出す
次に、業務やシステムで扱うデータを洗い出します。
たとえば、営業案件管理なら次のようなデータがあります。
・顧客情報
・案件情報
・商談履歴
・見積情報
・担当者情報
・売上見込み
・受注情報
社内申請ワークフローなら、次のようなデータがあります。
・申請情報
・申請者情報
・承認ルート
・承認履歴
・添付ファイル
・差し戻しコメント
・通知履歴
ここで重要なのは、画面に表示される情報だけでなく、裏側で管理されるデータも考えることです。
たとえば、承認履歴や操作ログは、普段の業務では目立ちません。しかし、内部統制や監査の観点では重要です。
手順3 機能や担当者を洗い出す
次に、データを操作する機能や担当者を洗い出します。
縦軸に何を置くかは、目的によって変わります。
機能別に整理する場合は、次のようになります。
・顧客登録
・案件登録
・商談入力
・見積作成
・受注登録
・レポート出力
・管理者設定
担当者別に整理する場合は、次のようになります。
・営業担当者
・営業マネージャー
・営業企画
・経理担当者
・システム管理者
・閲覧専用ユーザー
画面別に整理する場合は、次のようになります。
・顧客一覧画面
・顧客詳細画面
・案件登録画面
・見積作成画面
・管理画面
・レポート画面
初心者は、まず担当者別または機能別に整理すると理解しやすいです。
手順4 C、R、U、Dを記入する
データと機能、またはデータと担当者の組み合わせごとに、Create、Read、Update、Deleteを記入します。
たとえば、営業担当者と顧客情報の関係なら、次のように考えます。
・営業担当者は顧客情報を新規登録できるか
・営業担当者は顧客情報を閲覧できるか
・営業担当者は顧客情報を更新できるか
・営業担当者は顧客情報を削除できるか
すべてにC、R、U、Dが入るわけではありません。
むしろ、重要なのは「できる操作」と「できない操作」を明確にすることです。
たとえば、営業担当者は顧客情報を登録、参照、更新できるが、削除はできない。システム管理者は削除できるが、削除には承認が必要、といったルールを整理します。
手順5 抜け漏れや過剰権限を確認する
CRUDを記入したら、抜け漏れや過剰な権限がないかを確認します。
確認する観点は次のとおりです。
・誰も作成できないデータがないか
・誰も更新できないデータがないか
・誰でも削除できる危険なデータがないか
・参照権限が広すぎないか
・個人情報や機密情報の閲覧範囲は適切か
・業務上必要な操作が抜けていないか
・同じデータを複数部署が別々に更新していないか
・削除ではなく無効化でよいデータはないか
・承認履歴や操作ログが必要ではないか
CRUDマトリクスは、作成した後の確認が重要です。
表にすることで、「このデータは誰も更新できない」「この担当者に削除権限を与えるのは危険」「閲覧だけでよいのに更新できるようになっている」といった問題が見えてきます。
手順6 業務ルールや権限設計に反映する
最後に、CRUDマトリクスで整理した内容を、業務ルールやシステム設計に反映します。
たとえば、次のような設計につなげます。
・画面ごとのボタン表示
・ユーザー権限の設定
・承認ルートの設定
・データ更新ルール
・削除権限の制限
・操作ログの記録
・エラー時の対応
・管理者機能の設計
CRUDマトリクスは、単なる整理表ではありません。実際の画面設計、権限設計、データ管理、運用ルールにつなげて使うことが大切です。
CRUDマトリクスの具体例
例 営業案件管理システムの場合
営業案件管理システムを例に考えてみます。
このシステムでは、営業担当者が顧客情報や案件情報を登録し、商談履歴を入力します。営業マネージャーはチーム全体の案件状況を確認し、売上見込みを管理します。システム管理者はユーザーや権限を管理します。
主なデータは次のとおりです。
・顧客情報
・案件情報
・商談履歴
・見積情報
・売上見込み
・担当者情報
担当者は次のように考えます。
・営業担当者
・営業マネージャー
・営業企画
・経理担当者
・システム管理者
この場合、CRUDマトリクスでは次のような整理ができます。
営業担当者は、顧客情報を登録、参照、更新できます。ただし、削除はできないようにします。案件情報も登録、参照、更新できますが、削除は管理者だけにします。商談履歴は営業担当者が登録し、必要に応じて更新できます。
営業マネージャーは、部下の案件情報や売上見込みを参照できます。また、案件の重要度や受注確度を更新できるようにする場合もあります。
営業企画は、全体の案件データや売上見込みを参照できますが、個別の商談履歴を更新する必要はないかもしれません。
経理担当者は、受注後の請求に必要な情報を参照しますが、営業活動の商談履歴を更新する必要はありません。
システム管理者は、担当者情報や権限設定を作成、参照、更新できます。ただし、業務データそのものを自由に削除できるかどうかは慎重に決める必要があります。
このように整理すると、誰にどの操作を許可すべきかが見えやすくなります。
別の例 社内申請ワークフローの場合
次に、社内申請ワークフローを例に考えます。
社員が備品購入や出張申請を行い、上司や部門長が承認し、総務や経理が確認する業務です。
主なデータは次のとおりです。
・申請情報
・申請者情報
・承認ルート
・承認履歴
・添付ファイル
・差し戻しコメント
・通知履歴
担当者は次のように考えます。
・申請者
・承認者
・部門長
・総務担当者
・経理担当者
・システム管理者
申請者は、自分の申請情報を作成できます。下書き状態であれば更新や削除もできるようにします。しかし、承認後の申請情報を自由に更新できると問題になるため、承認後は修正不可にするか、変更申請を必要とします。
承認者は、申請情報を参照し、承認結果や差し戻しコメントを更新します。ただし、申請者が入力した内容を直接書き換えるべきではありません。
総務担当者は、承認済みの申請情報を参照し、必要な処理状況を更新します。経理担当者は、支払や精算に必要な情報を参照し、処理済みステータスを更新します。
承認履歴は、監査上重要なデータです。そのため、基本的には作成と参照はできますが、更新や削除は制限すべきです。
通知履歴も、後から確認する必要がある場合があります。削除できるようにするかどうかは、運用ルールに応じて決めます。
このようにCRUDマトリクスで整理すると、業務上の責任とシステム上の操作権限を合わせやすくなります。
具体例でわかるポイント
具体例から学べるポイントは次のとおりです。
・同じデータでも担当者によって操作範囲は異なる
・参照できることと更新できることは分けて考える
・削除権限は慎重に設定する必要がある
・承認履歴や操作ログは削除不可にすることが多い
・業務状態によって操作可否が変わる場合がある
・CRUD整理は権限設計や画面設計につながる
・業務部門とIT部門の認識合わせに役立つ
CRUDマトリクスは、データに対する責任と操作範囲を明確にするための実務的な道具です。
CRUDマトリクスを使うメリット
CRUDマトリクスを使うメリットは、データ操作の抜け漏れや権限の不整合を見つけやすくなることです。
主なメリットは次のとおりです。
・必要な機能の抜け漏れを発見できる
・誰がどのデータを操作するか明確になる
・参照権限と更新権限を分けて考えられる
・削除権限のリスクを確認できる
・画面設計や権限設計に活用できる
・内部統制や監査対応に役立つ
・外部ベンダーに仕様を説明しやすい
・業務フローとデータ操作の関係を整理できる
・誤更新や誤削除のリスクを減らせる
・システム改修時の影響範囲を確認しやすい
特に大きなメリットは、「なんとなく使える」状態を避けられることです。
システムでは、使いやすさも大切ですが、誰でも何でもできる状態は危険です。重要なデータを誰でも更新できる、過去の履歴を削除できる、個人情報を誰でも閲覧できるといった状態は、業務リスクにつながります。
CRUDマトリクスを使うことで、必要な操作と制限すべき操作を分けて考えられます。
CRUDマトリクスを使うときの注意点
CRUDマトリクスは便利ですが、使い方を間違えると、形式的な表になってしまいます。
よくある失敗例は次のとおりです。
・データの洗い出しが不十分なまま作る
・業務フローを確認せずに操作権限を決める
・すべての担当者に広い権限を与えてしまう
・削除権限を安易に設定する
・参照権限と更新権限を混同する
・承認後や確定後の操作制限を考えていない
・操作ログや履歴データを見落とす
・個人情報や機密情報の閲覧制限を考えていない
・状態によって変わる操作可否を整理していない
・作った表をシステム設計に反映しない
特に注意したいのは、削除権限です。
実務では、データを物理的に削除してしまうと、後から確認できなくなることがあります。注文履歴、承認履歴、請求データ、契約情報などは、削除よりも取消、無効、非表示といった扱いにしたほうがよい場合があります。
また、CRUDマトリクスだけで業務全体を理解できるわけではありません。業務の流れはBPMNや業務フローで確認し、データの流れはDFDで確認し、そのうえでCRUDマトリクスを使うと効果的です。
関連フレームワークとの違い
CRUDマトリクスと関連するフレームワークには、DFD、ER図、要件定義フレーム、UML、BPMNなどがあります。それぞれ目的が異なります。
DFDとの違い
DFDは、データがどこから来て、どこで処理され、どこへ出ていくのかを整理する図です。
CRUDマトリクスは、各データに対して作成、参照、更新、削除のどの操作が必要かを整理する表です。
DFDが「データの流れ」を見るものだとすれば、CRUDマトリクスは「データに対する操作」を見るものです。
DFDでデータの流れを整理した後に、CRUDマトリクスで操作の抜け漏れを確認すると効果的です。
ER図との違い
ER図は、データベースの構造を整理するための図です。
顧客、注文、商品、請求といったデータ同士の関係を整理します。
CRUDマトリクスは、そのデータに対して誰が何をできるのかを整理します。
ER図が「データ同士の関係」を表すものだとすれば、CRUDマトリクスは「データをどう操作するか」を表すものです。
要件定義フレームとの違い
要件定義フレームは、業務要件、機能要件、非機能要件を整理するための考え方です。
CRUDマトリクスは、要件定義の中でも、データ操作や権限設計を具体化する場面で役立ちます。
たとえば、要件定義で「顧客情報を管理する」という機能要件が出た場合、CRUDマトリクスを使うと、誰が顧客情報を登録し、誰が参照し、誰が更新し、誰が削除できるのかを明確にできます。
UMLとの違い
UMLは、システムの構造や動きを図で表現するための記法です。
ユースケース図では利用者と機能の関係を整理できます。クラス図ではデータや概念の関係を整理できます。シーケンス図では処理の流れを整理できます。
CRUDマトリクスは、UMLで整理した機能やデータに対して、操作の有無を確認する補助的な道具として使えます。
UMLがシステムを多面的に表現する図だとすれば、CRUDマトリクスは操作権限とデータ管理を確認する表です。
BPMNとの違い
BPMNは、業務プロセスの流れを可視化するための記法です。
BPMNでは、誰がどの順番で何をするかを整理します。CRUDマトリクスでは、その業務の中で扱うデータに対して、どの操作が発生するかを整理します。
たとえば、BPMNで申請業務の流れを描き、その後にCRUDマトリクスで申請情報、承認履歴、添付ファイルの操作権限を整理すると、業務とシステム設計がつながりやすくなります。
CRUDマトリクスはどんな場面で使うと効果的か
CRUDマトリクスは、次のような場面で使うと効果的です。
・業務システムの要件定義を行うとき
・画面や機能の抜け漏れを確認するとき
・ユーザー権限を設計するとき
・データベース設計の前提を整理するとき
・既存システムの権限を見直すとき
・内部統制や監査対応を考えるとき
・個人情報や機密情報の取扱いを整理するとき
・外部ベンダーに仕様を説明するとき
・システム改修の影響範囲を確認するとき
・業務フローとデータ操作の関係を確認するとき
特に、複数の担当者や部門が同じデータを扱う業務で効果的です。
たとえば、顧客情報を営業、サポート、経理、管理部門がそれぞれ使う場合、誰が更新してよいのかを決めておかないと、データの整合性が崩れます。
CRUDマトリクスを使うことで、データの責任者、利用者、更新者、管理者を明確にできます。
まとめ
CRUDマトリクスとは、データに対する作成、参照、更新、削除の操作を整理するためのフレームワークです。
CRUDは、Create、Read、Update、Deleteの頭文字です。システムや業務で扱うデータに対して、誰がどの操作を行うのかを明確にできます。
CRUDマトリクスを使うと、必要な機能の抜け漏れ、過剰な権限、誤更新や誤削除のリスク、個人情報や機密情報の閲覧範囲などを確認しやすくなります。
特に、業務システムの要件定義、権限設計、画面設計、データ管理、内部統制の場面で役立ちます。
ただし、CRUDマトリクスだけで業務全体を把握できるわけではありません。業務の流れはBPMN、データの流れはDFD、データ構造はER図と組み合わせると、より実務的な設計になります。
まずは、自分の業務で扱っている主要なデータを1つ選び、「誰が作成し、誰が見て、誰が更新し、誰が削除できるのか」を書き出すところから始めてみましょう。
次に読みたい関連記事
まず全体像を見たい方へ
仕事で使えるフレームワーク一覧｜初心者向けに意味・種類・使い方をわかりやすく解説
あわせて読みたい関連記事
DFDとは？初心者向けに意味・使い方・具体例をやさしく解説
ER図とは？初心者向けに意味・使い方・具体例をやさしく解説
要件定義フレームとは？初心者向けに意味・使い方・具体例をやさしく解説
目的別にまとめて読みたい方へ
IT・システム・業務設計で使うフレームワークまとめ｜初心者向けに種類・使い方・選び方をわかりやすく解説
