通販サイト/システムのリアーキテクチャの選定ポイント/選び方/種類

通販サイト/システムのリアーキテクチャに着手しようとすると、マイクロサービス化・DDD・イベント駆動といった技術用語が先行し、自社にとってどこまでの規模で進めるべきかを見誤ることがあります。通販サイト/システムのリアーキテクチャの選び方は、契約と受注のライフサイクル分離や頒布会・同梱物という自社固有の業務がどこにあるかを診断したうえで、進め方の種類とコアドメイン・汎用サブドメインの切り分けを決めることから始まります。

本記事では、選定前に整理すべき自社の課題、リアーキテクチャの進め方の種類、組織体制による選び方、コアドメインと汎用サブドメインの切り分け方、比較すべき評価軸、PoCの進め方までを解説します。これからリアーキテクチャの計画を立てる担当者の方が、自社の規模と業務特性に合った進め方を具体的に絞り込めるよう整理します。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・通販サイト/システムのリアーキテクチャの完全ガイド

リアーキテクチャ選定前に整理すべき自社の課題

最初に行うべきことは、マイクロサービス化の技術要素を調べることではなく、既存の深夜バッチがどれだけ複雑な条件分岐を抱え、契約(サブスクリプション)と受注(オーダー)の処理がどこまで密結合しているかを可視化することです。課題の所在が明確になるほど、進め方の種類や着手範囲を判断しやすくなります。

頒布会の周期変更、同梱物の出し分け、特売期間中の例外処理などが一本の深夜バッチに積み重なっている場合、そのロジックをドメインごとに解きほぐす作業だけでも数週間から1.5か月程度を要することが一般的です。また、契約の休止・解約と個別受注の生成処理が同じテーブル・同じコードパスで扱われているほど、どちらか一方を変更した際にもう一方まで意図せず影響してしまうリスクが高くなります。この二点をまず数値や具体例で把握することが、選定の出発点になります。

電話でのコールセンター受注がシステムと分断されたまま運用されている場合、オペレーターの在庫確認と実際のシステム在庫にずれが生じやすくなります。また、月末の定期受注確定日やセール時期にトラフィックとバッチ処理が極端に集中し、その時間帯だけシステムが不安定になっているなら、負荷が集中する処理を独立させる優先度が高いと判断できます。これらの実態を関係部門にヒアリングし、影響範囲と発生頻度をあわせて整理しておくと、後述する進め方の種類を選ぶ材料になります。

課題の洗い出しは、情報システム部門だけで完結させず、頒布会の企画担当者やコールセンターの運用責任者を交えて行うことが望ましい進め方です。企画側が把握している同梱物の切り替え頻度や、コールセンター側が日常的に感じている在庫確認の手戻りは、システムログだけを見ていても表面化しないことが多く、こうした現場の情報を合わせて初めて、どのドメインから着手すべきかの優先順位が明確になります。

リアーキテクチャの進め方の3つの種類

進め方は大きく、モジュラーモノリスに留める方法、API Gatewayを使ったストラングラーフィグパターンによる段階移行、対象領域をフルマイクロサービス化する方法の3つに分けられます。どれが優れているというものではなく、組織規模と課題の深刻度によって適切な選択が変わります。

モジュラーモノリスは、契約管理・受注管理・同梱物選定といった責務をコード上で明確に分離しつつ、デプロイ単位は一つにまとめる進め方です。マイクロサービス化で発生するサービス間通信や監視の運用オーバーヘッドを避けながら、将来的な分割の土台となる境界を先に整理できる利点があります。エンジニアチームの人数が限られる組織や、まず内部の責務を整理したい段階の組織に向いています。

ストラングラーフィグパターンによる段階移行は、API Gatewayを既存モノリスの前段に配置し、コールセンター連携APIなど特定のトラフィックから新しいサービスへ段階的に振り分けていく方法です。既存システムを稼働させたまま検証と移行を進められるため、多くの通販・定期購入業態の企業にとって現実的な選択肢になります。フルマイクロサービス化は、同梱物選定や定期便のスキップ制御など複数のコアドメインをまとめて分割する方法で、独立スケーリングの効果は大きい一方、分散トランザクションの検証範囲も広くなるため、十分なSRE体制が整っている組織向けの選択肢です。

組織体制で変わる選び方

技術的にどこまで分割できるかよりも、その構成を維持できる組織体制があるかどうかが、リアーキテクチャの選び方を左右する現実的な条件になります。

エンジニアチームの人数がおおむね10〜15名に満たない組織では、マイクロサービス化によって増える運用・監視・デプロイ管理の負荷が、独立スケーリングによって得られるメリットを上回りやすくなります。この閾値を大きく下回る場合は、無理にフルマイクロサービス化を選ばず、モジュラーモノリスや、影響範囲を絞った段階移行から着手する方が現実的です。

Sagaパターンによる補償トランザクションは、実装後も決済成功・在庫確保失敗といった例外ケースへ継続的に対応する運用体制を必要とし、こうした役割を担えるSRE人材の確保・育成には一定のコストがかかります。また、機能分割が進むほど「Cost per order」のような単位でコストを可視化するFinOpsの体制も必要になります。これらの運用力が整っていない段階でフルマイクロサービス化に踏み切ると、技術的には正しくても運用が回らない状態に陥りやすくなります。

体制面の準備状況を判断する際は、現在のインフラ運用担当者が障害対応をどこまで自動化できているか、24時間365日の監視体制を組めるかもあわせて確認します。補償トランザクションが必要になる場面は深夜や休日にも発生し得るため、日中しか対応できない体制のままフルマイクロサービス化を進めると、障害発生時の復旧までに長い時間を要し、顧客からの問い合わせ対応にも影響が及びます。

コアドメインと汎用サブドメインの切り分け方

進め方の種類を決めたら、次にどの業務領域を自社で作り込み、どこを外部のSaaSに任せるかを判断します。この切り分けを誤ると、フルスクラッチの運用負荷を無意味に増やしたり、逆に独自性が求められる部分まで汎用製品に合わせてしまったりします。

同梱物選定ロジックや頒布会・定期便のスキップ・休止・再開制御は、自社の商品構成や顧客対応方針を色濃く反映するコアドメインであり、既製のパッケージだけでは自社の細かい業務ルールを表現しきれないことが多くなります。この領域は、Sagaパターンによる補償トランザクションを自社の業務フローに合わせて厳密に実装できるよう、フルスクラッチのマイクロサービスとして設計する方針が適しています。

決済処理や定期便請求(サブスクリプション課金)は、業種を問わず共通する汎用サブドメインであり、PCI-DSSなど厳しいセキュリティ要件への対応も求められます。これらを外部のSaaSに委譲すれば、監査対象の範囲を限定しながら、自社で一からセキュリティ対応を担う負荷を避けられます。同梱物・頒布会という独自の価値を生む領域のみフルスクラッチで設計し、決済・定期課金という汎用領域は外部委譲するハイブリッド戦略が、コスト・納期・運用保守の観点で成功率の高い進め方です。

比較検討で押さえておきたい評価軸

進め方の種類とドメインの切り分けが決まったら、実際に検討する体制・パートナー・製品を、分散トランザクション設計、障害分離、コスト最適化、運用体制という共通の評価軸で比較します。

定期便のスキップ・休止・再開を扱うSagaパターンの補償トランザクションが、どの単位でロールバック・冪等性を担保できるかを確認します。あわせて、同梱物選定エンジンなど障害が起きやすい機能が停止した場合に、チェックアウトや決済まで巻き込まれず、デフォルト処理でフォールバックできる設計になっているかも重要な確認点です。

高負荷機能をPush型のイベント駆動で即時処理するか、遅延許容の処理をPull型のバッチ同期に留めるかによって、運用コストは大きく変わります。同梱物・頒布会最適化のように即時性が不要な処理は、Pull型を選ぶことでランニングコストを抑えられる場合があります。あわせて、「Cost per order」のような単位でコストを継続的に計測できる体制があるか、Sagaパターンの運用を支えるSREスキルを確保できているかも比較軸に含めます。

比較検討の結果は、担当者ごとの主観で優劣をつけるのではなく、確認方法まで統一しておくことが重要です。「Sagaパターンに対応できる」という説明だけでは、実際にどこまでの補償トランザクションを自動化できるのか、手作業での介入が必要な例外がどの程度残るのかが分かりません。デモで再現できた事項と、仕様書上でしか確認できていない事項を区別して記録し、未確認のまま評価点をつけないようにすることで、後になって想定と異なる運用負荷が判明する事態を防げます。

PoCと検証の進め方

比較検討で候補となる進め方が絞れたら、いきなり全面移行するのではなく、3〜6か月程度のパイロットフェーズで通販・定期購入業態特有の分散システム課題を検証します。

定期便のスキップ・休止・再開処理は、分散トランザクション・非同期通信・他システム連携というマイクロサービスで最も複雑度が高い領域です。全ドメインを一斉に検証するのではなく、スキップ処理とコールセンター連携の一部といった垂直スライスに絞り、補償トランザクションの連鎖、冪等性キーによる重複リクエスト対策、イベント順序の検証に集中することが、パイロットフェーズを成功させる鍵になります。

垂直スライスの選び方も重要な論点です。影響範囲が狭く、かつ分散トランザクションの複雑さを十分に含む処理を選ぶことで、限られた検証期間の中でも本番移行時に起こり得る問題の大部分を洗い出せます。逆に、影響範囲が広すぎる処理をいきなり垂直スライスに選んでしまうと、検証すべき例外パターンが膨らみすぎて、パイロットフェーズ自体が長期化する原因になります。

同梱物選定エンジンについては、あえてエンジンをダウンさせるカオスエンジニアリングを行い、チェックアウトや決済が巻き込まれずデフォルト同梱で注文を完了できるかを確認します。コールセンター連携APIについては、Prism・Mockoonなどのモックサーバーを使ったコントラクトベース開発で、バックエンド完成前にフロント・コールセンター改修を並行検証できるか、また電話対応中の在庫確保とWeb購入が競合するレースコンディションを排除できているかをあわせて検証します。具体的な製品・サービスの候補を確認したい場合は、通販サイト/システムのリアーキテクチャのパッケージ/クラウド製品一覧を参照すると、決済・定期課金・API連携それぞれの候補を比較しやすくなります。

通販サイト/システムのリアーキテクチャ選定前に確認しておきたいポイント

進め方の種類やドメインの切り分けを検討した後も、実際に着手する前に確認しておきたい論点がいくつかあります。

エンジニアチームが10〜15名に満たない場合でも、モジュラーモノリスとして責務を整理したうえで、コールセンター連携APIなど影響範囲を絞った一部機能だけをストラングラーフィグパターンで切り出す進め方であれば、運用負荷を抑えながら着手できます。全ドメインの同時分割は避け、優先度の高い領域から段階的に広げることが現実的です。

決済・定期課金を外部SaaSに委譲する場合も、どのデータを正本とするか、返金や解約時の補償トランザクションをどちらの責務で処理するかを契約前に明文化しておく必要があります。役割分担があいまいなまま連携すると、障害発生時にどちらが復旧対応を担うかで混乱が生じやすくなります。

PoCで扱う頒布会・同梱物パターンや契約条件が、実際の本番データの複雑さを反映していないと、本番移行後に想定外の例外処理が次々と見つかることになります。件数を絞ってもよいので、実在する契約形態・同梱パターンを使って検証することが重要です。

まとめ

通販サイト/システムのリアーキテクチャの選定では、深夜バッチの複雑度や契約と受注の結合度という自社課題を診断し、モジュラーモノリス・段階移行・フルマイクロサービス化という進め方の種類から、組織のエンジニア人数やSRE体制に見合った方法を選ぶことが出発点になります。そのうえで、同梱物・頒布会というコアドメインは自社開発、決済・定期課金という汎用サブドメインは外部SaaSへ委譲するハイブリッド戦略で境界を定め、分散トランザクション設計・障害分離・コスト最適化・運用体制という評価軸で具体的な進め方を比較することが重要です。

全ドメインを一斉に検証するのではなく、定期便のスキップ処理とコールセンター連携の一部といった垂直スライスに絞ったPoCで、Sagaパターンの補償トランザクションと障害分離を確認したうえで、対象範囲を段階的に広げることが失敗を避ける現実的な進め方です。

既製のパッケージやSaaSでは、同梱物選定や頒布会・スキップ制御といった自社独自の業務ルールを十分に表現しきれないことがあります。riplaはフルスクラッチ開発の立場から、進め方の種類の選定支援、コアドメインと汎用サブドメインの境界設計、既存の基幹システム・コールセンターシステムとの連携を含む構築まで支援しています。

▼全体ガイドの記事
・通販サイト/システムのリアーキテクチャの完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。