過去4回にわたり、DX時代の基幹システムを、様々な製品サービスの組み合わせで実現する際のポイントを確認してきた。

　今回は総括として、具体的なシステムアーキテクチャを示すことと、アーキテクチャが何を実現するのかを解説していく。

　DXレポートに対応した基幹システムを検討中・構築中の方々が考え方の整理、また検討や構築作業のチェックにご活用していただければと思う。

＼ SAP ERPに関連したおすすめイベント・セミナー ／

▼ 目次
・DX時代の基幹システム（SoR）はFit to Standardを組み合わせて実現
・アーキテクチャの確認
・アーキテクチャを適用した後のSoRとSoEの全体感

1. DX時代の基幹システム（SoR）はFit to Standardを組み合わせて実現

1-1. SoRは、複数のFit to Standardを組み合わせる

　まず初めに、これまでの復習から入ろう。

　最初に、ERP製品を選定する。ここで念頭におくべきは、オーダーメイドのシステムを長期に渡りメンテナンスし続けるのは、経営基盤のシステムとしてリスクであること、そしてこれからは先進的な機能がリリースされる都度、積極的に活用することが求められる点である。

　これを念頭におき、まずはERPシステム製品を選ぶ。

　ERP製品・サービスを選択したら、Fit to Standardの原則に基づいて、製品に合わせた業務の遂行可否を判断していくことになる。

　Fit to Standardとは、アドオン開発せず標準機能を徹底活用するERPパッケージの導入方式のことだ。

　とはいえ、ひとつの製品・サービスだけでは、十分な業務遂行がおぼつかないことがままあるため、次善の策として「足りない機能は別の製品で補う」ということを実施する。これが「組み合わせて作る」Fit to StandardのERP基幹システムである。ここまでが第1ステップ。

1-2. 組み合わせで業務×システムを構築

　組み合わせて業務システムを検討すると、ムリなくFit to Standardの実現が可能になる。ERP製品の使い方を理解し、製品に業務を当てはめていくが、それでもどうしても「ゆずれない」領域が発生しうる。その場合には、無理せず狙いを定めて手組み（スクラッチ）のシステムを選択する。ここまでが第2ステップ。

1-3. DX基盤としての基幹システム（SoR）の実現

　そして「組み合わせて作る」ということの意味は、APIで連携する疎結合のシステムの実現という意味で、これを実現しましょう、というのが第3ステップ。

　さて、概念上はそれでいいと思われるのだが、「本当にできるのか？」という疑問が当然ある。この疑問への回答として、これまで各種の技術要素を解説してきた。今回はそのまとめとして、これまでの解説の流れに沿って、具体的なシステムの配置イメージを見ていきたい。

2. アーキテクチャの確認

2-1. Fit to Standardの組み合わせで業務を構成する

　まずFit to Standardの原則に基づいて、基幹システムの製品を選択する。

　ここでは仮に世界で最も利用されているERPベンダーであるSAP社のSAP S/4HANAを選択。

　不足する機能をSaaSで補い、既存のシステムとしてシステムBと連携することを選択する。

2-2. 分散したシステム間はiPaaSでシームレスに連携する

　分散したシステムは、WebAPIで連携されることが望ましい。そして、連携にはローコード・ノーコードのiPaaS（連携基盤）が必要である。

　ここでは、SAP純正品であるCloud Platform Integrationを仮置きした。

　分散したシステム同士は、直接連携をするのではなく、iPaaSを通じて連携することにより、連携データ量や多重度による負荷を専用の基盤で吸収することができる。また、システムBやSaaSが変更されても、APIに変更がない限りシステム全体への影響を限定的なものにできることも将来的に大きなメリットである。

2-3. 譲れない機能は適切な場所に、適切な技術を用いて作成する

　SaaSなどの製品サービスを組み合わせても業務が成立しない、どうしても競争優位性のために必要な機能がある、という場合には、「狙いを定めて作りましょう」だった。

　どこに何を作るのが適切だろうか。

　業務プロセス丸ごと作成する必要がある場合には、最もメンテナンス性が高いローコードでの構築が推奨される。すでに何らかのローコード製品を導入済みであれば、そういった慣れた環境で構築するのが良い。

　図4・図5では例として、「システムB」にOutSystemsと記載した。

　既存の何らかのシステムをOutSystemsで構築しているイメージだ。UiPathも、使い方によってはシステムと呼んでいいような役割を担うことがある。もちろん、ローコードであることを強制するものではない。社内システムをKubernetes上のPythonで構築するのが標準という会社であればそれを選択すればよい。非常にシステム変更の頻度が高いことが予測されるプロセス、または負荷の増減幅が非常に大きいことが予測されるプロセスであった場合も、あえてローコードではなく、こういったコンテナ技術を活用することが考えられる。

　つぎに、業務プロセスの一部分だけ、補足的に構築する場合には、元となる業務と親和性が高い環境で構築するのが望ましい。

　ここでは例えとして、 SAP Business Technology Platform (SAP BTP)と記載した。

　メリットは何かというと、ユーザーが操作できる権限ロールを共通で定義して統合的な制御が可能であるという点や、業務プロセスをつかさどる製品（ここではSAP S/4HANA）との連携テンプレートが提供されている場合がある点だ。

　最後に、ひと工夫必要な場面に触れておきたい。

　それは、厳密なデータ整合性が必要とされる場面だ。

　多くの場合データには親子関係が存在する。この親子関係の整合性を担保しながらデータを更新したいという場合、APIが用意されていればそれを活用するのが第一の選択肢だ。しかし必ずしもこれが用意されていない場面も存在する。メッセージキュー（待ち行列管理の仕組み）を使って「最終的には整合性を合わせます」というのがクラウド上でよく採用される「結果整合性担保」と呼ばれるものであり、できればこれを採用したいが、実際には基幹システムで、一時的なデータ不整合が許容されない場面もある（製品仕様として許可していない場面もある）。その場合には、いっそのこと迷わずに基幹システム（SAP S/4HANA）内に機能構築をしてほしい。場合によってはメッセージキューを活用するよりもシステム構造がシンプルになり、メンテナンス性が向上する。この時、図上に「ABAP Modernize」と記載しているところがもう一つのポイントとなる。言語や手段がモダンであればDXに対応できると考えるのは早計だ。

　使い方や実装の仕方で最新の技術や言語もレガシーになりうるし、以前から存在する手段であってもDX対応は可能だ。ABAPにも属人化を避け、柔軟性・迅速性を確保できるような実装方法が存在するため、ぜひ検討してほしい。

2-4. ERP基幹システムの画面の使い勝手はノーコード・ローコードで改善

　業務機能の実装方法の次に、使い勝手を見ていこう。これだけ複数のシステムが連動する場合、ユーザーがストレスを感じながら作業をすることになる。不要な項目が多いとか、多くの画面を遷移しなければならないとか、システム間で切り替えるときにはログオンしなおして、メニューをたどりなおさなくてはならないといったストレスだ。

　これを解消するのが画面系のノーコード技術である。ノーコードなのでできればユーザーに近い人がやれるようになってほしい。そして、できる限りノーコードで「できる範囲」で多くの改善を実現してほしい。

※100%の改善に拘泥すると、結果として多くのユーザー、多くの画面に対応できないことが発生しうる。またノーコードではなく、ローコードに踏み出さざるを得ず、かつ作っているうちに普通に手組みしているのとそん色ないほどの複雑度にいたるといった事例も存在する。それではせっかくのアーキテクチャの意味が半減してしまう。

2-5. 人もシステムも流動的。テクノロジーで利用者の知識（ナレッジ）を支える

　もともとこういったアーキテクチャを検討してきた理由は、「事業環境の変化に対応できる経営基盤を手に入れる」ためである。つまり、必要であればシステムは変更する。サービスを取り換えるといったことも発生しうる。そうでなくても、これからの従業員は多様な働き方をしていく。システム環境上も、組織環境上も業務オペレーションのノウハウを、各個人に期待することには無理が出てきている。

　この状況を支えるテクノロジーとしてデジタルアダプションを検討したい。図8では仮にWalkmeを選定した。システムがユーザーに寄り添うように使い方をナビゲートすることによって、マニュアル不要なシステムを目指す。

2-6. ユーザーを統一的に管理するセキュリティ基盤

　ここまで、業務機能を実現する仕組みと、ユーザーのストレスを低減して、継続して高いパフォーマンスを実現する方法に触れてきた。ここからはこれらの仕組みを支える共通基盤について触れていきたい。

　まずは、セキュリティの領域である。

　認証認可の仕組みは、ID管理と権限管理と言い換えられる。様々なシステムやプラットフォームを横断する仕組みとなるために、全体としてどのような制御を行うかを検討しておきたい。

2-7. 複雑なマルチクラウドの仕組みの監視・管理はアウトソース

　次に運用。運用にはシステム運用と開発運用がある。

　システム運用は、分散するマルチクラウド、あるいはハイブリットクラウドを監視・運用する仕組みが必要だ。結論から言えば、これはアウトソースしてよいと思われる。テクノロジーとしてはAPM（図8では例としてNewRelic）を配置しているが、こういったテクノロジーとともに、人が管理する運用も考えていくとよいだろう。契約管理などはその最たるもので、非常に細分化された条件を個社で管理することは難しい。サービス事業者への委託を検討したい。

2-8. システム開発の文化もアップデート

　開発運用は、迅速性、柔軟性を備えたシステムに対して、システム変更を効率的に、品質良く、属人化を排除して運用していくための基盤だ。CI/CDと呼ばれるこの領域は、未だ本格的に導入されている企業は多くないが、DXの活動に積極的な企業はいち早く取り組みを開始している。

　以前は「とがった」一部の会社やグループがCI/CDに取組んでいた印象だが、ここ最近は大きな企業での採用が増えてきている印象を持っている。企業が持つシステムの位置づけが変わってきているように思われる。

　図11では導入しやすいフリーな組み合わせ（Redmine、GitLab、Jenkins）を記載している。DX対応のシステムにおいては、システム変更されることが前提となるため、こういった仕組みをはじめから検討しておくことが非常に重要になる。テスト自動化ツールの導入、システム変更に対する忌避感情を変えていくという文化的変革など、地道な努力が必要となる領域だ。

3. アーキテクチャを適用した後のSoRとSoEの全体感

　以上、ここまで復習しながら具体的なシステム配置を見てきた。

　さて、DX時代のSoRがこうして実現されると何が起こるのだろうか？

　その点に触れておこう。

　DX時代のSoRができることは大きく３つある。

1. データ保管
• いつも十分な粒度で整然とデータを保管している
2. 変更容易性
• システムをどんどん変更していくことができる
3. 高度機能活用
• 先進的な機能を導入して生産性を上げたり、これまで気づかなかったような気付きを得られる

　SoEは多くのチャレンジを伴う。システムは生まれたり消えたりする。その時SoRには、これまで管理していなかったような項目、切り口、業務プロセス、組織などが発生しうる。まずは全社的な経営判断に必要な情報はSoR内に保管されていることが求められる。

　この時、標準的なデータ基盤を活用していれば、標準パラメータの範囲内でデータの変化に迅速に対応が可能となるし、また変更を加えた場合でも、標準の範囲内の変更であるため、従来の事業を管理していた同じ基準で、いつでも利活用しやすいデータを保持できるということにつながる。

　SoEの影響が、明確にSoRの構造やシステムに影響を与えるほどのものであった場合（サブスク型ビジネスを開始したといった場合はこの典型だろう）、いかに早く、確実にSoRを変更できるかが課題となる。短期的には疑似的なデータの読替や運用で対応できることもあるが、「見たい切り口でいつでも判断できる」という状態でないのは、チャレンジの足かせにしかならない。DX時代のSoRは、SoEの要求に対して迅速にこたえられる必要がある。

　こうしてデータは常に適切な形で、変化しながら保管される。システムは柔軟に変化し続ける。それは、新しいSaaSを組み合わせるという形かもしれないし、既存の製品・サービスの進化に追従するという形かもしれない。いずれにせよシステムは、市場の要求に応じて「よりよく」なろうとする。そのシステム自身が持つ成長力を、自社の力に変えて、従業員の負荷を低減しながら（そしてより高付加価値化しながら）、経営判断もより高度化、迅速化し、次のDX戦略への施策を検討することができる。

　「DX時代のSoR」「組み合わせて作るSoR」「Fit to Standardで作るSoR」と、様々に表現してきた基幹システムが、DXの取り組みであるSoEを支えられる基盤であることを、ご理解いただけたのではないだろうか。

　SoRとSoEは、互いの結果をフィードバックしながら、各経営層に随時必要な情報を提供する。図12のような二つの円が高速に回転し続ける状況を、DX対応のSoRが目指すシステムであると考えている。このような基幹システムは企業が使う道具のうちの一つ、というものではなく、企業が事業を継続するための基盤であると考えている。

　これまで個々の業務や機能ではなく、アーキテクチャにこだわってきた理由はそこにある。もちろん業務を成立させること、そのための機能を有することは重要な要素ではあるが、今後の基幹システムは「全体として基幹システムに何を望むのか」「そのためのアーキテクチャを構成しうる方向で検討を進められているのか」を問い続けることが、システム部門だけではなく、業務部門にとっても、より重要になっていると考えている。

次回予告

　今回は、これまで散りばめてきたアーキテクチャの要素を具体的なシステム構成におとしこみ、「DX時代のERP基幹システム（SoR）」が何を目指すのか、を改めて整理した。アーキテクチャの総論は、今回で終了する。

　次回からは、少し理解しづらかったのではないかと思われる各論を、ひとつずつ掘り下げていく。