Airbnb成功の要因はなにか？ ランサーズのプロデューサーが語る、“いいマーケットプレイス”の条件

海外旅行で現地のネット動向を調べる

木下慶氏：みなさん、こんばんは。木下と申します。

最初、自己紹介なんですけど。簡単な経歴を申しますと、もともとエンジニアのバックグラウンドでして。中学校の時にインターネットに出会って、インターネットすごいなと思って、情報工学とかそういうインターネットみたいなのを勉強できるところを探して、高等専門学校、高専に入学しました。

入学したんですけど、高専じゃインターネットが勉強できなくて。プログラミングとかをずっとやってたんですけど、それが逆におもしろくて。大学、大学院もずっとコンピューターサイエンスをやってた人間で、専門は画像処理とか画像認識というのをずっとやってました。

新卒でNTTデータという会社にSEで入って、企業のシステムを作ってました。ランサーズには4年前に入社しまして、最初プログラマーで入って開発をしていて。そこからインフラエンジニアに転向して、3年ほど前ぐらいにディレクターになって、今プロデューサーというかたちでサービス全体の企画とかを担当させていただいております。

インターネットが好きで、Web上で情報をいろいろ発信してるので、もしよろしければブログとかSNS全部「kkino0927」でやっているので、見ていただければと思います。Twitterは一番更新頻度が高くて、けっこうWebのトレンドとか発信してるので、よろしければフォローしてください。

旅行がすごい好きで。学生のころとか、あと社会人の最初とかはいろんな国に行って。とくに中国とかアジアがすごい好きで、バックパッカーをしてました。Swarmというアプリが好きで、ずっと使ってるんですけど。

（スクリーンを指して）チェックインしたところですね。実際、中国のなかとかもっと行ってたんですけど、（Swarmには）チェックインし忘れて入ってないんですけど。こういった旅行をしたりとかしていて。

インターネットが好きで旅行が好きということで、最近はインターネット動向を調べる、旅行に行くみたいな、両取りしている感じでやっていて。

（スクリーン）左側はサンフランシスコとかシリコンバレーに行って。左上がFacebookで、左下がAirbnbなんですけど。現地の方にプロダクトの作り方とか聞いて、あとで話出るんですけど、プロダクトマネージメントの話を仕入れたりとか。

右は、好きな中国に行って、中国けっこう今O2Oアプリとかデリバリー系とか流行っているので、実際に現地で使ったりして。ユーザーさんのヒアリングをやっていたりしました。

これで自己紹介は終わりなんですけど、今日の話が大きく2つあって。1つが最初、サービス企画のプロセスですね。マッチングサービスというよりは一般的なWebサービスの作り方で、「弊社ではこうしてます」というお話。2点目に、マッチングサービス固有の話をできたらなと思っています。

最初に改善点を決める

最初、（ランサーズの）体制なんですけど、けっこう人が増えたりとかするので、変わることもあるんですけど。

ランサーズは1つのサービスを運営してるんですけれども、けっこう大きいサービスです。エンジニア、ディレクター、デザイナーといったクリエイターが関わっていて、プロジェクト別にチームをわけてます。

各プロジェクトがミッションをもっていて、そのミッションを負うチームというので、職種関係なく一緒にやってます。ディレクターがチームによって1人いたり2人いたり、エンジニアもチームによってまちまちなんですけど。デザイナーとインフラに関しては全チーム横断というかたちで、こういう体制でやらせていただいております。

この3つの職種の役割分担なんですけど、まずディレクターが最初に分析して、なにをやるか企画して、UI画面を実際に設計して。ここからデザイナーとも話しながらやっていくところですね。そのあと、デザイナーが実際にビジュアルデザインをして。HTMLコーディングまで、デザイナーがやっています。

そのあと、エンジニアが開発してリリースして、またディレクターに戻ってきて、モニタリングして、よかったら「よかったね」とか、悪かったらどこが悪かったか分析して、また改善して、PDCAを回しているというような役割分担になってます。

使ってるコミュニケーションツールは、けっこう一般的なやつで。ドキュメントはAtlassianのConfluenceにまとめていて、あとは必要に応じてGoogle DriveのDocsとかSpread Sheetとかを使ってます。チャットはChatWorkを使っています。

プロセスは、案件によっていろいろ進め方が違ったりするんですけど、よくあるプロセスについて。

1つ目が注力ポイント。まず、どこを改善するのか、どこをよくしたいのかを決めています。30人ぐらいいるんですけど、やっぱりサービスが大きくて、全部はできないので。一応、ここを注力しようと、優先度を決めるところをやってます。分析のところですね。

そのあと、そこに対してどういった打ち手があるのかというところの仮設の設定であるとか、あと仮設の検証ですね。いきなり開発とかするのではなくて、その仮説を検証するみたいなことをやっていて。それで、よさそうだったら開発して、そのあとモニタリングして、PDCAを回してやってます。

ディレクターがSQLを叩けることを重視

いくつかご説明させていただきます。注力ポイントの選定というところは、まずサービスがけっこうでかくて複雑なんですけど、いったん全部モデル化して、KPIツリーみたいのを作って、最終的なゴール指標というのを分解していくとどうなるのかというのを書いて、それぞれの数字を全部取ります。

（スクリーンを指して）これはまだ一部なんですけど、こんなかたちになってて。さらにこの下に、ずっと細かい資料が続いていくというかたちです。

例としてこういったものが。いろんな数字を取ってみたところ、「2ステップ目でめっちゃ落ちてます」みたいになったら、「じゃあ、今回ここを改善しよう」みたいなかたちで、ここをよくする施策をこのあと仮設検証のところでやっていくという流れになっています。

これ、例えばクライアント側の動きですね。数字とかはぜんぜん適当なんですけど、サイトに来たクライアントが実際にどのぐらい登録してくれて、登録したあとどれぐらい依頼してくれて、依頼がどのぐらい終わるのかというところで。

この減衰を見ると、「登録はしてくれたら、だいたい依頼して完了する」というのは見えるんですけど、「（サイトに）来ても、登録してない」みたいなところでだいぶ落ちてるので、この場合だったら「まず、登録をどうにか増やそう」みたいな施策を、ガッと注力してやっていくというような進め方をしています。

そこに対して仮説をいくつか設定して、それを検証するんですけど、その仮説設定のところは飛ばさせていただいて、「どうやって検証してるの？」とか「どうやって開発してるの？」というところの話をさせていただきます。

なるべく工数をかけないで、細分化して開発を減らすみたいなことを方針としていて。できれば、開発しないで検証できて……。理想は、開発しないでも伸びるみたいなのが一番いいと思ってるんですけど。開発するパターンと開発しないパターンというのがあって。開発しないパターンはデータ検証してみたりとか、あとオペレーション。今日、これは後ほど説明させていただくんですけど、人力で回してみたりとか。

あとはユーザーにヒアリングして、作る前にユーザーさんの声を聞いてみるということなどをやってます。「よさそうだね」となった時は開発するんですけど、いきなり全部開発せずにフェーズを切ったりとか。小さくリリースしていけるものはなるべく小さくして、リリースしていくというような方法を取ってます。

データ検証のところなんですけど、ここにけっこう1つこだわってるポイントがあります。よく見るデータとかを管理画面化して、ブラウザから誰でも見れるようにしていますが、仮説検証する時は、今まで取っていないデータを見たいということが多いので、管理画面にない指標というのが多くて。その場合、どうしても生データを取りにいくみたいなかたちになります。

SQLをエンジニアじゃなくても、叩けるようにしているのが1つあって。ディレクターとか、エンジニアのバックグラウンドがなくても、環境整備してもらったり、勉強してもらったり。あと、もともとエンジニアじゃなかったんですけど、けっこうSQL叩けるディレクターがいるので、その人がドキュメント整備してくれたり、周りに教えてくれたりとかして。ディレクターがSQLでデータが取れるみたいなことを整備してます。

この理由が2つあって。1つは、まずスピードが上がるというところですね。データを取ってくれる人にディレクターがお願いすると、人と人のコミュニケーションが間に介在するのでスピードが落ちますよね。

あと精度と書いてあるところは、けっこうみなさんもご経験あるかもしれないですけど、仮説設定した時にそれを検証するデータを取りたい場合、言葉で伝えてもずれちゃうことがあります。仮説は自分が持ってるから自分でデータ取って、違ったら修正して何度も取るみたいなことが、けっこう大事だと思っています。そこで、人を介すと精度が落ちちゃうかなというところで。自分でSQLを叩けるというのは、けっこう重視しています。

ムダな開発を発生させないために

あとは、GAや、どうしても取れないものはアプリケーションで、ログ吐いたりして取るようにしています。

（スクリーンを指して）オペレーションと書いてあるやつなんですけど、これはなにかと申しますと、機能開発をせずに、人力で機能開発したのと同じような変化をサービスに生んで、それで検証するみたいなものです。

説明させていただきたいんですけれども、これ実際にやったものなんですけど、クライアントが依頼を作る時に、とある情報があったほうがランサーさんとのマッチング精度が上がるんじゃないかなという仮説があったんですね。

ふつうに実現しようと思ったら、左の依頼作成ページのところで、フォームを作ってABCとか選んでもらって、それが出る。そうすると、依頼作成ページ直さなきゃいけなかったりとかするんですけど。もし、やってみてあんまり意味なかったら、ムダな項目をクライアントさんに選ばせちゃうし、取り下げなきゃいけないし、工数も2倍かかるよねというので、右のようにやりました。

実際にやったのが開発せずに、依頼作成されたら人力で人が目で見て「これはAだ」とか、左の選択肢ABCの分類を人がやって、それを依頼ページにピッとつけるという。これによって、開発はもちろん発生しなかったのと……。実際にこれ、残念ながら効果があんまりなくて、実装しなかったんですけど、不幸中の幸いと申しますか、右側の方法でやってたので、ムダな開発が発生しなかったというような事例になってます。

最後、モニタリング・PDCAのところに関しては、先ほどデータ検証のところで出したようなSQLとかGAとかいろんなデータを取って、Excelとか必要に応じて加工したりしてるんですけど。

Spread Sheetにおいて見たい場合は見れる状態にしてるんですけど、とくに重要な指標というのはディスプレイに常に出ている状態になっていて。見に行かなくても見えるし、ずっと出ていることによって、みんなが気にかけてくれるみたいな状態を作っています。

あとは、プロセスの一部かもしれないですけど、振り返りをしっかりするというのを文化にしていて。大きなプロジェクトとか月の終わりとか節目に振り返りをやるようにしてます。これは、プロジェクトとかに関わってるディレクター、エンジニア、みんな参加して、基本的にはディレクターが呼びかけることが多いんですけど、やってます。

KPTの方式でやっていて、全員にKeep＝よかったこと・続けたいことと、Problem＝問題だったことと、そのProblemに対してのTry＝どうしたらよくなるかみたいなところを書いてもらってます。事前に書いてもらって最後ミーティングするんですけど、ミーティングのなかでもいくつか出てきたら追加したりして。Tryを数個選んで、次のプロジェクトとか翌月に実践するというのをしています。

Tryを数個というのは、けっこうミソだと思っていて。どうしてもいっぱい出てくると、全部改善したいとなるんですけど。基本的には全部やろうと思ってもできないというのが、僕の実体験であって。全部やりたいというところも、いくつかしぼって3つとか、確実にやれるよねというのをしぼる。

あとは、しぼったものに対して担当者を明確にするというのと。Next Actionですね。「そのTryを、誰がいつまでになにするの？」というのを明確にすると、けっこう上がって。1回目だと3つかもしれないですけど、2回、3回とやっていけば6個、9個と増えていくので、おすすめの方法です。

ランサーズは“マーケットプレイス”の側面が強い

それで、マッチングサービスの話ですね。マッチングサービスとはなにかと申しますと、これは僕の解釈なんですけど、2種類のユーザーがいて、それをつなぐ・マッチングするという、そのままなんですけど。それで、特定のアクションでつなぐというものなのかなと思っていて。

けっこういろんなサービスが、ほとんどマッチングサービスだと思ってます。例えばECだったら、買う人とお店を購入というアクションでつないでいるし。このあと登壇されるPairsさんであれば、男性が女性に「いいね」すれば、女性が男性に「いいね」することでつながるし。ランサーズであれば、仕事が依頼されるみたいなところでつながるサービスかなと思ってます。

あと、マーケットプレイスという話があると思うんですけど、これもマッチングサービスとニアリーイコールというか、同じような概念なのかなと思ってます。

ランサーズも、昔はクラウドソーシングという言葉が今ほどは知られてなかったので、昔は仕事マーケットプレイスと言ってたんですけど。今はもうクラウドソーシングに変えました。なので、ランサーズもけっこうマーケットプレイスの側面が強いので、マーケットプレイスとして考えたらどうかという話をさせていただきたいと思います。

『A Guide to MARKETPLACES』というハンドブックがあって。

最近出たんで最近知ったんですけど、僕4年ぐらいランサーズやってて、マーケットプレイス4年やってて、これ読んだ時にここに書いてあることがほとんどそのとおりだなと思ったのと。自分がまだ思ってないことでも、書いてあることやってみたり、データ見てみるとけっこう参考になるなというのがあったので。これをベースに、今日はお話させていただきたいなと思ってます。

Version OneというVCがアメリカにあるんですけど、そこのVCがマーケットプレイスにけっこう出資していて、その創業者の方が書かれたハンドブックになってます。

創業者の方が自身でも古本のマーケットプレイスを立ち上げていて、2008年にAmazonに売却しているという。自身もマーケットプレイスの知見があるし、多くのマーケットプレイスに出資しているし、マーケットプレイスのスペシャリストみたいな人たちの集団ですね。

中身が「いいマーケットプレイスとはなんなのか？」とか、「成長のためにやるべきことはなんなのか？」とか、あと「マーケットプレイスとして見るべきKPI」みたいなのが。売り手と買い手、そのダブルターゲットそれぞれに対して、それぞれ「この指標を見ましょう」というのが、けっこう詳細に書かれています。

Airbnbはなぜうまくいった？

いくつか、かいつまんでご紹介させていただきます。1つがまず、マーケットプレイスの成長ステップというやつです。3つ書かれていて、「立ち上げ」と「成長」と「スケール」みたいなところを、それぞれランサーズの事例とか他社の事例で説明させていただきます。

「立ち上げ」のところは、他社の事例で恐縮なんですけど、まずマーケットプレイスの一番の課題は、鶏・卵問題みたいな。ユーザーがダブルターゲットなので、どっちのユーザーを集めていきますかというのがあるんですけど。

この本は、基本的に「供給サイド・売り手をまず集めましょう」ということを言ってます。Uberで言えばドライバーですし、Airbnbで言えばホストですね。そもそも車がなければUber使えないですし、泊まるところがなければAirbnbは使えないので、まず売り手を集めましょうと言ってます。

売り手集めたあとに買い手を集めないといけないんですけど、その時の有効な手段としては、「売り手が売るものをユニークなものにしましょう」と言っていて。例えばeBayがずっとあったところにEtsyが出てきて。EtsyはハンドメイドというのがeBayに対して圧倒的な差別化だったので、そっちで集まりましたとか。

あとAirbnbも（スクリーンを指して）これは船なんですけど、見られた方はわかると思うんですけど、けっこう変わったおもしろい家があって。ホテルに泊まるとか、普通じゃ体験できないところがあって、それが買い手をひきつける。それで買い手が来るので、また売り手が集まるみたいな最初の立ち上げができますよということが書かれてます。

2個目の「成長」というところですね。「うまくいってる部分を伸ばす」というやつなんですけど。

この本に載っていた事例として、Airbnbがまた出てくるんですけど。Airbnbも最初ニューヨークがけっこう回り始めたらしいんですよね。やっぱり観光客が多いとか、人が多いとか物件も多いとかで。

さらに、物件の写真がきれいなほど予約が入るというのがあったので、創業者自らがけっこう高いカメラをレンタルして、ニューヨークに毎週行って、ニューヨークで出してる物件の全部写真を撮ってあげて変えたというのがあって。その結果、ニューヨークの予約数が2倍、3倍とかになったので。そのエッセンスというのをほかの都市に展開して、伸びていったというのがポイントです。

いいマーケットプレイスは、この3つのコストが低い

最後、「スケール」のところなんですけど、スケールしてくるといろんな人が入ってくるので、マーケットプレイスとして安全などを担保する必要がありますよねという話と。マーケットプレイスは売り手と買い手がいるんですけど、やっぱり売り手がいるから買い手が来るというところがあって。パワーセラーと書いてあるのは、売り手のなかでもさらに優良な人ですね。この人をいかにひきつけるかというところ。

あとは流出。優良な人がいなくならないというのもそうですし。1度マッチングすると、マーケットプレイスを介さなくていいという話が出てきちゃったりするので、そういうマーケットプレイス外の取引にいかないような施策というのがスケール段階で必要になってきますという話があります。

いいユーザーの見える化というのは結構事例があって、例えば左上のAirbnbだとスーパーホストというのがあって。けっこう僕らと似てるんですけど、定量的な基準で、ある程度基準を満たすとバッジがつくだとか。

あと、右下はeBayでずっとあるやつですね。パワーセラーと言われてる。3段階あるんですけど、そのなかのトップレイテッドセラーというやつですね。これも同じようにプロフィールにバッジがついたりとか、手数料か送料かなにかが優遇があるというようなことも、他社さんけっこうやってます。

この本、ほかにもいろいろ書いてあるんですけど、時間の都合で最後になるんですけど。「いいマーケットプレイスは、この3つのコストが低い」と言ってます。

1つは「検索」です。売り手と買い手が出会うコストが低いということ。2つ目は、実際に出会ったあとに取り引きをするコストが低いこと。あとは交渉ですね。なにかもめごとが起きた場合に解決するとか、イレギュラーな交渉が起きた場合の交渉コストが低い。これらが低いと、いいマーケットプレイスですよねと言ってます。

最後にプロダクトマネージャーという話で。僕らが今注力しているプロダクトマネージメントみたいなところの話をご紹介させていただきたいんですけど。プロダクトマネージャーという職種の方、今日いらっしゃいますか。最近けっこう盛り上がってるなと思ってるんですけど。

（会場挙手）

ありがとうございます。けっこう最近増えてきて。僕らもWantedlyとかで（募集を）出したんですけど。去年に左の（伊藤）直也さんのブログに書かれたりとか、この前NewsPicksで須藤憲司さんが連載されたやつのなかにも、6回目とかにプロダクトマネージメントの話とかが出てきて。さっきWantedlyで検索してみたんですけど、プロダクトマネージャーで今206件求人が出てるというかたちで。けっこう盛り上がってきてます。

プロダクトマネージャーとして成長するために

プロダクトマネージャーがなにかと説明すると時間が足りないので、ここでは説明できないんですけど、（スクリーンを指して）この図が僕はすごい好きで。

これ、見る人によってプロダクトマネージャーは違いますという図なんですけど。IDEOというデザインファームのプロダクトマネージャーの方が書かれた、ブログに載ってたやつですね。

人によっては真ん中の、お母さんとかはけっこうスティーブ・ジョブズみたいにかっこいい仕事やってると思ってたりとか。左下は同僚ですね。プロダクトマネージャーは、けっこういろんな雑務をやってたりとかするので、同僚からするとなにやってるのかわからないというか、新聞読んでるように見えたりとか。

下の真ん中は、自分で思ってるやつですね。けっこう危機一髪のところを救ったスーパーマンだと自分で思ってるみたいなんですけど、実際には右下のところで。首の取れた鶏で走り回ってるみたいな状態で、けっこうこれは的を射てるんじゃないかなと個人的に思っています。

最後、参考書なんですけど、ここで説明しきれなかったので、もし興味ある方は見ていただければと思うんですけれども。左上にあるPMJPというのが、プロダクトマネージャーのコミュニティですね。これがこの前、立ち上がって。SlackとGitのコミュニティがあって、Slackのほうがとくに議論が流れる時は流れていて、かなりおもしろいので、読むだけでもすごい勉強になるかなと思います。

あと、書籍もいくつか出ていて。いろんなものがあるんですけど、僕のおすすめはこの『INSPIRED』というやつで。これはプロダクトマネージャーとしてやるべきこととか、心構えみたいなものが全体的に書いてあるいい本なので、ぜひ読んでみてください。

最後、Medium。海外の人は、けっこう今mediumに書いてるっぽくて。「Medium product management」で検索すると、めちゃくちゃいい記事が出てきます。英語なので大変なんですけど、読んでおくと情報も早いですし、あんまり日本じゃまだ議論されていないようなこととかも出てくるので、おすすめです。

以上になります。ありがとうございます。