「顧客体験をデザインする。#03」に参加してきた
参加メモ
大規模B2B Eコマース "モノタロウ" におけるテクノロジー - ECサイトから物流まで -
登壇者: 株式会社MonotaRO 執行役 データマーケティング部門長 久保 征人 @masatokubomro
フルスタックEコマース
モノタロウの紹介
- 特徴
- 在庫を持ってる
- 全て自社開発、運用
- 商品1800万点 353万事業者
- グローバル企業
フルスタックECにおける顧客体験の向上
会社として、顧客の接点の種類が多い
当社のケースでは、全ての業務担当者が、顧客体験を向上させることが可能な当事者である
- 管理
- CS
- IT
- 物流
=> その全ての業務担当者をエンジニアがサポートできれば、それが最も顧客体験の向上に繋がる
仕事が捗る基盤を作るとは
- 業務を自動化して生産をあげる => IT基盤を整える
- 業務分析と改善を加速させる => データ基盤を整える
データドリブンカンパニーとは
- 意思決定を支える経営と文化
- 意思決定を支える基盤
- 意思決定を支えるデータリテラシー
モノタロウのデータ基盤
- オンプレ時代
- 日時バッチでdata warehouseに突っ込んでた
- 新しいデータ基盤の必要性
- データが分散してる
- テーブル増える度に運用が限界
- スペックが足りない
- まだまだデータ増やしたい
- BigQuery
- GoogleAnalytics
- ApplicationLog
- MySQLのデータをリアルタイムで
- Binlog Connector
- 擬似的にMySQLのスレーブとして接続
- GitHub - shyiko/mysql-binlog-connector-java: MySQL Binary Log connector
- 3〜5分ぐらいの遅延レベルでリアルタイムに同期
成果
- データ量の限界はなくなった
- 100テーブル => 1000テーブル〜
- ダッシュボードの数も増えた
- 〜30 => 300
まとめ
- ECにおける顧客体験には業務担当者の業務が関わる
- それを達成する一つの方法が、業務分析 => 改善をサポート
ショップと顧客の絆を深める、デジタル＆リアルでデザインするEコマース顧客体験
登壇者: 株式会社ecbeing 製品開発統括部 統括部長/執行役員 渡邊 健太
会社紹介
本編
ECの中では、アプリの割合が大きいので、アプリも重要。
しかし買い物全体のうちECの占める割合がだんだん増えている一方で、オフラインでの行動が購入には重要であり続けている。
そのため、ECとオフラインの連携が重要である。
デジタルとリアルの顧客体験が重要
カスタマージャーニーマップ
デジタル&リアルで
nano universeの事例
ちゃんと、リアル店舗の在庫を連携できてるところは少ない
絆を深める、専門性の高いコンテンツ
ユーザが納得して購入できるように、ストーリー性を持って理解できるコンテンツを提供。
ライフスタイル提案・体験機会の提供
インテリア領域では特に、実際に家具を置いたらどうなるのかイメージを持ってもらうことが重要である。
unicoでは、3Dコーディネートの機能でカバーしている。
ユーザとブランドの絆の創出
設計・開発のポイント
- 「体験」を先に設計する
- デジタルとリアルの補完関係
- プロトタイピング
- 開発チーム / UXデザインチームの密度
- 「万人受け」よりも「こだわり派の納得性」を重視
- ペルソナ設定
- ユースケース記述
- リサーチと使い込み
- 体験の中心にスマホを考える
- スマホのGPS連動で、店舗の近くにユーザが来たらプッシュ通知
- 店舗に入ったユーザに対して、チェックインスタンプ、来店クーポンの配布
- スタッフ用のアプリで、連携してユーザを特定して、購入履歴、接客履歴、レコメンド商品
ABCマート スタッフ用のアプリで在庫状況をデータで把握
このあたりから、インスタとの連携などのチャネルや少しボイスコマースなどの話がありましたが、個人的にはあまり興味の範囲でなかったので割愛します。
まとめ
- あらゆる行動の中心にスマホがある
- モノ・情報・ヒトをデジタル＆リアルの体験に活用する
- 体験から先に、ペルソナを明確に設計する
- ファンと共に創り上げる顧客体験がSNSによって拡散する
- 5G時代には、顧客体験は動画が中心になる
- これから来るかも「ボイスコマース」
楽天スーパーSaleの舞台裏 - お買い物カゴシステムの負荷対策
登壇者: 楽天株式会社 ECマーケットプレイス開発部 Marketplace Core Architect Section シニアマネージャー 橋山 牧人 @capyogu
自己紹介
- 経歴
- 現在の仕事
- プライベート
- ゲーム
- プログラミングスクール講師、執筆活動
前提の説明
楽天スーパーセール => 2012年3月より開始した大型セールイベント
楽天スーパーセールの当日の様子
100名以上のエンジニアが同じフロアで監視
監視内容
- The Four Golden Signals
- Latency
- Traffic
- Errors
- Saturation
独自の監視項目
ビジネス的に重要なポイントを重点的に
- エントリー数
- 売上高
- 受注件数
- メール配信
トリアージの具体例
あくまでも、お買い物の継続が最優先で、外部要因であれば機能を切り捨てる。
例えば、外部APIを利用して表示してる機能や、お買い物のフローに関係のないサブ的な機能は切り捨てる。
トリアージの失敗例
会員ランクに応じて付与するポイントが変わるため、半年ぐらいかかる地獄に陥った。。
事後影響を考えると、会員サービスダウン時はお買い物かごを停止させるべきであった。
緊急時に何を優先するか、ビジネスや補償の観点を含めて事前に決めておくことが重要。
負荷試験
負荷状況の再現方法
※ 結構過去の話だそうです。
開始直後のピーク時には、通常ピーク時の約20倍のアクセス
深夜に本番環境で負荷試験
当時のエンジニアがノウハウを持っていたJMeterを採用。
イメージとしては、負荷生成サーバを構築して本番のユーザと同様に振る舞ってリクエストするみたいです。
試行錯誤その1 負荷テストの設計
- 全ユーザシナリオを再現するのは非現実的
- 90%のユーザアクセスがカバーできるシナリオを設計し、呼び出すAPI・システムを選別
- 何を目標とするか:
- 共通の目標数値: 分間受注件数
- 覚えやすい、理解しやすい共通目標を設定することで、課題や達成度を明確にできる。
試行錯誤その2 データの追加、フィルタリング、破棄
- トラフィック量・レイテンシが想定よりも少ない
- 原因1: 各ダミーデータのデータサイズが本番よりも小さかった
- 原因2: 特定のページや商品に集中したためキャッシュが効いた
- 大量のダミーデータを用意(20万の会員、6500の店舗、100万の商品)
- テストデータのフィルタリング、掃除
- 負荷試験のために、ダミーのデータの処理はさせたい
- その一方で、サービス影響出ないようにダミーのデータは早く破棄したい
対策
人気商品への対応
セール商品の分類
特性が異なるので、対応策も別々になる。
| 商品タイプ | 概要 | アクセス | 在庫数 | 商品例 |
|---|---|---|---|---|
| タイムセール商品 | 通常のセール商品。普段から売られてることが多い。 | 中 | 多い | カニ、肉、水 |
| 目玉商品 | スーパーSaleのみで販売。希少性や割引額が特に高い商品。 | 大 | 少ない | 車、宝石、時計 |
| 人気商品 | 特定の層に人気。値段はそれほど高くない。テレビで紹介された、など。 | 大 | 多い | 特定のファッションアイテム、おもちゃ、消耗品 |
今回の事例では、 人気商品に該当する、当時人気だった妖怪ウォッチのおもちゃ等の事例。
なぜシステム上の問題が出たのか
対策1: 専用システムを構築し、検知の仕組みを導入
人気商品を別のシステムに隔離することで、負荷でシステムがスローダウンしても通常のお買い物は継続させる。
対策2: 在庫キャッシュの更新を非同期にする
そもそも同期処理したところで、ユーザがアクションするタイミングで在庫状況がずれるので意味がない
今後の取り組み
| 課題 | アクション |
|---|---|
| スーパーSALE同様の負荷を受けきれる試験用の環境が用意できていない | クラウドプラットフォームに簡単にデプロイできるためのコンテナ化、マイクロサービス化 |
| スーパーSALE同様の負荷を柔軟かつ安全にかける手段が十分に用意できていない | システムメトリクスと紐付いた、クラウドベースの自動テスト実行プラットフォームの開発 |
| 複数のサービスを跨ったトラブルシューティングが十分なスピード・精度・統一された手段でできていない | 統一プラットフォーム上のサービスメッシュの導入 (1)分散トレーシングによるトラフィックの追跡 (2)Circuit BreakerによるSystem Reliability |
今後のシステムアーキテクチャ
