基幹系システムをクラウド化、その先に見えるものとは？：第3回（最終回）

2019年12月4日(水)磯谷元伸（NTTデータグローバルソリューションズ代表取締役社長）

リスト

「基幹系システムの未来」と題して、これまで「デジタルトランスフォーメーション時代の基幹系システム、その要件」「進化するERPはどのようにデジタルに向き合っているのか？」と題し、基幹系システムとデジタルについて解説してきた。最終回となる今回は「クラウド化されていく基幹系システムの将来像をどう考えていくべきか？」について解説していきたい。

クラウドサービスとEA

　そもそも、世に謳われている「クラウド化」とは何を指しているのか、いま一度、冷静に考えてみるところから始めたい。一口にクラウドサービスと言っても、各社のサービスの中身を調べると、IaaSと呼ばれるインフラレベルからSaaSというアプリケーションのレベルまで様々だ。ここで温故知新ではないが、システム化計画の王道・バイブルでもあるEA（Enterprise Architecture）に立ち返りながら、概念的な整理をしてみたい。

　EAが登場した当時はスクラッチ開発が主流だったこともあり、まずはBA（Business Architecture：業務プロセス体系）で業務モデルを整理し、DA（Data Architecture：データ体系）レベルでDOA（Data Oriented Approach：データ中心アプローチ）をベースにデータ構造を明確化。次にAA（Application Architecture：適用処理体系）でSOA（Service-Oriented Architecture：サービス指向アーキテクチャ）を取り入れつつ、アプリケーションを設計・開発した。最後のTA（Technology Architecture：技術体系）レベルでそれに見合ったシステム基盤を検討・構築するといったトップダウン型のアプローチが主流であった。

　このモデルに照らし合わせると、AAのレベルでERPやCRM等々のアプリケーションパッケージ製品が出てきた訳だが、日本ではこれまでウォーターフォール型の開発が主流だったこともあり、業務に合わせてシステム機能を追加開発（アドオン）で増やしてしまったことはこれまで述べてきたところだ（関連記事：「2025年の崖」に立ち向かうERP刷新プロジェクトの勘どころ）。

　しかしながら、アプリケーションのレイヤーにおいてSaaS型のクラウド製品が充実してきたことにより、パッケージ製品以上に「業務に合わせてシステムを作る」のではなく、「提供サービスに極力、業務を合わせていく：Fit to Standard」の考え方が重要となってくる。この場合、BAとAAの関係はBAからAAへのトップダウン・主従関係の一方通行ではなくなる。常に提供サービスをデモやプロトタイプシステムで見ながら、変えられる業務は変えていく、要件も柔軟に変更していく「イテレーション型」の進め方が重要となる。

　基幹系システムの肝となる業務とSaaS製品の活用機能が決まってくれば、おのずとそこから必要となるDAやTAも選択した製品アーキテクチャの一定の制約の元で、他システムとの連携を考えて再設計を進めていくことになるだろう。

　他方、既存システムのクラウド化について「リフト＆シフト」という方法が提言されている。これは、まず現在のアプリケーションをそのままIaaSに載せ替えて（リフト）、それからアプリケーションを徐々にクラウドネイティブな構造に書き換えたり、SaaS機能に載せ替えていく（シフト）方法である。しかし、筆者の個人的な意見としては、費用や期間など強い制約条件がある時以外はあまりお勧めしない。

　なぜなら、IaaSに載せ替えただけでは、インフラ費用は安くなったとしても、アプリケーションはそのまま、つまり単なる延命措置にしかならないからだ。アプリケーションを変えないのであれば、経営やビジネス部門からすれば、情報システム部門のテーマであると解釈されがちになる。これでは、BPRや経営の高度化等の基幹系システム更改の本来の目的・本質的な議論が後回しになってしまうからだ。

図1：Enterprise Architectureと対象となる製品・サービス（出典：NTTデータグローバルソリューションズ）
拡大画像表示

クラウド時代はMake or Buy がUse に変わる

　ここでクラウド化のもう一つの側面をお話したい。

　製造業の方々であれば、製品開発において構成部品を自社生産するか他社から購入するかに関する、「Make or Buy」の考え方はなじみ深いだろう。

　企業情報システムにおいても、この考え方は応用できる。スクラッチでゼロからプログラミングしたシステムを「Make」とすれば、パッケージシステムの導入は「Buy」である。本来、ソフトウェアパッケージを購入したら、パラメータ設定等でカスタマイズは最低限で済ませるべきものだ。ところが多くの日本企業は、すべての要件を満たそうと自社流に仕立て直したり、特注仕様を開発先に依頼したりしてきたことで、アドオン規模を膨らせてしまった。つまり、「Buy & Make」であった。基幹系システムの刷新でパッケージ製品を導入するにあたっては、ここでもう一度原点に立ち返り、「標準導入」を真剣に考える絶好のタイミングとなるだろう。

　そして、各社のクラウドサービスが充実してきたことにより、ここに「Use」が加わったのだ。釈迦に説法かもしれないが、クラウドになれば、何が変わるのか？所有ではなく、利用になる。オンプレ上で所有していればアイドリングタイムやピーク時対応の余裕リソースも含めたシステム構成・購入費用になるが、クラウドになれば使った分だけ利用料を支払う形になる。

　インフラ領域についてはハードウェア・ソフトウェア製品ごとの保守やEOSL（End of System Life）が、基本的にはクラウドベンダー側の責任に置いて対応してもらえる。そして、アプリケーション領域においても、多くのサービスが提供されるようになってきた。

　従来のようなパッケージ単位のものもあれば、より粒度の低いライブラリ単位で利用できるものまで様々だ。この結果、企業情報システムの領域においても、既存システムや他のシステムと繋げて、マッシュアップが可能になった。たとえば、DXに欠かせないAIライブラリも、学習データとセットのものがクラウド上で動いているものがほとんどのはずだ。

　ただし、クラウドアプリを活用するからには　これまでのパッケージ活用であった「Buy」以上に、標準利用である「Use」、つまり「クラウドサービスを使い倒す」姿勢が重要となってくる。