2015.03.27
保存版!ヤフー、スタフェス、アソビューと考える「ECのバックエンド」リアルとITの融合で大切なこと

保存版!ヤフー、スタフェス、アソビューと考える「ECのバックエンド」リアルとITの融合で大切なこと

ヤフー、スターフェスティバル、アソビューの技術責任者が集結!3月11日に開催された『リアルとITの融合』イベントレポートです。普段あまり表に出来ることのない「サービスECの裏側」が赤裸々に語られました。リアルとITの融合で大切なこととは?

0 0 8 0

知っておきたいサービスEC運営のウラ側

平成25年に、市場規模11.2兆円(前年比17.4%増)まで拡大している日本国内のEC市場(電子商取引に関する市場調査の結果を取りまとめました- 国内BtoC-EC 市場規模は11.2兆円に成長 - – 経済産業省)。

当然、ECに携わるエンジニアの数も増えていますが、そのノウハウが表に出ることは多くありません。突発的なアクセス増にはどう対応する?滞りなくサービスを提供するためのシステム設計上の工夫とは?インフラのチューニングポイントって?

そして、サービスECにとって重要となる本質的な考え方とは。

こんな問いについて考えるべく、ヤフー、スターフェスティバル、アソビューの技術責任者が集結。イベント『ヤフー×スタフェス×アソビュー 技術責任者が語る、リアルとITの融合』の様子をお届けします。


ヤフー×スタフェス×アソビュー

画像左からIDCフロンティア大屋さん、ヤフー平田さん、スターフェスティバル加藤さん、アソビュー江部さん


[モデレーター]
・株式会社IDCフロンティア 技術開発本部 副本部長兼R&D室長 大屋誠

[登壇者]
・ヤフー株式会社 ショッピングカンパニープロダクション本部 本部長/テクニカルディレクター 平田源鐘
・スターフェスティバル株式会社 CTO 加藤彰宏
・アソビュー株式会社 取締役執行役員CTO 江部隼矢

ITリテラシーの高くないユーザーに向けたシステムのあり方とは?

サービスECにおける特徴のひとつとして、消費者、サービス事業主、配送業者、社内のさまざまな職種のメンバーなど、プレイヤーが複数にわたること。そこでまずは登壇者の方々が携わっているサービスの説明と、携わるプレイヤーの紹介からスタートした。


平田(ヤフー):
『Yahoo!ショッピング』と『Yahoo!トラベル』を担当しており、本日は『Yahoo!トラベル』の話をメインで。もともと『Yahoo!トラベル』はアグリゲーションサービスだったが、最近、施設様から宿泊プランを仕入れる直接販売を始めた。

直販モデルの開発ノウハウはなかったので、ユーザーとなる施設様が利用していた管理画面なども参考にして開発。バックエンドの画面ではプラン登録画面、料金設定、予約管理、売上管理などができる。

この画面を使うお客様の中には、比較的小規模の施設様でパソコンにおけるリテラシーが必ずしも高くなく、ノウハウを持っていない方も多く、思わない操作をされることもある。迷わない仕組み、ガイドを準備するのは重要。

ちなみに多くの施設様は、複数のOTA(オンライントラベルエージェント)という、サイトを使って宿泊プランを販売している。またサイトコントローラーという仕組みがあり、宿泊プランを複数サイトに配信し、在庫管理を一本化するのがスタンダート。4社くらいのサイトコントローラー大手と連携している。


加藤(スターフェスティバル):
『ごちクル』はBtoBtoC(B)で、パートナーとなるレストラン・配送会社と消費者の方をつなぐお弁当の配送サービスを行なう。商品となるお弁当の登録は、スターフェスティバル側が担当する。バックエンドにあるものは買い物カゴ、受注情報など。レストラン向けに「明日どのお弁当をつくればいいか」などがわかるようになっている。また配送パートナー向け画面もあり、それはどのレストランにお弁当を取りにいくか、どこに届けるかなどが表示される。


ヤフー×スタフェス×アソビュー

『ごちクル』バックエンド概要


トップ画面では、レストラン側に気をつけてもらいたいことなどが配信される。遠隔地にいるレストランの方ともコミュニケーションを取る試み。思いを共有したい。

また、リテラシーが高くない方も多いので、WEB画面を見ない方も。たとえば、メールを飛ばして、そのメールを印刷して運用するなども多い。そういう意味では管理画面を使いこなすレストランの方は少ない。

スターフェスティバル側が使う社内画面の工夫としては、電話でも注文を受け取るため、コールセンターの担当者が注文入力で苦労しないように、一画面にかなり詰め込んでいる。画面遷移を少なくする。逆にこの使い慣れた画面を変えてしまうと、コールセンター側から文句が出てしまうこともある。


江部(アソビュー):
『ASOViEW!(あそびゅー!)』のサービスモデルは、一般消費者(ゲスト)の方々が週末にどこいこうか、旅先で何やろうか、現地のさまざまな体験を提供。レジャー事業者を紹介する。

ヤフー×スタフェス×アソビュー

『ASOViEW!(あそびゅー!)』に関わるプレイヤーとシステム


登場人物の大枠はゲスト(一般消費者)とパートナー(レジャー事業者)と社内。パートナー向けには在庫予約管理システムがある。

社内でいうと、サポートデスクで「ゲストサポート」「パートナーサポート」に分かれている。前者はゲストからの問い合わせに対応。「週末、暇なんですけど、どこにいけばいいでしょうか?」といった相談にも乗る。パートナーサポートは、予約があったレジャー事業者にリマインドなどを送る。また調整なども行なう。

社内を細かくご紹介すると「営業」「制作」「マーケティング」「経理」といて、それぞれが使うシステムがある。 社内でレジャー情報を制作・更新しており、SEO対策のためのコンテンツ管理も実施している。

工夫している点として、パートナーと、パートナーサポートが使う予約管理のダッシュボードがあること。パートナーが予約ステータスを更新してくれているかわかる。

またメッセージ機能もある。アウトドアレジャーは天候に左右されることもあり、直前のやり取りや調整も多い。メールだと既読か未読がわからずトラブルになることも。独自認証したアドレスにメッセージを飛ばし、既読か未読がわかるようにしている。それをもとに確認の電話ができたりもする。

多少使いづらいUIでも、売り手は”売れるサービス”を使う

3社におけるサービスモデルの共通点はBtoBtoC(B)であること。宿泊やお弁当、アクティビティなどのプラン・コースを仕入れてきて販売する。モデレーターである大屋氏より「Yahoo!トラベルなら宿泊施設、ごちクルならレストラン、アソビューならレジャー事業者…それぞれの管理画面について変更を加えるケースで気をつけてている点はあるか?」と質問が出た。


加藤(スターフェスティバル):
「慣れ」は強力なUXで、これを払拭しながら、万人に受け入れられるような変更は正直難しい。特に管理画面は普段使うWEBサービスとは一線を画すものだと思う。皆さんが業務で使うメーラーをイメージしてもらうといいかもしれない。変更があると業務効率に大きなインパクトがある。そのため大きな動機がない限り、UIは変更しない。あとは使いやすく、シンプル、直感的に…という部分は心がける。


平田(ヤフー):
宿泊施設の現場で働く人の声を聴きながら変更したりする。たとえば、決済まわりの調整が後からでもスムーズにできるなど。宿泊だと大人2人で予約していたが、子どもも行くことになった…など調整が多いため。特に経営者ではなく、実際にツールを使って作業する現場の方などの意見を聞く。

ただ、本質的にいえば、売り手は、管理ツールの充実よりも、自社の商品の売り上げが伸ばせるシステムを使う。管理画面ひとつ取っても、商品タグの設定、検索にヒットしやすいようなオプション、サジェストも「買い手が欲しがるような情報」が入力しやすいように工夫する。売り手がコンテンツの作り手でもあるので、そのコンテンツを魅力的にアップしてくれるようなところに注視。買い手の目にいいコンテンツが触れて、タグで絞り込んだときに良いプランに出会えるようにするなど。

それぞれのサービスにおけるシステム構成とは?

続いて紹介されたのが、各サービスのシステム構成。それぞれの成長のフェーズに応じた構成となっており、興味深い内容が共有された。


平田(ヤフー):
セキュリティは相当厳しくやっている。社員さえ入れないセキュアなネットワークとインフラがあり、施設情報、住所、名前などの情報が入っている。

また、検索は作りこんできたところ。もともと、予約サービスは意外とデータが少なそうというイメージがあったが大間違いだった。『Yahoo!トラベル』は直接的に取り扱う宿泊プランは4000くらいだが、「バースデー割」「早割」など…10~20プランがあり、値段と掛け合わせると数億、数十億のレコードが。

販売代行もしているため、膨大なレコードになる。そのため贅沢して高いサーバを入れた。同時に検索インデックスに入れるのも大変。そこでシステムに制限や条件を重ねて、検索で必ずヒットするようにした。


加藤(スターフェスティバル):
『ごちクル』の改修やリニューアルが簡単にできるように、どんどん変更しているところ。マイクロサービス化し、APIを介して全ての情報を取ってきたり、更新したり、それができるアーキテクチャへの変更を進めている。

そうすることでデータベースに向かっての疎結合が完成する。API改修だけで、データベースをまるまる入れ替えることも念頭においている。たとえば、新旧データベースをつくり、API側でハンドリングし、ケースに応じて新旧振り替えてやることで順次、古いデータはそのまま参照したり、新しいデータは新しいデータベースに入れたり。ビジネスロジックもAPIに肩代わりすることによってUI層だけの改修だけにも対応できたりする。


江部(アソビュー):
サービス自体、2012年の4月に開発を開始して2ヶ月でローンチを目指すなど、スピード重視でスタートした。大きなデータベースの中に全て入れていた。もともと経理も、WEBマーケティングも、制作も一人がやっていたので、同じとろこにあった方が使いやすかった。ただ、担当業務が細分化され、システムの利用者も増えてきた。組織の成長に合わせてアーキテクチャを変えていくフェーズ。マイクロサービス化、APIを介したDBとの通信、アプリを分けるなど、改修時の影響範囲を最小範囲で対応できるようにしていく。「余暇」に関するサービスは展開がすごく広い。海外でやろうとか、提携しようとか。フロントもたくさん出てくる。成長痛を感じているところ。最小構成でスタートして今はスケールさせるフェーズにいる。

買い手の目線に立つための取り組みとは?

加藤(スターフェスティバル):
買い手目線だと、テストはしっかりやっている。たとえば、お弁当を注文するケースは、重役の会議や、来客におけるランチミーティングなど。利用者は総務、秘書など。テスト対象者を多くすると、ブレが出るので5人で1クールで行なう。だいたい80%くらいの精度でデータが取れる。

また、解析ツール・数値をもとにしたPDCAもまわす。たとえば、ブラウザ対応も95%以上とするなど実績値ベースで決める。特に見ているのはどこでドロップ(離脱)しているか。改修前後で率を見て判定している。ただ、そこまで成熟したサイトではないので、ABテストはほとんどやらない。勝ちパターンを信じてやるフェーズと捉えている。

ドロップさせないために、買い物カゴに入れたあとに営業努力でカバーするなど泥臭くやる部分も。WEBでは完結しない。『ごちクル』の大きなポイントとして、電話注文が気軽にできること。サイト見てわからなかったら電話してもらう。チャットで問い合わせできるようにしたり、いろいろ試している。


江部(アソビュー):
アウトドアやレジャーは在庫管理、そもそも「在庫」の概念がむずかしい。ラフティングだと船の数が在庫になるが、たとえば7人乗りがよくある船で。3人グループと、別の4人グループが予約した場合、単純に考えれば1艇でいいが、違うグループだから別々に乗りたいとなれば、2艇必要となる。 その他、レジャー会社の業種業態によって在庫の定義はさまざまだが仕組みを提供する側としてはパターンに落とさないといけないので、各社の在庫の考え方についてサポートがフォローするなど泥臭い部分はどうしてもある。

サービスECにおけるシステム運用の苦労とおもしろさ


最後のパートでは「サービスECにおける運用においてどんな面白さが感じられるか」という部分においてそれぞれの見解が述べられた。


ヤフー×スタフェス×アソビュー


加藤(スターフェスティバル):
エンジニアからボトムアップで「こういう言語やフレームワークでやりたい」を吸い上げており、作り変える面白みがある。言語はPHPがメインで、フレームワークはアメリカで流行っているLARAVEL5などにトライした。

苦労としては、経理、営業、コールセンター、運行管理…ステークホルダーが多く、管理画面だけでもさまざまな要望があがること。もともとエンジニアが各部署に張り付いて改修していたが。リソースは限られる。先々を見据えて体制を変更。各部署がどういうシステム改修を希望するか、ROIを出してもらって、それをバックログにあげて全社員が見れるようにした。それに対してリソースを割り当てるようにしたことで、パフォーマンスと開発スピードがあがった。

使っている人たちは「便利になる」と思って挙げてくれる同じ改修でも、違う言い方になっている場合もあり、全てに対応していると継ぎ接ぎだらけに。バックログ管理をし、要望もプロダクトマネージャーがソリューションが最適か要件定義からやるようにしている。


江部(アソビュー):
改修における成果が見えることが非常におもしろいところ。ABテストやアクセス解析結果から導いた仮説を元に改善していくが、たとえば、予約フォームの使いやすさや配置などの微調整でも、小さな変更が成果に直結することもある。

苦労としては、サービスの拡大と充実など、「攻め」に注力していく一方で、それに伴い複雑化するオペレーションにどう対応するかなど、「守り」を見ることも重要になってきている。限られたリソースの中で攻守のバランスを保ちながらサービスを伸ばしていくことが大事。


平田(ヤフー):
社内のステークホルダーという点でいうとディレクターが「買い手」のほうを向き、営業が「売り手」のほうを向く傾向にある。いかにひとつの言語で意識を合わせられるかが大事。たとえば「全体の流通額を最大するために」という同じゴールを定義し、営業の事情を可視化することにもこだわっている。

施策を打つときも「どのくらい流総額があがるか?」というところからブレイクダウンさせる。そうすることで、たとえば、ショッピングカートの機能を担当するエンジニアが自身で「コンバージョンレートやCTRをあげるためにこうしたらどうか」と現場から考える風土が出来る。

気持ち的な部分として、クレームなどの場合、営業がパートナーに怒られるが、「技術的には問題なかったから私たちは悪くない」というスタンスでエンジニアがいると上手くいかない。「盾になってくれてありがとう」というスタンスだと営業側も歩みよって上手くやれたりもする。さまざまな職種のメンバーと、エンジニアの距離をいかに近くするかがポイントだと思う。


いかがだったでしょうか?それぞれ会社の規模やフェーズ、サービス概要によってさまざまなシステムの構成や課題、ノウハウ、醍醐味が感じられたイベントでした。参考になる話も多かったはず。ぜひ仕事に活かしてみてください!


編集 = 白石勝也


特集記事

お問い合わせ
取材のご依頼やサイトに関する
お問い合わせはこちらから