コンサルティングサービス
経営コラム
経済・政策レポート
会社情報

経営コラム

オピニオン

【DXインサイト】
DX時代の新たな基盤「コンポーザブルERP」の導入に向けて

2023年12月19日 林翔太


 近年、デジタル技術の急速な進展によって私たちを取り巻く社会や経済は大きな転換期を迎えている。企業や組織は、デジタル技術を活用した事業変革や企業変革、すなわち“デジタルトランスフォーメーション(DX)”への対応の必要性に迫られている。一方で、DXの必要性や重要性は認識しつつも、“何を、どのように、どこから”着手すれば良いのかという課題を抱える企業や組織は多いと考える。このシリーズでは、DX関連のトピックから、最新のトレンド、日本総研の事例や見解まで幅広く取り上げ、企業や組織におけるDX推進の一助となることを目指す。

 本稿では、DXの阻害要因としての「レガシーシステム」を脱却するにあたり、今後、最も有効な概念となってくるであろう「コンポーザブルERP」を取り上げ、導入に向けた示唆を提供したい。

コンポーザブルERPとは
 ERPの概念は、この数十年で大きく2段階の進化を遂げている。
「モノリシック(一枚岩)型ERP」から「ポストモダンERP」へ、というのが2010年代に生じた第一段階の進化である。そこから、2020年代初頭にガートナー社が提唱した概念が、「コンポーザブルERP」である。
 コンポーザブルは、「(複数の要素や部品などを結合して)構成可能な」という語義である。コンポーザブルERPとは、まさしく複数の機能部品を組み合わせた構造で、かつ柔軟に機能部品を組み替えられる、疎結合の組み立て型ERPである。
 
 前前代のERPの概念は、「モノリシック型ERP」と呼ばれ、巨大な密結合の構造を特徴としていた。前代のERPの概念である、「ポストモダンERP」では、普遍的な業務領域を担うERP(以下、「コアERP」という。)とSaaS型サービス等の組み合わせでERPを実現する、という一定の疎結合化が進んだ。

 コンポーザブルERPは、ポストモダンERPが持つ「組み合わせ」という考え方を基に、新たなデジタル技術をフル活用しながら、抜本的に推し進めた概念だと筆者は理解している。
 究極的には、コアERPという概念を中心に据える必要すらなく、コアERPがこれまでカバーしていた業務機能を含めたさまざまなビジネスロジックを、デジタル市場に存在するサービスを縦横無尽に組み合わせながら、マイクロサービス・アーキテクチャ(説明は後述)で開発し、最終的に一連のビジネスプロセスに対応したERPの形に組み立てる。そこで生成されるデータは、疎結合ながらも自在に統合し、活用できる。
 結果、大規模な事業環境の変化や個別要件への対応でも、柔軟性や迅速性を確保しながら自社の競争力を最大限に強化できる唯一無二のERPを作り上げられる。

コンポーザブルERPの根幹を支えるデジタル技術
 コンポーザブルERPという新たな概念を可能としたのは、2つのデジタル技術であると筆者は捉えている。それは、「マイクロサービス・アーキテクチャ」を実現する開発基盤としての「統合APIプラットフォーム」と、「データファブリック」を実現するための「データ統合プラットフォーム」である。
 これらのデジタル技術の詳説は、本論の趣旨から外れていくため、今回は割愛するが、この2つが存在することで、なぜコンポーザブルERPの概念が実現されるのか、この点に関する筆者の理解を以下に記載する。

 まずは、マイクロサービス・アーキテクチャという考え方自体が、独立して機能する個々のサービスを組み合わせて、最終的に一つのアプリケーションを構築するという、「コンポーザブル」を実現するための技術そのものである。コンポーザビリティの確保により、事業環境の変化や個別要件への対応が実現できる。
 さらに、マイクロサービス・アーキテクチャの特徴として、アプリケーションの機能部品は独立している(疎結合である)ことから、各機能部品単位で、柔軟に機能開発・拡張・修正を行うことができる。結果、アジャイル開発やDevOps(※1)を実現しやすいため、各機能部品の開発を並走させつつ、圧倒的な開発スピートを享受することができる。

 ただし、このアプリケーションの機能部品の独立性の高さにはデメリットもある。それは、ERPが必要とする「データの一元性・リアルタイム性・データの活用性の確保」が難しいことである。マイクロサービス・アーキテクチャを前提として、コンポーザブルな構成をとる場合、各サービス上にデータはどうしても分散してしまう。

 その問題を解決するのが、データファブリックである。データファブリックという技術は、「ファブリック(布)」という名のとおり、あらゆる場所に存在するデータを組み合わせ(織りあげ)、必要なデータに容易にアクセスし、活用できるようにするというものである。データファブリックを実現することで、各サービスに散在しているデータを、適切に統合し、活用していくことができるようになる。

 この2つを組み合わせることができるようになったからこそ、これまでのERPが有していた「密結合であるが故の大福帳的なデータのリアルタイム性と一元管理性」という圧倒的な優位性に対し、疎結合型を究極的に追及しても、一定の対抗力を確保できるようになったと筆者は捉えている。
 データファブリックにより、データの一元性や活用性の問題点を解消した上で、マイクロサービス・アーキテクチャの適用により、事業環境の変化や個別要件対応を、柔軟に、より競争力のある形で、しかも圧倒的開発スピードで実現できる。

コンポーザブルERPの無限の可能性
 事業環境の変化や個別要件対応を、柔軟に、より競争力のある形で実現できる、というコンポーザブルERPの特徴を、前代および前前代のERPとの比較を通じて掘り下げてみる。

 前代および前前代のERPは、世のベストプラクティスをベースに、各業務領域のビジネスロジックが埋め込まれ、有効に連動する仕組みとなっているため、導入にあたっては、システムを業務に合わせるのではなく、業務をシステムに合わせる、いわゆる「Fit To Standard」が求められる。一定の汎用機能の実現は容易な一方で、競争優位性の確保に必要な、業務の個別要件への対応の柔軟性に欠ける。
 また、ERPベンダーが研究開発費をつぎ込み、機能強化を進めて出来上がった機能は、より多くの企業にとって役立つ「最大公約数的な機能」にとどまる可能性が高い。

 一方で、コンポーザブルERPが、パーツとしての活用を想定している個別のサービスは、無数のITベンダーが市場に日々投入し、爆発的スピードで増加し、多様化していく。
 結果、両者のサービスの強化スピードと機能の多様性を比較した際に、前代および前前代のERP側が劣後していく可能性は高い。だからこそ、市場のサービスを前提とするマイクロサービス・アーキテクチャを適用した方が、事業環境の変化や個別要件対応を、柔軟かつより競争力のある形で実現できると考える。

 ここまでコンポーザブルERPの可能性について解説してきたが、コンポーザブルERPの導入は、コンポーザブルであるが故に、その分、実装の難易度が高いと考えている。

コンポーザブルERP導入の難しさ
 コンポーザブルERP導入の前提として、まず自社の競争力を高めるためにはどうすべきなのかを捉え、具体的な業務や活用シーン等の構想に落とし込むビジネススキルが不可欠である。
 さらに、コンポーザブルにする上では、どのような単位でサービスを組み合わせるのかというデザインスキルが必要となる。具体的な業務や活用シーンを十分に意識しながら、アプリケーションの機能部品の単位を検討し、その上で、裏で動く各サービスの組み合わせを検討していく。サービスの組み合わせについても、市場に存在するあまたのサービスや技術動向を把握した上で、一部のサービスを共通部品化していくなど、全て自身で組み立てる必要がある。

 これを住宅で例えると、全てが決められた状態で出来上がった建売住宅と違い、自分で全ての仕様を決める注文住宅である。ただし住宅の場合は、住宅メーカーに発注し要望を伝えると、設計士が各種部材を把握した上で設計し、建築士が建築して、完成形で引き渡してくれる。
 コンポーザブルERPの導入では、住宅の設計士と建築士の役割を自身一人で担う必要がある。そこには高い専門性と洞察力、開発力が求められることが容易に想像できるだろう。
 もちろん、外部のコンサルタントやベンダーを活用して検討・開発を進めるというのは一手である。

コンポーザブルERP導入のファーストステップ
 高い専門性と洞察力、開発力が求められるため、スキルやマンパワーなどに懸念がある場合は、一足飛びに完全な注文住宅まで追及せずに、セミオーダー住宅レベルでの対応を目指していくというのが、導入のファーストステップとしての現実解だと考える。
 セミオーダーというのは、コアERPの機能領域については、自由に組み立てる形で設計するところまでは踏み込まないということである。コンポーザブルERPの概念をつきつめると、前述のとおり、理論的には、コアERPさえ、各サービスの組み合わせで実現することができる。ただし、ファーストステップではそこまで実現せずに、コアERPのスタンダードでいったん抑え、自由に組み立てる範囲を限定するのである。

 統合APIプラットフォームとデータ統合プラットフォーム上で、コアERPを活用しつつ、コアERPのギャップ部分だけを、SaaSをそのまま活用したり、マイクロサービス・アーキテクチャを適用する形で構築したりするレベルから始めてみるのが、一つの現実解だと考える。

 このファーストステップの実現イメージは以下である。



 このようなイメージを実現する際に留意しておきたいのは、コアERP製品の設計思想である。コアERPは、可能な限り、コンポーザブルERPの概念に対して開かれた製品を選定することが重要である。API連携やデータ統合に対する根本的な考え方にギャップがあると、将来、機能拡張したい時やレベルアップしたい時に制約が生じる可能性がある。

おわりに
 本稿では、コンポーザブルERPが、大規模な事業環境の変化や個別要件への対応でも、柔軟性や迅速性を確保し、自社の競争力を最大限に強化できるという強みをもつ一方で、コンポーザブルである分だけ、適切な導入の難易度が高いことを示し、導入に向けたファーストステップとしての現実解を提示した。
 ファーストステップとして、前述の図表のようなコンポーザブルERPを導入しておくことで、少なくとも、レガシーシステムの制約から解放され、一定の競争力のあるERPが活用できる。加えて、今後、DXを推進し、さまざまなデジタル実装により新たなデータが生成された際には、データファブリックにより、容易にデータを統合し、活用を強力に推進していくことができる。
 導入の難度が高い分だけ、得られる果実も大きいため、コンポーザブルERPは、DX時代の新たな基盤のデファクトスタンダートとなっていく可能性が高い。競争優位性の獲得に向けて、コンポーザブルERP導入の検討を進めることは、決して無駄にはならないだろう。


(※1) デブオプス。開発担当と運用担当が連携・協力し、柔軟かつ迅速な開発を実現するソフトウェアの開発手法。


※記事は執筆者の個人的見解であり、日本総研の公式見解を示すものではありません。
関連リンク
経営コラム
経営コラム一覧
オピニオン
日本総研ニュースレター
先端技術リサーチ
カテゴリー別

業務別

産業別


YouTube

レポートに関する
お問い合わせ