Quipper で Web Engineer 兼 Engineering Manager を務める @ohbarye です。スタディサプリの開発、その中でも特に合格特訓コースや決済周りの機能開発・保守が主な業務です。
弊社が開発するプロダクト「スタディサプリ」ではA/Bテストを用いたプロダクトの改善を行っています。Quipper の行動指針の一つに "Fact based" という言葉が含まれており、憶測や独断ではなく計測されたデータや事実に基づいて意思決定することが強く推奨されているためです。
このたびスタディサプリにおいて負債と考えられていた機能を「消してよいかどうか」、A/Bテストを通して判断しました。その際に用いた手法や結果、そこから見えたこと、考えたことをご紹介します。
プロダクトの負債とは
プロダクトチームにとって負債と考えられていたのは「キャリア決済」という決済手段でした。そう考えることに至った背景について簡単にご説明します。
決済手段の概況
スタディサプリは月額課金のサービスを提供しており、その支払い方法は大別すると以下の6種類になります。*1
キャリア3社をまとめ、2017年4月~12月のコンバージョン率（以下、CVR と表記）から概算したシェアと手数料を併記したものが以下の表になります。
| 決済手段 | シェア (%) | 手数料 (注1) |
|---|---|---|
| クレジットカード | 55 | 1 |
| コンビニ | 9 | 1 |
| キャリア | 11 | 3 |
| IAP | 25 | ※ (注2) |
※ 注1) クレジットカード手数料を1としたときの相対値
※ 注2) ご存知かもしれませんがIAPの手数料は30%で、他のどの決済手段よりも割高です。しかしスタディサプリにおいてIAPはその高額手数料を補うほどのシェアを獲得している優良決済手段でもあります。
負債と言われた理由（わけ）
上記の表を一見し、どんな印象を抱かれたでしょうか？
「キャリア3社まとめてもたった11%のシェア？」
はい、その通りです。そのうえクレジットカード・コンビニに比して手数料はおよそ3倍と高額なのです。ビジネスサイドとしては低額手数料の決済手段に移行してもらえたほうが当然ありがたいことになります。
エンジニアからするとどうでしょうか。11%のシェアのためだけに3キャリアそれぞれの特異仕様に対応する実装が求められることになります。新しい決済手段を実装する際の足かせになったり、決済機能全体のメンテナンスコストを高めたり、果てには決済機能の実装を好まないエンジニアの増加、いわばエンジニアの決済離れを起こすのではと思わせる悩みの種です。
また、カスタマーサポートチーム（以下CS）の観点でも決済種別が増えることはスタッフの育成コスト増加や誤案内リスク増大といった問題に繋がっていました。
ここでプロダクトチームの心が一つになります。
＿人人人人人人人人人人人人人人＿
＞ キャリア決済お別れの予感 ＜
￣YYYYYYYYYYYYY￣
A/Bテストの設計
たとえ瞬間、心重ねたとしても、先述の通り我々は "Fact based" company なのですぐに機能を消し去るようなことはしません。
キャリア決済は、プロダクトチームにとってどれだけの"価値-バリュー-"があるのか？ キャリア決済は、ユーザーにとって本当に必要な"体験-エクスペリエンス-"なのか？
その謎を明らかにすべく、我々はアマゾン奥地へは向かわずにA/Bテストの設計に着手しました。
仮説
私が立てた仮説はこうです。
- 仮説1: 「スタディサプリがキャリア決済を提供しないとき、ユーザーは他の決済手段を選ぶ」
- 仮説2: 「キャリア決済でなければ課金しないという層がいたとしても、他の手数料が安価な決済手段を選んだユーザーによる利益増分で補填できる」
この2つの仮説を同時に検証するため、以下の2パターンでA/Bテストを行います。差分はキャリア決済の選択可否のみです。
(加筆: 2018-05-31 10:30 JST) 本記事で紹介するのは新規登録するユーザーを対象にしたA/Bテストです。キャリア決済を利用中の既存ユーザーには影響のないよう配慮して実施しました。
A(既存動線): web の登録動線に「クレジットカード」「コンビニ」「キャリア」の3種別を表示する
B(新規動線): web の登録動線に「クレジットカード」「コンビニ」の2種別のみを表示する
法律の壁
このA/Bテストを実施するにあたって最も心配だったのが、法務部門によるストップがかかることでした。キャリア決済で支払いたいユーザーには不便を強いることは重々承知していましたが、それ以上に法的なリスクがあるのではないかと。
しかし、待ちに待った法務部門からの回答は「以下の2点を守れば実施可能」とのことでした。
- 特商法のページへ注意文言を追記すること
- CSへ問い合わせがあった時にキャリア決済できるフローを案内できること
A/Bテストができる… その事実は"歓喜の歌-An die Freude-"。
A/Bテストの実装
ここでようやくエンジニアがBパターンを実装した…と言いたいところですが、今回はエンジニアの実装の手間を一切かけることなく実現しました。
スタディサプリでは Optimizely というA/Bテストツールを導入しています。Optimizely は、訪問者のN%をA/Bパターンに割り振る設定、jQuery によるwebサイトの簡単なDOM操作、さらには成約（コンバージョン）とみなす条件の設定や計測までをも一気通貫して行うことができる高機能なツールです。
今回の「選択肢を1つ隠すだけ」のような操作とテストに必要な設定はすべて Optimizely の web console 上で完結しました。
この設定を行ってくれたのは当時のプロダクトマネージャー（以下、PM）の @a-tanaka717 で、先述した法務確認などの調整タスクも嫌な顔ひとつせずにやってくれました。テストの実施による一時的な売上減少のリスクにも歯を食いしばってOKを出してくれた彼をぜひMVPとして推薦したい気持ちです！
A/Bテストの実施
実施期間は2週間としました。平日と休日ではユーザーの行動が異なるため両方を含まなければならないこと、有意か否かを判定するための十分なサンプルを集められることを考えてこの期間を定めました。
CVRの変動結果
まず、CVRがどれだけ増減したのか、A/Bテストの結果をお見せします。
| パターン | クレジットカード | コンビニ | キャリア | 全体CV(人)(注3) | 全体CV比(%)(注4) |
|---|---|---|---|---|---|
| A (既存動線) | 814 | 73 | 113 | 1000 | 100.0 |
| B (新規動線) | 835 | 109 | 0 | 943 | 94.3 |
※ 注3) A(既存動線)パターンの全体CVを1,000人に調整しています。
※ 注4) 全体CV比はA(既存動線)パターンを100%としています。
見ての通り、駄目っ… B(新規動線)パターンの圧倒的敗北っ……！
キャリア決済を外した新規動線パターンの CVR は既存動線より低く、有意差もあり、クレジットカード・コンビニ決済への転換もあるがそれ以上に離脱の動きが目立つ結果となりました。
仮説1がこの時点で破れ、"I dreamed a dream." そんな言葉が頭をよぎりました。
売上・利益の試算
しかしまだ仮説2が正しい可能性はあります。
クレジットカード・コンビニ決済へ転換したぶんだけ手数料が軽減されているはずなので、この変更が利益に寄与しうるのです。ということでCVR差によりどれだけ利益の差が出るかを試算していきます。ちなみにこの試算はスタディサプリのデータ分析チーム*3が行ってくれました。
まず、既存動線パターンと新規動線パターンとのCV数の差と過去の実績からCVRの最小/最大範囲を推定*4します。
| パターン | 最小CVR (%) | 最大CVR (%) |
|---|---|---|
| A(既存動線) | 100.0 | 105.0 |
| B(新規動線) | 92.2 | 97.5 |
※ 注) A(既存動線)パターンの最小CVRを100%としています。
この計算によって CVR は最大12.8%、最小で2.5%の差が発生するということがわかりました。
次に、過去の獲得CVとシェアの実績を用いて両パターンでどれだけの売上と手数料の差額が発生するかを見てみます。（細かい計算が続くため過程を省略して結果をお見せします）
| ケース | 売上の増減 (百万円) | 手数料の削減 (百万円) | 利益 (百万円) |
|---|---|---|---|
| 最小の場合 | -18.3 | +10.8 | -7.5 |
| 最大の場合 | -95.1 | +13.5 | -81.6 |
つまり、キャリア決済をなくすと年間で数百万円程度の利益減に留まると想定されるが、それ以上に数千万円減少するリスクも想定されるという結論になり、仮説2も誤っていたことが検証されたのです。
このリスクを事業としては許容できず、キャリア決済はこれまで通り残すことになりました。
振り返り
かくして当初の仮説は否定され、スタディサプリではキャリア決済を残すことになりました。とはいえ機能の価値を確認するという目的を無事達成することができたこのA/Bテストの取り組みは決して無為ではありませんでした。得られた教訓を振り返ってみたいと思います。
今の我々は、"A/Bテスト"以後の世界に生きているのですから。
良かった点
- ぼんやりと「負債」だと捉えていた機能を感覚的にではなく事実に基づき数値で示すことで納得感が得られた
- これからは「負債」といわず、売上の一角を十分に担う「機能」と呼びたい
- 検証したい内容についてA/Bテストを実施し有意差を検定、さらにそれによるリスク幅の試算まで行い、結論を出すことができた
- Web エンジニアとデータエンジニア、PM、CSなど多様なポジションのメンバーが協力しながら実施できた
課題
- キャリア決済の抱える課題自体は残っている。将来的にはこちらも解消され、エンジニアの負担も低減されていってほしい
学んだこと
- 人は不本意な「機能」をしばしば「負債」と呼ぶ
- ファクトに基づいて分析するにあたり、A/Bテストはやはり協力な武器
- インパクトの大きそうな事案はもちろん、施策実施のための試算で行き詰まった場合、A/Bテストによって納得のいく検討ができる
- 統計的な考え方も合わせれば、確率や母集団の区間までも考慮できるので精度も高まっていく
以上、スタディサプリにおけるA/Bテストの取組みをご紹介しました。Quipper では "Fact based" なプロダクト開発に関心のあるエンジニア・デザイナーを募集しています!!
https://www.quipper.com/career/Japan/
ーーーTRUE ENDーーー