200万点のモノが登録される「Sumally」

山本　Sumallyのベースコンセプトは 「モノの百科事典」を作ることです。ユーザーはSumallyに「欲しいもの（Want）」と「持っているもの（Have）」を登録することができ、その数は現在200万点に上ります。

サービスを立ち上げた目的は、「人とモノの関係性を良くすること」です。世界中のモノの中から自分が好きなモノを知った上で、素敵なモノを選択できる。そんな状態が実現できるといいですね。

昨年、Sumally Pocketという新しい事業も開始しました。モノのDropBoxのようなサービスで、使っていないものを簡単に預けたり取り出したりできるサービスです。

アプリもしくはAmazonから専用のダンボール箱（1箱300円）を注文していただき、届いたらその箱に倉庫に預けておきたいアイテムを詰め、集荷の予約をして倉庫に送ります。

送ったものは倉庫内で撮影されて自動的にSumallyに登録され、アプリを使えば簡単に1点ずつ取り出すことも可能です。保管料は月額1箱あたり300円になります。

理想として考えているのは、ホテルのような快適な空間で必要な時だけ預けたモノを取り出して使うような暮らしです。そもそも何を持たない方がいいじゃん、という話になるかもしれませんが、お坊さんならともかくそれは少し寂しい部分もあるじゃないですか。

ミニマリストを否定するわけではないのですが、Sumally Pocketを使えば、空間を快適にした上で、モノとも素敵な関係性を築くことができるかな、と思っています。

コミュニティーを作るため、インフルエンサーから地道に声がけ

山本　Sumallyは2010年にリリースしたのですが、大規模な宣伝はせずに地道にヒーヒー言いながら成長させてきました（笑）。

Sumallyのようなコミュニティの場合、その中にどのような人がいるかが重要だと思います。集まっている人たちが作ってくれるコンテンツが、コミュニティの魅力になるわけじゃないですか。そのため、初期はインフルエンサーにできるだけ使ってもらい、Facebookのシェアなどによって少しずつターゲットにリーチしてユーザーを増やしていきました。

こだわりを持った人がそのこだわりをSumallyに登録してくれるように、最初はファッション業界の方やアーティスト、カメラマンといった方に声をかけましたね。

広告を打ってユーザーを獲得するという手段もあるとは思いますが、広告からは様々なユーザーが入ってくるので、コミュニティを作り上げることには向いていないと思います。

そのように地道に活動を続け、ある一定までユーザーが増えた時点から、日下部を中心に徹底的なデータ分析による改善を繰り返していきました。

「1兆の1,000万倍」点の販売データを扱った後、Sumallyに参画

日下部　以前は、ミスミという工場で使われる機械の部品をカタログ販売する会社にいました。前職のビジネスモデルは秀逸で、「半製品」という途中まで作っておいた形で在庫を持っておいて、お客様からの注文が入った後で「最終商品」に仕上げていくという部品の作り方をすることで、お客様の幅広いニーズに対応しつつ、高い収益性を実現できていました。

僕が担当していたカタログだけでも、載っている部品の種類は、なんと1兆の1,000万倍というとんでもない数です。その膨大な販売データから売れ筋を把握したり、自分の担当部品の需要を予測して在庫を補充したり、新商品を考えたりという仕事をしていましたので、自然と数字には強くなっていきました。

Sumallyには、創業期の2011年に山本に声をかけられて参画しました。それ依頼、データ分析、プロダクトマネージャー、広告の運用、契約書の取り回し、採用、などなど…たくさんの役割を担ってきました（笑）。

基本的にSumallyはスペシャリストの集まりなので、メンバーの皆さんが自分の専門性を活かせる仕事に集中してもらえるほど、チームとしての生産性が高くなると僕は思っています。でも会社や事業を運営する上では誰かがやらなくてはいけない業務が出てくるので、そこを全部拾ってきた感じです。

データドリブンの開発スタイルはユーザー数10万人を超えてから

日下部　Sumallyの特徴であるデータドリブンの開発スタイルは、ユーザー数が10万人超えてきたぐらいから試しはじめました。そもそもある程度ユーザー数がいないと、統計的に有意なデータが取れないので。

開発のフローを説明すると、まずAsanaというコミュニケーションツールに、各メンバーが改善したいことやアイデアをとにかく入れていきます。それを見ながら、開発工数とインパクトの掛け算で開発の優先順位を決定します。

そして、基本的には実装するものはすべて「狙い」を定義し、それが果たせたかどうかをデータで振り返ることができるように実装します。

機能を実装するだけの方が短期的には楽ですが、そこはエンジニアメンバーが結果を評価しやすいように僕ら解析担当が指定したデータを取れるように協力してくれるので、とても助かっています。

1〜2週間で狙い通りに機能したかどうか結果が出るので、チームに共有して振り返り「なぜ良かったのか」「なぜ悪かったのか」を議論して学習します。このフローをひたすら高速で回し続けているのがSumallyの開発です。

分析例：検索画面を改善したが、そもそも見られていないと判明

日下部　最近リリースした機能で、具体的にどう分析しているのかを説明します。今回は、iPhoneアプリで検索画面の下におすすめのキーワードを並べるような機能をリリースしました。

▼検索画面の下におすすめのキーワードが並ぶ機能を実装

この機能を作った主な狙いは、まだSumallyの楽しみ方を理解できていないような初心者の方に「こういうワードで検索するとSumallyの中で面白いものが見つかるよ」ということを教えてあげることで、Want/Have数と定着率を上げられないかというというものでした。

リリースしてから2週間ほど経った時に、さっと見れるGoogle Analyticsで検索画面の閲覧数をチェックして結構見られていることを確認。続けて、これは毎日自動で集計されるようになっているのですが、狙いであったサインアップした初日に「Want」「Have」を押してもらう確率の変化をチェックしました。

すると、思ったような結果が出ていない。じゃあその原因は何だ、と探っていくことにしました。

そこで、「ある日のサインアップの総数」と「その日にサインアップした人が、検索ボタンをタップした回数」を、SQLを書いてAmazon Redshiftにクエリを打って集計。すると、そもそも検索ボタンをタップしたユーザーは、初心者のうちわずか20％しかいなかったことが分かって、ここが原因だろうと。

Webサービスのデータ分析を担当する人は、機能をリリースしたら数字を見て、狙い通りに動いているかどうかを見ることはもちろんですが、何で上手くいったのか、何で思い通りいかなかったのかの理由を把握することが重要だと思っています。

理由を把握するには、実際のアプリやサービスを触りながら、「ここが怪しいな（ウケたな）」という勘所を見つけていくのがはじめの一歩で、それが合っているのかデータを集計して、裏付けを取っていくのが、地道ですが確実な方法かなと思っています。

データは「解釈」を添えて共有することが重要

日下部　あと「初心者の20％しか検索ボタンをタップしていない」という結果だけをチームに伝えるのでは、その20%が高いのか低いのか人によって解釈が違ってくる可能性がありますので、これだけだとチームに動いてもらうには不十分です。

実はこの施策はAndroidアプリで先行して実施していました。Androidの数字も同じように調べてきたところ、70%の初心者が検索をタップしていることがわかりました。そこで、その数字も添えて「iPhoneアプリでは初心者のうち『わずか』20%のユーザーしか見ていない」とチームには共有しました。

▼共有資料のイメージ

ちなみに、この「わずか」という言葉を入れるかどうかは、出てきた数字をただ伝えているだけなのか、それとも数字の解釈を付けて伝えるかの違いです。実行に移すデータ分析という意味では、とても大事なポイントだと思っています。どこのチームでも数字を読むというスキルだけで言えば、得意な人もいれば、そうでない人もいますので。

ともあれ、このように「わずか初心者の20%」というデータをチームに共有することで、検索部分に「ここを押すとはかどるよ」といったガイドを表示するなど、もっと目立たせてみては、というアイデアが出てきました。近々試していきます。

ただし、データを解釈を付けて共有した上で「どうしたら良いか」という仮説の部分は、皆さんの意見を募っています。前職でねじとか歯車を扱っていた僕よりも、Web経験が長いメンバーの引き出しの方が充実していますし。

デザイナーやエンジニアならではのアイデアで実際に数字が大きく伸びたこともたくさんありますので、今後もメンバーに皆さんからは積極的に施策案を出し続けてもらいたいですね。これを続けていけば、もっともっといいサービスに出来ると確信していますので。

ユーザー単位で細かく分析すると、施策につながる仮説を得られる

日下部　あとWebのデータ分析で重要なことは、1人ひとりのユーザーの動きをなるべく細かく見ることだと思います。使ってくださっているユーザーは人間なので「KPIがこう動いた」というマクロの動きを見るだけでは捉えることができず、改善のアイデアを出すことが難しいんです。

例えば「今月は「Want」数が5％下がりました」というマクロなデータだけでは、「なぜそれが起こったのか。どう改善したらいいのか」という次の施策につながる仮説は生まれません。「今月は正月だったので忙しかったんではないでしょうか」みたいな話になってしまう。

一方で、マクロな動きに加え、ミクロな動きも見ていけば、施策につながる仮説が生まれます。ミクロな動きを見るアプローチというのは、試しやすいところだとコホート分析、ユーザーを属性別に切ってデータを見ること。

「この層の人にはこの機能がすごく受けているんだけど、この層の人には受けてない」ということが分かると「じゃあそれってなぜそれが起きているんだろう。ひょっとして初心者には使いづらい機能なんじゃないか」という課題を得ることができて、その対策を考えることで次の施策につながりますよね。

これは極論かもしれませんが、施策につながらないデータ分析は、あまり意味が無いと思っています。そして、なるべく1人ひとりのユーザーの単位までアプローチした分析の方が良い施策が出る可能性が高いと僕は思っています。

ユーザーが好きなモノに出会える世界をデータドリブンで生み出す

山本　このようなデータドリブンの開発スタイルで追求していきたいのは、Sumallyへのアイテム登録数を増やすことというより、ユーザーが好きなアイテムに出会える精度を上げることです。

人が好きなものをわかった上でベストチョイスができる状態を作りたいので、200万を500万にするよりは、200万点の中で出会えてない「好きなモノ」に出会えるような仕組みを作りたいと思っています。そのためには、1％の改善を引き続き積み重ねていくのみです。（了）

▶SELECKにおけるデータ分析の手法を紹介した記事も公開中です。
新規Webサービスにおけるアクセス解析入門・その1【SELECKの事例を公開】

データは扱い方がすべて　データドリブン開発5つのポイント