この記事は2023年08月08日にShopify Japan株式会社様と共同で開催した「”一休お取り寄せ”サイトに学ぶ！Shopifyで実現する産直型ECサイト構築」セミナーを記事化したものになります。

記事化することにより、当日ご参加いただけなかった皆様にも当サービスを知っていただき、より多くの方にサービスを届けたいという趣旨となっております。

セミナー当日は、一休お取り寄せのサイト構築にあたり株式会社一休サイドで責任者を勤められた尾﨑氏にもご登壇頂き、プロジェクトの背景や苦労話、実際に運用してみての感想などをパネルディスカッション形式でお話しいただきましたが、記事としてみなさんが読みやすいように一部改変をしてございます。

記事にて紹介している産直型ECサイトの構築にご興味いただけましたら、是非問い合わせフォームよりお問い合わせいただければ、サービスデモや貴社の要件に合わせたカスタマイズが可能かどうかなどについてもお話し出来ますので、お気軽にお問い合わせください。

 

 

 

1. 登壇者紹介

株式会社一休 一休.comお取り寄せ事業責任者　尾崎　亮太氏

新卒で商空間やイベントのプロデュースを行う企業に入社し、プロデュース業務を経験。2012年一休入社。共同購入型クーポンの販売サービス「一休マーケット」のセールス職を経て、「一休.comギフト」の事業責任者、「一休.comレストラン」の営業企画部長・セールスリーダーなどを歴任。現在はお取り寄せ事業の責任者を務める。

 

Shopify Japan株式会社　シニアパートナーソリューションエンジニア　岡村 純一 氏

 

 

 

 

 

 

広島県出身。システム開発会社にソフトウェアエンジニアとして入社後、ソフトウェア・ウェブの多言語化の会社、マーケティングSaasの会社、グローバル決済サービスの会社を経て現職。Shopifyの日本のパートナーのストア構築やアプリ開発、決済連携、事業開拓などの技術的な支援を担当し、開発者コミュニティの拡大とサポートにも従事。

 

株式会社飛躍 代表取締役社長　明石健夫

 

 2004年の自社EC黎明期からEC業界で経験を積み、コンサル件数1000件以上。現在プロジェクトリーダーとして運用支援中のECサイトの月商合計1億円以上。お客様のやる気を着火します。

 

 

2. 産直型ECサイト構築パッケージを生み出した背景とは

明石健夫(以下、明石):「モール型ECを作りたい」というお問い合わせをいただくことが多かったのですが、Shopifyでは既存のアプリなどで最適なソリューションが無かったため、では自分達で作ってしまおうというのがこの産直型EC構築パッケージができたきっかけとなっております。

※株式会社一休様の一休.comお取り寄せサイトをお借りしてデモを行いましたが、詳しくデモを知りたい方は弊社までお問い合わせください。

 

 

明石 : 一休様から去年の9月くらいにお問い合わせをいただきまして、「産直型ECサイトを作りたい」というご要望をいただきました。

上記スライド内のご要望③に記載がある”コンプライアンスに対応した各種個人情報処理”についてですが、一休さんは大企業様になりますので、色々と個人情報に関する管理が厳しいということで、そういったご要望にも対応いたしました。

 

 

 3. 株式会社飛躍が提供する産直型ECサイト構築パッケージとは？

明石 : 産直型ECサイトの構築パッケージとは、Shopifyのフロントエンドは通常のECサイトのようにThemeで構築し、バックエンドにはマルチサプライヤー仕様のカスタマイズが施されるというものになります。

Shopifyをある程度利用されている方向けに説明させていただくと、カスタムアプリとしてマルチサプライヤー化をできるカスタマイズをShopifyにインストールしてご利用いただくということです。

 

 

*緑→Shopifyの環境
*赤→弊社側のサーバー領域
*Sp→サプライヤーの略称

 

明石 : ストアフロントではShopifyテーマを使って普通にサイト構築をします。＋αのカスタマイズで、「スプリットカート機能・サプライヤーの一覧・詳細ページ」などのマルチサプライヤーっぽい機能を実装します。

バックエンドには、マルチサプライヤーのカスタムアプリをインストールすることで、いわゆる「管理者ページ」というものができます。その管理者ページ内で、各サプライヤーの情報管理が可能になります。文字通り”マルチサプライヤー”なので、上限なく仕入れ先を増やすことができます。 そして、それぞれのサプライヤーに「個別のアカウントやページ」が発行されます。

管理者：「ストアのフロント」と「マルチサプライヤー化されたカスタムアプリ」の管理者ページの運用・管理をします。

サプライヤー(出品者)：個別のページが発行され、そこで商品登録や注文の管理、配送の管理をします。

サイトが公開されると、お客様(エンドユーザー)がストアフロントにてお買い物をします。購入後、注文情報が、個別の出品者アカウントに直接飛びます。 

 

 

明石 : 続いて産直型ECサイト構築パッケージのコンセプトについて説明いたします。

Shopifyでこういったモール型の運用を実現するためには、決済の問題をクリアする必要があります。一般的なモールの場合は、出店する企業が個別に決済プロバイダと契約する形となりますが、Shopifyで同じことができないため、それであればモールのいわゆる運営者を特定商取引法上の売主とするドロップシッピングの形式であれば実現が可能なのではないかと思い、それで行こうということになりました。

それ以外にはサプライヤーごとに個別アカウントを発行し、受注処理などを自動化するとか、運営を適切に管理できるような各種機能を揃えてあるというのがポイントです。これは既に稼働しているサイトが複数ありますので、その中で出てきている必須であろう機能についてはデフォルトで網羅できているということですので、安心してご利用いただけるのではと思っています。

 

 

続きまして、もう少々細かい機能一覧についてですが、ざっと120個くらいの機能が実装されているので、全部はアレですが、一部重要なところを紹介します。

例えば異なるサプライヤーの注文をフロントでどうやって捌くのか？という部分ですが、弊社ではスプリットカートという形でサプライヤー毎の注文の切り分け、個別の送料計算、注文情報の適切な仕分けを実現しています。また、このケースでは1つ目のサプライヤーの注文が完了した後に、自然なUXで他のサプライヤーの商品も決済してもらう必要があるので、サンクスページからカートページに自動リダイレクトする機能なども入っています。

また、管理者側のページであれば、サプライヤーとの仕入れにおける仕切値を%や固定金額などで決めて管理する機能や、サプライヤー毎の売上や支払い予定の金額などが一元的に閲覧、DLできる機能などもあります。

サプライヤー側のページについてはShopifyの商品管理や注文管理にUI/UXを寄せているので、類似の業務が行えて、それ以外には個別に送料設定などする機能などがあります。

 

 

明石 : 続きまして、オプション機能の紹介です。機能とそれに合わせた費用の話にも繋がるんですが、我々のパッケージではデフォルト、オプション、カスタマイズの3段階に分けています。標準機能でもサイトの運用上必要なものがある程度網羅されている為、実際に運用ができます。

ただ、やはり大手の企業様のような要件がある程度大きいものになってくると、標準機能だけでは要件が満たせないということも理解しています。このパッケージは、我々が自社開発しておりますので、やろうと思えばどうとでもカスタマイズすることが可能ではあります。

ただ、1から10まで全部やってしまうと、初期もメンテコストも少々お高くついてしまうので、すでに弊社で開発済みの機能の中でも、 いわゆる高級な機能はオプションとして提供させていただくといったコンセプトとなっております。

スライドで紹介しているのはそのオプション機能の例ですので、簡単に紹介させてください。

ロール管理機能についてですが、ここで言うロール管理機能とは、ユーザーごとに個別の権限を設定するのではなく、「役割によって使える機能を設定できる」形式になります。

IPアクセス制限機能は、特定のIPアドレスからしかアクセスできないようにする機能です。

大企業様のコンプライアンス的に、個人情報の閲覧が特定の部屋であったり、特定のIPアドレスからしかできない、といったケースがあるのでそれらの制御を実現する為の機能です。 

各種登録フォームのカスタマイズは、普通に登録項目をカスタマイズすることはもちろん、基幹システムのデータ連携などをする際の細かなご要望に対応しております。

 

 

明石 : 続きましては、テクノロジーのお話になります。

サーバーサイドとしては、Ruby on Railsを使用していて、フロントはReact、インフラはAWSです。ShopifyのAPIは基本的にはGraphQLを利用しているんですが、実現したい要件によってはRESTも併用しなければいけなかったりするので、その辺りはまちまちです。

 

明石 :弊社のこのパッケージが他社と比べてどうなのか？という話なんですが、みなさまどうでしょうか？こういったプラットフォームみたいなECを作りたいとなったとしても、どこに頼んだらできるのか分からないですよね。これ実際にそういうことが出来るベンダーに見積もり依頼するとざっくり言って数千万円ぐらいから〜みたいな話になります。むしろ要件次第だったりするので、見積もりをそんなに正確に出すところはほぼいないんじゃないかと思います。とりあえず要件定義と実現性の確認で2ヶ月350万、みたいな感じで始まると思います。

それだと、クイックにやるというのはなかなか難しいと思います。かたや、安いパッケージのようなものがあったとしても、与件がマッチしない・カスタマイズができない。

「こういうビジネスがやりたい」とイメージを持っていらっしゃる方は多いと思うのですが、実際には実現のハードルがまあまあ高そうだ、みたいな悩みが業界的にあったと思います。

ですが、弊社のサービスであれば、圧倒的な低価格でほとんどの機能を実現することができますし、一休さんのようなエンタープライズレベルの機能も柔軟に実装が可能です。

スピード感も、標準でご導入いただく場合であれば最短1.5か月で実装が可能です。

明石 : また、運用中のサイトにも導入可能でございます。

普通のECサイトが悩むポイントというのは、結局は商品の問題と集客の問題に帰結すると思うので、 こういったドロップシッピング型のアプリを追加すると、単純に他社さんの商品をお借りして、サイトに販売することができるということなので、商品数を増やすこと、それが結果として間口の増加に繋がり、ユーザーの流入も増えると。ECの品揃えと集客を同時に解決することが可能になり得るというメリットがあります。

 

 

明石 : ここで少し話がそれるんですが、ドロップシッピングをまだ利用経験がないオーディエンスの方に向けて少々だけアフィリエイトとドロップシッピングとモールという3つのビジネスモデルを比較して説明させていただきます。

アフィリエイト → 広告サービスの一種です。例としては個人ブロガーの方が特定の商品を紹介し、広告主のバナーをブログ内に掲載します。ブログにアクセスしてきたユーザーが広告バナーから広告主のサイトに遷移して注文をする、それによって取り決めてあった単価の報酬を成果報酬の形で受け取るといった形式です。

ドロップシッピング → ネット上での委託販売になります。一般的には購入者にメーカーが直送するモデルになりますが、売り主は販売者である自社です。代金は売主が直接受け取り、後日メーカーに支払う形式となります。注文者の顧客情報も売主に残るため、その後のCRMなどの展開に繋げることが出来ます。

モール → 楽天やamazonに代表される形態です。ご存じの通り、モールに出店させる形式です。出店料や売上の%、その他モール内の販促メニューなどで課金するビジネスモデルになるため、モールの客を出店者に売るビジネスになり、注文者のメールアドレスは共有しません。

 

続いて、Shopifyが提供しているMarketplace Kitという仕組みとの違いについても簡単に説明します。

Marketplace Kit → ポータルやアフィリエイトに近いサイト構築をすることになり、 サプライヤーに当たる方々それぞれがShopifyと契約した上で、契約したShopifyのストアと大元のストアをアプリを使ってデータ連携するイメージです。決済は各サプライヤーのストア上で行われるため、個人情報はポータル運営ではなく、各サプライヤーさんのストアにストックされる形式です。つまり集客のお手伝いをするだけという形式なので、広告サービスのようなものですね。

弊社の産直型サイト→　全ての注文は、1つの産直サイト(1つのShopifyストア契約)上で決済されるので、運営者に個人情報が蓄積されます。Marketplace Kitでの開発とは違い、サプライヤーがShopifyのアカウントを契約する必要はありません。

※ここでデモを行いましたが、ご興味のある方は弊社までお問い合わせください。

 

 

 4. その他導入事例

 

明石 : 導入事例ですが、ヴィンテージの商品を集めた100社程のサプライヤーが出店しているヴィンテージコレクションモール様のサイトです。

https://vintagecollectionmall.jp/

 

 

明石 : それ以外にも現在進行中のプロジェクトとして、キャンプ用品のBtoBサイトや冷凍食品販売サイトがあります。

 

 

5. 導入までの流れ

明石 : 導入までの流れですが、大きくは、”要件定義”と”開発”の2つのフェーズに分かれています。 最初はざっくりと仕様決めを行い、概算見積もりと納期をある程度決めた上でお申し込みをいただき、その後要件定義フェーズで詳細を詰めていく感じです。

インフラの設定、ステージング環境で実装などを行い、問題がなければ本番環境に導入→公開、というような流れとなっております。

公開までを我々はよくPhase1開発、公開後をPhase2開発と呼んでいますが、Phase1でどこまで機能面にこだわるかという話を少しさせていただくと、結論として多少機能が漏れても、Phase2開発の際に実装しても遅くはないので必須でない機能はPhase1ではカットすることをおすすめしたいです。むしろ本当に必要かどうかわからない機能をまだ運用していない段階から無理して詰め込んで結局あまり必要無かったとなってはもったいないですし。

 

明石: こちらは今後開発予定の機能ですね。Shopifyさんの仕様次第なものもあるため、その辺りはShopifyさんに期待したい部分もありますが、将来的に開発を予定している機能もたくさんあります。スプリットカート(サプライヤーごとに決済)ではなく、ふるさと納税のサイトみたいに一発で決済できる機能や、レビュー機能を活用してサプライヤー同士が相互で直接やり取りできるもの、ポイント機能などの開発を検討しています。

 

明石 : 最後にサービス提供の座組みについてです。

もちろん弊社に構築全体を丸投げしていただいても大丈夫なんですが、分業して構築をすることも可能です。

分業というのは具体的には、フロントエンドをShopifyパートナーの皆様に作っていただき、バックエンドと先ほどご紹介したスプリットカートなどのカスタマイズ機能のみを弊社が実装する、という座組みです。産直型ECサイト、一緒に作ってみたくないですか？普通のECとはまたちょっと違って楽しいですよ。

 

 

6. 株式会社一休の尾崎氏×Shopify Japan株式会社の 岡村氏×弊社代表の明石によるパネルディスカッション

司会 徳永 真穂(以下、徳永) : 続きまして、第2部のパネルディスカッションに入ります。 

ここから株式会社飛躍の明石様、そして株式会社一休の尾崎様、 Shopifyからは岡村が参加いたしまして、皆様の気になるテーマをもっと深掘りしていきます。

 

岡村 純一 (以下、岡村) : まず、初めの質問です。

導入にあたってのパートナーである株式会社飛躍様と事業者である株式会社一休様との関わり方や役割分担についてです。

今回かなり高機能なソリューションを提供されていると思うのですが、支援パートナーである飛躍さんと実際の事業者さんである一休さんとの役割分担などについてお伺いします。

まず、支援パートナーである明石さんの方から、今回どのように一休さんと役割分担を進め、どういったディスカッションをされたのか、簡単にご共有いただければと思います。

明石 : はい、ありがとうございます。我々、支援事業者でございますので、基本的には設計して開発をするといった形になります。

ですが、皆様もご存じの通り一休さんはプラットフォーマーであり、当開発においては一部我々よりも知見がおありでしたので、要件定義は、半分くらい一休様の方でやって頂きました。弊社ではご要望を確認しながら、Shopifyの現行の機能とすり合わせた上で実現に向けた仕様を提案をさせて頂きました。その上で完成した要件整理表を両社で見ながら、機能毎にやるやらない、Phase2回すなどを議論して決めました。

岡村 : なるほど。ありがとうございます。では飛躍さんに丸投げというよりはゴールなどを共有しながら擦り合わせたのですね。

明石 : そうですね。エンドユーザー目線で考えた時の管理画面の作り方や諸々のUXに関しては、尾崎様や一休さんのCS担当をしていらっしゃる方々からのご指摘をいただきながら、 実際に詰めていきました。

岡村 : なるほど。では続いて、尾崎さんに質問です。私のイメージだと一休さんは社内にエンジニアをたくさん抱えている、事業者さんの中でもIT投資をかなり進められている企業さんという印象なのですが、社内で開発体制がある中でもパートナーである飛躍さんにお願いした経緯を教えてください。 

尾崎 亮太 (以下、尾崎) : はい、ありがとうございます。 我々は、社内にエンジニアがたくさんいるのですが、新規事業に割けるエンジニアリソースは非常に限られております。ですので今回、社内のリソースはほとんど使わない方向性でプロジェクトを進めました。

元々色々な仕組みを作っているのですが、現状ECのサービスを持ってるわけではなかったので、 メンテナンスコストなどを考えると自社でフル開発するよりは、どこかのサービスにもたれかかったままやらせて頂く方がサステナブルなのではないかというのが前提としてあり、今回Shopifyさんと飛躍さんにお願いしました。

 

 岡村 : ありがとうございます。

では、次のトピックに入ります。なぜShopofy Plusを選んだのか。これは事業者さんである尾崎さんに一言頂きたいのですが、いかがでしょうか。

尾崎 : はい。2つありまして、1つ目は、APIが潤沢に使えるところです。

データを使ってユーザーを接客するという考え方が社内にありますので、自社のデータと連携できたり、自社のDWHに保管できることがマスト要件でした。

2つ目は、シンプルに事業に関わる人数が多いので、アカウントの数をより多く扱えるShopify Plusしか選択肢がなかったことです。

岡村 : なるほど。先ほど新規事業にリソースを割けないとおっしゃっていましたが、Shopify Plusであればクイックにローンチするところに有効だったということですかね？

尾崎 : そうですね、実は5月頃にShopify Plusに契約を変更して本格リリースという形を取っておりまして、その前は1年間ぐらいテスト販売をしていました。その時は1個下のプランを契約させていただいたのですが、限られたアカウント数で、手動運用で試してみようと言う期間を経てShopify Plusプランにしました。

 

 岡村 : わかりました。ありがとうございます。

では、次のトピックです。 パートナーとしてこのソリューションを開発にあたり苦労した点についてです。こちらについては、明石さんお願いします。

明石 : はい。PM的な大変さで言いますと、要件定義で潰しきれないロジック漏れみたいなものがあったりですとか、実際にプロジェクトが始まると、「この機能がなきゃダメだ」みたいなことに気が付くわけです。

後半でそういった追加の要件だったりとか、DBの設定を大幅に変更しなきゃいけない！みたいなことがあった際に、 調整をしたりするのが多少大変でした。

あとはそのサイトディレクションだけでなく、いわゆるテスターの役割も、うちの場合はPMが兼ねてやっていることが多いので、単純にとても忙しかったです(笑)

今回のサイトの中で私が1番大変だったのは、レストランの方々がお弁当を送る、お取り寄せするといったコンセプトのサイトということもあり、「送り忘れた」「このお弁当今日20個作らなきゃの間に合わない」のようなことを避けるために、フロントや注文管理、配送、売り上げの中継などの細かな設計で詰まる部分が多かったです。注文管理の画面の中にWMSの機能も実装していく必要がありましたし。

岡村 : ありがとうございます。Shopifyでは、APIはGraphQLを使うことを推奨しております。Shopify自体が1番新しくて良い技術に投資してるので、より製品を良くするための アップデートがあるのですが、飛躍さんの場合はプラスエージェンシーという形で大手向けのShopifyプランの構築をメインにされてるパートナーさんなので、大規模のソリューションになると個別の要件が多いということと、飛躍さん自体がPlusプランで構築をするというワンストップのソリューションをされているというのがあったと思います。そういった色々なご苦労の集大成がこのソリューションに詰まっている気がしています。

逆に言うと、日本で唯一のソリューションとしてブラッシュアップができているのは、少なくとも我々が認知してる限りだと飛躍さんのだけなので、キャッチアップに色々と汗を流していただいていると同時に、実績とやりがいという実感はあるのかなと思いますね。

明石 : めちゃめちゃあります笑

岡村 : あとは、ウェブアプリの新しい仕組み・アプローチに自然となっていくので、そういう意味でも結構苦労された部分の資産という意味では今後も使えるのではないかと思います。ありがとうございます。

 

 岡村 : では、次のお題に行きます。

事業者として、今回、一休さんに提供されているようなソリューションを選定した理由や背景を尾崎さんに伺いたいと思います。

尾崎 : はい。まず我々賞味期限の短い食品を扱うというのが今回のメインテーマで、商品サイクルが短いものなので、 到着日ごとに在庫を持たせるような機能を今回は必須の要件として考えていたのですが、それが叶えられるECサービスがなかなか見つからなくて。

Shopifyさんの場合は、オプション情報を到着指定日ごとの在庫として持つことが可能だったので、「消去法的にここしかないかな」という形で選びました。また、商品の到着指定日ごとに在庫を持たない仕組みで良いのであれば、今回みたいにオーダーメイドで作らなくても海外のアプリで実現できそうなものがあったりしたのですが、やはり我々の今回の鍵となる要件は「商品の到着指定日ごとに在庫を持たせる」でしたので、Shopify Plusプランを使って飛躍さんに要件通り作ってもらう必要がありました。

岡村 : なるほど。ありがとうございます。そうですね。結構細かいところですけど事業の核になるケースも多いのかなという気がしますね。

先ほど言ったように、海外向けのものをうまく使って早くローンチできる部分もあるのですが、どうしても譲れない部分の要件は飛躍さんのようなパートナーさんに頼んでしまうのも有効な手ですね。

 

岡村 : では、最後です。 

ミニマムスタートでリリースすべきか、コストと時間をかけてクオリティを追求すべきかというところで、 まずは事業者さんの一休さんの方にお伺いしたいのですが、今回ミニマムスタートなのかどうなのかというところと、今後のスケールアウトの展望をお聞かせいただけますか。

尾崎 : はい。まずはミニマムスタートした方がいいというのが回答です。今回、本番リリースを5月に設定していたのですが、実際はその1年前ぐらいに、店舗だけを掲載する”一休お取り寄せ”というショップを作り、はじめは1店舗のみでの販売を行っておりました。そこで実際にShopifyの仕様やAPIでどんなものが取得できるのかを認識した上で、飛躍さんに相談しました。

岡村 : なるほど。ありがとうございます。ちなみに、ミニマムスタートをした時にもある程度将来のスケールを見据えてShopifyを選定頂いたんですかね。

尾崎 : そうですね、ベースのバリエーションの考え方のところは、最初に検証してから選定したというのはスタートとしてあります。

岡村 : なるほど。では飛躍さんにもちょっとお伺いいたします。制作する場で期待値のすり合わせや認識合わせが必要だと思うのですが、事業者さんによっては最初から全てフルセットでローンチしたマーチャントさんもいらっしゃると思うのですが、支援パートナーとしてはどのように認識のすり合わせをしているのでしょうか？

明石 : そうですね、一応、当社にはPJシートというヒアリングシートのようなものがございまして、そこでやりたいサービスやコンテキスト、期間や規模などを擦り合わせます。

今回のような産直型ECみたいなお話になってくると、やはりビジネスドライバーの1つにサプライヤーの数が重要なポイントになります。

サプライヤーの数がものすごく多いのであれば、 実際ミニマムでスタートするよりかは、もうしっかりとプロダクトとして作り込んだ上で擦り合わせた方が良いです。ですので、本当に目指す事業規模などに合わせて柔軟に対応しながら提案しています。

岡村 : わかりました。ではパートナーとしては、ヒアリングのテンプレート等のノウハウが重要になってきますね。ありがとうございます。
それでは、パネルディスカッションは以上で終わりにしたいと思います。

徳永：ありがとうございました！お時間になりましたので、以上でセミナーを終了いたします。