SYSTEM STRATEGY / ARCHITECTURE

SOAとは？業務機能をサービスとして組み合わせる設計思想

SOA（Service Oriented Architecture：サービス指向アーキテクチャ）は、「在庫を調べる」「注文を受け付ける」「支払う」といった業務上の機能を、ほかのシステムから利用できる独立したサービスとして整理し、組み合わせる設計思想です。単にプログラムのファイルを分割することではありません。

01何が困るのか：同じ在庫確認を3回作る会社

ある小売企業では、店舗のレジ・ネットショップ・卸売向け受注システムが別々に開発され、それぞれ独自の「在庫確認」を実装していました。倉庫が増えたり、在庫の計算ルールが変わったりすると、3つのシステムすべてに修正が必要です。修正漏れがあれば、店舗では在庫あり、ネットでは在庫なし、と矛盾した結果が表示されます。

共通化すれば、どの利用者も同じ在庫ルールを使えます。ただし共通サービスが止まると複数の利用者に影響するため、可用性や障害時の設計も重要です。

02SOAの「サービス」は、何を約束するのか

ここでいうサービスは「利用者にとって意味のある業務機能」です。例えば在庫確認サービスなら、「商品コードを渡すと、販売可能数が返る」という利用方法（インターフェース／契約）を明確にします。利用側は、在庫がどのテーブルに保存され、どんな言語で計算されているかを知らなくても利用できます。

03別の業務フローに組み合わせて使う

在庫確認だけでは注文は完了しません。「在庫確認 → 注文登録 → 決済」という複数のサービスを業務の順序に沿って利用します。後日、店舗受取という業務を追加するときも、既存の在庫確認や決済サービスを再利用できます。

04メリットと、実務で考えるべきこと

SOAは、すべてを細かく分割すればよいという意味ではありません。分けたことでかえって変更が難しくなるなら、サービスの境界を見直します。

05ERP・フィット＆ギャップ分析・PDCAとの違い

これらは対立する製品名ではなく、そもそも問いの種類が違います。

例えばERPの一部機能をサービスとして外部公開することもできます。つまりERPとSOAは同時に採用できるもので、「どちらか一方しか使えない」関係ではありません。

06SOAとマイクロサービスは同じ？

どちらも独立した機能を連携させるという共通点があります。ただし、SOAは企業の業務機能をサービスとして捉え、再利用・連携する広い設計思想です。マイクロサービスは一般に、より小さなサービスを独立して開発・デプロイ・運用するアーキテクチャ上の方法を重視します。

「SOAなら必ずSOAPを使う」「APIがあれば全部SOA」「一つのサービスが一つのサーバーにある」といった理解は不正確です。大切なのは、業務の意味を持つサービスの境界・契約・連携の設計です。

07操作して理解：サービスを組み替える

利用する業務を切り替え、どの共通サービスが呼ばれるかを確認してください。サービス障害も発生させると、共有の利点だけでなく影響範囲が広がる欠点も見えてきます。

08まとめ：部品を分ける目的は、業務をつなぐこと