定期購入ECサイト構築 : 業務とシステムの両面から構築する必要性
ECサイトはWeb黎明化から存在する業務とシステムの両面を考慮することが求められる代表的な分野です。ECサイトにおける「業務」とは、下記のような作業がまず思い浮かびますが、そのために以前からECサイト構築用のパッケージソフトウェアという分野も存在していました。
・在庫管理
・返品・取り消し
・売上集計
しかし、2006年にオープンソースのEC-Cubeが登場して有償のパッケージソフトウェアを購入して構築することは減ってきましたし、近年はSHOPIFYやBASE、STORESのようなSaaSを利用してECサイトを開設することがどんどん増えてきています。
また、これらのSaaSはAPIを用意していて、外部のシステムと在庫情報などをオンラインで連携するようなことも、SaaS側のカスタマイズなしにさまざまなこともできるようになってきています。
ほかのWeb分野と同様に、ECについてもさまざまなSaaSを利用して簡単にECサイトを開設できるようになってきているとともに、それらのSaaSに用意されているAPIを利用することにより、外部のシステムとの連携も大きなシステム開発なしにできるようになってきています。もちろん、大規模なECサイトでさまざまなカスタマイズも行いたい場合には、EC-CubeのようなEC機能のパッケージベースにECサイトシステムを構築するということも行われますが、どのようなECサイトを作りたいかという業務要件とどのようなことはどのようなシステムで実現することができるかというシステムおよびUIの両面の知識をもっていて、業務要件を実現するための最適なシステム・UIを選択・描き出すことが重要になってきています。限られた予算・期間の中で要件をできるだけ満たすECサイトを作るために重要なポイントです。
本記事では、ECサイトを構築するにあたり、「業務」と「UI・システム」の両面から要件定義・設計・構築を行うことが、どのように重要となってくるのか、三つの例を取り上げて解説していきます。
1. Shopify, STORES, BASEなどSaaSによるECサイト構築
近年、Shopify、STORES、BASEなどのECサイト構築用のSaaSを使ってECサイト構築を行うことが多くなってきています。これらのSaaSはシンプルなECサイトだけでなく、定期購入型のECサイトも構築できますし、ECサイトで要望されるさまざまな機能を用意していますので、Web制作のひとつとしてWeb上での販売機能を実現したい場合のまずの選択肢として考慮すべきでしょう。
このような定期購入もできるECサイトでの業務の内容というと、定期購入においてユーザに対してどこまでの柔軟性を認めるのか、どのような機能まで用意するのかがポイントとなります。
【機能例】
初回割引 / 契約回数縛り / スキップ機能 / お届け先住所の変更 / 支払情報の変更 など
定期購入というと継続利用を始めてもらえば継続し続ける割合が高いという特性上、初回は割引をして定期購入を開始してもらうことを誘引することはよくありますし、毎月の定期購入であっても、来月はスキップしたいというユーザニーズはよくあります。ユーザが引っ越しをすれば、これまでの定期購入は終了して別途新しい定期購入の申し込みをしてそのお届け先を新しい住所にするという手続きをしなくても、これまでの定期購入での登録お届け先の変更ができればユーザにとつては便利です。ユーザにとってどこまでの柔軟性を認めるのか、どこまでの機能を用意するのか、それによってシステム要件もいろいろ変化します。
Shopify, STORES, BASEといったときにも、STORESとBASEがより簡単にECサイトを構築したい用途向け (小規模向け) のSaaSで、Shopifyはより機能が豊富・アプリのエコシステムなどもできあがっていてアプリによる機能拡充などもより幅広くできるSaaSといえると思いますが、STORESやBASEにも定期購入への対応は可能です。
ただこの三つのSaaSの間、STORESとBASEの間でも用意されている機能にはもちろん違いがあります。料金体系・手数料率・対応して決済手段の違いもありますが、機能面の違いとしても、Shopifyではギフトカードの発行ができますが、STORESやBASEではクーポンには対応していますがギフトカードの発行機能はもっていません。STORESもBASEもECサイトの定期購入機能は用意されていますが、BASEでは購入サイクルが毎月しかないのに対して、STORESでは毎週や隔週など購入サイクルの選択肢が多い一方、購入回数の選択肢としてはBASEでは3回、6回、12回、無制限から選択できるのに対して、STORESでは解約されるまで継続するという一種類のみという違いがあります。
Shopify, STORES, BASEのようなSaaSで対応できる範囲のEC構築であれば、そのECではどこまでの機能を用意したいか、対顧客向けのフロント側に対する要件とともにバックエンド側に対する要件も含めて要望をヒアリングできること、そのための前提として一般的なEC業務について理解・把握していることおよび、Shopify, STORES, BASEそれぞれが対応できる機能について把握していることが重要となります。
また、いずれのSaaSでもSaaS単独では実現できないのは、在庫管理のオンライン化です。販売数が限られていて、仕入れの頻度や数もそれほど大きくない場合には仕入れ作業の一環として、入荷した商品の情報をEXCELファイルで一覧として作成してCSVファイルに出力して、そのCSVファイルをShopifyなどのSaaSに読み込めば、ECサイト上での販売による在庫数の削減はSaaSが自動的にやってくれるので在庫管理ができます。
しかし、ECでの販売数が増えてくると、仕入れのたびに上述のようなCSVファイルを作成してSaaSに取り込む作業が負担になってきます。そのような場合に検討されるのが在庫管理のオンライン化ですが、ECのSaaSとは別のシステムに接続する必要がありますので、SaaS単独ではすまなくなり、多少なりともシステム開発が必要となってきます。
2. 社内のシステムとShopifyを連携して在庫をオンラインで更新
各商品の在庫数がシステムに入っている社内システムが存在する場合は多いのではないでしょうか。ECでの販売数が増えてきた際に、その在庫管理システムとオンラインで接続するというのはよくあるニーズです。
Shopifyには豊富なAPIが用意されていて、その中には在庫管理のためのAPIも含まれています。たとえばInventoryItem APIであれば、在庫商品の在庫を一覧表示したり、更新したりすることができます。Shopify側はShopifyに用意されているAPIを利用することにすれば、在庫管理のオンライン化に際してShopify側はカスタマイズ・システム開発は不要となります。
一方で社内のシステム側では、ECサイト側への在庫の追加 (ECサイトの仕入れ) が行われたタイミングでShopifyの在庫数を更新するのであれば、Shopifyの在庫管理APIなどを呼ぶバッチ処理などを用意/開発する必要はあります。
一からECシステムを開発したりEC-CubeのようなパッケージベースでのECシステム開発よりはもちろん軽微が開始ですが、システム開発とはなりますので、開発エンジニアのアサインが必要となりますし、そのバッチ処理などを実行させるサーバなどの環境の用意も必要となりますので、ディレクタ/プロデューサのような役割の人間としてハンドリングする対象のタスク・工程もSaaS単独でのECサイト構築とはだいぶ違いがあります。基本的には設計書の作成・管理からテスト検証までシステム開発の工程を行う必要があるでしょう。
しかし、Shopify側のカスタマイズ、開発はなく、社内のシステム側の開発作業のみとなるのであれば、社内のシステム担当と連携してECサイトの在庫のオンライン化を進めることになり、開発作業は社内のシステム側のタスクとなりますので、ECサイトのディレクタ/プロデューサが社内のシステム側は担当外で、その担当は別にいるのであれば、ECサイトのディレクタ/プロデューサに求められる内容は、SaaS単独でECサイトを構築する場合とそれほど異ならないと思います。
ただし、その社内のシステム担当がShopifyやSaaSについて知見がない場合には、ECサイト担当側がシステム開発の知見ももった上でShopifyやSaaSについての情報を社内のシステム担当に共有するとともに、在庫管理のオンライン化を実現するためのシステム構成としてどのような形態がよいか、いっしょに検討・議論することが必要になりますので注意が必要です。
たとえば、在庫管理はECサイト個別で行うのではなく、会社全体で統合されているのであれば、Shopifyとしてはその会社全体の在庫情報を参照してECサイト上の在庫情報を表示すべきですし、ECサイト上で販売されたら、その会社全体の在庫情報を更新する処理を行うべきです。
ShopifyのInventory APIを使用すると、店舗の在庫レベルの取得、更新、調整などをプログラム的に管理することができます。これにより、社内の在庫管理システムとShopify間で在庫情報を同期することが可能となりますので、以下のような処理を社内のシステム側に用意することになりますが、具体的なシステム設計にあたっては、Shopifyというものについての理解が必要ですし、ShopifyにどのようなAPIが用意されているのかという情報も必要です。
・商品がShopify上で売れたときに、WebhookやOrder APIを使用してその情報を取得
・取得した情報をもとに、社内の在庫管理システムで在庫を減らす
・ShopifyのInventory APIを使ってShopify上の在庫情報を更新
業務についての理解として、どのような在庫管理を行うかという内容も含めて必要となるとともに、システム面・システム開発についての理解もある程度は求められるECサイト構築となります。
3. いろいろな顧客の要望に応えた独自カスタマイズを含むECサイト構築
最後の例が、いろいろな顧客の要望に応えた独自カスタマイズを含むECサイト構築の事例です。そのような場合には、やはりSaaSでは対応が難しくEC-Cubeなどのパッケージベースにシステム開発してECサイトを構築するようなことはよく行われます。
システム開発を行ってECサイトを構築するとなると、サーバ環境を用意する必要があり、セキュリティ対策をはじめとするインフラ関連の業務も必要となってきますが、ECサイトの構築プロセスとしても、要件定義からシステム設計を行うというシステム開発プロセスを踏んでテスト検証 (動作試験) についても、システムの仕様に沿ったさまざまな動的な動きのバリエーションをテストケースとして洗い出してテスト打鍵していく必要があります。
ECサイトとしてさまざまなカスタマイズ・ユーザのさまざまな要望に応えることができるようにしようとしているのであれば、サイトとしてのユーザ体験・UIの設計もきちんと行う必要があると思われますし、サイト内にコンテンツも用意することも考えられます。そのようなプランニング・コンテンツ企画・情報設計 (UI設計) から画面デザインやHTML制作などの工程は、エンジニアではなくプランナ/ディレクタ/IA (Information Architect) / デザイナ / コーダ などのビジネス/クリエイティブ系の職種の人間もかかわる必要があるので、広い意味では「要件定義」ともいえますが、要件定義プロセスを分解して記載すると、下記のようなプロセスとなります。
※下図の要件定義は、システム要件定義プロセスとなります
定期購入型のECサイトで顧客の要望を柔軟に応えていこうとするのであれば、上図のプランニングおよび概要設計までのプロセスにおいて、どこまでの機能にどのように対応するのかということを検討することになります。また、フロントエンド側をカスタマイズすると、在庫管理や返品・取り消しなどのバックエンド側の対応も対応してカスタマイズが必要となる場合があり得ますので、プランニングから概要設計までのプロセスでどこまで漏れなくきちんと業務要件を詰めることができるかが重要となります。画面構成設計以降のプロセス、特に実際にサイトができてテスト動作試験を行っている段階で考慮漏れが判明するとずっと前の工程からやり直しになりますのでスケジュール遅延や予算オーパなどの問題を引き起こす可能性がありますので、注意が必要です。
これからのWeb構築・Webディレクションとして、業務にまで踏み込んでディレクション/プロデュースすること、それが近年のバズワードであるDXにもつながること、そしてWebの進化とともにWeb構築の各種ツール/サービスやSaaSが広がってきていることにしたがって、業務とシステムの両面からWeb構築・運用していく人間が求められていくこと、そのためにどのような知識や能力を身に着けていくとよいかについて解説している「マガジン」です。