CRUDビジネスアプリ

1980年代以来、ほとんどのビジネスアプリは同様の内部設計、すなわちCRUD（Create / Read / Update / Delete）を採用してきました。この設計は、ビジネスデータを永続化するために関係データベースの採用を反映しています。CRUD設計は、コンソール端末からメインフレームに接続されたモバイルアプリがクラウドプラットフォームに接続されるまで、いくつかの大きな技術的進歩を経てきました。CRUDアプリで構成されるアプリケーション全体のアプリケーションレイヤー上で動作する、供給チェーンなどの複雑な分野では、CRUD設計の理解が重要です。このような洞察は、ソフトウェアベンダーとの交渉から、これらのアプリケーションを通じて収集されたデータエントリの活用まで、このアプリケーションレイヤーを適切にナビゲートするために不可欠です。

概要

1980年代初頭までに、関係データベースはビジネスデータの保存とアクセスの主要なアプローチとして登場しました。1990年代末までに、新興のオープンソース関係データベースがこの実践をさらに固めました。これらの日々、CRUD設計は関係データベースの上にビジネスアプリをエンジニアリングするための最も普及しているアプローチを反映しています。

関係データベースの意味でのデータベースには、テーブルのリストが含まれます。各テーブルには、列（フィールドとも呼ばれる）のリストが含まれます。各フィールドには、数値、テキスト、日付などのデータ型があります。テーブルには、行（行とも呼ばれる）のリストが含まれます。一般的に、列の数は限られており、最大で数百であり、行の数は無制限で、数十億に達する可能性があります。

図1：製品のリストと在庫状況を反映した単純なテーブル。これは、関係データベースで一般的に見られるものの例です。

実際には、関係アプローチでは、ビジネスに関連する何かを反映するために複数のテーブルが必要です（例：発注）。これらのテーブルの「グループ化」は、_エンティティ_と呼ばれます。エンティティは、ビジネスの高レベルな理解を反映しています。

図2：2つのテーブルで構成される単純な「ショッピングカート」エンティティ。このエンティティは、ECサイトの訪問者のショッピングカートの状態を反映しています。

上記のように、CRUDはテーブル内で実行する4つの基本操作であるCreate、Read、Update、Deleteを指します。

• Create：テーブルに新しい行を追加します。
• Read：テーブルから既存の行を取得します。
• Update：テーブル内の既存の行を変更します。
• Delete：テーブルから既存の行を削除します。

これらの操作は、専用のデータベース言語を介して実行されます。現在では、ほとんどの場合、SQL（Structured Query Language）の方言¹が使用されます。

CRUD設計は、エンティティとそれに対応するユーザーインターフェース（通常は「画面」と呼ばれる）を導入することで構成されます。画面は、ウェブページである場合があり、通常は対象エンティティの4つの操作を備えています。

「トランザクション」ビジネスアプリのほとんどは、シンプルなタイムトラッカーから非常に複雑なERPやCRMまで、4十年以上前に確立されたCRUD設計パターンを採用しています。シンプルなアプリは数個のエンティティのみを備えている一方、複雑なアプリは数千のエンティティを備えている場合もあります。しかし、シンプルから複雑まで、固有の設計の観点では、同じものの延長です。

ビジネスアプリの中で見られるユーザーインターフェースの多様性は、アプリが非常に異なるように見えるという意味で誤解を招くかもしれません。しかし、実際には、ほとんどのアプリはCRUDの観点に沿ったほぼ同一の内部設計を持っています。

サプライチェーンにおけるCRUDアプリ

企業やそのプロセスを操作するために使用されるほとんどのアプリ（エンドユーザーに公開されているもの）はCRUDです。一般的に言えば、ERP、MRP、CRM、SRM、PLM、PIM、WMS、OMS、EDIなどのように、3文字の略語で表される企業向けソフトウェアはほぼ必ずCRUDとして実装されます。このルールの最も顕著な例外は、ドキュメントエディタ（スプレッドシートソフトウェアなど）であり、これはまったく異なるタイプのソフトウェア技術を表しています。

内部的には、IT部門はCRUDではないさまざまな技術を使用しています：ネットワーキング、仮想化、システム管理ツールなど。ただし、これらの技術はエンドユーザーにはほとんど見えないか、少なくとも目立たないようになっています。

このようなCRUDアプリには、サプライチェーンを定量的に改善するために活用できるほぼすべての関連する履歴的トランザクションデータが含まれています（例：在庫レベルの最適化）。そのため、多くのCRUDアプリは、ある時点で解析機能（計画や最適化など）に分岐しようとします。残念ながら、CRUDは多くの利点を持っていますが、解析能力に関しては厳しい制約もあります（以下の「CRUDの限界」を参照）。

CRUDの利点

CRUDは、数十年にわたってビジネスアプリの主要なアプローチとなっています。技術的な観点からは、このアプローチは、主要なソフトウェアスタック全体で包括的なオープンソースのフレームワークとツールを利用することができます。その結果、技術的なパスは非常に明確になります。さらに、CRUDは高品質の開発ツールも利用できるため、CRUDベースのアプリの開発に関与するソフトウェアエンジニアの生産性も高い傾向にあります。

スタッフの観点からは、CRUDに精通したソフトウェアエンジニアの市場が広範であり、CRUDはソフトウェアエンジニアリングの中でも最もアクセスしやすい部分の1つです。これは、高品質の開発ツールのおかげです。そのため、CRUDは、初心者のソフトウェアエンジニア（および才能のないシニアエンジニア）でも非常にアクセスしやすいです。CRUDの基本原則が数十年間安定しているため、より新しい技術スタックに移行することも比較的容易に行うことができます。

最後に、ビジネスの継続性の観点から、CRUDは基礎となる関係データベースに関連するすべての利点を提供します。たとえば、データベースがクライアント企業にアクセス可能である限り、データはアクセス可能なままです。これは、元のCRUDアプリのベンダーがもはや運営/協力していない場合でも当てはまります。この極端な場合でも、控えめな逆解析の努力によってデータのアクセスが可能です。

CRUDの限界

CRUDアプリは、内部的に関係データベースを活用する方法に関連する固有の制限に直面しています。これらの制限は、CRUDに関連する利点を根本的に放棄することなく回避することはできません。これらの制限は、表現力とパフォーマンスの2つの大きなカテゴリに分類されます。

表現力の制限は、4つのアクション（または「動詞」）- 作成、読み取り、更新、削除 - がより詳細な意図の配列を適切に捉えることができないという事実を反映しています。たとえば、従業員がSRM（サプライヤーリレーションシップマネージャー）内で誤って作成された複数のサプライヤーエントリを重複排除する場合を考えてみてください。この操作には、マージという適切な動詞が必要です。しかし、CRUDの設計にはこの動詞がありません。実際、この機能は必ずしも2段階のプロセスとして実装されます。まず、削除される予定のサプライヤーエントリに向かっていたすべての行を更新し、それらが保存されるものを指すようにします。次に、余分なサプライヤーエントリを1つを残してすべて削除します。元の意図（マージ）が失われるだけでなく、データの変換も破壊的です。逸話的に、CRUDアプリがユーザーにデータに対して不可逆な変更を行う予定であることを警告する場合、ほとんどの場合、CRUDの制限²がユーザーエクスペリエンスに干渉しています。

パフォーマンスの制限は、長時間実行される操作 - つまり、データベースのごく一部の読み取り以上の操作 - がCRUDアプリを応答不能にするリスクがあるという事実を反映しています。実際、CRUDアプリでは、ほとんどの日常的な操作に対してレイテンシがほとんど気にならないことが期待されています。たとえば、WMS（倉庫管理システム）での在庫レベルの更新はミリ秒単位で行われるべきです（操作をスムーズにするため）。CRUDアプリに与えられるすべての操作が、同じ基礎となる関係データベースから計算リソースを消費するため、ほとんどの非自明な操作はこのコアを計算リソースの枯渇の危険にさらします。逸話的に、大企業では、CRUDアプリが数秒（数分）間応答しなくなることがよくあります。これらの状況は、数少ない「重い」操作が短時間に計算リソースを独占し、他のすべての操作（「軽い」操作も含む）を遅延させるためです。この問題のため、非自明な操作は通常、夜間に実行されるバッチジョブに分離されます。また、分析作業負荷はオフィス時間外のみで実行することが実用的ではないため、CRUDアプリは通常、分析には適していません。

現代のCRUDフレーバー

過去数十年間、エンタープライズソフトウェアは大きな進化を遂げてきました。1990年代には、ほとんどのアプリがコンソール端末からデスクトップユーザーインターフェースにアップグレードしました。2000年代には、ほとんどのアプリがデスクトップユーザーインターフェースからWebユーザーインターフェースにアップグレードしました。過去10年ほどで、ほとんどのアプリはSaaS（サービスとしてのソフトウェア）に転換し、その過程でクラウドコンピューティングに移行しました。ただし、CRUDの設計はこれらの進化にほとんど触れられていませんでした。

シングルテナンシーからマルチテナンシー³への移行により、ソフトウェアベンダーはエンティティへのデータアクセスをAPI（アプリケーションプログラミングインターフェース）の背後にゲートする必要がありました。実際、データベースへの直接アクセスは、読み取り専用であっても、わずかな数の重いリクエストによってトランザクションのコアの計算リソースが不足する可能性を生み出します。APIはこのような問題を緩和します。アプリのデータへのアクセスをAPIの背後にゲートすることは、少なくともクライアント企業にとってはCRUDの利点の一部を否定します。APIから大量のデータを信頼性を持って抽出するには、通常、比較可能な一連のSQLクエリを作成するよりも多くの努力が必要です。さらに、APIは不完全な場合があります。アプリに存在するデータを公開していない場合がありますが、直接のデータベースはデータへの完全なアクセスを設計上提供するはずです。

CRUDの主な進化はツールに見られます。2010年代には、高品質なオープンソースエコシステムがさまざまな形で登場し、CRUDアプリの開発をサポートするようになりました。これらのエコシステムはCRUDアプリの開発を大幅に商品化し、それに伴い開発に必要なスキルを大幅に低下させ、開発プロセスに関連する摩擦を減らしました。

ベンダーのダイナミクス

CRUDアプリの開発コストは、主にエンティティの数によって決まります。エンティティの数が多ければ多いほど、開発、ドキュメント作成、保守が必要な画面も多くなります。したがって、CRUDアプリを推進するソフトウェアベンダーの自然な進路は、限られた数のエンティティから始め、徐々に追加していくことです。

エンティティの追加により、新たな機能が解放され、ベンダーは価格を引き上げる機会を得ます。これは、クライアント企業に対して作成された追加価値を反映したものです。また、モジュール⁴、つまりビジネス関連のエンティティのグループ化は、ソフトウェア製品の使用範囲に応じて追加料金を請求するための価格設定メカニズムとして頻繁に導入されます。

その結果、CRUDアプリは時間の経過とともにより複雑になりますが、同時により関連性が低くなります。実際、新たに追加されるエンティティの多く（もしくはほとんど）は、個々のクライアント企業にとっては関連性がありません。クライアント企業の観点からは、「死んだ」エンティティはCRUDを汚染する増加する偶発的な複雑さを表しています。

SaaSとして販売されるCRUDアプリは、機能と知名度が向上するにつれてより高価になります。ただし、参入障壁が非常に低いため⁵、新しいベンダーが頻繁に登場し、価格がはるかに低いユースケースに焦点を当てることがあります。そして、このサイクルは無限に繰り返されます。

Lokadの見解

多くの大企業は、CRUDアプリの商品化の程度を過小評価しています。これらを販売するほとんどのエンタープライズソフトウェアベンダーにとって、開発コストはアプリ自体のマーケティングと販売にかかるコストのほんの一部です。特に、CRUDアプリを開発するベンダーは、CRUDのアプローチ（その全体的なアクセシビリティによる）が、より才能のない（そしてより安価な）エンジニアリングチームを許容できるため、エンジニアリングチームを低コストの国に配置することがあります。

現在、CRUDアプリに高額な料金を支払う理由はほとんどありません。一般的な目安として、年間25万米ドル以上の費用がかかるCRUDアプリは、社内ソフトウェアに置き換えるための真剣な候補です。年間250万米ドル以上の費用がかかるCRUDアプリは、ほぼ確実に社内ソフトウェアに置き換えるべきです（可能であれば、既存のオープンソースのベースラインからカスタマイズを開始することも考慮されます）。

CRUDアプリを販売するエンタープライズソフトウェアベンダーは、この問題について非常によく認識しています（そして長い間認識してきました）。したがって、ベンダーはソリューションに非CRUDの機能/アプリ/要素⁶を追加し、これらの部分が重要であるとクライアントに説得し、これらの部分がクライアントが再現できない「秘密のソース」を表していると主張することが誘惑されます。しかし、このアプローチはほとんど成功しません。主な理由は、ベンダーが適切なエンジニアリングDNA⁷を持っていないためです。逸話的な証拠として、ほとんどの有名で確立されたERPは、予測と計画の機能を広範に備えていますが、これらの機能の実行性能が非常に低いため、ほとんど使用されていません。

Lokadは、サプライチェーンの予測最適化に特化したエンタープライズソフトウェアベンダーです。当社のテクノロジーは、企業の日常業務をサポートするCRUDアプリから抽出できるような、過去のトランザクションデータを活用するように設計されています。ただし、Lokad自体はCRUDアプリではありません。当社の本番環境には関係データベースさえ含まれていません。CRUDは、会社のトランザクションワークフローの管理に対する有効な技術的な回答ですが、サプライチェーンの予測モデリングや数理最適化にはまったく関係ありません。

ノート