CRUD Style UI
業務システムの画面を、テーブルのカラムをそのまま入出力フォームに並べる形で作る設計。一覧・検索・登録・編集・削除を1セットの画面群として揃え、ユーザの業務フローではなく、データ構造のCRUDをそのまま画面化したもの。日本のSIer現場では「画面駆動設計」とも呼ばれるが、根は同じで、テーブル定義が先にあって画面はその入出力フォームになる。
ユーザが何をしに来たか(申請を出す、状況を確認する、上長承認を待つ、月次で締める)という行動軸ではなく、「商品マスタ画面」「受注一覧画面」「承認待ち一覧画面」のようにテーブル軸で画面が並ぶ。例えば受注管理画面の典型はこうなる。
https://gyazo.com/be8c7a1ff945ad8beac9c393d7247180
画面上半分に受注番号・各種日付・ステータス・倉庫・商品コード・商品分類など30以上の検索条件が並び、下半分の一覧では1レコードが多段に折り返されて表示される。検索条件・一覧表示・詳細編集がテーブル全カラムを軸に組まれており、「今日出荷予定の遅延を確認する」「特定顧客の今月の受注状況を見る」のような業務の入口は画面側に用意されない。画面は汎用的に作れるが、特定の業務には合わない。
対立概念としての提唱
CQRS文脈での提唱。「CRUD-based UIはユーザの意図 (intent) を捉えない」「ドメインから動詞 (verb) が失われ、データモデルの飾りつけにすぎないアプリケーションになる」と批判。Task-based UIではユーザの行動をCommandとして送り、意図を保ったまま処理する。DDDのドメインモデルと整合するUIだと論じる。
従来の deductive UI(コントロール一式を画面に並べてユーザに使い方を推論させる) の問題点として、ユーザがメンタルモデルを構築できないことを指摘。各画面は「ひとつのタスク」に焦点を絞り、タスク名を画面上に明示すべきと提唱。Microsoft Money 2000やOfficeのタスクペインで採用された。タスク中心UIを最も体系的に書いた一次文書。
Implementation model 批判 — Alan Cooper『About Face』(初版1995, 第3版 Notes) 「プログラマは実装モデル通りのソフトを、ありとあらゆるオプションを並べて作る癖がある」。データベース構造をそのまま画面化する設計への古典的批判で、Implementation Model / Manifest Model / Mental Model の三項対立を提示し、UIは Mental Model に合わせるべきと主張。
実務面の批判
Task-Driven User Interfaces — Janet M. Six UXmatters (2014) 「レガシーCRUDアプリは、ユーザの行動を自動化する手段として ineffective」とし、タスクフローに沿ってユーザを導くtask-driven UIと対比。処方箋変更の例で、CRUD UIだと「患者プロフィール検索→該当患者選択→処方箋画面→編集→保存」と画面遷移を強いられる非効率を指摘。
「CRUDを中心に組み立てたシステムは、軽い検証を超える振る舞いを実装するのが過剰に困難になる。on-change や on-click のハンドラに業務ロジックをねじ込んでいるなら、その症状」。画面側に書かれた業務ロジックが時間と費用を浪費する典型と論じる。
共通する症状
呼称や文脈は違っても、各文献が共通して指摘するCRUD UIの症状は以下である。
ユーザの意図が記録されない: 操作の記録が「商品コードA-123を発注承認した」ではなく「商品マスタの該当レコードを更新した」になる。誰が・なぜ・どの業務文脈で行ったかが画面の責務に含まれず、後から監査ログを見ても何が起きたかが復元できない。Task-based UIはCommandに業務名を持たせることでこれを記録する。
画面が業務に追従しない: 業務フローが変わっても、テーブル構造が変わらないと画面は変わらない。逆に、テーブルにカラムを足すと自動的に画面が膨らむ。「全カラム検索可能」「全項目入力可能」が既定値になっているため、業務上は1-2項目しか使わなくても画面は肥大化する。
業務ロジックが画面コードに混入する: CRUDは検証ルール程度しか想定していないため、複雑な業務ルール(承認ルートの分岐、状態遷移の制約、複数レコードの整合性)はon-change/on-clickハンドラの中に書かれる。Cordesが指摘するのはこの症状で、ロジックが画面コード内に分散すると、別UIから同じ業務を呼び出せなくなる。
データモデルが汎用なら画面も汎用で済む、という誤解: テーブルが汎用的なら画面も汎用的に作れる、という発想で「全顧客対応」「全業務対応」「全フィールド対応」の画面が量産される。実際にはユーザの業務は具体的で、汎用画面は誰にとっても少しずつ使いにくい。Cooperの implementation model 批判はこの誤解を指している。
なぜCRUD UIが選ばれるのか
業務分析の不足と、ユースケースごとにUIを設計したときの開発工数増大が、発注側・開発側双方の事情として効いている。
発注側の業務分析不足: 業務部門がIT部門やSIerに「現行踏襲で」「漏れがないように」と指示すると、設計者は「とりあえず全カラムを画面に出す」を選ぶ。利用部門が自分の業務を言語化できないと、テーブル構造をそのまま画面化するしかなくなる。
ユースケース設計の工数: ユーザの行動軸で画面を切ると、似たような申請画面が業務文脈ごとに複数並ぶ。共通テーブルへのCRUD画面1セットで済ませれば画面数は減り、開発工数も保守工数も下がる。発注側の予算も開発側の見積もりも画面数で計算されることが多く、ユースケース別UIは「冗長」「重複」と扱われる。
コストは利用者が払う: 開発・保守のコストは抑えられるが、業務との不整合は利用者が引き受ける。汎用画面の中から自分の業務に必要な項目を毎回探し、関係ない項目を読み飛ばし、業務上不要な必須項目をダミー値で埋め、画面遷移を覚え、マニュアルを引く。買う人と使う人が違うため、このコストは決裁の判断材料にならない (Why Enterprise Software Sucks)。 典型例: 汎用課題管理SaaS
Redmine、Jira、Backlog、Asana、ClickUpなどの汎用プロジェクト管理SaaSは、CRUD UIの代表例である。「課題 (issue / ticket / task)」という1テーブルに対する一覧・検索・登録・編集の画面が中心で、業種・業務・チームを問わずカスタムフィールドを生やして対応する。
「バグ報告」「機能要望」「実装タスク」「レビュー依頼」「経費精算」「総務問い合わせ」のように本来別々のユースケースが、同じ issue list + issue detail 画面に集約される
「ステータスを In Progress に変える」という同じ操作が、業務文脈ごとに「着手しました」「レビュー依頼します」「上申します」と意味が変わるが、画面はそれを区別しない
検索パネルにはプロジェクト・担当者・ステータス・優先度・トラッカー・カスタムフィールド10種類以上が並び、実際にはユーザは1-2項目しか使わない
フィールド構成・ワークフロー・通知ルールはユーザ側がカスタマイズで埋める。導入のたびに「このプロジェクトでは『優先度』を『緊急度×重要度』で運用」という暗黙ルールが出来る
ただし汎用SaaSの場合、CRUD UIになるのは設計の手抜きというより商売の構造上の事情である。複数の組織・業務に売るプロダクトは、特定のユースケースに最適化すると他の顧客に売れなくなる。CRUD UIで土台を作り、ユースケース別の最適化はユーザ側のカスタマイズとオペレーション習慣で吸収させる、という分業が成立している。Jiraのワークフローエディタや Redmine のカスタムフィールド機能は、この分業を前提にしたメタ機能と見ることができる。
自社開発でCRUD UIになるのとは原因が違う。SaaS側は「複数顧客に売るため特定業務に最適化できない」という事情だが、自社開発側は「自社の業務を聞き出していない」「ユースケース別UIの工数を惜しんだ」が原因になる。