ECサイト構築をカオスにしない！ 次世代のeコマース「 ヘッドレスコマース」のメリット・デメリットとは
みなさんはヘッドレスコマースという言葉を聞いたことはありますか？
次世代のeコマースアーキテクチャのひとつなのですが、いまひとつピンと来ていないのではないでしょうか？
今回は、ヘッドレスであることはどういう事なのか？メリット・デメリットは？といった基本的なギモンを具体例を織り交ぜながら、お話させていただきます！
目次
1. 次世代のECサイト構築とは？ 2. ヘッドレスコマースとは？ 3. 変化が早い具体的な例～技術やトレンド～ 4. 変化が早い具体的な例～顧客接点～ 5. 変化が早くないものとは？～バックオフィス～ 6. ヘッドレスコマースの課題点 7. 『prismatix』というヘッドレスコマース1. 次世代のECサイト構築とは？
ECサイトをとりまく変化は年々加速度を増し、リニューアルを繰り返しながら日々成長を続けています。住宅と同じように、修繕や最新の設備への交換といったリフォームを行い、ある一定の時期を迎えると建替えが必然となってきます。
建替え（ECサイトリニューアル）の手法は様々です。パッケージから異なるパッケージに乗り換える場合や、パッケージからスクラッチへ、またその逆もしかり。
現在抱えている課題の解決とさらなる成長を求めて、最も適した手法を選んでECサイトのリニューアルプロジェクトは発足していきます。成熟度が増したECサイトをさらに進化させていくことが命題となっている今、EC構築リニューアルにおいては柔軟性とスピーディな対応が求められます。
ECサイトをリリースするとき、100点満点の状態でリリースできることは、ほとんどありません。なぜなら、要件定義をしてからリリースするまでには数か月～1年程度かかってしまうため、要件に誤差がでてしまう場合があるからです。また、100点満点を求めすぎた結果、開発ボリュームが大きくなり、泣く泣くフェーズ分けをしたり諸々調整していきます。限られたリソースの中で優先順位を決め、リリース後少しずつ必要な改修を繰り返していくのが理想的なやり方となります。
導入後も大小さまざまな改修や機能追加を継続して繰り返していくことを前提としたときに、重要となるのは、システムの柔軟性や拡張性です。改修や機能追加を繰り返していくうちに、ECサイトの作りがカオスになっていくことは避けなければいけません。
改修や機能追加の柔軟性の高さから、フロントエンドとバックエンドを切り離し、APIで連携するという設計思想であるヘッドレスコマースは、今注目されている設計思想のひとつです。
また、次世代のECサイト構築から切っても切り離せないのが、OMO施策です。OMOは、ECサイト・店頭POS・WMS・基幹システムといったそれぞれのシステムとの情報連携によって実現されます。OMOについてここでは詳しくは触れませんが、個（各システム）を線（API）で連携させるヘッドレスコマースの設計思想はOMOと相性が良いと言われています。
2. ヘッドレスコマースとは？
ヘッドレスコマースは、フロントエンドとバックエンドを切り離し独立して構成され、APIで連携させる設計思想です。それぞれが独立した作りになっているので、双方システムの制約を受けることがほとんどありません。柔軟な改善や機能追加が可能となります。
ECサイトはフロントエンドとバックエンドを一体化し構成されています。ECパッケージのほとんどが一体型の構成になっています。
近年のECパッケージは機能も充実した良いソリューションがたくさんあります。機能のFIT率が高ければ導入までの速さは断トツです。
しかしこのFIT率が実は曲者です。選定時にFIT率が高かったはずなのに要件定義後はカスタマイズの嵐といったことも珍しくありません。
あらかじめ用意されている機能はあくまで標準機能、つまりあらゆるものをそぎ落とした最もシンプルな形で用意されています。標準機能のままでは、細やかな要件が満たされずカスタマイズが必要になってくるのはある意味やむを得ないことかも知れません。
要件を実現するために行った数々のカスタマイズがカオスなECサイトの作りにさせてしまうケースも少なくありません。要件を満たすためには、同じくやむを得ないことかも知れません。苦しいところです。
サイトの見た目（アプリケーションフロント画面）はデザインでカバーできますが、デザイン料は別途かかりますしデザイン適用のカスタマイズは必要になってきます。ECパッケージのフロント画面そのままだと、みんな同じ顔をしたサイトになってしまいます。カスタマイズが発生することは避けられません。
お客様(ユーザー)にご利用いただくフロントエンドは顧客満足度に直結するものです。新しい技術やトレンドをいち早く取り入れて日々進化していく必要があります。
パッケージの課題点としては、導入後の機能拡張や改善に自由度が欠けてしまうことです。
一般的なECパッケージはフロントエンドとバックエンドが一体型のつくりになっていますので、フロントエンドの機能拡張をしたいのにバックエンド側の影響で対応できないといったようなケースも起こってきます。なかなか自由が利かないのがECパッケージです。ECパッケージはフロントエンドとバックエンドが一体型になっているのが一般的で、ヘッドレス・コマースを実現するためのソリューションの選択肢が少ないのが現状です。
業務担当者「なんでできないの？」
システム担当者「パッケージだから難しいそうです」
といった会話は、良く聞かれます。もちろん相応の工数をかければ実現は可能なのかもしれませんが、現実的では無い場合に良く聞かれるお話です。
一方スクラッチは、ECパッケージにくらべて工期やコストは長くなってしまいますが、自由設計なのでパッケージのように決まり事や制限はありません。もちろん限界はありますが、必要な機能を必要なタイミングで追加修正していくことが可能です。
しかしながら、作り方次第といったところがあるのは事実です。
3. 変化が早い具体的な例～技術やトレンド～
ECサイトのお客様の目に触れる部分、つまりECフロント（フロントエンド）は変化が早いもののひとつです。
販売方法や決済方法は、ここ数年の間でも変化がみられています。
続々と〇〇ペイが生まれてきて、多種多様な決済方法の対応は、開発側としては正直面倒ではありますがお客様のニーズには答えていきたいものです。
技術的な側面でも、Web周りの進歩は著しく「作りの古さ」ゆえにレスポンスが悪くなったりすることも起こります。新しい技術やトレンドを常に取り入れていくことで、ECサイトの老朽化を回避できます。アンチエイジングは大事です。
4. 変化が早い具体的な例～顧客接点～
フロントエンドはECサイトだけとは限りません。モバイルアプリやSNS、スマートスピーカーといった顧客接点は多種多様で、様々な変化が見られます。
今後も新しいソリューションが次々と生まれてくることは想像に難くありません。ヘッドレスコマースは、それぞれ独立したフロントエンドとバックエンドをAPI連携で構成します。たとえばすでにECサイトを運営していて、新たにリアル店舗で使うモバイルアプリを作りたい場合を例にとってみます。
ECもリアル店舗も、お客様は同一人物として管理していきたいと考えます。すでにデータ化されているECのお客様をベースにリアル店舗のお客様としても捉えていきたい。
商いに必要な情報（商品・顧客・注文）はすでにバックエンドで管理されてるので、ECバックエンドの仕組みを活用します。
そんな場合には、モバイルアプリと必要なAPIを追加または既存APIを流用することで実現が可能です。
改修ではなく増設になるので、もともとあるECサイトに影響することもされることもなく、モバイルアプリを追加することができます。また、外部システムとの連携もAPIで行うことになりますので、店舗POSと連携すればリアル店舗で購入した購入履歴の取得や店舗とECのポイント統合といったOMO施策を実現可能となります。
5. 変化が早くないものとは？～バックオフィス～
では、バックエンド側に目を向けてみましょう。
ECサイトで商いを行うために必要な情報の管理を行うのが、バックオフィス業務の役割ですが、バックオフィス業務で行うべき管理そのものは、どのサイトもほとんど変わりません。
もちろん対抗システム（フロントエンドや外部システム）や業務内容によってデータ項目レベルでの変化は出てきますが、フロントエンドのように差別化を図ったりトレンドを取り入れる必要はありません。
「ヒト・モノ・カネ」が不動の管理情報です。ECにおける基本的な管理情報は昔から大きく変わっていません。バックオフィスをちょっと大雑把な表現で言うとしたら、「商いに必要なデータを管理する機能群」といったところでしょうか…。「ヒト・モノ・カネ」を、EC管理システムに置き換えると「会員管理・商品管理・注文／決済管理」にあたります。
バックオフィス機能は商いの要です。フロントエンドがキラキラしたステキなECサイトであってもバックオフィスがしっかりしていなければ「売るだけ」の残念な商いになってしまいます。注文完了してからお客様のお手元に品物が届くまで、さらにはお手元に届いてからのフォローまでを管理できるしくみが必要です。
対抗システム（フロントエンドや外部システム）とは、APIやデータファイルを使って連携し、情報のやり取りを行います。バックオフィスがしっかりと作られていれば、フロントエンド側や外部システムの変化に柔軟に対応することが可能となります。
6. ヘッドレスコマースの課題点
図2のような構成のヘッドレス・コマースのサービスは現時点では少ないです。スクラッチで作り込む部分も多くなります。初期導入の期間とコストはそれなりにかかり、ECシステムを中長期的に検討した上でないと見合いません。
フロントエンドとバックエンドをつなぐ要となるのがAPIです。双方に精通していないと要件を満たしたAPIを開発することができません。また、外部システムとの連携にも精通しておく必要があります。注文→出荷→配送→会計→アフターといった全体を見据えたグランドデザインの理解が求められます。
7. 『prismatix』というヘッドレスコマース
さて、ここから手前味噌になりますが『prismatix』はヘッドレス・コマースを実現するアーキテクチャです。バックエンドに必要な管理サービスとAPI群を備えており、様々なニーズに対応可能なデータベースと約700本の汎用APIを提供しています。
フルスクラッチでヘッドレス・コマースを実現しようとした場合、API開発はテスト工数含めかなりのボリュームになりますが、『prismatix』はすでに製品化されているAPIなので信頼性も高く、汎用APIを組み合わせることによって多岐に渡る業務要件を実現することが可能となっています。
ヘッドレス・コマースの課題である初期導入期間とコストの削減に大きく貢献します。
何よりフルスクラッチは常に一番風呂の宿命を持っていますが、『prismatix』は製品化されたサービスなので信頼性は高いと言えるのではないでしょうか？
『prismatix』はバックエンドに必要なサービスを各種取り揃えておりますが、必要なサービスのみ導入が可能なマイクロサービスとして提供しています。
手前味噌が過ぎておりますので、マイクロサービスについてはまた別の機会に。
執筆者プロフィール
菊田 亜由美 業務・システムコンサルタント
日航情報開発（現JALインフォテック）を経て、2000年からフリーランスにて、システム開発およびコンサル業務に従事。小売流通、サービス、⾦融等、あらゆる分野でのシステム開発を多数手がける。また、事業会社においてEC、CRM等のシステム導入経験あり。2018年2月クラスメソッドに参画。小売業を中心に幅広い業界での業務設計、要件定義、PM⽀援に対応可能。
≪⽀援実績≫
・OMO/EC：無印良品のDX推進⽀援、大手GMS/ネットスーパー構築、大手生活用品メーカーのD2C施策検討、家事支援サービスシステム強化支援、専門店オムニチャネル支援等
・CRM:大手アパレルの会員・ポイント基盤等
この記事をシェアする
プリズマティクスのサービス
Keyword
Follow Us
