2024年12月3日に、オンラインセミナー『DX時代、基幹システムの更新に「何億・何十億」もかけるべきなのか？ ～コスト削減と柔軟性・俊敏性の向上を実現する新しいアプローチ～』を開催いたしました。
この記事では当日用いた資料を公開し、そのポイントを解説しています。
目次
基幹システムの課題の歴史と、今採用すべき刷新の形
基幹システムの課題は多くの企業にとって、長年にわたり重要な課題であり続けています。その歴史を振り返ると、技術の進化と共に新たな問題が生まれ、その解決策を模索する過程が繰り返されてきました。そこで、本セミナーでは、これまでの基幹システムの歴史を踏まえ、今後進んでいくべき方向性について考えていきます。
まず、基幹システムとは、企業経営や活動に欠かせない業務を支えるシステムを指します。例を挙げるとERP（統合業務パッケージ）が代表的ですが、業界や業種によってはスクラッチ開発などの形態を取ることもあります。例えば、金融業界では口座管理システム、建設業界ではプロジェクト管理システムなども基幹システムの一例です。これらのシステムは1990年代から現在に至るまで、技術進化とともに変化してきました。
1990年代には、企業内のシステム化が始まります。基幹システムはその中心的な存在でしたが、当時は紙やエクセルからのシステム化が目的の中心であったため、機能も必要最低限でしかなくシンプルなものでした。しかし、2000年代になると、ERPやJava、.NETなどの技術を用いたシステム構築が進みました。この時期の大きな問題として、開発されたシステムが業務部門のニーズに十分応えられず、結果的に「使われないシステム」が企業に残されるというものが挙げられます。せっかく多額のコストをかけたにもかかわらず、従来の紙やエクセルの運用に戻るケースが多発しました。
その後は、「使ってもらえるシステム」を目指し、細かい作業にもフィットするようにパッケージやERPであってもカスタマイズが盛んに行われるようになりました。しかし、これにも新たな問題が伴います。過剰なカスタマイズによってシステムが肥大化し、例外業務にも対応可能な「業務にとって至れり尽くせり」の基幹システムになっていったことです。その結果、非常に高額なシステムが多くの企業に導入されましたが、これらは現在老朽化が進み、更新の必要性に迫られています。
2020年代に入り、技術の進化はさらに加速しています。クラウド技術を活用した新しいアーキテクチャや、ローコード・ノーコードツール、SaaSやPaaSといった新たな手法が登場し、システム構築の選択肢が広がりました。これにより、現在では従来のような多額のコストをかけずとも、柔軟かつ俊敏なシステム構築が可能になっています。
上記のような歴史を踏まえ、基幹システム刷新時には、こうした最新技術を活用することをご提案します。中でも特に注目すべきは、マイクロサービスを基盤としたアーキテクチャです。この方式は、従来の一枚岩的なシステム構造から脱却し、モジュールごとに独立性を持たせることで、更新や機能追加が容易になるというメリットを持っています。そのため、DXの実現に向けた鍵となることが期待できるのです。
基幹システム刷新時、アーキテクチャの選定で考慮すべき重要な要素とは？
次に、基幹システム導入に関するトラブル事例を机上検証したうえで、適切なアーキテクチャの選定がプロジェクトの成功にどのように寄与するかを考えます。
ここでは、大手食品メーカーにおける基幹システム刷新プロジェクトの事例を取り上げました。このプロジェクトは、ERPとしてSAPを導入するものらしく、当初3年間で215億円の予算が計画されていたようです。しかし、実際には予算が約1.5倍に膨れ上がったと言われています。さらにシステムトラブルによって商品の出荷が2か月間停止する事態が発生しました。製造業においてシステムトラブルがここまで大きな影響を及ぼすのは非常に稀です。このような特徴があるため、本事例に着目しました。
トラブルの原因については、計画段階での問題が指摘できるかと思います。粗い試算をしてみると、最盛期にはおそらく少なくとも600人程度の人員が同時にシステムを開発するような計画が組まれていることが読み取れます。このような規模のプロジェクトは、運営が非常に困難です。なぜなら、ソフトウェア開発は形のないものを作り上げる作業であり、高層ビルを作るような大人数でのモノづくりには適していない特性があるからです。さらに、費用計画から推測するに、計画当初から多くのカスタマイズが要件として盛り込まれていたことが考えられます。ERPパッケージはできるだけカスタマイズせずに使うことが前提になっているものです。要求を満たすために、最初から多くのカスタマイズを要するのであれば、ERPパッケージそのものの選定が正しかったのか？もしくは業務をERPに合わせることを前提に進めるべきだったのではなかったのか？という疑問が生じます。
こうしたトラブルを防ぐためには、業務をパッケージに合わせる前提で進めるか、慎重にアーキテクチャを選定する必要があります。アーキテクチャには、技術の進化に伴い、常に洗練されたものへと変化していく特徴があります。本事例のような場合であれば、最新のアーキテクチャを採用することで、多くの課題を事前に回避できる可能性が高まります。従来のシステムが一品一様に一から開発していたのに対し、現在のシステムは部品化、標準化されたパッケージや、SaaS型のソリューションが主流となっています。これにより、コストや時間の削減が可能になるだけでなく、将来的な拡張性や保守性も向上します。
ただし、標準化されたアーキテクチャには制約が伴います。ショッピングモールに店舗を出店する場合に例えてみましょう。
多数の店舗が足並みを揃える必要のあるショッピングモールにおいて、自店舗のみが他店舗と異なる営業時間を設定しようとしたり、他店舗にはない駐車場を要求したりすると、その実現のためには多大なコストと時間を要してしまいます。標準仕様に沿わない要求は、大きな負担になるということです。アーキテクチャの選定も同様に、自社の業務要件と標準仕様との適合性を慎重に評価することが不可欠なのです。
基幹システムのリプレースは、単なるシステム更新に留まらず、業務全体の効率化や競争力向上に直結する重要なプロジェクトです。その成功には、適切なアーキテクチャの選定が鍵となります。
SaaS Integrationを活用した基幹システムの構築方法
続いて、マイクロサービスアーキテクチャの考え方を取り入れた基幹システムの特徴について解説します。
マイクロサービスアーキテクチャは、巨大なシステムを一つのアーキテクチャで構築せず、小さな単位に分割しAPIで連携する考え方です。この手法により、業務プロセスに応じた最適なツールやプラットフォームを柔軟に選べます。例えば、財務会計や生産管理にはERP、勤怠管理や営業支援にはSaaSソリューション、原価管理はスクラッチ開発といった選択をすることで、効率的なシステム構築が可能になります。
一方で、既存システムの活用も重要です。生産管理システムの一部を新しいAPIで連携させることで、大幅な改修を避けつつコストや時間を節約することができます。また、標準的なSaaSやERPで対応できない業務は、クラウドネイティブ環境でカスタム開発を行うことで、柔軟性と拡張性の高いシステムが構築できます。こうすることで、独自業務にも迅速かつ効率的に対応ができるようになります。
実際に、従来型の一体型システムでは、データの一部に問題が生じた際に全体への影響が大きくなってしまった事例があります。食品メーカーのシステムトラブルについて、賞味期限の短い商品のデータ管理に問題があったことで、全体の出荷システムが数ヶ月にわたり停止したという報告が公開されていました。もしここでマイクロサービスアーキテクチャを採用していれば、影響範囲を限定的に抑え、迅速な修復が可能になっていたかもしれません。
SaaS Integrationは、業務システムの「コンビニ化」とも言えるものです。必要なときに必要な機能を手軽に利用できるSaaSを組み合わせることで、初期コストを抑えつつ、柔軟で効率的な基幹システムを構築できます。ただし、SaaS利用には業務をシステムに合わせる必要があるため、適合性を慎重に見極めることが求められます。
以上のように、マイクロサービスアーキテクチャの導入やSaaS Integrationを活用した基幹システム構築では、既存システムの活用、適切なツールの選定、データ管理の工夫が鍵となります。柔軟性と効率性を両立させるこのアプローチは、変化の激しいビジネス環境において非常に有用です。
事例から学ぶ、基幹システムリプレースとマイクロサービスアーキテクチャの最適解
最後に、基幹システムのリプレースにおけるマイクロサービスアーキテクチャの導入事例を紹介し、企業がどのようにして効率的なシステム構築を実現しているのかを解説します。
ある大規模企業の事例では、標準的な業務と特殊な業務を明確に分ける方針が採られました。標準業務には可能な限りSaaSを活用し、特殊業務についてはクラウドネイティブなスクラッチ開発を行うというものです。既存のERPパッケージを財務・管理会計システムとして活用し続けながら、一部の特殊業務をスクラッチで再構築する手法で、勤怠管理や工数管理に関しては既存システムの大規模なカスタマイズを行わず、SaaSをそのまま利用する形でスリム化を図っています。一方、経費申請など業務特有の特殊性が強い部分については、適切なSaaSを選定した上で業務フローを調整することで対応しました。
また、SaaSインテグレーションの事例では、中規模企業が基幹システムを完全にSaaS型で運用する方法を選択しました。この企業は、専任のシステム管理者を持たない状況で、複数のSaaSベンダーの製品を組み合わせて運用を進めています。このようにして、会計や原価管理、勤怠管理、営業支援といった業務ごとに異なるSaaS製品を採用し、全体的な効率性を大幅に向上させることができました。なお、近年ではSaaS同士を連携するための専用ツールも存在しており、これらを活用することでさらなる効率化も可能とされています。
これらの事例から導き出せるポイントは、基幹システムのリプレースにはAPIの公開が重要であり、クラウドベースのアーキテクチャが求められることです。特に、複数のSaaSを組み合わせて利用する場合は、APIの有無がシステム全体の柔軟性に大きく影響します。
基幹システムリプレース・アーキテクチャ選定のご相談はNCDCへ
NCDCでは、お客様の現状やご要望に合わせた基幹システムリプレースのご提案をいたします。実現が難しそうな詳細な要望がある場合はもちろん、システムのリプレースを考えているのだけれど、具体的なことはまだ何も決められていない、といった段階からでもご支援が可能です。
まずは一度、お気軽にご相談ください。
