基幹システム移行の現場で起きていること
基幹システムの移行プロジェクト。経営層は「クラウド化で効率化」「最新システムで競争力強化」と期待を膨らませます。しかし現場では、想定外の問題が次々と噴出し、スケジュールは遅延、予算は超過、関係者は疲弊していく——これが多くのプロジェクトで起きている現実です。
特にOracle EBSからSAPへの移行は、単なるシステムの入れ替えではありません。業務プロセスの再定義、20年分のカスタマイズの棚卸し、膨大なマスタデータの移行、そして何より現場ユーザーの抵抗という、複雑な問題が絡み合います。
私は2024年9月から2025年4月まで、公共インフラ企業の会計システム再構築プロジェクトにPMOとして参画しました。100名規模、8ヶ月という短期間でのOracleEBS→SAP移行という無謀とも言えるチャレンジでした。
プロジェクト初日から漂っていた不穏な空気
キックオフミーティングで顔を合わせた瞬間、私は「これは大変なことになる」と直感しました。現行システムの仕様書を管理している部署が3つに分かれており、それぞれが異なるバージョンの資料を持っていたのです。さらに、過去15年間に実施された600以上のカスタマイズのうち、詳細な実装仕様が残っているのは3割程度。残りは「誰かが昔作った」という口伝の世界でした。
ETLツールとしてDataSpiderを採用し、基盤はMicrosoft Azureで構築する計画でしたが、レガシーシステムのデータ構造が複雑すぎて、初期のデータマッピング作業だけで予定の3倍の工数がかかることが判明しました。
2024年9月から2025年4月にかけて、私は公共インフラ向け会計システムの再構築プロジェクトに、PMOとして8ヶ月参画しました。規模は100名、OracleEBSからSAPへの基幹刷新で、ETLはDataSpider、基盤はAzureという構成でした。最大の混乱は、20年以上動いてきたOracleEBSの『業務に密着しすぎたカスタマイズ』をSAPの標準機能にどう吸収するかでした。レガシー側の業務フローを把握している担当者が定年退職寸前で、ドキュメント化されていない仕様が現場で次々と発覚。データ移行テストフェーズに入ってから『そもそもこのデータ項目はどう移すのか』という議論が再燃する事態に。ユーザー教育のスケジュールも圧迫され、結果的にカットオーバー直前まで非常にタイトな状況が続きました。段階移行とPoC期間確保の重要性を、改めて痛感したプロジェクトです。
「このカスタマイズは絶対に必要」という現場の主張
要件定義フェーズで最も時間を食ったのが、既存カスタマイズの取捨選択でした。業務部門の担当者は「このカスタマイズがないと業務が回らない」と主張します。しかし、その機能が実際にどれだけ使われているかを調査すると、月に1回しか使われていない、あるいは代替手段があることがわかるケースが多数ありました。
特に厄介だったのが、特定の担当者しか使い方を知らない「秘伝のタレ」のような機能です。その担当者が異動や退職で不在になると、誰もメンテナンスできない状態になっているのに、システム上は残り続けている。こうした「ゾンビ機能」が数十個も存在していました。
データ移行テストで発覚した致命的な仕様齟齬
開発フェーズが終盤に差し掛かった頃、データ移行のテストを実施しました。ここで、プロジェクトを根底から揺るがす問題が発覚します。Oracle EBSとSAPでは、勘定科目の階層構造に対する考え方が根本的に異なっていたのです。
Oracle EBSでは5階層の勘定科目体系を自由に設計できましたが、SAPでは標準で3階層が推奨されていました。既存の会計データをそのまま移行すると、階層構造が崩れ、月次決算の集計ロジックがまったく機能しなくなる可能性がありました。
この問題の解決には、会計データのマッピングルールを全面的に見直す必要がありました。経理部門と2週間にわたる調整会議を重ね、最終的には一部の勘定科目を統合することで対応しましたが、当初のスケジュールからは3週間の遅延が発生しました。
ユーザー教育の時間が圧倒的に足りない
本番稼働の1ヶ月前、ユーザートレーニングが始まりました。しかし、ここでも想定外の事態が起きます。エンドユーザー向けのトレーニング資料が、システムベンダーの標準テンプレートをベースにしており、実際の業務フローとまったく合致していなかったのです。
経理部門のベテラン担当者からは「この操作手順では実務で使えない」「Oracle EBSでは3クリックで済んだのに、なぜSAPでは10クリックも必要なのか」という厳しい指摘が相次ぎました。急遽、業務部門と協力して実務に即したマニュアルを作り直しましたが、トレーニング期間は予定の半分しか確保できませんでした。
結果として、本番稼働後の1週間は問い合わせが殺到し、ヘルプデスクは朝から晩まで電話対応に追われることになりました。システムの不具合ではなく、操作方法がわからないという基本的な質問が大半を占めていました。
なぜ基幹システム移行プロジェクトは混乱するのか
私がこのプロジェクトで痛感したのは、基幹システム移行の難しさは技術的な問題よりも、組織的・人的な問題に起因するということです。いくら優れたツールや方法論があっても、それを使う人間の理解と協力がなければ、プロジェクトは成功しません。
レガシーシステムの「見えない資産」を軽視している
多くのプロジェクトが失敗する最大の原因は、現行システムに蓄積された「暗黙知」を軽視していることです。長年使われてきたシステムには、マニュアルや仕様書には記載されていない、現場の知恵が詰まっています。特定の条件下でしか発生しないエラーの回避方法、月末処理の手順、イレギュラーな取引の処理方法——こうした知識は、実際に運用してみないと表面化しません。
Oracle EBSを20年使ってきた企業では、システムの癖や制約を前提とした業務プロセスが定着しています。それをSAPに移行するということは、単にシステムを入れ替えるのではなく、業務プロセス自体を再構築するということなんです。
ベンダー主導の標準プロセスが現場とマッチしない
SAPのようなパッケージシステムには「ベストプラクティス」と呼ばれる標準業務プロセスが組み込まれています。ベンダーは「カスタマイズを最小化し、標準プロセスに合わせることが成功の鍵」と説きます。理論的には正しいのですが、現場の実態を無視した標準化は、かえって業務効率を下げる結果になります。
私が関わったプロジェクトでも、SAPベンダーは「購買承認プロセスは3段階承認が標準」と提案しました。しかし、この企業では部署によって承認フローが異なり、緊急時の特例処理も頻繁に発生していました。標準プロセスに無理やり合わせようとすると、現場から強い反発が起きたのは当然でした。
データ移行の複雑さを見誤っている
基幹システム移行で最も時間とコストがかかるのがデータ移行です。単純なマスタデータの移行だけでなく、過去の取引履歴、仕掛中の案件、未決済の債権債務——すべてを新システムに正確に移行しなければなりません。
特に会計データは、過去5年分の取引履歴を保持する法的義務があります。Oracle EBSとSAPでは勘定科目のコード体系が異なるため、単純なデータコピーでは済みません。DataSpiderのようなETLツールを使っても、データのクレンジング、マッピングルールの定義、移行後の整合性チェックには膨大な工数がかかります。
私たちのプロジェクトでは、データ移行だけで全体工数の35%を消費しました。当初の見積もりでは20%だったので、大幅な超過です。データの不整合が発見されるたびに、原因調査と修正対応に追われ、テストスケジュールは常に遅延していました。
変革への抵抗を甘く見ている
システム移行は、単なるツールの変更ではなく、働き方の変革を伴います。長年慣れ親しんだシステムから新しいシステムへの移行は、多くのユーザーにとってストレスです。特に、新システムの操作性が直感的でない場合、抵抗はさらに強くなります。
Oracle EBSに慣れたユーザーにとって、SAPの画面構成や操作フローは大きく異なります。同じ業務を実行するのに、クリック数が増えたり、画面遷移が複雑になったりすると、「なぜ新システムに変える必要があったのか」という不満が噴出します。
この心理的な抵抗を軽視し、「慣れれば大丈夫」と楽観視するプロジェクトは、本番稼働後に大きな混乱を招くことになります。
現代のクラウド移行で活かせる教訓と解決策
私がこのプロジェクトで学んだ最大の教訓は、「急がば回れ」ということです。8ヶ月という短期間での移行は、結果的に多くの問題を先送りにし、本番稼働後の混乱を招きました。現代のクラウド移行プロジェクトでは、段階的なアプローチと十分なPoC期間の確保が不可欠です。
段階移行戦略でリスクを分散する
一度にすべてのシステムを切り替える「ビッグバン移行」は、リスクが高すぎます。特に基幹システムの場合、業務が止まることは許されません。私が次に同様のプロジェクトに関わるなら、必ず段階移行を提案します。
具体的には、まず影響範囲の小さい部門や機能から移行を開始し、問題点を洗い出します。次に、その知見を活かして主要部門の移行を進める。最終的に、全社展開するというステップを踏むことで、リスクを最小化できます。
例えば、会計システムであれば、まず補助部門の経費精算機能から移行し、その後、購買管理、最後に総勘定元帳という順序が考えられます。各段階で1〜2ヶ月の安定稼働期間を設けることで、ユーザーも徐々に新システムに慣れることができます。
十分なPoC期間で「捨てる勇気」を持つ
PoCとは概念実証のことですが、私はこれを「失敗する権利」と呼んでいます。本格的な開発に入る前に、小規模な検証環境で実際の業務プロセスを試してみる。うまくいかなければ、方針を変更する。この柔軟性がプロジェクトを成功に導きます。
私たちのプロジェクトでは、PoC期間がわずか2週間しかありませんでした。この期間では、表面的な機能確認しかできず、実際の業務フローとのミスマッチが後になって発覚しました。理想的には、3〜6ヶ月のPoC期間を設け、主要な業務シナリオをすべて検証すべきです。
そして、PoCの結果が芳しくなければ、システム選定自体を見直す勇気が必要です。「もうベンダーと契約してしまったから」「経営層に説明がつかないから」という理由で無理に進めると、取り返しのつかない失敗につながります。
データ移行専門チームの早期編成
データ移行は、プロジェクトの最後に慌てて対応する作業ではありません。プロジェクト初期から専門チームを編成し、継続的にデータの棚卸しとクレンジングを行うべきです。
具体的には、以下のようなタスクを並行して進めます。
- 現行システムのデータ構造の詳細分析
- 不要データや重複データの洗い出しと削除
- 新システムのデータモデルとのマッピングルール策定
- 段階的なデータ移行テストの実施
- 移行後のデータ整合性チェックツールの開発
ETLツールとしてDataSpiderを使う場合でも、単純なマッピング設定だけでは不十分です。データのクレンジングロジック、例外処理、エラーハンドリングなど、詳細な設計が必要になります。これらの作業を後回しにすると、テスト段階で大量のデータ不整合が発覚し、スケジュールが大幅に遅延します。
ユーザー中心設計のトレーニングプログラム
システムの操作マニュアルは、ベンダーが用意する標準テンプレートをそのまま使ってはいけません。実際の業務フローに沿った、現場の言葉で書かれたマニュアルを作成する必要があります。
私の推奨する方法は、業務部門から「パワーユーザー」を数名選出し、彼らに新システムを先行して習得してもらうことです。そして、パワーユーザーが実際に業務を実行しながら、つまずいたポイントや疑問点を記録してもらいます。その記録をもとに、実践的なマニュアルを作成するのです。
また、トレーニングは座学だけでなく、ハンズオン形式で実施すべきです。実際に新システムを操作しながら、自分の業務データを入力してみる。この体験型トレーニングを通じて、ユーザーは新システムへの理解を深め、不安を軽減できます。
さらに、本番稼働後の最初の1ヶ月は、各部署に専任のサポート担当者を配置することを強く推奨します。問い合わせ窓口に電話するのではなく、隣の席にいる人にすぐ質問できる環境があれば、ユーザーの不安は大幅に軽減されます。
現代のクラウド移行を支援するツールとサービス
基幹システムのクラウド移行は、以前に比べて技術的なハードルは下がっています。データ移行、プロジェクト管理、ユーザートレーニングを支援する様々なツールが登場しており、これらを適切に組み合わせることで、プロジェクトのリスクを大幅に低減できます。
データ移行を効率化するETLツール
DataSpiderは、私が実際のプロジェクトで使用したETLツールです。GUIベースでデータマッピングを設定でき、複雑な変換ロジックもノーコードで実装できます。Oracle EBSからSAPへのデータ移行では、勘定科目のコード変換、組織階層の再構築、取引日付の形式変換など、多様な処理が必要でしたが、DataSpiderの柔軟性は高く評価できます。
ただし、DataSpiderはあくまでツールであり、魔法の杖ではありません。データのクレンジングルールやマッピングロジックは、業務知識を持った人間が設計しなければなりません。私たちのプロジェクトでは、DataSpiderの設定だけで2ヶ月以上かかりました。特に、例外処理やエラーハンドリングの設計に多くの時間を費やしました。
また、DataSpiderはオンプレミス版とクラウド版がありますが、クラウド版(DataSpider Cloud)は大量データの処理性能に制約があります。数百万レコードを超える移行を行う場合は、オンプレミス版の方が適しています。ライセンス費用は高額ですが、プロジェクトの成功を考えれば、投資する価値はあると思います。
段階移行を管理するプロジェクト管理ツール
複雑な基幹システム移行プロジェクトでは、何百ものタスクを並行して管理する必要があります。私が使用したツールは、Microsoft Project OnlineとJira Softwareの組み合わせでした。
Microsoft Project Onlineは、全体のスケジュール管理とリソース配分に使用しました。ガントチャートで各フェーズの依存関係を可視化し、クリティカルパスを常に監視することで、遅延リスクを早期に検知できます。特に、データ移行、カスタマイズ開発、ユーザートレーニングという3つの並行作業の進捗を一元管理できたのは大きなメリットでした。
一方、Jira Softwareは、日々の開発タスクや障害管理に使用しました。開発チームがアジャイル手法で作業を進める際に、スプリント管理やバックログの優先順位付けがスムーズに行えます。また、ユーザーからの問い合わせや不具合報告もJiraでチケット管理することで、対応状況の可視化と漏れ防止が実現できました。
ただし、これらのツールは高機能である分、使いこなすには相応の学習コストがかかります。プロジェクト初期に、チーム全員がツールの使い方を習得する時間を確保することが重要です。私たちのプロジェクトでは、ツールの使い方が統一されておらず、一部のメンバーがExcelで並行管理してしまい、情報の二重管理が発生するという問題がありました。
ユーザー教育を支援するLMSプラットフォーム
大規模なシステム移行では、数百人のユーザーに対するトレーニングが必要になります。対面研修だけでは時間とコストがかかりすぎるため、eラーニングを併用することが効果的です。
私が注目しているのは、Moodleやドキュメントという国産のLMS(Learning Management System)です。これらのプラットフォームでは、動画教材、クイズ、実技試験などを組み合わせたトレーニングコースを作成できます。ユーザーは自分のペースで学習を進め、理解度をチェックできます。
特に有効なのが、画面操作の録画動画です。実際の業務シナリオに沿って、「経費精算の申請から承認までの流れ」「月次決算処理の手順」などを10分程度の動画にまとめます。ユーザーは業務中に疑問が生じたら、すぐに該当する動画を見返すことができます。
ただし、教材コンテンツの作成には相当な工数がかかります。私たちのプロジェクトでは、動画教材の作成が間に合わず、結局PDFマニュアルの配布に留まってしまいました。理想的には、プロジェクト中盤から教材作成専任のチームを立ち上げ、継続的にコンテンツを充実させていくべきです。
クラウド移行を包括支援するSaaSプラットフォーム
最近注目されているのが、基幹システムのクラウド移行を包括的に支援するSaaSプラットフォームです。例えば、AWS Migration Hub、Google Cloud Migration Center、Azure Migrateなどがあります。
これらのサービスは、現行システムのアセスメント、移行計画の策定、データ移行の実行、移行後の最適化まで、一連のプロセスを支援します。特にAzure Migrateは、私たちのプロジェクトでインフラ基盤として使用したMicrosoft Azureとの親和性が高く、Oracle EBSのような既存システムからのリフト&シフト移行に強みがあります。
Azure Migrateでは、現行システムのサーバー構成、ネットワークトポロジ、データベースサイズなどを自動で検出し、最適なAzureリソースを提案してくれます。また、移行にかかるコストを事前にシミュレーションできるため、予算策定にも役立ちます。
ただし、これらのクラウドプラットフォームは、あくまでインフラ移行を支援するものであり、アプリケーション層の移行やデータ変換までは自動化できません。Oracle EBSからSAPへの移行のように、異なるERPパッケージ間での移行では、結局は人間が業務要件を分析し、カスタマイズ内容を判断する必要があります。
また、クラウドプラットフォームの利用料金は、データ転送量や移行期間に応じて変動します。大規模なデータ移行では、想定外のコストが発生する可能性があるため、事前に詳細な見積もりを取ることが重要です。
基幹システム移行を成功させるために本当に必要なこと
私が100名規模のOracleEBS→SAP移行プロジェクトで学んだ最大の教訓は、技術やツールよりも、人と組織の問題が移行の成否を決めるということです。どれだけ優れたETLツールやプロジェクト管理ツールを導入しても、現場の理解と協力がなければ、プロジェクトは成功しません。
経営層のコミットメントが不可欠
基幹システムの移行は、単なるIT部門のプロジェクトではなく、全社的な変革プロジェクトです。経営層が「IT部門に任せておけば大丈夫」という姿勢では、必ず失敗します。経営層自身が移行の目的とビジョンを明確に示し、必要なリソースと予算を確保し、現場の抵抗に対して強いリーダーシップを発揮する必要があります。
私たちのプロジェクトでは、途中で予算不足が明らかになりましたが、経営層の追加承認が得られず、品質を犠牲にしてスケジュール優先で進めざるを得ませんでした。結果として、本番稼働後の混乱が長期化し、最終的なコストは当初予算を大幅に超過しました。最初から十分な予算と期間を確保していれば、こうした事態は避けられたと思います。
現場の声に真剣に耳を傾ける
システムを実際に使うのは現場のユーザーです。彼らの業務を理解せずに、ベンダー主導で標準プロセスを押し付けても、うまくいきません。プロジェクト初期から、現場の担当者を巻き込み、彼らの意見を設計に反映することが重要です。
ただし、すべての要望を受け入れていては、プロジェクトのスコープが際限なく拡大します。重要なのは、「なぜその機能が必要なのか」「代替手段はないのか」を徹底的に議論することです。その過程で、実は不要だったカスタマイズや、業務プロセス自体を見直すべき部分が見えてきます。
失敗から学ぶ文化を作る
プロジェクト中には、必ずトラブルや想定外の問題が発生します。重要なのは、問題を隠蔽せず、早期にエスカレーションし、チーム全体で解決策を考える文化を作ることです。
私たちのプロジェクトでは、毎週の定例会議で「今週発生した問題と対応状況」を必ず報告するルールを設けました。最初は失敗を報告することに抵抗があったメンバーもいましたが、徐々に「失敗を共有することで、他のメンバーが同じ失敗を避けられる」という前向きな雰囲気が生まれました。
また、プロジェクト終了後には、必ず振り返り会議を実施し、「うまくいったこと」「うまくいかなかったこと」「次に活かせる教訓」を整理することが重要です。この記録は、次の移行プロジェクトの貴重な財産になります。
長期的な視点で投資判断をする
基幹システムの移行は、短期的にはコストと混乱をもたらしますが、長期的には業務効率化、データ活用の高度化、競争力の強化につながります。目先のコスト削減だけを追求して、品質や期間を犠牲にすると、結果的により大きなコストを支払うことになります。
私が次に同様のプロジェクトに関わる機会があれば、経営層に対して「適切な期間と予算を確保すること」を強く提言します。8ヶ月ではなく18ヶ月、十分なPoC期間を設け、段階的に移行を進める。短期的には投資額は増えますが、長期的には安定した運用と高い投資対効果が得られるはずです。
基幹システムの移行は、企業にとって数十年に一度の大プロジェクトです。その成否は、今後10年、20年の企業の競争力を左右します。だからこそ、性急な判断を避け、現場の声に耳を傾け、十分な準備期間を確保することが、何よりも重要だと私は考えています。
コメント