企業の業務を支える基幹システムを刷新する際、特に難易度が高いのが、長年利用してきた環境から新しい環境へ移行するプロジェクトです。
今回ICが支援したのは、大手化学メーカー様における、既存SAPから最新の「SAP S/4HANA」への移行と、クラウド環境「RISE with SAP」への移行プロジェクト。
今回のプロジェクトでは、既存システムに約8000本ものアドオンプログラムが存在していました。アドオンとは、SAPの標準機能だけでは対応できない企業独自の業務要件を実現するために追加されたプログラムです。長年にわたって業務に合わせて追加・改修されてきたアドオンは、企業にとって重要な資産である一方、SAPのバージョンアップや実行環境の変更時には、移行の大きな負担となることがあります。今回のプロジェクトでは、OS環境がWindowsからLinuxへ変わることによる影響も考慮しながら、既存の約8000本のアドオンを一つひとつ精査。周辺システムへの影響を最小限に抑えながら、新しい環境でも従来通りの業務を継続できる状態を目指しました。
この難易度の高いプロジェクトで中心的な役割を担ったのが、2009年から長年このSAP環境に携わってきたNさんです。今回は、NさんがどのようにSAP移行を進め、技術的な課題だけでなく、お客様のリソース不足やプロジェクト上の不安まで先回りして解決していったのか、その取り組みについて詳しく紹介します。
|
この記事でわかること ・SAP S/4HANAへの移行とは何か |
大手化学メーカー様 SAP移行プロジェクト
プロジェクト期間：2025年5月～2026年8月
対象 ：基幹システム
主な対応 ：SAP移行支援／アドオン改修方針策定／製造／単体テスト
製品・環境 ： SAP S/4HANA／RISE with SAP
環境変更 ： Windows → Linux
既存環境 → SAP社提供のクラウド環境
改修対象 ： 約600本のプログラム
ICメンバー ： 5名
SAP S/4HANAとは？SAPは、企業のさまざまな業務を支える基幹業務システム（ERP）です。 |
RISE with SAPとは？一方、今回のプロジェクトで登場する「RISE with SAP」は、SAPを動かす環境に関係するものです。 |
SAPには、企業の業務を支えるためのさまざまな標準機能があります。
しかし、企業ごとの業務すべてを標準機能だけで実現できるとは限りません。
そこで、
・ 自社独自の業務処理
・他システムとのデータ連携
・標準機能では対応できない処理
などを実現するため、SAPに追加のプログラムを組み込むことがあります。これがアドオンです。長年SAPを利用している企業では、こうしたアドオンが積み重なっていきます。
そしてSAPの標準機能や実行環境が変わると、「今まで動いていたアドオンが、新しい環境でも同じように動くのか？」を一つひとつ確認する必要があります。
今回のプロジェクトでは、当初約400本、最終的には約600本のプログラムを修正することになりました。
実は、今回のプロジェクトで最も重要だったのは、600本のプログラムを書き直す作業そのものではありません。
その前に、「600本を、どう直すのか」を決める必要がありました。
なぜなら、1本のプログラムで決めた修正方法を、同じパターンのプログラムに横展開していくからです。
もし最初の方針を間違えれば、その間違いが大量のプログラムに広がってしまいます。
だからこそ、今回のプロジェクトでは改修方針の策定に約1カ月半をかけました。
影響がありそうなプログラムを調査し、実際の検証環境で動かしながら、「この方法なら新しい環境でも正常に動く」という方法を確定していったのです。
今回、もう一つ大きな変更がありました。それが、
Windows → Linux
というOS環境の変更です。
「WindowsからLinuxに変わる」と聞いても、システムに詳しくない人には、その変更の大きさがなかなか想像できません。
Nさんが例として挙げたのがファイルパスの表記です。
Windowsでは「￥」で区切られていたものが、Linuxでは「/」に変わります。また、ファイルの改行コードなど、普段はほとんど意識しないような部分にも違いがあります。一見すると小さな違いです。しかし「見た目はほとんど変わらないのに、コンピューターの世界では中身が大きく変わっている」ということ。その影響を一つひとつ洗い出していく必要がありました。
プログラムの中でその違いを前提として処理している箇所があれば、修正が必要になります。だからこそ「WindowsとLinuxで何が変わるのか」をまず網羅し、その影響を受けるプログラムを洗い出す必要がありました。
そして、その結果として約600本の改修につながったのです。
ここで、今回のプロジェクトの本質が見えてきます。今回の目的は、「最新のシステムにして、現場の画面を大きく変える」ことではありません。むしろ、「新しい環境に移行しても、これまで通り業務ができること」が重要でした。
SAPの周辺には、さまざまなシステムやアプリケーションが接続されています。SAPだけを新しくして、周辺システムをすべて同時に変更することは現実的ではありません。
そのため今回のプロジェクトでは、「基幹システムが元と同じ動きをする」ことを基本的な考え方として、どのように修正すれば従来と同じ動作を実現できるのかを検証しました。
「新しいバージョンにするなら、ユーザーにとってもものすごく使いやすくなるのでは？」
そう思いませんか？
ところが、Nさんの答えは意外なものでした。「ユーザーからすると、画面はほとんど変わらない」むしろ現場からは、「画面が変わっちゃうと分からなくなるから、変えないでくれ」と言われることもあるそうです。
つまり今回の目的は、「新しくして、現場の使い勝手を劇的に変える」ことではありません。既存の業務を止めないまま、新しい環境へ移行する。これは基幹システムの刷新において、とても重要な考え方です。
企業の基幹システムは、SAPだけで完結しているわけではありません。
SAPの周辺には、
・他の業務システム
・各種アプリケーション
・データ連携システム
・社内独自の仕組み
などがつながっています。
そのため、「SAPを新しくしたから、周辺システムも全部変更しましょう」というわけにはいきません。
今回特に重視されたのも、「基幹システムが、元と同じように動くこと」でした。
だからこそ、単純にプログラムを修正するのではなく、「どう修正すれば周辺システムに影響を出さずに済むか」を実機検証しながら決めていきました。
SAPは販売・購買・財務・人事・生産・品質管理など、企業の幅広い業務をカバーできるパッケージです。また、大規模なシステムに求められる大量のトランザクションデータを処理する点にも強みがあります。
だからこそ、多くの企業で利用されている一方、長年使い続けることで独自のアドオンや周辺システムも増えていきます。
結果として、「重要だからこそ、簡単には止められない」、そして「重要だからこそ、慎重に新しい環境へ移行しなければならない」という構造が生まれます。
今回のSAP移行が初めてではないNさん。前回の大きなバージョンアップにも携わっています。今回よりも、むしろ前回のほうが大変だったとNさんは振り返ります。
当時はシステムの環境が変わり、Unicodeへの対応によって、既存プログラムがほとんど動かなくなる状況になりました。さらに当時はオフショア開発の取りまとめも担当。海外での開発を進めるため、月1回ほど上海へ出張し、約半年にわたって現地との調整を行っていたそうです。
18年前から同じシステムを見ている。
前回の移行も経験している。
そして、システムがなぜ今の形になっているのかも知っている。
今回、Nさんが再びプロジェクトに呼ばれた背景には、こうした「過去を知っている」という強さがあります。
大規模な基幹システムでは、現在のシステムだけを見ても分からないことがあります。
「なぜこの仕組みになっているのか」
「なぜこのプログラムが必要なのか」
「前回の移行では何が問題になったのか」
こうした過去の経緯を知っていることが、次の移行では大きな強みになります。
NさんがSAPに携わり始めたのは2009年頃。入社時にはSAPそのものを知らない状態でしたが、現場で開発や保守を経験しながら知識を身につけていきました。そして18年間、SAPの現場に関わり続けてきました。
前回の移行を知っている。
現在のシステムを知っている。
そして今回の移行にも関わっている。
この「時間をまたいだシステム理解」が、Nさんならではの大きな強みです。
Nさんは、長年同じ現場に携わっていることから、開発に必要な工数やスケジュールを見積もり、「このタイミングでは、これくらいの人員が必要になる」
というところまで考えて、お客様側に提案しています。
例えば、
・どのくらいの工数が必要なのか
・いつ作業が集中するのか
・どのタイミングで人員が必要になるのか
・どの程度の体制を組む必要があるのか
といったことを、開発の進行だけではなくプロジェクト全体から判断します。
お客様から依頼された人員を用意するのではなく、「これから必要になる人員」を先に考える。今回のプロジェクトでは、この先回りした支援が大きな役割を果たしました。
アプリケーションとインフラの境界があいまいなトラブルが発生した際にも、まずNさんが窓口となり、問題を切り分けます。
どの領域に原因があるのかを整理し、必要な担当者へつなげる。こうした対応を積み重ねることで、「Nさんに聞けば、的確な答えが返ってくる」という安心感につながっていきました。
大規模なシステム移行では、問題が発生すること自体を完全になくすことは難しいものです。だからこそ、問題が発生したときに、誰に相談すればよいのかが明確であること。そして、問題を迅速に切り分け、解決へ導けることが重要になります。
Nさんの役割は、プログラムを開発する技術者にとどまらず、プロジェクト全体を前へ進める「技術面のハブ」でもありました。
大規模なシステム移行では、設計・開発だけでなく、テスト工程も重要です。
今回のプロジェクトでも、テスト段階で予期せぬ不具合が発生しました。しかし、Nさん率いるチームが迅速に原因を確認し、リカバリーを実施。
結果として、全体スケジュールを遅延させることなく、2026年8月の本番切替を迎えることができました。
大規模なSAP移行を成功させるためには、事前の計画だけでなく、実際の現場で発生する問題に対して迅速に判断・対応する力も求められます。
今回のプロジェクトを通じて、お客様からは、「方針策定から開発まで安心して任せられた」という評価に加え、「今後別の案件があれば、ぜひまたNさんにお願いしたい」という期待の声も寄せられました。
大規模な基幹システムの刷新では、技術力はもちろん重要です。しかし、それだけではプロジェクトを成功に導くことはできません。
システムの過去を理解する。
現在の課題を把握する。
これから起こる問題を予測する。
そして、お客様が必要とするタイミングよりも前に提案する。
こうした積み重ねによって生まれる「この人なら任せられる」という信頼が、プロジェクトを支える大きな力になります。
Nさんが長年にわたり培ってきた経験は、単なる技術スキルではありません。システムと業務、そしてお客様を長期的に理解してきた経験そのものが、今回のSAP移行プロジェクトにおける大きな強みとなりました。
今回のインタビューで最も印象的だったのは、SAP移行における高度な技術力そのもの以上に、システムを安定稼働させ続けるための「徹底した先回りと思考力」でした。
プロジェクトにおける個々のタスクは、一見すると専門的な技術作業の積み重ねです。
・約600本に及ぶプログラムの修正
・WindowsからLinuxへのOS環境移行
・周辺システムとの確実な連携維持
・複数ベンダー間にまたがる課題の切り分け
・不足するプロジェクトリソースの補完
・お客様が上流工程へ専念できる適切な役割分担
・本番切替後における着実な正常稼働の確認
しかし、これらすべての施策の根底にあり、全体を力強く繋ぎ止めているのは、「この先に何が起こるか」を常に予測して動く確かな先回り力なのです。
今回のプロジェクトで実証されたのは、ICが持つ「確かな技術力」だけではありません。
お客様が抱えている課題を自分事として捉え、「次に何が必要になるのか」を考えて提案する、伴走型の支援力です。
SAP S/4HANAへの移行、基幹システムの刷新、クラウド移行など、大規模なシステムプロジェクトでは、技術面だけでなく、体制・スケジュール・業務への影響など、さまざまな課題を同時に考える必要があります。
ICでは、こうした複雑なプロジェクトに対して、上流工程から開発、テスト、移行まで、お客様と連携しながら支援しています。
単に「システムを作る」のではなく、お客様の一歩先を考え、プロジェクトを前へ進める。
それが、ICが目指すシステム開発・IT支援です。
SAP S/4HANAへの移行や基幹システムのクラウド化では、単に新しい環境へシステムを移すだけではなく、既存のアドオンや周辺システム、データ連携、業務への影響など、さまざまな点を考慮する必要があります。
特に、長年利用してきたSAP環境では、
・大量のアドオンをどこまで改修するのか
・既存の業務をどのように維持するのか
・新しい環境への移行による影響をどう洗い出すのか
・複数ベンダーが関わるプロジェクトをどう進めるのか
・移行に必要な人員・体制をどう確保するのか
といった課題が発生します。
今回のプロジェクトでは、約600本のアドオン改修をはじめ、WindowsからLinuxへの環境変更、周辺システムとの連携確認など、さまざまな課題に対応しました。
ICでは、こうした技術的な対応だけでなく、プロジェクト全体を見ながら、次に必要となる工程や体制まで考え、一歩先回りした支援を行っています。
「SAP移行は決まっているが、どこから手をつければよいか分からない」
「既存アドオンや周辺システムへの影響が心配」
「移行プロジェクトを支える技術者・体制が不足している」
そんな課題をお持ちでしたら、ぜひICにご相談ください。
※記載されている会社名、製品名およびサービス名は、各社の登録商標または商標です。