なぜERPシステムは設計上、導入に時間がかかり、高額になるのか

Joannes Vermorel

数週間ごとに、まだ「ERPを導入中」と称する経営者に出会います。そのプログラムは前の経営陣のもとで始動し、予算は誰も口に出して繰り返したくない数字になっています。そして、既に半分書かれた事後分析では、ベンダー、インテグレーター、「変革への抵抗」、あるいは企業固有の事情のどれかが非難の的となります。このような話はあまりに一般的で、まるで背景音のように聞こえます。

不快な現実として、ほとんどのERP導入が遅く高価であるのは、関係チーム全員が無能なためでも、要件が不明瞭だったためでもなく、数十年にわたってERPを形作ってきた経済的および技術的インセンティブによって、カテゴリとしてERPが遅く高価になっているからなのです。¹

私の著書 Introduction to Supply Chain （第5章「情報」、節「記録システム」）では、驚くほど軽視されがちな考えについて触れています。それは、取引を記録するソフトウェアが不可欠である一方、根本的に限界があるということです。本来、その役割は信頼できる台帳として機能することであり、それ以上のことは求められていません。企業がこの点を忘れると、本質は単なる取引処理機器であるにもかかわらず、「戦略的」な価格を支払い始めるのです。この誤解こそが問題の発端となります。

エンティティの密林とベンダートレッドミル

まず、実際のERPとは何かを考えてみましょう。それは、リレーショナルデータベース上に構築された取引処理システムであり、多くのモジュール、画面、そして（製品、顧客、請求書、注文などの）多数の「エンティティ」を通じて、企業の資源と日常業務を追跡するものです。¹

さて、ここにERP導入が今後も苦痛であり続けることを静かに保証するダイナミクスがあります。

ERPベンダーは、あなた専用のためにソフトウェアを構築するわけではありません。彼らは、数十年にわたる全クライアントの合計のためにソフトウェアを構築します。製品は次々と蓄積的に成長していきます。大口のクライアントは「必須」とされる概念、例外、ワークフロー、規制上の特殊性、用語などをいくつか持ち込むため、ベンダーは追加することはあっても、ほとんど削除することはありません。レガシークライアントが依存する曖昧なエンティティを削除しても商業的利益は得られないのです。その結果、製品は容赦なく、一度に一つのエンティティ、ひとつのモジュールずつ拡大していきます。¹

これは重要な点です。なぜなら、複雑性は線形には増加しないからです。機能が2倍になると、必要なエンジニアリング努力は単純に2倍以上に膨れ上がり、製品内部の「意味論的一貫性」は時間とともに低下してしまいます。¹

初回の導入では、この成長は営業戦略によって隠されます。ERPベンダーはモジュール単位で販売し、クライアント企業もまたモジュール単位で導入します。今はあるモジュール、6ヶ月後は別のモジュール、翌年はさらに別のモジュールを追加するのです。これにより、企業は段階的な進展の錯覚を抱き、インテグレーターは作業をフェーズに分散させることができるのです。¹

しかし、アップグレード時にその錯覚は崩壊します。

同じベンダーを継続して利用していても、アップグレードは非常に困難で、多くの場合数ヶ月、時には数年にわたって延びるのが常です。¹ 技術的な理由は決して不可解ではなく、移行は単なる1対1のコピーではないからです。エンティティの意味が進化するため、かつて「顧客注文」を意味していたテーブルが返品も表すように再利用されると、その「修正」は負の数量、追加のフラグ、余分な結合、特殊ケース、そして静かに崩れる下流の前提条件へと変わってしまうのです。¹

これが、本当の厄介な問題、すなわちマッピング問題を招くのです。

作業の大部分は、ソフトウェアの「インストール」ではなく、ビジネスにおける2つの互換性のない辞書、つまり旧ERPの意味論と新ERPの意味論との対応関係を構築することに費やされます。しかも、両方の意味論があなたの会社だけでなくベンダーの歴史によって形作られているため、調整すべき概念の数はベンダーの蓄積されたクライアント基盤を反映してしまいます。すなわち、あなたの会社は他社が築いた迷路を進むために費用を支払っているのです。

カスタマイゼーションは問題をさらに複雑にします。クライアントとそのインテグレーターが、ベンダーが採用するには適さなかった特注のエンティティ、画面、ワークフローなどを追加すると、それらのカスタム要素は独自の方言となります。その後、ベンダーがリファクタリング（たとえ僅かでも）を行うと、企業は旧カスタム方言から新しい標準方言への、さらに新たなカスタマイゼーションでギャップを埋めるという、第二の、はるかに醜いマッピングに直面することになるのです。

これは偶然ではありません。製品の商業的成功が、多様なクライアントベースに対する後方互換性を維持しながら、その範囲を継続的に拡大することに依存している場合に避けられない現象、すなわちエンティティの密林という緩やかな必然性なのです。

一つのシステムが三つの役割を果たそうとする時

二番目の構造的問題は、さらに広範囲に及びます。企業は通常、ERPに対して一度に三つの異なる役割を果たすよう要求するのです。

企業は、ERPに取引の記録（台帳）、分析とダッシュボードの提供（「鏡」）、そして意思決定の実行（「脳」）という三つの機能を求めます。ベンダーは、ERPが「企業を運営するプラットフォーム」と位置付けられると、追加されるすべてのモジュールが「必須」となるため、これを快く奨励するのです。²

しかし、ソフトウェア設計の観点から見ると、これらの役割は互いに相反する要求を引き起こします。

トランザクション処理は、高速で信頼性のある更新と厳格な一貫性を求めます。一方、分析処理は、大規模なデータセットのスキャン、集計、切り分け、探求を目的としています。これらは異なる作業負荷であり、しばしば異なるデータモデルや性能上のトレードオフを伴って実装されます。この違いには、業界で何十年も前から（OLTP対OLAPという）名称が付けられているほどです。³

一つのモノリシックなシステムで両方を実現しようとすると、システムは常に内部で対立状態に陥ります。レポート、分析、擬似的な計画機能といった「重い」処理が、日常的なトランザクション処理と競合し、ユーザーはシステムの遅延、タイムアウト、夜間バッチ、脆弱な連携、そして「システムはそれを実行できない」という永遠のリフレインを体験するのです。その一方で、企業は矛盾をアーキテクチャに組み込むという特権のために高い費用を支払っています。

さらに、「ERP」という名称自体が誤解を招く要素となっています。歴史的に「P」は計画（プランニング）を意味し、知性の約束のように受け取られてきました。しかし実際には、計画はERPにおいてせいぜい二次的な関心事であり、予測分析はその中核であるトランザクション設計としばしば対立するのです。¹

私の2024年6月のエンタープライズソフトウェアに関する記事では、業界の慢性的な無駄が、これらのカテゴリーを曖昧にし、誤ったものに対して過剰な費用を払うことに起因していると論じました。専門用語を抜きにすれば基本は単純です。台帳は戦略エンジンではなく、それを戦略エンジンと見なすと、逆に複雑性だけが増し、メリットがもたらされないのです。²

もし私と同じ考えを持つ人が他にもいるのか疑問に思うなら、大手クラウドベンダーがデータシステムについて説明する方法を見てください。彼らは、取引処理システムを用いて記録を確実に保存・更新し、分析システムを用いてレポートを生成し複雑な分析を行うことを明示的に推奨しています。一つのデータベースモードがすべてに優れていると主張することはなく、互いに補完し合う役割を説明しているのです。³

一方で、ERPベンダーは全ての機能を一つのシステムで実現しようという正反対の夢を売り込みます。この夢は非常に利益性が高いのですが、その後遺症はクライアント側が負担することになるのです。

「カスタマイゼーション」という罠と「移行」という作業

サードパーティの文献やベンダーのドキュメントは、実務者が肌で感じている一点、すなわち、カスタマイゼーションと移行がプロジェクトの行き詰まり地点であるという点で一致しています。

ScienceDirectのERPカスタマイゼーションに関する論文は、これを「両刃の剣」と表現し、カスタマイゼーションが適合性を向上させる一方で、実装コストや複雑性、そしてその後のアップグレードにかかる費用が増大すると指摘しています。⁴ これは、インテグレーターがあらゆる提案に静かに織り込む、標準路線からの逸脱が将来の負担となるという学術的見解そのものなのです。

主流のベンダーの枠内に留まっていても、話は同じです。Microsoft自身のDynamics 365導入ガイダンスでは、「データの移行は複雑で時間のかかるプロセスである」と率直に述べ、次にソースの分析、範囲の定義、フィールドのマッピングと変換、ロード、テスト、そしてデータ品質の検証と確認といった作業内容を列挙しています。⁵

そのリストを注意深く見てください。それは、エキゾチックな技術でも「イノベーション」でもなく、単なるマッピングと照合作業の工業化にすぎないのです。

まさにこのため、ERPプログラムは数年に及ぶ大規模プロジェクトへと膨れ上がるのです。新たなソフトウェアを構築するのではなく、生きたビジネスを広大で絶えず変動する、ベンダー主導のスキーマに翻訳し、アップグレード時にその作業を再び繰り返す。それだけ台帳、鏡、脳といった複数の役割を果たそうとすればするほど、その翻訳作業は一度限りのものではなく、永続的なプロジェクトとなってしまうのです。

より賢明な代替案：意図的に小さな台帳を構築する

ここで、明らかな異議が浮上します。「確かに、ERPは混沌としている。しかし、洗練された機能が必要だ。計画も、最適化も必要だ。我々自身でこれを構築するわけにはいかない。」

その異議には、ERP提案と同じカテゴリーの誤りが含まれているのです。

もし範囲を、ビジネスの意味論を捉え日常のワークフローを支えるシンプルな取引層、つまり台帳に限定すれば、問題は劇的に単純化されます。全く考慮不要という意味ではなく、主に規律あるCRUDアプリケーションとして実装できるという意味です。

そして、ここが2026年が2015年と本質的に異なる点なのです。

現在、コードベースと一連のタスクを迅速に動作する変更へと変換するために特化したコーディングエージェントが登場しています。AnthropicのClaude Codeは、ターミナル上で動作し自然言語コマンドを通してコード生成を支援するエージェント型ツールです。OpenAIのCodexは、機能実装、バグ修正、プルリクエストの提案といったタスクを処理できるソフトウェアエンジニアリングエージェントとして位置付けられています。さらに、xAIは、共通のエージェントワークフローを通じてコードエディターと連携できる、コーディング指向のGrokモデルを提供しています。

これらのツールは魔法ではありません。2025年7月にMETRから発表されたランダム化比較試験では、特定の環境（馴染みのあるオープンソースリポジトリで作業する経験豊富な開発者の場合）において、AIツールの使用が、コーディングからレビュー・修正へと時間が移るため、平均して開発速度を低下させることが判明しました。⁶ この結果は重要な教訓であり、「エージェント型」であることが「自動的」であることを意味しないという点を示しています。

しかし、それは同時に、作業が反復的で範囲が明確かつ意味論的に限定されている場合に、最も大きな利点が発揮されることも明らかにしています。まさに、意図的に退屈であるべき台帳の理想と一致するのです。

率直に申し上げます。年商5000万ユーロ以上の十分な規模の企業であれば、ERPモノリシスを購入し、そのエコシステムに10年分の使用料を支払うよりも、台帳レイヤーを自社内で構築するのが最善の選択です。

なぜでしょうか？

それは、ERPの「モダナイゼーション」における主要なコスト要因が、数千のベンダー主導のエンティティと何年にもわたる意味論的ドリフトを跨ぐスキーママッピングに起因しているからです。ゼロから構築すれば、ベンダーのポートフォリオ中の全企業に適合させるための妥協ではなく、自社の意味論に沿ったレコードレイヤーを作ることができます。実際、その結果として生まれるデータモデルは、規模が1桁または2桁小さくなることが多いのです。これは、あなたのビジネスが些細であるためではなく、他社によって残された意味論的破片への支払いを止められるからです。

導入方法も変わります。何年にも及ぶ仕様策定後の英雄的な切替えの代わり、冷静なエンジニアリングチームのように反復的に進められます。まず、レガシーデータの新鮮なスナップショットをインポートし、従業員に新システムと対話させます。彼らはソフトウェアと実際のワークフローとの不一致を報告し、あなたはコードを調整。再インポートを行い、台帳が適合するまでこの工程を繰り返すのです。このアプローチは、Microsoftのガイダンスが示唆している―すなわち移行にはマッピング、テスト、検証、リハーサルが必要である―ことの、規律ある実践版に他なりません。⁵

確かに、これにはコーディングスキルが必要です。そのスキルは社内であっても外部委託であっても構いませんが、実際に存在するものでなければなりません。また、私が「機械への共感」と呼ぶもの、つまりベンダーの演出に惑わされずに技術プロジェクトを舵取りできるだけの経営陣の理解も求められます。私が別の場面で用いた例えでは、優れたパイロットは機械工学者ではないが、機械を最大限に活用するために十分な知識を持っているというものでした。⁷

これは、多くの企業が避けようとする部分です。彼らは、実装と共に考えることも外部委託したがり、安全という幻想を購入したがるのです。

しかし、成長、バンドル、ロックインをインセンティブとするモノリシックなシステムに企業の台帳を外部委託することは、安全ではありません。結局、将来的に取り替えなければならなくなるソフトウェアを購入する、最も遅い方法なのです。

もし計画と最適化が必要ならば、それらをクリーンな台帳の上に層状に重ねられた別個の問題として扱ってください。台帳を最適化装置に変えることを強制せず、最適化を移行プロジェクトに巻き込まないでください。まず、記録を正確で迅速、そして退屈なものに作り上げ、その上で初めて、毎回企業全体の記憶を書き直すことなく改善できる意思決定システムを構築すべきです。

ERP導入が遅く高価であるのは、ERPカテゴリがそのような構造的インセンティブの下で進化してきたからです。抜本的な解決策は、同じ罠の中でより優れたプロジェクト管理を行うことではありません。台帳に神託の役割を求めるのをやめ、ベンダーの過去の負債に自分のもののように対価を支払い続けるのを止めることこそが脱出の鍵です。