電子楽器大手のローランドのIT本部長/CIOの井手尚幸氏は、「レガシーシステムとは、ビジネス観点からメリットが低いため更新プライオリティは上がらないが、事業継続に不可欠なために残されているシステム」と定義する。しかしレガシーシステムはいつか使えなくなるし、DX推進のボトルネックにもなる。そこで同社では2023年の中期経営計画においてERPを最新化することを決め、2008年に導入したSAP ECC 6.0からSAP S/4HANAへの更新を2024年に完了させている。

  • ローランドにおけるSAPの状況

    ローランドにおけるSAPの状況

5月19日に開催された「TECH+セミナー 製造業DX 2026 May. レガシー刷新、ROIを可視化し変革を加速へ」に同氏が登壇。「成功だった」という同社のレガシーシステムの更新プロジェクトについて詳しく解説した。

「準備9割、段取り8分」、ERP更新における課題を事前に洗い出す

井手氏が「準備9割、段取り8分（はちぶ）」と表現した通り、ローランドのレガシーシステムの更新プロジェクトは事前に入念な準備が行われていた。その準備とは、ERP更新における課題を洗い出し、それぞれの課題を解決しながらプロジェクトを進められるのはどのような状態であるべきかを考えるものだった。

例えば、経営承認の取り付けが難しいという課題に対しては、経営陣にその意義や不可避性を理解してもらう、期限/予算を超過しやすいことに対しては、あらかじめ全タスク/工期の全貌が見えるようにする、安定稼働まで時間がかかることについては、公開前にテストを完了させる、というように、プロジェクトを実現できる望ましい状態を事前につくっておくのだ。

さらに、即時の意思決定ができる体制にしておくこと、プロジェクトの実行中にも計画の改善の工夫がされるようにしておくことで、想定外の事象にも対応できるようにした。こうした準備をしたうえで、ベストなパートナーとソリューションを検討し、NTTデータ グローバルソリューションズ（NTTデータGSL）とBeeXをパートナーとして選定した。

結果として、コミット期日通りの公開、公開初日より安定稼働、予算以下でプロジェクト完了、フルリモートかつ過多な残業なくプロジェクトを完遂する事ができたという。

5つの課題にどう向き合ったか

ここから井手氏は、レガシーシステムの更新プロジェクトにおける課題と、その解決策を具体的に示した。

経営承認を取り付ける

経営承認を取り付けるため、井手氏は経営陣に対し、ERP更新の意義を説明した。具体的には、eコマースや直営店など新たに検討しているビジネスプロセス、最新の周辺システムへの対応における制約をなくすことだ。加えて2027年の次回サーバ更新では現行システムに対応したものが入手できず、更新ができない可能性があるといった不可避性も提示。これにより、現行システムが将来的なビジネス成長のボトルネックになっていることを理解してもらった。

期限/予算を守る

期限/予算を守るために、全タスク/工期を可視化した。ここで利用したのはNTTデータGSLの提供する「i-KOU!」アセスメントである。i-KOU!は、SAP S/4HANAへの移行のためのソリューションであり、アセスメントを実施することで、SAP S/4HANAに更新が可能であることが分かった。また、更新におけるタスクリストやタイムライン、コスト見積もりなども取得。それによってパートナーも合わせた作業/構築期間が16カ月であること、カットオーバー直前には7日間のシステム停止期間が必要であることも分かった。システムの停止期間については、海外も含めた全部門において、1年以上前から調達、製造、出荷、販売、会計の一連のプロセスを1週間前倒しにして調整したそうだ。

「必要な作業やコスト、スケジュールなどがあらかじめ明確にできたからこそコミットできた内容です。実際にファクトを示して話すことができたので、経営に対してもしっかり信用を得ることができました」（井手氏）

こうしたことを踏まえ、周辺システムの移行やクラウドリフトも含めた全体のスケジュールを約2年と設定し、基本構築完了後に2回の移行リハーサルを行う計画とした。2回目のリハーサル前には移行時間の短縮を図り、実際にシステム停止期間は2日短縮して5日間となった。

安定稼働までの時間を短縮する

安定稼働までの時間を短縮するために実施したのは、公開前にユーザーが全テストを完了することだ。前述のアセスメント完了時に、すでにテスト対象となるトランザクションや業務シナリオを把握できていたため、事前に各部門に対して工数を予約することができた。そのため、新旧の環境における1,008件のトランザクションの確認、移行における影響リスク確認のための670件の業務シナリオのテスト、2回の移行リハーサル、その他オペレーションテストやインフラテストまで、全て公開前に完了させることができた。予定より早く完了したため、本番の移行前に、ストレステストなどのテストを追加で行うことができたという。

想定外の事象に対応できるようにする

想定外の事象への対応のための体制は、3つの階層で構成した。1階層目にはCEOをプロジェクトオーナー、井手氏をプロジェクトマネージャー、執行役員をステアリングコミッティとして配置。経営判断を要する課題を即時上程して決断できるようにした。2階層目では、プロジェクトリーダーとプロジェクトマネジメントオフィスをIT部門、パートナーのNTTデータGSLとBeeXにそれぞれ立て、週2回の定例会で全体の進捗管理を行うことで、課題を3日以上寝かさないようにした。3階層目は各部門から業務に精通しオーナーシップを発揮できるメンバーをIT部門が指名して集め、要件整理や進捗報告、テストなどを取りまとめてもらった。

「スリムな意思決定階層と、オーナーシップをしっかり発揮できる人員で構成された体制をつくったことが、成功の要因です」（井手氏）

  • システム更新プロジェクトの体制図

    システム更新プロジェクトの体制図

実際に想定外の事象もいくつか発生した。例えばBWからPower BIへの移行では、ツールが異なるためパフォーマンスが出なかったが、最終的にはチューニングで解決した。また、本番移行の際、これまでになかったエラーが出たが、これはシステム停止期間が2日間短縮されていたため、事なきを得たという。さらに、マレーシア工場で現地ベンダーの導入したアドオンが理由でプロジェクトが止まったが、ちょうど井手氏がマレーシアに出張していたため、ベンダーを直接訪問し改めて協力依頼を行い、期限に間に合わせることができたそうだ。

このような想定外の問題が発生しても、予定通りの期日に公開できたのは、プロジェクト開始後にも計画改善の工夫を行っていたためだ。主な工夫としては、3社での定例会の実施、プロジェクト開始後にも前倒し/スコープ整理を随時実施していたこと、そしてメンバー全員で毎月のゴールの必達にこだわったことが挙げられる。常に前倒し/スコープ整理をすることで、必ず発生する想定外の事象に対応できるようにすることができたし、どこかに遅れが生じるとそれに付随する報告が上がり、結果として作業が増えてしまうため、毎月のゴールの必達にこだわったことも成功につながった。

ベストなソリューションとパートナーを選定する

NTTデータGSLとBeeXをパートナーとして選定したのは、ローランドの求める技術的要件とパートナー要件を満たしていたためだ。技術的要件とは、SAPのコンバージョン・ソリューションがあること、アセスメント・サービスがあること、SAPインフラのAzureへのクラウドリフトができること、BWからPower BIへの移行ソリューションがあることである。そしてパートナー要件はグローバルに対応可能であること、将来的なシナジーが見込め、共感を抱けることだったという。

「この両社には技術的な側面だけでなく、プロジェクトの進め方においても寄り添っていただきました。信頼できるパートナーとともに進められたことも、成功の大きな要因だと思います」（井手氏）

最後に井手氏は、「レガシーシステムが減少するたびに得られたものがある」と話した。まず、経営層や他部門からは「しっかりやってくれる」という信頼を得られ、期待も高まったという。またIT部門ではメンバーの自信やモチベーションが向上。システムを更新するたびに、最新のソリューションを制約なく使うことができ、それをベースにより戦略的な中長期計画が立てられる、といったメリットも実感できているそうだ。

「こうした状況のなかで、仕事そのものを楽しくできるようになりました。そしてその結果、ITが経営スピードや競争力の向上に、より直接的に貢献できるようになったと感じています」（井手氏）