ERP のモダナイズ案件は、たいてい全面置き換えから始まりません。
現場で本当に先に出る要件は、もっと地味です。
このシステムは残る前提でいいから、新しいチームが触りやすくしてほしい
だからこそ、ERP 周辺で SOAP-to-REST の需要が出ます。
制約は技術より政治にあることが多い
現場ではよく「もう置き換えたい」と言われます。
実際に困っているのは次のようなことです。
- 連携が遅い
- 新しい担当者の立ち上がりが重い
- XML ロジックが各所に散っている
- エラーの意味が分かりにくい
でも ERP は残りがちです。理由は分かりやすくて、
- 会計や業務フローが依存している
- 調達や社内承認が重い
- ワークフローに深く埋め込まれている
- 移行コストが今の痛みより大きい
だから実務上の課題は「ERP を今すぐ置き換える」ではありません。
「ERP を残したまま、連携だけを現代の開発に耐える形にする」です。
いま無駄になっている時間
ERP の SOAP 連携で時間が溶ける場所は、だいたい次です。
- 各サービスに散った手書き XML
- consumer ごとに微妙に違う認証処理
- WSDL の解釈の重複
- timeout や retry 方針のバラつき
- 下流向けの共通契約がない
つまり、小さい変更でも高くつく構造になっています。
現代化は「置き換え」とは限らない
モダナイズは、データモデルの全面再設計だけを意味しません。
たとえば次でも十分に価値があります。
- SOAP の前に安定した JSON 契約を置く
- リクエスト検証を1か所に寄せる
- 認証処理を1か所に寄せる
- operation のテスト導線をまとめる
- 下流チームに OpenAPI を渡す
これは全面刷新よりはるかに小さいですが、単発スクリプトを増やすよりずっと意味があります。
特に刺さりやすい条件
この進め方が効きやすいのは次の条件です。
- ERP 自体は当面残る
- 複数チームが同じ upstream operation を使う
- 困っているのが業務ロジックではなく連携の複雑さ
- 今四半期中に前進が必要
逆に相性が弱いのは:
- upstream 自体の業務要件がもう合っていない
- ドメインモデルを全面的に組み直す必要がある
- contract が信用できないほど頻繁に変わる
本当の価値は protocol より運用にある
SOAP と REST の違いだけを見ると、話が浅くなりがちです。
大きいのは運用面です。
- デバッグ箇所を減らせる
- XML を直接触るチームを減らせる
- テストしやすくなる
- 新しい担当者が入りやすくなる
- upstream fault が起きた時の見通しが良くなる
今の ERP 連携が5か所で別々に壊れるなら、直すべきなのはそこです。
現実的な進め方
安全なのは、だいたい次の順番です。
- operation を少数に絞る
- 認証と request 生成を1回だけちゃんと固める
- 下流向けに見やすい契約を出す
- 個別スクリプトや場当たり対応を徐々に減らす
地味ですが、これが legacy integration の負債から抜ける一番現実的な形です。
最後に
SOAP-to-REST は ERP そのものを現代化する魔法ではありません。
でも、ERP の周囲にある「使いにくさ」を現代化することはできます。
多くの組織にとって、今年本当に改善できるのはそこです。