ランサーズ(Lancers)エンジニアブログ > DevOps > 具体例で見るユーザーファーストなプロダクト改善プロセス

具体例で見るユーザーファーストなプロダクト改善プロセス

adachin|2017年11月30日
DevOps

こんにちは。「ランサーズ」というサービスのプロダクトマネージャーをしております、新卒2年目の齋藤です。
独学でUIデザインを学んでおり、部署は違いますが、このユーザーファーストデザイン室にもこっそり参加している人間です。

今日はデザインの話から少し遠くなりますが、「ユーザーファースト」なプロダクト改善について思っていることをまとめてみます。

何も具体例がないまま書いてもなかなか想像しにくいかと思いますので、今回は数週間前にリリースしました「あしあと機能」を例に挙げてお話しします。

あしあと機能とは

読者の方の中にはランサーズを使ったことがない方もいらっしゃるかと思いますので、あしあと機能について軽くご説明します。

ランサーズには「ランサー(受注側)」「クライアント(発注側)」の二方向のユーザーがいます。
あしあと機能とは、ランサーのプロフィールを閲覧したクライアントの履歴を、ランサーに対して表示する機能です。
あしあと機能と聞くと、某SNSを連想される方も多いのではないでしょうか。

ユーザーへの価値提供を最速にする

とにかくユーザーへの価値提供が最優先です。
僕も細かいインタラクションなどこだわりたい派ですが、ぐっとこらえて、まずは出すことを最優先に考えています。

このあしあと機能の開発でも、最速で価値提供するために「データベースに新規テーブルを作らず、既に取得しているアクセスログデータを応用する」「本当は全履歴一覧ページをつくるといいかもしれないが、まずは直近5件のみ表示する」etc…といったことをしました。

データの持ち方をリリース後のKPIモニタリングに少し時間がかかるなどトレードオフな側面も多分にありますが、出さずに価値提供していない状態より1728612987倍良いです。

ただし、最速で出す上で
1)ユーザーに提供する価値の最低ラインを満たしていない(課題を解決していない)
2)仮説の検証ができない(サンプル数が不足するような表示ロジックなど)
といったケースについては注意が必要です。

仮説を明確にする

当たり前ですが、日々並行して様々な施策を打っていると意外と曖昧になりがちなところではないでしょうか。
上記でも述べましたが、最速で出しても学びがなければ意味がありません。

このあしあと機能も、社内で話を出したときには「サイト上に活発感が出るからいいね!」「SNS感出ていいよね!」といった声をもらうことが多々でした。
まだリリースもしていないのに社内での評判がうなぎ登りになっていくあしあと機能…

しかし、この機能の仮説はより実際のKPIに結びつくところにありました。
これまでランサー(受注側)は仕事検索ページから能動的に仕事起点で仕事をさがすというルートしかありませんでした。
そこで、ランサーが「人起点」で仕事をさがす世界があっても良いのではないか?そのルートのほうがマッチング率が高いのではないか?という上段の仮説の下、様々な詳細仮説を立て、そのうちの一つとしてこの機能をリリースしました。
なので、仮説に基づき、ステークホルダーからの声があっても逆方向のあしあとはあえて表示しない仕様にしています。
また、上記の仮説の下準備として、クライアント(発注側)のプロフィールに募集中の仕事一覧を表示させるという施策でフィジビリティも取り、仮説の確度を上げた上で検証しました。

重要なのは、ユーザーやステークホルダーから色々な期待・要望が寄せられても仮説・課題の定義をブレさせないことだと考えています。

ユーザーの声を拾いにいく

ユーザーへのそれぞれの価値提供の前後どちらでも、能動的に声を拾いにいくことは非常に大切です。僕は一度、ユーザーさんと飲みに行き、そのまま仲良くなってお宅に泊まらせていただいたことがあります。笑
このようなシチュエーションはあまりないことなので再現性は低いかもしれないですが、実際にユーザーがプロダクトを使用している場を目の前で見ることには多くの学びがあり、おすすめです。
実際、あしあと機能とその後の構想も、その時に課題と仮説が明確化しリリースに至ったという側面もありました。

また、施策リリース後もデータだけでなくTwitterや各種ユーザーミートアップイベントで定性的な声を聞きに行っています。ただし、ユーザーの声をそのまま反映することが「ユーザーファースト」ではありません。そこから課題を抽出し次の仮説に結びつけていくという意識が重要です。ユーザーの声を「聞きにいく」のではなく「拾いにいく」感覚が近いかもしれません。

まとめ

いかがでしたでしょうか。
「ユーザーファースト」というと人によって定義がブレてしまうかと思います。チームで上記のように定義をすり合わせておくと向かう先、そこへの向かい方が明確になるかもしれません。
今回生まれて初めてブログというものを書いたので拙かったかもしれませんが、これを機に引き続き「ユーザーファーストなプロダクト作り」についてアウトプットしていきたいと思います。