ポスト2027年の基幹システムは如何にビジネスの変化に対応するか？

ITの役割は、昭和から令和になるにつれ大きく変わってきています。1990年代半ばまでは、現場効率化がITの役割でした。そのため、ITはいかに多くの情報を効率的に低コストで処理するかが命題でした。ホストから分散化の時代です。その後、失われた30年が始まり、プロセス改革や構造改革が企業の命題になると、システムにより経営課題を解決しようとする動きが本格化しました。それにうまく合致したのがERPです。

そして、令和の時代。消費者の価値感は、コト消費（体験価値）からトキ消費（限定価値）に変わりつつあり、かつ消費者は常に新たな価値の提供を求める時代になっています。したがって、ITにも新たな顧客価値を生み出すとともに、急速に変化する環境に迅速に対応していく能力が求められています。まさに合体ロボのようなシステムが求められているのかもしれません。時代に対応するために、ポスト2027年の基幹システムはどうあるべきかを考えてみたいと思います。

変化に対応するITアーキテクチャとして、かなり以前からシステムの疎結合化が言われています。2000年代半ばにはSOAが登場し、単機能のビジネスロジックをサービスとして独立させようという設計が盛んに行われました。しかし、この時代の疎結合化は、メンテナンス性の向上が主な目的でした。簡単に言うと、ある仕様に修正が発生した場合、それまで複数のプログラムのいろいろな箇所を直していたのが一つのプログラムを直せば良くなった、という事です。

それをもう一歩進めたのが、マイクロサービスの考え方です。マイクロサービスは、業務的に完結したシステム単位で完全に分割して、なるべく小さな単位で独立させようという考え方です。完全に独立して機能するという事は、分離する中にデータベースも含むという事であり、従来の疎結合と大きく違うのは、まとまった業務単位で大幅な変更や取り換えができるという点です。

振り返りますが、ポスト2027年の基幹システムに求められていることは、新たな顧客価値を生み出すことと、急速に変化するビジネスに対応するということでした。システムは、新しい顧客サービスの提供や、新たなインサイトを得るための新たな情報収集へと、絶えずアップデートを続けていかなくてはなりません。つまり、システムの疎結合に求められる単位が、部品単位からビジネス単位になったという事です。そして、数年後にはそれがもっと当たり前になるだろうと予測されます。

マイクロサービスは、急速な変化にビジネス単位で対応するITアーキテクチャのひとつの考え方です。決してマイクロサービスやコンテナという技術を導入することが目的ではありません。各々のビジネス・プロセス・データの特性を鑑み、独立・分離させるビジネス単位を見極める事が重要なのです。

「基幹システムは、モノリシックでよいのではないか」という議論があります。基幹システムが担う業務は枯れた業務であり、変化も少ないSoR（System of Record）だ。よって、密結合でよく、逆にデータの整合性が確保しやすいため、密結合のままでよいという主張があります。一方で、SoE（System of Engagement）は顧客やビジネス環境の変化によって取り換え可能なように、それぞれの目的に応じたシステムの単位にし、基幹と各SoEシステム間をデータ連携ハブという名のETLツールやAPIプラットフォームで繋げば良いという考え方です。

今までは、どちらかというとスクラッチを含めた汎用的な基幹システムを念頭に話をしてきました。しかし、多くの業種で基幹システムはERPというのが一般的です。ご存じのとおり、従来のERPは最もモノリシックなシステム形態です。情報を統合的に管理することによって（昔は大福帳と言われていました）、経営判断を支援する情報をリアルタイムで提供するというのがERPのコンセプトだからです。

ERPの最近の流行は、アドオンせずに標準機能をそのまま使って（Fit to Standard）、さくっと導入しましょう、です。これは、SoRである基幹業務はコストをなるべく使わず、お金を生み出すSoEシステムにコストと労力をかけましょう、という考え方に基づいています。ポスト2027年を見据えた時、この考え方は有益でしょうか。限られた経営資本の有効活用という観点からは効果的ですが、変化へのアジリティという観点では硬直的です。Fit to Standardばかりが強調され、本来は併せて語られるべきアプリケーションサービスの疎結合化という側面が抜け落ちてしまっています。

前述のように、本来は、なるべく最小限のビジネス領域単位で独立したシステムに分離することがERPと言えども望ましい事に変わりありません。しかし、それはそもそものERPのコンセプトとは真逆です。そこを打破すべくガートナーは「ポストモダンERP」という概念の中で、「ERPコア」と周辺アプリケーションをクラウド上で疎結合化するという方向性を提示しています。会計、販売、在庫管理などの「ERPコア」と、生産、物流、購買、営業支援など個別アプリケーションを、SaaSの組み合わせとして使っていく事で、変化に強い疎結合アーキテクチャを作ろうという概念です。しかし、今後は「ERPコア」領域も変化への対応力を高めていく必要があります。それを考えると、個別に分けたそれぞれのビジネス単位に最適なアプリケーションサービスを標準機能のまま組み合わせて使っていく、というのが疎結合アーキテクチャを実現するFit to Standardの考え方ではないでしょうか。

マイクロサービスは、疎結合化を実現するトレンドのアーキテクチャなので、システム更改の際に、次期システムのアーキテクチャとしてベンダーからよく提案されます。しかし、手段と目的を混同してしまっている提案が散見されます。例えば以下のような提案をされたりします。

『サブシステム単位にアプリケーションとミドルウェアをコンテナ化して、マイクロサービスを実現しましょう。』

コンテナ化は、マイクロサービスを実現する有効な技術的手法の一つですが、マイクロサービスではありません。そして、データベースを分離する事は、ベンダーとしては面倒なので、安易にアプリケーションだけをコンテナ化して、マイクロサービスと称したりします。しかし、これではビジネス単位での取り換えに対応できない事はこれまで見てきたとおりです。

また、大規模で多くの業務領域に跨り、かつ複雑に絡み合ってしまったモノリシックな基幹システムを一気に疎結合化するのは大変だしリスクがある、領域ごとに徐々に分離していく方法がリスクも少なく現実的だ、という提案もベンダーからよくされます。

しかし、一つのビジネス領域を分離するためには、データベースを含めて分離しなければならず、元のモノリシック側にも同じデータを保持しなければならないため、データの同期問題も解決しなければならず、実際には容易ではありません。そして、最も注意すべきは、2、3のビジネス領域を分離したからといって、ほとんど疎結合化の目的を達成できていないということです。他の多くの領域はモノリシックのままだからです。

仮に、徐々というものが10年かかるとしたら、6～8年くらいは、疎結合化のメリットを享受できないという事になります。本末転倒ではないでしょうか。
したがって、疎結合アーキテクチャへの転換は一気にやるべきであり、基幹システムの更改はその最大のチャンスです。最近よく話題になるERPのサービス期限切れによる更改問題も同様です。単にグレードアップか否かということではなく、疎結合アーキテクチャへの転換点ととらえるべきなのです。また、ハードウェアの保守切れ、古い言語による保守の限界などによる更改も、安易にハード更改やコンバージョンなどに流れるべきではありません。そして、先にも述べたように、まずは各々のビジネス・プロセス・データの特性をよく把握し、独立・分離させるビジネス単位を見極める事が重要なのです。