社内システムだからといって、連携が楽とは限りません。
むしろ厄介なのは、社内の別部門が持つ legacy SOAP だったりします。
なぜこれは独特に面倒なのか
この種の案件は、ベンダー連携でもなければ、きれいな社内 API でもありません。
相手部門はたいてい、
- 優先順位が違う
- リリースサイクルが違う
- 仕様を変える動機が弱い
- こちらの開発速度に最適化していない
ので、「社内なのに、実態としては固定された外部依存」に近い動きをします。
ありがちな見誤り
社内だから、あとで API を直してもらえるだろうと思いがちです。
実際にはこうなりやすいです。
- 「今期はそこまで手が回らない」
- 「まずは既存 SOAP を使ってほしい」
- 「そこを変えると他システムにも影響する」
数か月後も、納期責任はこっちにあり、SOAP の複雑さもこっちが抱えたままです。
現実的な進め方
連携の観点では、そのサービスを「固定された外部依存」として扱った方が健全です。
つまり、
- 仕様改善待ちをやめる
- こちら側に境界を置く
- 下流チームには上流の歴史ではなく、自分たちに必要な契約を渡す
という考え方です。
同じ会社の中でも、管理された SOAP-to-REST 層が意味を持つのはこのためです。
1か所に寄せたいもの
- WSDL の解釈
- 上流認証
- JSON への写像
- 下流向けの REST / OpenAPI
- fault の正規化
- XML を各チームが読まなくて済むテスト導線
同じ legacy SOAP を複数部門や複数プロダクトが使うほど、この集約の価値は大きくなります。