近年、話題となっている「Fit to Standard（フィットトゥスタンダード）」によるシステム導入と刷新。

　従来の ERP 導入において主流であった「Fit and Gap（フィットアンドギャップ）」ではERPパッケージを業務に合わせて開発・カスタマイズする考え方であったのに対して、Fit to Standardでは、「ERP パッケージの標準導入」によりERP パッケージに備わるパワーを最大限に活かしながらベストプラクティスを実現できるだけでなく、定期的なバージョンアップにより最新機能を素早く活用できる点が注目を集めている理由となっている。

　とはいえ、標準機能で全業務のリプレイスが可能な企業がある一方で、Fit to Standardだけでうまくいくのか疑問を抱いている企業も多い。

　そこで「ERP基幹システムは “作る” から “組み合わせる” 時代へ。Fit to StandardでDXを加速」と題し、ERP基幹系システムはどうあるべきかについて解説していく。連載第１回目の本記事では、本題への導入とし、市場の変化に迅速に追従できるERP基幹システムをデザインするうえで、必要となる考え方について解説する。

▼ 目次
・DXレポート、DXレポート２のおさらい
・アドオン開発と個別カスタマイズにより肥大化した基幹システム
・DX時代の基幹システムとは
・Fit to Standardで考慮するポイントとは
・「足りないものはつくる」から「足りないものは他サービスと組み合わせる、補う」に必要な要素
・「足りないものは他サービスと組み合わせる、補う」を実現させる基幹システムの図解

1. 「DXレポート」「DXレポート２」のおさらい

　DXを推進するためには、データの収集と管理、活用が重要である。

　企業内のデータの収集/管理という面においては、ERP製品、特にSAP製品は非常に優れた製品と言えるだろう。現に、ERPの導入理由として、サイロ化されたデータの集中管理/リアルタイム管理による企業状況/経営状況の見える化が上げられ、ERPを導入することにより、リアルタイムに経営状況を分析/把握できる基盤を手に入れた企業は多数ある。

　しかし、導入時、自社独自の業務プロセスや、日本独自の商習慣に合わせ、独自プロセスをアドオンという形で追加開発してきたため、ERPシステム自体が強大なレガシーシステム化してしまったのが今の状況であり、基幹システムがDX推進の足を引っ張る要因となっている。

　こうしたERP製品をはじめとした基幹系システムについて考えるうえで重要な指標となるのがDXレポートだ。（2018年9月発行）

　DXレポートでは、老朽・複雑化した古い基幹系システムでは、データの利活用がうまくいかず、保守運用コストは跳ね上がり、セキュリティリスクも高まる危険性がある、と提言された。そして、こ のまま古い基幹系システムを使い続けると、国内における経済的損失は、2025年以降、最大12兆円（／年）発生。これが「2025年の崖」である。（図１）

　DXレポートから2年後、「DXレポート２」が中間報告という形で発表された。

　DXレポート2では、90％以上の企業がDXに取り組めていない事実と、「DX=レガシーシステム刷新」と本質ではない解釈が是となったと警鐘が鳴らされた。レガシーシステムを刷新してもDXへの対応は不十分である、との指摘だが、いったい何が不十分なのだろうか？

　DXレポート、DXレポート２では下記について強調している。

• 変化の激しい現代において、要件定義をした「とき」と、システムが実稼働する「とき」では、経済的・社会的情勢がまったく異なる可能性があり、いままでのように要件定義から入るウォーターフォール型の開発手法では、時代の変化に柔軟に対応することは不可能である
• DX化で企業が実現すべき姿は、レガシー化した基幹系システムの刷新だけでなく、顧客・市場の変化に柔軟に対応しつつ、クラウド・モバイル・AIなどデジタル技術をマイクロサービス・アジャイルといった手法で取り入れ、素早く新たな製品、サービス、ビジネスモデルを国際市場に展開し企業成長を遂げることである

　つまり、レガシーシステムの刷新は最低限必要でありながら、それだけでは不十分であり、いままでと同じ考え・方式・アーキテクトでシステムを構築していたのでは、DXに対応できない、と伝えている。レガシーシステム刷新時に、システム構築の考え方・開発手法・システム全体のアーキテクトを全面的に見直す必要があるにも関わらず、「上物のERPアプリ」を刷新して満足してしまったことに問題がある、とDXレポート２は指摘している。

2. アドオン開発と個別カスタマイズにより肥大化した基幹システム

　諸外国では、SAP社などに代表されるERP製品などの基幹系システムは、経営判断を効率的かつ迅速に実施するために導入することが主流であり、製品パッケージに業務を合わせるのが一般的だ。

　特にSAP社のERP製品は、各業界を代表する企業の業務プロセスをベストプラクティスとして取り入れて作られたパッケージであり、各業界で必要とされるプロセスは概ね標準機能で対応できると世界的に評価されている。一方、日本では、自社独自の業務プロセスや、日本独自の商習慣に合わせ、独自プロセスを基幹システムに追加で開発するのが主流となり、世界標準のERPパッケージの使い方から大きく乖離していることが昔から指摘されている。

　結果として、業務が拡大するごとに追加開発を重ね、肥大化した追加開発資産がレガシーシステム化し（＝技術的負債状態）、DXの推進だけでなく急速に変化する時代の流れにシステム変更が追い付かず、ERPシステムが業務の足を引っ張る状態となる。

　本来、定期的にバージョンアップし、最新の機能のメリットを享受できるERPパッケージの利点が全く生かされていないだけでなく、レガシーシステム化しにくいはずのERPパッケージが、企業の中で一番大きなレガシーシステムとなっているのは、ものすごく残念な状態であり、同じERPパッケージを活用しているにも関わらず、DX推進において諸外国に大きな後れを取る要因となっている。

3. DX時代の基幹システムとは

　DXを推進するため、企業内のデータの収集/管理という面においてERP製品、特にSAP製品は非常に優れた製品であるが、導入時、自社独自の業務プロセスや、日本独自の商習慣に合わせ、独自プロセスをアドオンという形で追加開発してきたため、ERPシステム自体が強大なレガシーシステム化してしまったのが今の状況であり、基幹システムがDX推進の足を引っ張る要因となっている。

　これからの基幹システムに求められるものは、データの集中管理/リアルタイム管理はもちろんのこと、顧客・市場の変化に柔軟に対応し、デジタル技術をマイクロサービス・アジャイルといった手法で取り入れ、素早く新たな製品、サービス、ビジネスモデルを市場に展開し企業成長を遂げることを下支えする基盤としての役割だ。

　SAP製品は、これらの要求に十分応えられる製品だが、その性能を生かすためには「Fit to Standard による導入（標準導入）」が欠かせない。「Fit to Standard」で導入できなかった場合、現在同様、柔軟性に欠ける巨大なレガシーシステムを誕生させることになる。

※ ERPを導入することにより、リアルタイムに経営状況を分析/把握できる基盤を手に入れた企業がある一方で、ERPを導入したにも関わらず、経営状況を思うように分析/把握できない企業も多い。なぜこの違いが発生するかについては、別の記事にて解説する。

4. Fit to Standardで考慮するポイントとは

　過去に導入したERPパッケージがレガシーシステム化してしまい、扱いに困っている企業ほど、Fit to Standard（標準導入）の重要性を身に染みて感じていることだろう。

　しかし、Fit to Standardを推進する際に懸念される「現場からの反発」や、「自社が持つ競争優位が失われてしまう点」を危惧し、Fit to Standardでの導入に踏み切れない企業や、プロジェクトを推進するうちに、なし崩し的にアドオン開発を許容してしまった企業は数多い。

　これまでERPパッケージの導入では、自社業務にFitしない部分について、下記の2択で検討することが多かった。

• 現場業務を変える（業務変革）
• 独自プロセスを追加する（アドオン開発/ERP外でのスクラッチ開発）

　昨今では上記の２つに加えて、下記の選択肢がある。

• 他サービス（SaaS/PaaS）の活用、という「第三の道」
• ノーコード/ローコードでの開発、という「第四の道」

　この第三の道や第四の道を考慮せず、経営陣の「強い意思」や、外部コンサル会社の「チェンジマネジメントの技術」に頼ってFit to Standardでの導入を目指しても、これまでの歴史が示す通り、非常に危ういものであると言わざるを得ない。

　Fit to Standardは手段であり、目的ではないことを意識し、

1. 現場業務を変える（業務変革）
2. 独自プロセスを追加する（アドオン開発/ERP外でのスクラッチ開発）
3. 他サービス（SaaS/PaaS）の活用
4. ノーコード/ローコードでの開発

をうまく組み合わせ、DX時代の基幹システム、すなわち、顧客・市場の変化に柔軟に素早く対応できる基幹システムを構築することが重要だ。（選択肢の優先順位は1→3→4→2）

5. 「足りないものはつくる」から「足りないものは他サービスと組み合わせる、補う」に必要な要素

　さて、「第三の道：他サービス（Saas/Paas）の活用」、「第四の道：ノーコード/ローコードでの開発」(局所的に「第二の道：独自プロセスの追加」)によってDX時代の基幹システムを実現するために重要なことは何であろうか。それは以下の２点である。

• インテグレーション基盤
• 運用/CICD基盤

5-1. インテグレーション基盤

　様々な製品/サービスや、ノーコード/ローコードで開発した独自システムが複数存在すると、必ず問題となるのがインテグレーション部分だ。

　インテグレーション基盤に問題があると、データが分散化サイロ化されるだけでなく、システムの利用者（ユーザー）にとって使いにくいシステムとなり、結果として生産性が低下することがありうる。インテグレーション基盤を考えるにあたって重要なことは、システム利用者に複数のシステムを利用していることを意識させないことであり、この中には、プロセスインテグレーション、UXの統合に加えて、これらを支える認証認可などのセキュリティ技術も含まれていることを強調しておきたい。

5-2. 運用/CICD基盤

　CI/CDとは、Continuous Integration / Continuous Delivery（継続的インテグレーション/継続的デリバリー）の略で、ソフトウェアのテスト、環境の管理、各環境へのリリース管理を自動化したうえで、リリース後のシステム状態を見える化し、常に開発や各環境からのフィードバックを得ながら高品質にシステムを改変運用し続ける技法のことだ。CI/CDを取り入れることで、システムに迅速性や継続性を付与しつつ、品質を向上させる事ができる。

　DX時代の基幹システムは「顧客・市場の変化に柔軟に素早く対応できる」ことが求められることから、様々な製品/サービスを素早く、柔軟に組み合わせたり、切り離したりできる基盤や体制（CI/CD環境）、そして、製品/サービスが入れ替わっても、運用の品質が担保されることが重要だ。

　運用基盤を構想/設計せずに、小手先で様々なSaaSサービスやアジャイル開発を取り入れても、すぐに行き詰る結果を招く。

6. 「足りないものは他サービスと組み合わせる、補う」を実現させる基幹システムの図解

図 2. 「足りないものは他サービスと組み合わせる、補う」を実現させる基幹システムのイメージ図

　業務システムのコア（中心）は、SAPを中心としたERPパッケージである。追加の開発など一切せずFit to Standardで導入/稼働する。

　足りない部分は、ERPパッケージ自体に追加開発（アドオン開発）で作りこむのではなく、他Saasや他パッケージを組み合わせて対応する。（第三の道）

　他のサービスで対応できない場合も、なるべく作りこみを行わずノーコード/ローコードの技術を取り入れ、柔軟に迅速に基幹システムを構築する。（第四の道）

　最後に、どの道にも該当せず、企業の競争力の源泉になるような機能は局所的に、しかし人的/技術的にレガシー化させないようにしっかり作る。（第二の道）


　ここで大事なことは、こういう構想からＤＸ時代の基幹システムを考え始めることである。

そしてその前提で、必要なシステム要素をアーキテクチャとして検討する事である。

　Fit to Standardに気を取られると全体像を捉えることに時間を割く事ができなくなりがちだが、必要となる機能は、環境変化や技術進化により変わり続けることを考えるならば、これからの基幹システム構想においてアーキテクチャ構想の重要性は格段に高くなった。

　次回は、DX時代の基幹システムを支える技術要素の全体像、アーキテクチャに焦点を合わせて解説する。続きは以下をご欄いただきたい。