Amazon Web Services ブログ

店舗システムのクラウド化に向けた考察2 – クラウド移行後アーキテクチャと進め方

前回の記事では、ストアコンピュータや、POS といった店舗に配置されているワークロードを AWS で稼働させるにあたってのメリットや構成について可用性と応答性能に焦点をあてて考察しました。本記事では、AWS クラウドに移行後のアーキテクチャと、実現に向けたアプローチについて考察します。

アーキテクチャとして検討すべき対象範囲

店舗システムをクラウド化するメリットとして、前回の記事では以下のメリットを述べました。

  • コスト削減(ストアコンピュータレス)
  • 運用効率化(システム集約化、ハードウェアライフサイクルからの解放)
  • 機能の高度化(データ活用のし易さ、ハードウェアリソース制約からの解放)

最後の機能の高度化について、店舗システムということで、POS や検品や陳列、発注やスタッフ管理といった店舗業務が検討範囲であることは言うまでもありませんが、”顧客の購買体験を提供する店舗” として考えた場合、購買体験がテクノロジーの進歩と共に変わっていることは、顧客でもある皆様はご理解いただけるのではないでしょうか。

  • 以前:顧客の購買体験は店舗で完結
  • 現在:顧客の購買体験は店舗で完結するわけでなく、ECやモバイルなどをまたがっている(例えばモバイルオーダーで注文して店舗で受け取る、フードデリバリーのように顧客は店舗に来店しないが店舗が介在する)

図1:購買体験の変化

購買体験が変化すると、店舗オペレーションや店舗システムも対応する必要があります。従って、アーキテクチャを考えるにあたり、既存業務の継続はいうまでもありませんが、絶えず変化する顧客ニーズや購買体験の変化に対応できるアーキテクチャが求められます。つまり、下図のような店舗システムにおける主要な機能とデータの配置を、そのままクラウドに移行することはできますが、変化により対応しやすいアーキテクチャに変更する契機と捉えることもできます。

図2:店舗システムと連携先システム

多様で変化する顧客ニーズに統一的な体験を提供するユニファイドコマース

絶えず変化する顧客ニーズや購買体験の変化に対して、リアル店舗やアプリケーションを含めた統一した体験を提供するユニファイドコマースを通して顧客体験を向上させることに取り組まれています。小売業者がリアル店舗、EC サイトなど複数の販売チャネルを消費者に向けて用意する販売戦略がオムニチャネル戦略ですが、それぞれのチャネルにおいて消費者へ “統一された ( Unified ) ” 購買体験を提供することを目指す考え方がユニファイドコマースです。

ユニファイドコマースを実現するにあって、統一された顧客体験を提供するため、顧客との接点であるモバイルアプリ、店頭のタブレット、店舗の POS 端末など、様々なチャネルから顧客の行動履歴やオペレーションのデータをリアルタイムで受け取る必要があります。そして、チャネルが様々であっても、注文や在庫などの複数の拠点から随時更新される情報は最新の正しい値を特定できるようにデータを一元管理し、各チャネルからのリクエストに応じて共通のコマース機能を通してリアルタイムに情報を返す必要があります。

図3:ユニファイドコマース実現イメージ

アーキテクチャは、多くの小売業者が注目している MACH (Microservices-based, API-first, Cloud-native SaaS, Headless) アーキテクチャを取り入れることで実現できます。ビジネスの機能別に開発できるようなマイクロサービスで設計し、機能間の連携は API を通して行い、クラウドの柔軟性やスケーラビリティを活用し、フロントエンドはヘッドレスな設計にすることでバックエンドのロジックと切り離して疎結合とする、という原則に基づいたアーキテクチャです。

図4:MACH アーキテクチャによる実店舗と EC が連携するアーキテクチャイメージ

ユニファイドコマースを実現するにあたってのガイダンス

AWS は、ユースケース別の AWS ベストプラクティスに基づく設計や実装として、AWS Solutions / Solutions Guidance / AWS Samples を用意してます。これらを利用することによって、全てを 1 から考えて自社向けに開発して、他社との差別化にならない部分に時間とお金を投資することを避けられます。

ユニファイドコマースについては、Solutions Guidance(ソリューションガイダンス)が用意されていて、「AWS でのユニファイドコマースに関するガイダンス 」を参考にできます。

図5:アーキテクチャ図

詳しくは、ソリューションガイダンスのウェブページに加えて、本ソリューションガイダンスを解説しているこちらのブログ(ビジネスアジリティを加速する AWS のアーキテクチャ part 2 – Unified Commerce on AWS)にまとめられていますが、MACH アーキテクチャの原則に則っています。

店舗システムの移行にあたってのコンポーザブルアプローチ

店舗システムは、様々な業務機能やデータから構成されています。ストコン や POS といった機器に分かれているものの、長年運用していると、初めは別々に作られていた機能が、相互に関連し合う、いわゆる密結合となっていることは起こり得ます。また、クラウド移行後のユニファイドコマース、MACH アーキテクチャを紹介しましたが、今後を見据えてアーキテクチャを変更するものもあれば、差別化にはならないためそのまま移行するものもあります。

店舗業務の分類 業務システムに対する期待 システム/機能の例 移行方針の例
接客・販売 多様で変化する顧客ニーズに素早く対応することが期待される POS セルフレジ、スマフォレジを展開をしやすくするためアーキテクチャを変更する
在庫 モバイルオーダー、フードデリバリーとの連携をしやすくするためアーキテクチャを変更する
バックヤード・店舗管理 接客・販売に注力できるための効率化が、業務だけでなくシステム面でも期待される 検品 既存機能を踏襲するので単純移行する
スタッフ勤怠管理 開発と運用の負担を軽減するため SaaS を利用する

1 回で移行するビッグバンアプローチは、シンプルではあるものの移行失敗時による変革のリスクがありますが、共通のコマースメカニズムをマイクロサービスで提供するユニファイドコマースにおいては、必要となる仕組みを段階的に組み立てていくコンポーザブルアプローチにより、リスクの軽減を図りつつ、すばやく実現していくことができます。

密結合となっている、結果として一枚岩(モノリス)なアプリケーションを段階的に移行する設計パターンとして、ストラングラーフィグパターンを利用することができます。利用できるケースや考慮事項、実装といった詳細については、AWS の規範的ガイダンスのクラウドの設計パターン、アーキテクチャ、実装にまとめられています(こちら)。

この他、モノリスのアプリケーションからマイクロサービスとして機能を切り出すにあたっては、AWS の規範的ガイダンスの モノリスをマイクロサービスに分解 に、ビジネス能力別に分解、サブドメインによる分解、トランザクションによる分解、チームごとのサービスパターンなどの各パターンの利点と欠点を含む特徴がまとめられているので参考になります。さらに、マイクロサービス間でデータを永続化するためのパターンについては、マイクロサービスにおけるデータ永続性の実現 にまとめられています。

まとめ

本記事では、店舗システムの AWS クラウドに移行後のアーキテクチャと、実現に向けたアプローチについて考察しました。顧客の購買体験を提供する店舗として、店舗に限らない各販売チャネルで統一した体験を提供するユニファイドコマースとして検討していく必要性と、ユニファイドコマースを実現する MACH アーキテクチャを紹介し、AWS より提供するソリューションガイダンスや規範的ガイダンスを利用することで、1 から考える必要がなく、実現に向けて迅速に進められることを説明しました。

コンビニエンスストアやスーパーマーケットなど多店舗展開している小売業では、どの機能からどのような移行方針で進めるか、という観点だけではなく、全店舗一斉に切り替えるのか、あるいは地域や店舗形態などの分類単位より段階的に切り替えるのか、という観点も考える必要があります。本記事によって、店舗システムのクラウド化にあたって考えなければならないことが減り、それによりクラウド移行が促進され、結果としてビジネスの成長につながれば幸いです。

 

関連情報

 

ソリューションアーキテクト 平井 健治