前回の記事では、DXレポートの振り返りから、既存の製品サービスをそのまま活用すること（Fit to Standard）の重要性についてみてきた。そして、不足する機能は、自前で作るのではなく、組み合わせて使うという選択肢を提示した。

　今回の記事では、この前提に立った際に、システムに要求される要素（アーキテクチャ）について触れていきたい。

　非常に多岐にわたる要素に触れる必要があるため、今回は、基礎的な用語整理とポイントとなる3つの要素の確認を行う。

　その後、一つめのポイントとしてクラウド（SaaS・PaaS・iPaaS）の活用というトピックに入っていきたい。

　DXレポートに対応した基幹システムを検討中/構築中の方々への考え方の整理、あるいは自社の活動のチェックに、ぜひご活用いただければと思う。

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

▼ 目次
・SoRとは、SoEとは
・基幹システムに求められるアーキテクチャのポイント
・基幹システムはクラウド（SaaS・PaaS・iPaaS）を組み合わせて作ろう

1. SoRとは？、SoEとは？

　よく「基幹システム」の意味でSoR（System of Record）という言葉が使われる。SoE（System of Engagement）と対で使われることが多い言葉だが、アーキテクチャ全体を語るうえで避けて通れないキーワードなので、SoEとSoRの違いについて触れておきたい。

• SoRとは
• SoEとは
• SoRとSoEの関係は車の両輪

1-1. SORとは

　SoRとはSystem of Recordの略で、正確に記録することを重視して設計されたシステムを指し、業務システムの意味で使われる。SAP S/4HANAなどERPを含む基幹システムが該当し、品質・安定性・継続性がSoRの特長・メリットである。

1-2. SoEとは

　SoEとはSystem of Engagementの略で、企業と顧客とのつながりを重視して設計されるシステムを指す。顧客に利用されることで競争力強化や収益拡大を目指すサービスが中心で、正確性・継続性よりも、市場の変化に応じた俊敏性が重視される。

1-3. SoRとSoEの関係は車の両輪

　一般的にDXというと、SoEが注目されがちだ。これまで考えられなかったような方法で顧客とつながっていこう、という取り組みが、DXの文脈で語られることが多いためだ。

　しかし、激しい市場変化に対応するためには、SoEで行った試行錯誤の結果が、できるだけリアルタイムにSoRに連携されて経営判断がなされる必要がある。その意味で、SoEとSoRは車の両輪とみなすことができ、SoRも柔軟性・迅速性が要求されている。

　SoRが個別開発の塊では市場変化に対応できないため、Fit to Standard（標準導入）が強調されてきている。

　以降、「基幹システム」の意味でSoRという言葉を使用する。

　尚、Fit to Standardについての解説は以下よりご覧いただきたい。

2. Fit to Standardを中心とした基幹システム（SoR）に求められるアーキテクチャのポイント

　Fit to Standard（標準導入）を中心とした基幹システム（SoR）のアーキテクチャを検討するにあたって成功のポイントは3つ。簡単に3つの内容について触れておこう。

• クラウド（SaaS・PaaS・iPaaS）の有効活用
• 多様な人にストレスフリーで使ってもらう
• 運用の負荷低減

ポイント1. クラウド（SaaS・PaaS・iPaaS）の有効活用

　Fit to StandardでSaaSを活用する。システムが複数の組み合わせで作られたときにデータの自動連携が必要、という点と、それでも競争力の源泉となりそうな機能拡張をする場合に、どういった考慮点があるかという点を検討する。

ポイント2. 多様な人にストレスフリーで使ってもらう

　良い仕組みが存在していても、使われなければ意味がない、あるいは使うために多大な労力を必要とするような仕組みになってしまうと、企業としての生産性は低下する。この対応をするための機能配置について検討する。

ポイント3. 運用の負荷低減

　クラウド上に分散したシステムは、各クラウド事業者にて運営されている。API単位で契約や事業者が分散する中、極力運用負荷を低減するための考慮点を検討する。また、ローコード、ノーコードで作成したものの版管理や、迅速性、品質、属人化排除を実現するための仕組みについて検討する。

　アーキテクチャそのものはプロダクトを選ばないが、具体性を持たせるためSAP社のERP製品、SAP S/4HANAの活用を前提とする。

3. 基幹システムはクラウド（SaaS・PaaS・iPaaS）を組み合わせて作ろう

　基幹システムのアーキテクチャを複数のクラウド（SaaS・PaaS・iPaaS）を組み合わせて構成した際に、個々の構成要素の連携が必要である理由と連携手法について解説する。

• Fit to Standardとシステム間連携のデメリット
• システム間連携ならWeb API
• Web APIの魅力
• Web APIの注意点
• iPaaSの活用
• 競争力の源泉となる仕組みはしっかり属人化排除で作成

3-1. Fit to Standardとシステム間連携のデメリット

　Fit to Standard（標準導入）で複数のシステムを導入したときに、ユーザ体験がどのようになるのかを考えてみよう。

　例えば、一つのシステム（システムAとする）で商談から受注まで対応して、別のシステム（システムBとする）で受注から請求までを対応したとする。

　システムAで受注処理したら、その内容をシステムBに入力する必要がある。

　この時、取引先ID、商品コード等が異なる番号体系の場合、何が起こるだろうか。人間が解釈して別の番号体系で個別に入力しなおす必要が発生する。

　このように、複数のシステムを利用するということは、そのまま放っておくと、純粋に手間が増えるということだ。

　単に手間が増えるというだけでなく、マスタ設定の誤り、二重入力による入力内容の不整合等があると、SoRとしての役割を著しく損なうことになりかねない。

　こうなってしまうと、Fit to Standard（標準導入）を実現するために複数のシステムを連携して構築したということが、むしろ業務生産性にとって足かせ、デメリットになってしまう可能性がある。
これが、Fit to Standardとシステム間連携の関わりが深いトピックとして議論される所以である。

3-2. システム間連携ならWeb API

　これまで多くのシステム間連携で活用されてきた手法は、FTP/SFTP を用いたファイル連携ではないだろうか。ファイル連携は大量のデータを連携するのに適しており、その限りにおいて今でも有力な選択肢だ。

　また、APIと言ったとき、SAPの世界ではBAPIとかRFCといった手法がとられていた。比較的高速に処理が行える方法だが、独自の仕様であり、独自のコネクタを準備する必要があるなど制限事項も多かった。

　これに対して、SAPはSAP S/4HANAとともに「よりオープンな仕組み」を採用した。Rest APIやODATAといった手法である。これらはSAP社が定めた連携手法ではなく、HTTP/HTTPSを用いてどのような言語、環境からでも連携できる手法である（一般的な名称としては、Web APIと呼ばれる）。

　今後我々が主に採用していきたいのは、このオープンなWeb APIである。

3-3. Web APIの魅力

　一言で言えば、任意のタイミングで、任意の単位で、オンデマンドで必要な情報だけを連携できるようになる、というのがWeb APIの魅力である。

　例えば、先ほどの例のように受注までのプロセスを司るシステムAで、受注のタイミングで顧客の与信状況を参照したいとする。

　与信情報はシステムBにしか存在しない場合、これまでのバッチ系の連携ではせいぜい前日閉局時点での情報を参照する事ができるかどうかというところだ。しかも個別開発が必要となる。

　一方Web APIの世界では、画面表示時点での与信情報をリアルタイムで参照することができる。その実現のために必要な事は、システムAからシステムBへのAPI呼び出しの実装のみである。システムAでは、与信情報を保持しなくて良い。シンプルでメンテナンスしやすく、機能的にもより良いものを簡単に手に入れる事ができる。

　昨今、耳にするようになった「チャットボットを通じて仕事を行なう」といった働き方も、このオープンなAPIによって実現されている。承認が必要なオペレーションが発生した時に、チャットツールが承認者へ必要な情報を提供する。忙しい承認者は、チャットボットの質問に答えるだけで、システムを起動せずに承認を実行する事ができる。こういった使い方、働き方が、いよいよSAPを活用したSoRの世界でも実現可能となってきた。

　これらはすべてWeb APIによって実現可能である。

3-4. Web APIの注意点

　Web APIはオープンな仕組みである。それだけにセキュリティは気になるところだ。

　接続方法には二重で都度認証認可を行う方式や、あらかじめ取り交わしておいた鍵を用いる方法などさまざまだ。いずれの手段を選択するにしろ、この手続きは個別にプログラム内で記載するのではなく、ポリシーを持って集中管理する必要がある。

　システムの可用性に関してはどうだろうか。

　分散したシステムは、各サービス事業者が運用しており、障害だけでなく、計画的なメンテナンスやサービス提供時間の考え方に従って、適宜停止する。この運用は利用者にはどうすることもできず、データ連携で考慮するか、業務運用を調整する必要がある。


　エラーが発生したときはどうなるだろうか。

　一般的にWeb APIには、複数のAPI呼出を行った際にデータの整合性を担保する機能は備わっていない。通常は、「結果整合性担保」と呼ばれる、時間差で最終的にデータ整合性が担保されるような仕組みを導入することになる。


　大量データの連携はどうだろうか。

　これも一般には、Web APIは1件ずつの登録に対応していることが多い。1万件のデータを連携するためには1万回APIを呼び出すことになるが、直列で実行すると処理が終わらないということになりかねない。当然並列処理を実装することになる。

3-5. iPaaSの活用

　iPaaSとは「Integration Platform as a Service」の略で、分散したシステムを連携・統合させる文脈で昨今非常に注目を浴びているものである。有名なところではInformaticaといった製品が存在する。これまで触れてきた「様々なシステム間連携」を実現するための専用製品サービスと考えていただくと良い。

　SAPの世界では「Cloud Platform Integration（CPI）」というものが存在する。この製品の特長は、SAP製品同士のシステム間連携に関しては、ある程度典型的なシナリオについて「出来合いのパッケージ」が配布されている点である。個別に作る必要はなく、システム間でシナリオを有効化して、必要なパラメータを設定すればとりあえずは動く。個別で開発をしなくて良いのは大きなアドバンテージだ。もちろん、前章で触れたセキュリティの集中管理や、可用性考慮、結果整合性担保、並列処理を行うための専用の機能が備わっており、これも個別で開発する必要がない。

　シナリオに存在しない機能の構築も、基本は部品を並べてパラメータ設定することでフローを構築でき、それで賄えない部分だけスクリプトを埋め込むというローコード開発のプラットフォームだ。活用しない手はない。

3-6. 競争力の源泉となる仕組みはしっかり属人化排除で作成

　「システム間連携に留まらない、全く異なるプロセスが、どうしても自社の特性として必要」ということもあるだろう。

　最後にその方法について触れておきたい。

　一言で言えば、その場合は個別で構築するより方法がない。ただし、構築する際に、注意いただきたいのは、ERPにできることはERPにやらせた方が効率的だということだ。

　APIで処理させられるものは処理させた方が良い。また、厳密なデータ整合性が必要とされるような場面では、思い切ってERP内に構築した方が良い。そして、その時にはしっかりとモダナイズされた手法で構築し、属人化排除や迅速性柔軟性の担保を実現すべきだ。

　つまり、ERPの外で構築する機能は、ERPではできないプロセスで、ERPのデータとの整合性が厳密に求められない機能、ということになる。

　とはいえ、できるだけ個別で作りたくはない。なおかつ、先ほどデータ連携で指摘したような注意点は、ここでも考慮すべき事項となる。

　そこで登場するのがPaaS（Platform as a Service）である。

　SAPでは、BTP（Business Technology Platform）というPaaS環境を保持している。例によって、SAPの各種製品サービスと連携する仕組みを構築するにあたって便利な各種機能をあらかじめ備えている。ここまでくるとコーディングはある程度避けられないが、コンテナを活用するオープンな仕組みと、SAP社が提供するPaaSの各種機能、ライブラリやツールを活用することで、トータルの開発運用コスト（負荷）は最適化することが可能だ。

　次回以降で、こういった場面でも「できるだけ作らない」ために何ができるのか、それでも作った資産が足かせにならないためにどのようなことをすべきか、といった点に触れていきたい。

次回予告

　本記事では、DX時代の基幹システム（SoR）に求められるアーキテクチャの1回目として、全体を概観したうえでSaaS・PaaS・iPaaSの有効活用について確認してきた。

　複数のシステムを組み合わせること、特にマルチクラウドに分散する仕組み（およびそのサービス事業者）とうまく付き合っていくためにどのようなポイントが必要になるのかを確認し、中でもまずは課題となるシステム間連携についてそこで活用される技術と、考慮点を確認した。

　次回は、多様な人にストレスフリーで使ってもらう（効率的に使われなければ意味がない）というテーマで引き続きアーキテクチャを見て行きたい。

　尚、本記事の続きやバックナンバーは、以下よりご覧いただきたい。