コラム

ユニファイドコマースとは何か?
2025/01/23

最近、「ユニファイドコマース」という言葉を目にすることが増えてきたと思われている方も多いのではないでしょうか?

この概念が何を示すのか、オムニチャネルとは何が違うのか。
このコラムでは、オムニチャネルを踏まえたECパッケージのアーキテクチャー(システム的な構造)はどうあるべきかを追求してきたERSとしての視点で考えてみます。

新たなトレンド?オムニチャネルはもう古い?

いつの世のどこの業界でもそうでしょうが、EC界隈にも新しいワードが次々と登場します。

SEO(Search Engine Optimization)、EFO(Entry Form Optimization)、LPO(Landing Page 以下略)あたりはまだわかりやすいものでした。アクロニムであり、元のワードにしてしまえば読んで字のごとく。「対象+何をしたいか」という言葉なので、具体的手法はともかく何を意図しているかは見ればわかるといった印象がありました。まだ平和といえば平和だったなと思います。

しかしその平和は「オムニチャネル」で破られたような気がします。チャネルという言葉はまさに慣れ親しんだテレビの「チャンネル」なのですが、この言葉は概念的で少し意味がわかりにくく、困惑させられることがあります。そして極めつけなのはそれを修飾する「オムニ」という不思議なワードです。「遍く」などと訳されてもそもそもそんな言葉を日常で使う人がどれだけいるのか疑問です(ゲームやアニメの決め台詞ならありそうですが)。

オムニチャネルについては、ERSの解釈については以前に こちら に書いてみました。この記事とは別のやや異なる視点での考察になっていますので、興味のある方はぜひご一読いただければと思います。

そんなオムニチャネルが、ちょっと意味がもやっとしていても耳には馴染んできたなという安心感も束の間、それに代わる新たなワードとして登場し、最近よく耳にされる方も増えたであろうものが「ユニファイドコマース」です。

今回は、この言葉が意味するところについて、まだ十分に解釈が定まっていない言葉だという認識ではありますが、ひとまず現時点でのERSなりの理解を述べさせていただきます。いろいろ思うところはありますが、オムニチャネルも踏まえてわりと単純化できたと思います。

結局ユニファイドコマースって何だろう、オムニチャネルって何だったんだろう・・・という答えを探し求めてウェブ上を彷徨いこんなページにまで辿り着いてしまった方は是非、お付き合いください。

「Unified Commerce」

この言葉はオムニチャネルと同じく欧米の業界に起源を持ちますから、英語版のWikipediaの説明を読むのが手っ取り早い・・・と思ったのですが、残念ながら該当するページはまだ見つかりませんでした。
しかし英語で検索を行えば、わりと多くの文書を目にすることができます。

例)参考その1 参考その2

他にもいくつかのページを読んでみましたが、定義・解釈に揺れを感じるものの、結局、「1つのプラットフォームで」ということが共通項の中でもコアな部分という印象です。

顧客情報をチャネル問わずに統合し、パーソナライズされたシームレスな体験を顧客にもたらす。いつでもどこでも(スマホでも店でもその他でも)、連続的なサービスを提供する。そうした考えは、もちろんあわせて語られています。

しかし、米国でのオムニチャネルの合言葉は10年以上前から「Anytime, Anywhere」でしたし、パーソナライズもその頃からの最重要課題でした。つまり、先のような顧客体験に関する要求は最近になってユニファイドコマースという新しい概念によりもたらされたわけではなく、それに先立ち普及していたオムニチャネルという概念がすでに明確に表しています。言葉を変えて再定義する必要はありません。

ですので、繰り返しのようになりますが、Unified Commerceという概念は、耳馴染みの良い言葉で言い換えれば「シングルプラットフォームにより統合されたEC」、あるいはそれを前提にオムニチャネルに対応した戦略と捉えることが妥当ではないかと考えます。そしてこれは単純に言ってUnified Commerceという英熟語の直訳に近い意味でもありますから、解釈として自然なのではとも思います。

ユニファイドコマースとは何か?という問いに対する、既存の解説を踏まえたひとまずの回答は以上の通りです。

しかし、唐突に「シングルプラットフォームで」と言われても釈然としないものがあります。ですので、ここからはその定義を踏まえて、シングルチャネル・マルチチャネル・オムニチャネル・ユニファイドコマースと順を追って、その概念および必然性と関係性について、筆者なりに整理してみます。

そもそも「〇〇チャネル」とは何か?

最初に注意すべき点として、〇〇チャネルという言葉は、システムの機能やマーケティング手法を指しているわけではありません。チャネルという言葉はこの場合は販売経路ですが、それが単一であるという「人の消費行動の様式、その背景にある社会の状態」の定義であるということの方が本質です。その上で、そのような状況におけるビジネス上の戦略という意味を含むということになります。状況の定義を行う動機は戦略の立案にあるかもしれませんが、その状況認識自体は戦略に依存するものではなく、戦略が状況認識・定義の上に成り立ちます。逆ではあり得ません。

ですので、〇〇チャンネルを戦略と結び付けて考えることは間違っていませんが、まず具体的手法(戦術と呼ぶべきでしょうか?)を議論する前に、戦略が前提としている状況の理解が必要なはずです。

チャネルは別に情報通信技術に固有の言葉ではないので、システムがなければチャネルがないわけでもありません。懐かしい昭和中期までの八百屋さんでお店にソロバンくらいしかないとしても、その店舗はチャネルです。

チャネルという概念を、「ネット」「電話」「ECサイト」「店舗」といったわかりやすい具体イメージから切り離して捉えられるようにしておくことが、議論を明確にする上で重要です。チャネルとは、単一の戦術(施策)を当てはめることが出来る同質な販売経路と考えるべきでしょう。

脱線しているように思えるかも知れませんが、抽象度の高い概念を正確に理解したい場合、簡単で基礎的に思える要素をしっかりと定義し理解していくということが、その近道になるのではないかと思います。

シングルチャネル

さて、シングルチャネルですが、図ではこうなります。

シングルチャネルは必ずしもECのことではありません。最初にネットショップだけで起業したショップであればそれはECサイトのことでしょうが、ECには無縁の商店を営んでいるならば店舗がそのチャネルです。つまり、シングルチャネルということは「販売経路が単一である」ということを言っているだけです。数十年前は大部分のショップがシングルチャネル(店舗のみ)だったと思われます。その後、電話通販が広まり、ネット通販も始まりました。ですが、どのチャネルを利用していたとしても、一つのチャネルしかないのであればシングルチャネルです。

※ なお、ここで「ショップ」とは消費者にものを売る事業者です。近年は特に、メーカーを含む場合もあります。総じてこの場合の役割からリテーラー(小売業者)と呼ぶべきかも知れませんが、ここでは売り手側を表すものとして慣れた言葉である「ショップ」で統一します。

シングルチャネルは単純ですが、注意すべき点があります。

ここでチャネルとして識別されるものは本来、「電話」「ネット」という単位ではありません。それらはチャネルを構築する基盤技術の種類です。ただ、過去には1つのショップが複数のECサイトなり電話受注システムなりを同時運用するケースが少なかったでしょうから、そうした状況では「ネット=特定のECサイト」と見なすことも大きな誤差にはならないでしょう。とは言え、先に述べた通り、本来的にはチャネルはそれを構築する基盤技術の種類を指しているのではない、という理解は重要です。

このことは反対に言えば、チャネルがキャッシュレジスターや支店を指すものでもないということも同時に意味します。したがって、仮にリアル店舗しか持たないショップが10店舗を有していたからといって、10チャンネルあるというわけではありません。単一の仕組みによる店頭販売という基盤しか持たないのであれば、10店舗あろうが100店舗あろうがシングルチャネルということになります。店舗別の売上を追跡することは出来るでしょうが、それはここで言うチャネルとはまた別のものです。しかし、2店舗しかないショップが、それぞれでまったく別の仕組みで異なる状況・条件で販売を行っているならば、これはシングルチャネルではないのかも知れません。

つまりシングルチャネルとは、たった一つの販売経路しかないという意味ではなく、質的に単一の販売経路しかないということです。

社会的な背景

ECを中心に考えれば、黎明期(1990年代あたり)におけるECはしばしばスタンドアローンでした。モール出店のみであったり、メール受注のみであったり、実店舗をもたないショップの自社ECあるいはカートASPのアカウントであったりです。これが孤立したままであった背景には、実店舗を有しているショップにとってユーザーも少ないネット上のチャネルは弱かったので敢えてECを構築する必要性は低く、逆にニッチ商材などでECを中心に起業したショップには実店舗を持てるほどの体力はなかった、といったことがあったのではないかと思います(※ この頃のインターネットは一部の愛好者が電話のアナログ回線で接続していた程度の原野のような状態です)。


ECシステムへの要求

システム的には要求事項は多くはありません。乱暴に言えば、単一のシステム内で受注して記録する、それが出来ればOKです。そもそも利用者も注文も少なく、ネット通販などはかなり特殊な消費行動ですから、そのユーザーも購買そのもの以外の何かを期待してはいなかったでしょう。自宅にいても接続自体が難しい、というよりはそもそもPCの普及率自体が低い時代の話ですから、「買える」ということが十分なゴールになります。

マルチチャネル

図にするとこうなります。


突然に複雑さが増したように見えます。実際、構造的に複雑で、大変なので、その後にはオムニチャネルやユニファイドコマースという概念が必要になりました。

私が思うに、マルチチャネルはシングルチャネルとはまったく別の新しいパラダイムです。ただ、この強力なアイデアは複雑さに対する脆弱さがあったがためにオムニチャネルが必要になったのだと考えています。したがって、マルチチャネルの複雑さをよく観察することが、オムニチャネル以降の概念の理解の助けになるはずです。

マルチチャネルの素晴らしいところは、リテーラーが2つ以上のチャネルを用いて顧客と取引するということです。いまとなっては当たり前の前提でしかないと感じられると思いますが、その前提はシングルチャネルの世界には存在しません。マルチという言葉はここでは「多くの」ではなく「さまざまの」と考えるべきで、単に店舗が2つというのとは違います。

まとめると、マルチチャネルは、質的に異なる2種類以上の販売経路があるということです。

社会的な背景

「ネット世界」「仮想世界」「バーチャル世界」といった言葉がわりとそれらしく受け入れられていた時代背景における状況認識だと言えます。2000年代あたりでしょうか。

インターネットは最初から仮想ではないし実社会と切り離れてもいませんから上記のような表現は夢があり過ぎます。「電話世界」というものが存在していないのと同じように、ネット世界などというものはありません。確かにネット上には記憶媒体がありますが、それは単に情報伝達に時間差を生んでいるだけであり通信の両端にはいつも現実社会があります。

それでも、ネットが仮想世界だと説明されると「そうか」と思ってしまいがちなほど、まだこの頃のネットは不便でした。

十分な性能を持つPC端末と回線は家や職場にしかありませんし、家にいてネットショッピング(ショッピングをしなくても、Webを閲覧するだけでも)をするという行動はまだかなり特別なもので、外出してお店のサービスを利用する場面とは別世界と思えるくらいに状況にギャップがありました。皆さんは「ネットサーフィン」という言葉を覚えているでしょうか。Webを閲覧するというだけの行為は、わざわざ名前をつけた休日の趣味にできるくらいの特別さをまだ備えていました。

インターネット黎明期の不便さを回顧するのは、マルチチャネルが社会的に受容可能であった理由が明らかにならないことには、マルチチャネルを定義する必然性も理解できないと考えるためです。くどいかも知れませんがもう少しお付き合いいただければ幸いです。

さて、マルチチャネルの社会においては、「ネットとリアル店舗は違う」という前提が社会そのものにあります。消費者は、ネット上でのサービスと連続性のあるサービスが近所の店頭に反映されないということや、そもそもネットショップに同一サービスのリアル店舗がないといったことにいちいち違和感を覚えることはあまりありませんでした。

そして、ショップ側もそれらを別事業として明確に区分していることが当たり前にありました。実店舗を持つ非ネット通販のショップやメーカーがECに取り組んでも実験的なレベルに留まることも多く、またシステム上の制約から同じ施策を行えないことが多いなどの理由もあり、店舗とネットは別のビジネスとして運用されていることが多くありました。

また、電話通販は、ネット通販とは別の歴史の中で進化してシステム化されている上に固有の戦略(アウトバウンドであるとか)を中心にしており、やはりECとは別のビジネスであったと言えます。

この状況がマルチチャネルです。ひとつのショップが複数のチャネルを利用する状況が必然的に生じていましたが、それが統合されていないことを社会がまだ十分に受容できていた状態と言えます。

マルチチャネルの時代を通して、ECはチャネルとしての存在感を増して行きますが、そのことが逆に他チャネルにとっての脅威となり、競合する状況も生じてきます。特に大きな企業では、このことは事業部や個人の評価・成績にも関わる問題になってきますし、予算にも影響します。そうした背景は、その後のオムニチャネルという概念を形作る動機となっていきます。オムニチャネルは単に消費者に高レベルのサービスを提供したいというマーケティング的な動機によって必要となった概念ではありません。

システムへの要求

さて、そんなマルチチャネル、典型的にはECと店舗などをイメージすれば良いでしょう。先の通り、電話通販も加えても構いません。ただこれはわかりやすいイメージというだけで、実際にはECとECでも、店舗と店舗でも構いません。要するに「システムのプラットフォームが異なる」ということです。

マルチチャネルでは必ずシステムがあります。要するに、先ほどの八百屋さんのそろばんで例えるなら、その「そろばんで計算し店主の頭の中のみに帳簿がある」という方法がひとつのシステムと見なせます。そして、それではない何か別の方法、例えば近所のスーパーの産直コーナーなのか、インターネットモールに出店してしまったのか、何にせよ、別の方法で受注と在庫と顧客が管理されるシステム(電子的なものに限らず、”系”という意味合いで)が存在します(つまり、先ほどシングルチャネルは必ずしもシステムを必要としないと言いましたが、この場合にはあれは嘘です)。

ITを駆使したシステムかどうかはわかりませんが、何か(少なくとも脳内とか紙と鉛筆とか)を基盤とした処理系が存在していて、それがシステムです。もちろん実際には、昭和も後期になってからは、少なくともスタンドアローンのソフトウェアはたいてい使われていたと思います。

つまるところ、複数のチャンネルが存在するマルチチャネルでは、チャネルそれぞれに異なるシステムが存在しています。それらのシステムはプラットフォームも異なっており、ECと店舗の受注管理も顧客マスタも、別に存在しています。

しかし、2000年代後半に向けて、それらが独立していることの弊害が目立つようになり、加速度的に「連携」の需要が増しました。受注情報や顧客情報の連携、在庫情報の連携も、一方的なものばかりでなく相互連携を行うケースも増えました。ECの市場拡大に伴い必然としてECサイト/システムの存在感が高まり、その結果、受注管理のメイン部分(いわゆる”基幹”)との連携密度を上げていかなければいけないということが背景にあったためです。統合顧客管理システムやポイントシステム、在庫管理システムとの連携、売上管理、CRM連携、BIと、ECの連携対象は増える一方です。

マルチチャネルは、複数のチャネルがあるということが特徴です。ですがもうひとつ重要なこととして、データの連携自体はマルチチャネルでも頻繁に行われています。とは言え、異なるシステム間でのデータ連携は制約が多く、リアルタイム性に欠けたり、情報の劣化が大きいことも多くありました。存在感を増すECは、同時にチャネルの技術的特性により情報収集にも優れており、そのため多くの連携が求められ、それがECのシステム構築のコストを押し上げもしました。

それでも何とかなったのは「ネットとリアルは別だと思う」という社会状況による寛容さの恩恵が、まだわりとあったからではないかと考えています。


オムニチャネル

さて、だいぶ話が長くなってしまっていますが、ここからがより重要なポイントです。
オムニチャネルを図にするとこうなります。

わかりやすいように模式化していますので極端な面もありますが、データを統合したということがマルチチャネルとの違いです。
マルチチャネルでは、データを連携していました。これらのデータは個々の連携相手のために調整された必要最小限のデータであり、その連携相手の向こう側での再利用を前提とはしていません。

なお、連携と統合は似ていますが違います。連携するということは、データを受け渡すことであり、送受信の双方が主体であり、他方の部分的なデータを保持している状態を含みます。一方、統合は連携を経て実現されますが、統合されたデータはそれ自体が全体であり主体である(逆に言えば、被統合側は従属する)場合を言うと考えるべきでしょう。

オムニチャネルでは、データを統合する唯一の存在が望まれます。統合の対象は受注を含む顧客データであり、統合されたデータは他のチャネルを担うシステムにも利用されます。受注を含むということに注意してください。単なる顧客マスターの共有ではありません。その顧客の取引を中心にした行動に関する様々な情報という意味の顧客情報であり、そこには在庫に関するメッセージングも含みます。これにより顧客は、チャネルを横断して、高度なパーソナライズとシームレスなサービスを享受することが可能となります。

もっとも期待されるのはECと店舗のチャンネルにおける顧客体験の統合かも知れませんが、オムニチャネルの本質はチャネルを横断でアクセス可能なデータ統合にあるのであって、EC・店舗連携ということはその適用例のひとつに過ぎません。また、EC・店舗連携では在庫連携が重要な役割を果たすケースが多くありますが、在庫連携が即ちオムニチャネルなわけでもありません。重要なことは、顧客に対してチャネルにより限定されない一貫性のあるサービスを提供できることであり、そのためにシステムは必要な情報を自チャネルに限定されずに各チャネルから取得し、また更新できることです。

社会的な背景

2010年代に入るころから、社会に大変なことが起きてしまいました。言わずもがなですが、Apple社のiPhoneの爆発的な普及です。これにより、社会(消費者)がチャネルの断絶に不満を持つようになってしまった、ということがオムニチャネルが必要とされた背景です。

ネットに常に接続している端末を誰もが持ち歩くようになり「ネット世界」がいつの間にか店舗の中にも入りこんでしまった・・・というよりは、そんな「別世界」はどこにもなく、ネットは現実社会の延長でしかないということが明らかになってしまったということです。

オムニチャネルの登場した頃には「Connected Customer」という言い回しもアチラでは流行っていたと記憶していますが、そうした状況に慣れた消費者は、同じ企業のサービスがいま手元のスマホに表示されているサービスと目の前にある店頭とで異なるということに違和感しか感じません。また、これもネットの普及の影響ですが消費者の意識は「店から買う」のではなく「メーカーから買う」という方向にシフトしたとも言われます。そうすると、「ネットでは出来るが店頭ではシステム的にできない(あるいはその逆)」といったことは受け入れがたいものとなりますし、また消費者は店頭でサービスを受けてもそこでコンバージョンをしなければならないという義理のようなものを感じることがありません。

チャネルの垣根が消えてしまえば、ECと店頭だけでなく他のチャネルとの垣根もなくなります。ECと店頭が同じサービスなのに、電話した時だけはまったく違うということは自然の成り行きとして受け入れられません。ですので、オムニチャネルでは、顧客体験の一貫性はECと店舗だけでなく、ECと電話受注やFAX受注との間にも求められますし、ECと、別プラットフォームのECとの間にも求められます。

一連の消費行動がチャネルを限定せずに連続して行われるとなると、販売事業者はチャネル別の事業、あるいは売上管理を見直す必要も生じて来ます。これは、チャネルを識別しないでよいという意味ではなく、より正確に識別しなければならないということです。最後のコンバージョンに貢献したチャネルだけが功績のある効果的なチャネルだった、とは考えられなくなるためです。

移動端末とネットのほぼ完全な普及、それによる「異世界としてのネット」という感覚の消滅がオムニチャネルの背景です。

システムへの要求

こうした状況では、マルチチャネル時代からのシステム連携はますます緊密になることが求められます。しかし、異なるプラットフォーム間でのデータ連携は簡単ではありません。CSVのバッチ連携に限界が見えたとしても、それをWeb上でのサービスとしての「API連携」が魔法のように解決してくれるという期待もあったかも知れません。しかし、システムを開発する企業が異なれば呪文の体系も異なりますので、APIの魔法は期待通りの効果を必ずしももたらしてはくれません。APIが有効なことは確かだとしても、古典魔法たるCSV転送も同時に使ってみるにしても、それだけではない何かが必要だと思われました。

そこでオムニチャネルに効果的と考えられるものがOMH(Order Management Hub)です。Order Mangement Systemと呼ぶ場合もあると思いますが、ハブ機能を持ち、マルチチャネルの受注データを統合管理し、また情報を必要に応じて再分配(各チャネルに提供)することが特徴です。この再分配を目的とすることが、従来のいわゆる「基幹」といったもので一方的に受注を集約するだけの連携とは異なる点です。

OMHとしての製品は、海外を中心にある程度は存在している様子ですが、あまり上手くいっていたのかはわかりません。
他方、別のアプローチとしてのオムニチャネルへの対応としては、MACHと呼ばれるものがあります。

https://machalliance.org/mach-technology
MACH - microservices, API-first, cloud-native SaaS, and headless architecture

マイクロサービス(アーキテクチャ)、APIファースト、クラウドネイティブ、ヘッドレスといったことを重要な技術的方針と位置付けており、こうした中から「コンポーザブルコマース」を実現すべきということが以下の文書で語られています。
https://machalliance.org/insights/8-Best-Practices-for-Composable-Commerce

コンポーザブルコマースです。ユニファイドコマースの説明のためにオムニチャネルの説明を試みていたら、困ったことに違うところに行きついてしまったようです。

コンポーザブルコマース

コンポーザブルコマースについての上記の記事においては、ECのシステム的な実現方法を以下のように区分しています。

  • モノリシックコマース
  • ヘッドレスコマース
  • コンポーザブルコマース

モノリシックコマースとは、「Adobe(Magento)、HCL、Salesforce、SAP、Shopify」が例に挙げられており、「限定的で不便なカスタマイズ性」しか備えないとされています(念のため申し上げますが、Google翻訳の結果であって私の評価ではありません)。

ヘッドレスコマースというものも確かに流行しました。フロントエンドを切り離すということが勘所とされています。古典的なECシステム(パッケージでもスクラッチでも)の致命的な問題は、フロントエンド、つまりWebサイトの画面を出すと言う処理のためのロジックと、モノを売るためのビジネスロジックがプログラムとして混然一体となって癒着してしまっているということです。それを緩和するためにMVC(Model-View-Controller)という設計が好まれたりということはあっても、問題を取り除くにはなかなか至らなかったと思えます。ですので、潔くフロントエンドを切り離してしまうヘッドレスコマースはビジネスロジックを独立させるという効用が期待でき、そうすれば他のシステムもそのロジックを利用できるのではないか・・・という期待があります。
その上で、さらにサービスの構成要素を細分化することで、ショップが自身の要求にあったECを既存の小さなサービスの集合としてくみ上げることが出来る。サービスの再利用性があり、ROIに優れており、柔軟性、拡張性も確保できる、と、これがコンポーザブルコマースということではないかと理解しています。

オムニチャネルに対するシステム的な回答

ヘッドレスコマースは、それ以前のフロントエンドあるいはプレゼンテーションとビジネスロジックが結合してしまっているECよりはシステムの品質的にマシだとしても、EC以外のチャネルを統合するというオムニチャネルへの対応としては不十分です。

コンポーザブルコマースでは。細分化されたサービスはそれぞれが様々なチャネルに接続できるかも知れません。その意味では、オムニチャネルの実装となり得る可能性を秘めてはいます。ただ、これは構造としてのポテンシャルは高いのですが(クラウドネイティブ以外はある意味、プログラミングにおける教科書的原則のようなものですから、価値があるのは間違いありません)、だからと言ってその原則さえ守れば価値の高いサービスを構築できるというものでもまたありません。

コンポーザブルコマースが期待通りの成果を発揮するには、質の高い部品(サービス)が揃っており、それらがシステム的な仕様・規格をすり合わせて手軽に統合可能な上に、ECの業務的コンテキストにおける十分な合意、共通認識のもとに設計されており、そこに少なくとも顧客情報に関する柔軟かつ双方向のAPIを備えながら、最終的には先述のOMHのような役割を果たすサービスも存在するということが必要に思えます。

しかしながら現状はおそらくそこまで整ってはおらず、オムニチャネルに対する明確なシステム的回答、こうあるべきという姿は定まらないまま10年以上が経過したということが現状なのではないか、ということが私の見方です。


ユニファイドコマース

そしてユニファイドコマースの図です。


社会的な背景

まず、社会的な背景についてはオムニチャネルと変わっていません。iPhoneの性能は上がり続けていたり、生成AIが普及したりというトピックはありますが、老若男女、下手をすれば赤子までがいつでもどこでもネットに接続するようになった、ということに匹敵するほどの劇的な変化は訪れていません。

つまり、ユニファイドコマースは、ここまで説明した○○チャネルとはそもそも異なる観点の用語です。シングルチャネル、マルチチャネルは、そのパラダイムが支配的であった当時に認識されたものではなく、オムニチャネルを認識した時に過去を捉えなおして定義されたものです。したがって、いずれもが同じように、消費行動の手段としてのコミュニケーション基盤の変遷という社会的な背景をもとにした概念であり、施策面に重きを置いたビジネス戦略と言えるはずです。それに対して、ユニファイドコマースはシステムの実装面に注目した戦略と言えます。ですから、「ユニファイドチャネル」だったりはしません。

先の話の流れからすれば、「コンポーザブルコマース」に対する、アンチテーゼを含んだ発展形と位置付けるのが正しいのではないでしょうか。

シングル、マルチ、オムニチャネルと来て次のステージがユニファイドコマースであると線形的な発展を前提に考えるよりは、オムニチャネルに対応するためのシステム的な戦略がいくつかあり、その中で新しく登場したものがユニファイドコマースという考え方なのだと位置づける方が妥当です。

これは完全に私の理解においてということになりますが、ユニファイドコマースを特徴づけているのは、オムニチャネルが顧客を中心としたデータの統合を要求したことに対して、それを実現し利用するためのロジックの統合も要求しているいうことだと考えます。そして、ロジックを統合するということを別の言い方で表すと、「シングルプラットフォーム」ということになります。

統合されるデータとロジックは、オムニチャネルの説明でも述べた通り、顧客マスタのみを指すものではありません。顧客およびその行動を中心とし、それに関連付けられる様々な情報であり、在庫情報や決済情報、問合せ履歴、フルフィルメントにおける諸々の状態に関する情報なども含まれます。

システムとしての要求

まず、シングルプラットフォームであることです。これは目的ではなく手段として必要になるということです。
なぜシングルプラットフォームであることが必要なのかと言えば、先の、コンポーザブルコマースが成功する条件が関係しています。
つまり、効率的で再利用性の高いシステムアーキテクチャーとしてマイクロサービスやAPIファースト、クラウドネイティブ、ヘッドレスといったことは重要ですが、これらはあくまでも技術的な問題に対する処方箋です。プロトコルレベルでAPIが接続可能ということは、それで業務が期待通りに動くということではありません。業務上の成果を効率よく得るには、それらのマイクロサービスが業務的なコンテキスト、セマンティクスを共有している必要があります。例えば、「アイテム」と言った時にそれが一方のサービスでは倉庫内の在庫品であり、他方のサービスでは価格リストに掲載された販売条件であり、ということでは、言語上は一致しているようでも実際には違うものを指しておりコミュニケーション(連携)に齟齬が生じます。
そうしたコンテキストを統一するために、シングルプラットフォームであること、つまり同じ価値基準と前提の中で各サービスが構築されているということが求められます。

プラットフォームがひとつということは、サーバーが1台という意味でも、実行可能なプログラムが1種類ということでもありません。ですので、コンポーザブルコマースが求める優れたアイデアのひとつ、マイクロサービス・アーキテクチャーをシングルプラットフォーム上で実現することは可能です。

コンポーザブルコマースがマルチプラットフォームを前提に加えるならば、ユニファイドコマースはそれに対するアンチテーゼということになりますが、そうでないならば発展形と捉えることもまったく無理というわけではないと思えます。

ユニファイドコマースを取り入れるには?

ユニファイドコマースの実現にはコストがかかる、ということになっています。特に、現状がすでにバラバラのシステムのモザイクのようになっているならば、それらをすべて「単一のプラットフォーム」に一気に置き換えるとすれば、膨大なコストがかかるでしょう。膨大が具体的にいくらなのかはともかく、要するに現状のシステム規模に対して考えられる最大規模のリプレースを行うハメになるからです。

ただ、もし2つのシステムがあり、その片方だけを統合するならあまり意味はないでしょうが、5つのシステムのうちの3つを統合できれば、60%の統合は達成されます。それはそれで、不完全であったとしても意味があることです。特に、顧客とのタッチポイントとして重要な役割を果たしているチャネルにおいてそれが出来れば、より大きな成果となるはずです。

最終的な理想はすべてのサービスの統合、単一プラットフォーム化です。これを達成しているわかりやすい例がAmazonだと思います。ただ、そう考えることで、その強力さと同時にこれがいかに大変なことかということも想像がつきます。

とは言え、皆さんは何もいますぐAmazonのように、世界中の顧客にあらゆるものを数10兆円も売らなければいけないということではないでしょう。

単一プラットフォームに業務を集約するということの効果を確認したいのであれば、幸いなことにひとつ、ちょうどよいSaaS型のECパッケージがあります。

そのECパッケージは、EC業務を実行するAPIライブラリとしてまず開発され・・・つまり、フロントサイトがないだけでなくバックオフィスも存在しないAPIのみで業務を実行可能なプログラムとしてまずビジネスロジックのみを実装され、その後に様々な業務機能をプラガブルな拡張機能として構築するという方法で、従来のECパッケージが対象とせずに外部連携まかせにしてしまいがちだった広い範囲の業務を機能的に網羅しつつ、柔軟な連携機能で未知の連携対象に対するノンカスタマイズでの自動ファイル連携、API連携も可能としています。

つまり、あなたのECの中で統合し単一プラットフォーム上で稼働させたい部分を選べるということです。最大限の統合で最大の効率を得ることができますが、うまく機能している外部システムを慌てて切り離す必然性がなければ、連携を選ぶことも出来ます。ノンカスタマイズで。

そんな都合の良いパッケージがあるのか?と思われるかも知れません。確かに何から何までを統合できるわけではないかも知れません。が、思うよりかなりのことが出来ると思いますので、自社のECシステムがどのくらい「ユニファイ」できそうか気になる方は、以下からお問い合わせください。

Lexica E-Retailing Platform 導入に関するお問い合わせ