• スマクラ
  • お役立ち情報
  • EDIコラム「「SAP ERP 2027年問題と富士通メインフレームの生産中止」基幹システム刷新とIT人材不足の乗り越え方を考える」

EDIコラム「「SAP ERP 2027年問題と富士通メインフレームの生産中止」基幹システム刷新とIT人材不足の乗り越え方を考える」(2024/3/8更新)

「SAP ERP 2027年問題と富士通メインフレームの生産中止」待ったなしの基幹システム刷新とIT人材不足の乗り越え方を考える

現在、SAP ERPの2027年問題や2030年における富士通メインフレームの生産中止などにより、多くの日本企業が基幹システムの刷新を早急に推し進めなければならなくなっています。その中で課題として浮上しているのが、限りあるIT人材のリソースを基幹システムの刷新やのちの保守・運用にどう割り振るかです。

ここでは、IT人材の有効活用という観点から、基幹システムの刷新と運用をどのようにデザインすべきかについて考えます。

基幹システムを巡る2つのインパクト

現在、日本企業の基幹システムを巡っては「SAP ERPの2027年問題」と「富士通メインフレームの2030年問題」の2つをどう乗り越えるかに注目が集まっています。
では、これらの問題は、どのようなインパクトを企業ITに及ぼしているのでしょうか。まずは、その点から確認しておきます。

■「SAP ERPの2027問題」のインパクト

「SAP ERPの2027年問題」とは、基幹業務を支えるERPとして広く普及している「SAP ERP 6.0」の標準保守期限が2027年に終了することを指しています。

現在、この問題を早急に乗り越えるべく、SAP ERP 6.0を使用してきた企業の多くが、SAP S/4HANAへのシステム移行に取り組んでいます。SAP ERP 6.0で構築したシステムの移行先としてSAP S/4HANAを選ぶのは、他の仕組みを使って一からシステムを構築し直すよりも、同じSAPの製品を使ってシステムを刷新したほうが少ない手間で済むとの判断からです。

この判断に間違いはないといえるでしょう。ただ、SAP ERP 6.0からSAP S/4HANAへの移行にも相応の工数がかかるのが一般的です。理由は、SAP ERP 6.0とSAP S/4HANAとではデータベースの構造が大きく異なるほか、標準でサポートされている機能やベストプラクティス(テンプレート)にも違いがあるためです。そのため、SAP ERP 6.0で構築したシステムをそのままSAP S/4HANAに乗せ換えられるわけではなく、それによってSAP S/4HANAの利点を生かせるわけでもありません。SAP S/4HANAへの移行時には、ERPを適用する業務範囲を改めて定めてシステムの要件を定義し、実装(開発)を行うといったステップを踏むことになるのが通常です。そして、システムの実装に向けてはデータベースの設計も見直さなければなりません。また仮に、SAP ERP 6.0に実装した多数のカスタムモジュールをSAP S/4HANAに移行させようとした場合には、相当の開発工数を要することになるはずです。

2027年問題、2030年問題

■「富士通メインフレームの2030年問題」のインパクト

「富士通メインフレーム 2030年問題」とは、富士通メインフレームの生産が2030年に中止になり、2035年にはサポートも終了になることを指しています。

2035年のサポート終了までには、かなりの時間的猶予があるように思えます。ただ、メインフレーム上のシステムは長年にわたる運用を通じて機能追加が繰り返された結果、肥大化してしまっているのが通常です。それを他のプラットフォームに乗せ換えるのは容易ではありません。しかも、メインフレーム上のシステムは「COBOL」をベースとした独自性の高い言語で記述されていることが多く、仮に富士通メインフレームからオープンプラットフォームへの移行を図ろうとした場合には、肥大化したCOBOLベースのシステムをJavaなどのオープン系の言語プラットフォームで動作するように改変する(書き換える、または変換する)必要も出てきます。

加えて、メインフレームからオープンプラットフォームへのシステム移行を図る際には、メインフレームと同等の処理性能と可用性、耐障害性のレベルをどう担保するかといった問題にも突き当たるでしょう。そのためのソリューションを適切に選び、実際の運用へと至るまでには、相当入念な検証が必要とされるはずです。

さらに言えば、メインフレーム上の基幹システムには、相当数の外部システムが接続されているのが一般的です。そのため、基幹システムの刷新によってどの外部システムにどのような影響が出るかを特定したうえで、基幹システムと外部システムとを結ぶインタフェースを正しく改定しなければならず、相当の手間がかかるはずです。

ちなみに、SAP ERP 6.0で構築したシステム(例えば、財務・会計や販売管理などのシステム)も、たいていの場合、多数の外部システムと接続されています。そのため、システムの刷新時に多くのインタフェースを改変しなければならなくなるのが通常です。

問題の本質はIT人材の不足にあり

上述したように、SAP ERPや富士通メインフレームの刷新には、かなりの手間がかかります。その作業を担えるIT人材が潤沢であれば問題はありません。ところが、そうしたIT人材がユーザー企業の間で総じて足りていないのが実状です。いわば、SAP ERPの2027問題や富士通メインフレームの2030年問題の本質は、問題の解決を担えるIT人材がユーザー企業の間で不足している点にあるといえるでしょう。

IT人材不足

もちろん、SAP ERPや富士通メインフレームの刷新について、すべてをユーザー企業(のIT組織)が担う必要はなく作業の多くを協力会社に委ねることは可能です。それでも基幹システムの刷新にあたっては、最終的な成果物やコスト、スケジュールに関する責任をユーザー企業のIT組織が背負います。そのため、IT組織はプロジェクト全体をリードしながら、協力会社の成果物が自社の要件を満たしているかどうかを適宜精査し、満たせていない場合には予算とスケジュールを勘案しながら、改善のプランを協力会社とともに練り、実行に移していかなければなりません。ただし、そうした作業を担えるIT人材はユーザー企業内に足りていません。そのため今日では、SAP ERPの刷新プロジェクトに対して、EDIなど他の基幹システムの運用で忙殺されている人員を振り向けようとする「ムリ」も散見され始めています。

このような状況が生まれた背景理由としては、ITの戦略活用やデジタルトランスフォーメーション(DX)の取り組みが活発化したことが挙げられます。その活発化に伴い、企業のIT組織がカバーすべきシステム領域は、基幹システムなどの「System of Records(SoR)」から、自社の顧客に向けた「System of Engagement(SoE)」、オフィス業務のデジタル化を目的にした各種のSaaS(Software as a Service)、さらにはデータ分析・活用の基盤づくりへと大きく広がってきました。結果として、ERPやメインフレームの保守・運用の担い手が必要最小限の人員に絞り込まれてきたといえます。その限られた人的リソースの中で、SAP ERPや富士通メインフレームの刷新プロジェクトを担うのは負担が大きく非常に困難といえます。

また、富士通メインフレーム上で長く運用されてきたCOBOLベースのシステムに関しては、その内容を把握し、Javaへの移行プロジェクトなどを適切にリードできるIT人材が(ユーザー企業の間で)かねてより減少傾向にありました。しかも、その多くが数年後には定年を迎えて会社を去ってしまう可能性もあります。

限りあるIT人材の能力を最大限に生かすために

こうしたIT人材不足の問題は、今後、基幹システムの刷新が発生するたびに起こりうる問題です。しかも近年では、企業ITの次の担い手たちの志向は、SoE系システムの企画・開発やAI(人工知能)の有効活用、データ分析・活用の基盤づくりなどへと向かっています。

そのため、企業(とりわけ非IT系の一般事業会社)が基幹システムの保守・運用の新たな担い手を雇用する難度は高まり続けており、今後においては基幹システムの刷新に割り振れるIT人材のリソースはいま以上に厳しくなることが予想されます。

そこで重要になるのは、SAP ERPや富士通メインフレームといった基幹システムの刷新において、のちの保守・運用、あるいは刷新の工数を最小限にするための手立てを講じることです。実際、その観点から、例えばSAP ERP 6.0からSAP S/4HANAへの移行に際して、クラウド版のSAP S/4HANAを採用してインフラ運用の業務負担を “ほぼゼロ” にしようとする動きが活発化しています。また、クラウド版SAP S/4HANAの採用と併せて、自社の業務プロセスを世界標準に適合させる「Fit to Standard(フィット トゥ スタンダード)」の考え方のもと、カスタムモジュールの実装を可能な限りゼロに近づけてSAP S/4HANAへのシステム移行と保守・運用の手間を大きく低減させようとするアプローチも浸透しつつあります。

さらに、ERPの機能拡張や外部システムとの連携をシンプルにする目的で、SAP S/4HANAを適用する業務の領域を財務・会計や販売管理などに限定し、そのうえでAPIを介して外部システムとの連携を必要に応じて図るといった手法を採用する企業も増えています。この手法により、システムの保守性と変化への対応力がともに高められます。

さらに、SAP S/4HANAベースのシステムを含む基幹システム全体の保守・運用の手間をより大きく削減したい場合には、保守・運用のフルアウトソースが可能なシステムはすべてそうしてしまうという手も有効です。

例えば、SCSKのクラウド型EDIサービス「スマクラ」を採用すれば、手間のかかるEDIのシステム開発から保守・運用までをすべてSCSKにアウトソースすることができます。そのベネフィットから、スマクラはすでに本部契約300社以上に導入されており、DXに力を注ぐお客様が、スマクラの採用により、DXを推進する人的リソースを拡充させた例も多くあります。

このようにして基幹システムの保守・運用の手間を下げれば下げるほど、より戦略的なIT業務に一層多くの人材を割り振り、各人のモチベーションを高いレベルで維持できる可能性が高まります。そうなれば、企業の市場競争力強化へのIT人材の貢献度も自ずと上がっていくでしょう。その可能性を追求するためにも、SAP ERP 6.0や富士通メインフレームのサポート切れの問題を好機ととらえ、基幹システムのドラスティックな変革を推し進めてみてはいかがでしょうか。

EDIサービス スマクラとは

PAGE TOP