プリズマジャーナルTOP＞OMO 時代のシステムアーキテクチャ (2) バックエンドサービスの利用
OMO 時代のシステムアーキテクチャ (2) バックエンドサービスの利用
徒然ジャーナル
2022/10/25

OMO 時代のシステムアーキテクチャ (2) バックエンドサービスの利用

早川貴裕
早川貴裕
# バックエンド # OMO # フロントエンド # ヘッドレス # API # ECサイト構築

「OMO (Online Merges with Offline) を実現したい」──そんな時、皆さんはどのようなシステム構成を思い浮かべるでしょうか。これに対する1つの解をお持ち頂くことを目指してスタートした連載「OMO 時代のシステムアーキテクチャ」。2回目となる今回は、バックエンドの構築、運用コストを抑える方法の1つとして、外部のバックエンドサービスを利用する案を紹介します。

目次
1．OMO 実現に必要なシステム構成「ヘッドレス」 2．EC / アプリなどの構築パターン 3．フロントエンドに注力するためのバックエンド : 外部サービスの利用

1．OMO 実現に必要なシステム構成「ヘッドレス」

前回の記事「OMO 時代のシステムアーキテクチャ (1) ヘッドレス」では、 OMOの実現に必要なシステム構成として「ヘッドレス」を紹介し、フロントエンドとバックエンドを分離することをお伝えしました。これにより、以下のような効果を見込めます。

●API 仕様を決めておけば、フロントエンドとバックエンドを個別に構築できる。
●各チャネルは、独自の体験をフロントエンドに作り込める。
●各チャネルから取得した共通のバックエンドデータを利用し、ユーザーへの提供価値を高められる。
●各チャネルでの重複機能の開発を削減できる。

一方、このような構成を実現するには、 API開発や、 APIを用いたフロントエンド開発など、難易度の高い設計、開発が求められることをお伝えしました。

OMOの実現を目指す上で特に注力したいのは、フロントエンドでの独自体験の構築ではないかと思います。

本記事では、フロントエンドに注力するために、バックエンドの構築、運用コストを抑える方法の1つとして、外部のバックエンドサービスを利用する案を紹介します。

2．EC / アプリなどの構築パターン

ECやアプリなどを構築する際、大きく以下のような選択肢があり、それぞれメリット、デメリットがあるかと思います。

1．　ASPやパッケージを利用する

▼メリット
・要件がフィットすれば、開発スピードの向上やコスト削減を見込める。
・製品によっては、ノーコードや簡単なコードの修正で UI を変更できる。
・ASP / パッケージベンダーに、構築 / 運用を任せられる。

▼デメリット
・カスタマイズを行う際は、製品毎の制約に縛られる。
無理なカスタマイズを行うと、開発スピードの低下やコストの増加が発生する。
・ベンダーロックイン状態になる可能性がある。
自社が利用しない、不要な機能が含まれる。
・フロントエンドとバックエンドが一体 (密結合) となっていることが多く、ヘッドレスの実現には向かない。

2. スクラッチで構築する。

▼メリット
・製品毎の制約などに縛られず、自社の要望を作り込める。
・システム構成 / 運用などを、自社の希望に沿って設計できる (ヘッドレスの実現も可能) 。

▼デメリット
・内製化やITベンダーへの構築依頼を行うことになるが、かなりのシステム投資や、体制構築が必要になる。
・うまく構築できなかった場合、技術的負債を自社で抱える形になる。
・運用後も見据えた優れた設計 / 開発を行うなど、高い技術レベル / 体制が求められる。

その他に、 EC向けオープンソースを利用する方法なども考えられますが、 ASP、パッケージ利用と同様に、オープンソースの制約に直面したり、スクラッチと同様に、体制構築が必要になります。また、セキュリティの担保や内部モジュールの更新など、運用を自社で行う必要があったり、インフラ運用なども必要になるため、維持するのが大変そうですね。

実際に、ヘッドレスな構成をスクラッチで構築する場合、どのような構成になるかを見てみましょう。

構成としては、以下のようなものになるでしょう。

1．各チャネルに対応するフロントエンド

・画面に加え、各チャネルの画面 (体験) を最適化するための、 Backend for frontend (以下、 BFF) 層を含みます。BFF には、チャネルに最適化するための API / ビジネスロジックの他に、独自体験を構築するために必要なデータ (DB) を保持することもあります。
・BFF をチャネル共通にしたり、アプリから WebView で EC サイトを表示するパターンなども考えられますが、各チャネルの自由度を最も高める場合は、このような構成になります。

2．　チャネル共通のバックエンド (コマース関連)

・フロントエンドなどからのリクエストを受け付ける API に加え、各チャネルから共通で利用されるデータ (DB) や、ビジネスロジックからなります。

3．　外部サービス

・上記のバックエンド以外に利用する外部サービスです。
・決済代行サービスなどが候補になると考えられます。

スクラッチで構築する場合、フロントエンド / バックエンド / 外部サービス連携の構築が必要となるため、構築量が多くなりそうです。

上述の構築パターンのメリットを最大化 / デメリットを最小化させ、「ヘッドレスの実現を目指しつつ、全体の構築 / 運用コストを抑え、フロントエンドでの独自体験の構築に注力したい。」そんな課題を解決する方法はあるのでしょうか。

そこで紹介したいのが、バックエンドサービスに外部サービスを利用する方法です。

3．フロントエンドに注力するためのバックエンド : 外部サービスの利用

チャネル共通のバックエンドとして、構築、運用を外部サービスに任せ、各チャネルは、フロントエンドでの独自体験の構築に注力するという方法です。前回も少し触れた、「ヘッドレスCMSの利用」も、この流れですね。

外部のバックエンドサービスを利用する場合、どのような観点が必要となるでしょうか。

まずは「構築面」から見ていきましょう。各チャネルから共通で利用できそうな、コマース領域に必要な機能の充実度を確認しましょう。機能がない場合、フロントエンドに構築することになります。自社にとっての基本機能が、ある程度揃っていることを確認するとよいでしょう。次のような機能について、確認しておきたいところです。

・商品 / 注文 / 顧客管理などの基本機能
・エンゲージメント向上を図るためのポイント / マイル機能
・プロモーション施策を行うための割引 / クーポン機能
対応する決済サービス / SNS 連携

また、フロントエンドを構築する際に、特定の技術 (フレームワークなど) の利用を求められないかを確認できるとよいと思います。

次に「運用面」です。運用やセキュリティにおける基準が、自社基準を満たしているか確認しましょう。正常時の稼働に加え、アクセス数が増加した際の拡張性などを確認できるとよいかと思います。この辺りは、プロモーション施策を行う際の柔軟性にも関係します。

また、必要な機能群 (商品機能など) のみを選択して利用できるかを確認できるとよいかもしれません。これにより、以下のようなメリットを受けられます。

・インフラ費用が機能群毎になっていれば、不要な費用の発生を避けられる。
・プロモーション時にも、対象の機能群のみを増強すればよい。
・将来、特定の機能群を他サービスにリプレイスしたり、戦略機能として自社開発を行うような場合に、切り替えやすい (ベンダーロックイン状態を回避しやすい) 。

上記のような条件を満たすバックエンドサービスを利用することで、外部から調達可能な機能を、必要な時に必要な分だけ導入しつつ、独自の差別化機能や不足機能を、フロントエンドに構築できます。外部サービス利用では実現できない部分を、フロントエンド (下図の赤塗り部分) に構築する形ですね。

次回は、これまでに紹介した内容を実現している具体例を、弊社製品の「prismatix」を通してご紹介します。前回と今回で、 OMO を実現するためのヘッドレスな構成、さらに、フロントエンドでの独自体験の構築に注力するための選択肢として、外部のバックエンドサービスを利用する案を紹介しました。次回は、その具体的なイメージをお持ちいただけるようにしたいと思います。

早川 貴裕

執筆者プロフィール

早川 貴裕 　ソリューションアーキテクト

ソフトバンク、DeNAなどで、PMO、ITエンジニアとして、携帯端末販売システム、EC、物流サービスなどの開発に従事。前職では、アパレル製品の製造小売を行うマザーハウスで、ITグループリーダーとしてシステム対応全般を担当。学生時代は物理学を専攻し、その後経営学修士を取得。2020年11月にクラスメソッドに参画。prismatixの導入支援、導入後サポートを担当。

≪支援実績≫
・OMO/EC ：アンファー、グラニフ（導入後サポート、導入支援）
・CRM：サンリオ、大手アパレル（導入後サポート、導入支援）

この記事をシェアする
Facebook

記事一覧へ戻る

プリズマティクスのサービス

Keyword

Follow Us

Facebook