12015/12/02に行われたThink user first #2での発表資料です。

1. フリルの機能改善における
仮説と検証
株式会社Fablic
山口 有由希

2. 自己紹介
山口 有由希
Designer
2013年まで福岡でデザイナー
2014年1月に上京し、Fablicに入社。
手と頭を動かすのが大好きなデザイナーです。
twitter:@yuki930 / FB:yuki.0930
や ま ぐ ち ゆ う き

3. Fablicについて
• 2012年に設立
• ファッションフリマアプリ
「フリル」の開発/運営
• 振り返ればユーザーがいる
開発環境が特徴

4. 機能改善における仮説と検証

5. Fablicの機能改善のプロセス
問題の洗い出し 問題の精査 課題の設定
仮説を立てる
UIの検証実装／リリース検証

6. 評価機能の
改善について
Before

7. 問題の洗い出し
問題の洗い出し 問題の精査 課題の設定
仮説を立てる
UIの検証実装／リリース検証

8. 問題の洗い出し
定性的
• カスタマーサポートにヒアリング
• 社内ユーザーへのインタビューの実施
• 過去のアンケート結果の確認
定量的
• これまでの評価の内容の精査

9. 問題の洗い出し
カスタマーサポートへのヒアリング
• 【お問い合わせ】「よいコメントが書いてあるのに
評価が わるい"になっていた。評価を変更してほし
い」
• 【退会理由】「いままですべてよい評価をもらって
いたのにふつうをつけられた、フリルを辞めたい」

10. 問題の洗い出し

11. 問題の洗い出し
ユーザーインタビューの実施
• 「使っているうちにフリルでは特になにも問題なければ よい を
つけるのが普通なんだなとわかってきた」
• 「初心者ユーザーが特に問題のない取引で ふつう をつけてきたこ
とがあり傷ついた」
• 「そのふつう評価が目立ってつらい」
• 「そもそもどのレベルで満足すれば よい なのか？
基準が人によって違う」

12. 問題の洗い出し
過去のアンケート結果の確認
過去のアンケート結果より
「評価」についてまとめられたもの

13. 問題の洗い出し
これらをもとに、実際の評価のデータを集計
• 過去のそれぞれの評価の割合の調査
• ふつう／わるいをつけたユーザーは具体的にどのよ
うな内容で評価をつけたのかのデータを集めて分析

14. 問題の洗い出し
それぞれの評価の件数をもとに割合を算出

15. よい評価の文面なのにわるいに
なっていると思われる評価が
5%もあった
わるい評価の内容の精査
問題の洗い出し

16. 問題の洗い出し
取引の内容に満足しており
内容としては特に問題なさそうだが、
ふつう評価となっている評価
ふつう評価の内容の精査

17. 問題の精査
問題の洗い出し 問題の精査 課題の設定
仮説を立てる
UIの検証実装／リリース検証

18. 問題の精査
• 全体の評価数における「ふつう／わるいの評価数」は
そもそも少ない
• 少ないからこそわるいの評価／ふつうの評価を
受けた時のユーザーが感じるインパクトは非常に大きい
• ユーザー間の「ふつう」「わるい」への価値観の違いが
ある
• わるい評価をつけているうちの約5%が「よい評価」のコ
メントを投稿しているのに「わるい」になっていた

19. 課題の設定
問題の洗い出し 問題の精査 課題の設定
仮説を立てる
UIの検証実装／リリース検証

20. 課題の設定
• 評価の価値観を統一することでふつう評価がつく
ことを減らす
• 間違った悪いの評価を0にする

21. 問題の精査
問題の洗い出し 問題の精査 課題の設定
仮説を立てる
UIの検証実装検証

22. 仮説を立てる
• タップできる領域が近く、スクロール時などに誤
タップしやすい作りになっているのではないか
• 良い/普通/悪いと表記していたので良いと悪いを
見間違えている可能性はないか？
• 評価の一覧では晴れ／曇／雨マークで評価を表
しているが、評価ページではわかるようなビジュ
アルすらなく、評価の基準もまったく明示できて
いないことが原因ではないか？

23. 仮説を立てる
• 項目を選択した時、その評価の基準を出してあげればわかりやすいのではないか
• わるい評価を選択した時、そもそもすぐに解決してあげられるようにお問い合わせへの動線を出してはどうか

24. UIの検証
問題の洗い出し 問題の精査 課題の設定
仮説を立てる
UIの検証実装／リリース検証

25. UIの検証

26. 実装／リリース
問題の洗い出し 問題の精査 課題の設定
仮説を立てる
UIの検証実装／リリース検証

27. 問題の精査
問題の洗い出し 問題の精査 課題の設定
仮説を立てる
UIの検証実装／リリース検証

28. 今回の課題のおさらい
• 評価の価値観を統一することでふつう評価がつく
ことを減らす
• 間違った悪いの評価を0にする

29. 改善後の効果検証
ふつうとわるい評価の割合の変化
価値観の統一の検証

30. 改善後の効果検証
よいと思われる内容でふつう評価をしているコメントの減少を目視で確認
価値観の統一の検証

31. 改善後の効果検証
間違った悪いのレビューを0に
• 間違ったわるいのレビューの
判断には目視による内容確認が必要
• 「ありがとうございました」などの
お礼のメッセージと思われる文言を
含む悪いの評価が投稿されたらslack
に通知
• 変更以降、間違ってわるいをつけた
と思われる評価がほぼ0になり改善が
みられた

32. Fablicの機能改善のプロセスのおさらい
問題の洗い出し 問題の精査 課題の設定
仮説を立てる
UIの検証実装検証
効果が見られなかった時

33. 改善プロセスをまわす上で
気をつけている3大ポイント

34. これだけやっていると時間かかりがち…
問題の洗い出しはすばやく、でもしっかり。
• 過去のアンケートを確認したり、社内のユーザーイン
タビューを通してヒントとなる情報をすばやく集める
• これらの情報を元に実際のデータを確認
定量的な情報をプラスして問題の本質をみきわめる

35. 調査、調査ってなにも進んでない感ある…
まとめは常にチーム全体に見える化
• Fablicではqiita:teamを使い、情報共有
• 異なる視点から意見をもらえたり、分析を手伝って
もらえたり
• 残しておけば次の改善／機能開発のヒントに
なるとこも多々

36. 調べまくった問題、全部解決したーーーーーーい！
仮説はちいさく早く試せるものから
• 問題点を洗い出すとあれも直したい、これも直
したいとなりがち
• 小さく試せてインパクトのあることから一つず
つスピーディーに検証する

37. 素早く改善サイクルを回して
ユーザーに価値あるものを
より多く、スピーディーに

38. ご清聴ありがとうございました
Fablicではユーザーのいる環境で一緒に開発したい人を大募集しております！