プロダクト開発部のエンジニアの大平 (@kokitecture)です。
最近は散歩する時に、わざとゆっくり歩くのにハマってます、なんとなく気持ちが落ち着きます。
この記事は Lancers Advent Calendar の14日目の記事です。
昨日は友利さんの「トピックモデルでランサーズのデータを文書分類をしてみる」でした。機械学習に疎い自分としては、流石友利さんって感じでした。
はじめに
自分は下期から、施策の課題策定からリリース、結果分析までの一通りの作業を担当させて頂いています。
この記事ではその中で学んだ3つのことを共有したいと思います。今思えば当たり前のことが多いですが、反省も含めてどなたかの参考になれば幸いです。
1. 大通りから攻める、がそこは本当に大通りか？
ここでの内容は、課題策定や施策考案する上での行動原理のような話です。
課題分析や施策考案する上で、重視すべき指標の1つとして「そこが大通りかどうか」は認識すべきだと考えています。
ここで言う「大通り」とは、サービスにおける重要な機能や画面のことを指しています。
そこに力を加える方が効率的だと考えているので、この指標を意識しながら分析や設計などを行なっていました。
参考
・#13 神は順序に宿る
・グロースの逆説 : メルカリで分析とサービスグロースをやる前に知りたかったこと
ですが、、
それらを認識しつつも、自分は「大通り」を勘違いしていました。なのでそれに関して反省も含めた学びをここに共有します。
① 「入り口」が1番の大通りとは限らない
自分が企画考案し始めた時、まず提案したのがパッケージトップページのUI改善でした。理由はトップページであり、ユーザーはそこを起点に流入していると考えていたからです。
しかし、実際のPVを確認してみると、トップページはパッケージ関連のページの中でもPVは多いほうではあるが、それよりもPVの多いページはいくつかありました。
「入り口」が1番の大通りと言うわけではなく、その先にユーザーの関心が高いページがあったのです。
大通りかどうかは、ユーザーの行動・事実ベースで判断すべき、だと言うことを学びました。
② 「全体の」大通りかどうか
次に、上記の学びを踏まえてパッケージ関連のページでPVの多い (大通りの)画面の課題解決を考え始めました。
しかし、いくつかの分析とチームと会話する上であることに気づきました。
自分が提案したページは、パッケージ関連においてはPVが多い方でしたが、プラットフォーム全体を見渡すと同程度のPVのページはいくつかありました。
「大通り」と言っても、基準をどこに置くかで判断が変わるということです。時には全体を俯瞰して比較することも大事そうです。
まとめ
ここでの話をまとめると以下について学びました。
- 大通りは事実ベースで確認すること
- 大通りを何を基準とするかで判断が変わること
今後も施策を検討する上ではこの学びを活かしつつ、そこが大通りかどうか判断していこうと思います。
2. その判断は正確か、数字の構成と奥行き
ここでの内容は主に数字の正確性についてです。
企画考案・設計をする際に、クエリを書いた分析をよく行います。日々クエリを書いている中で、少し数字の見方を知ったので、ここではその学びについて振り返ります。
ただ書いていて説明が難しかったので、ここでは「ECサイトにおける検索」という具体例を使って説明しようと思います。
① 数字の構成について
例えば、「検索したユーザーが商品を閲覧する割合」を明らかにしたいとします。その時に「検索結果一覧」→「商品」への遷移率が50%だったとします。
高い数字ではないので、この数字から「検索結果に課題がある」と判断できるでしょうか？
個人的にはこの数字だけを見て判断するのは賢明ではないと考えていて、その数字が何で構成されているのか、もう一歩先を明らかにしてから判断すべき、だと今は考えています。
この場合だと「検索したユーザー」の構成をもう少し詳細にできそうです。
これを見ると「検索結果に課題がある」と言うよりは、「画面Aからのユーザーには需要が低い」といった判断ができそうです。
こういった形で、データの構成を明確にすることで判断が変わる、と言ったことを学びました。
② 数字の奥行きについて
続いて、先ほど「画面Aからの検索ユーザー」の閲覧率の改善に取り組むとした時、次はどんな数字を明らかにすべきでしょうか。
いくつか候補はあると思いますが、その1つとして「検索回数」があると考えています。
上記の場合、画面Aのユーザーに対して「需要が低い」という判断から
「需要は高いが、どんな文言で検索すれば分かっていなそう」などの仮説が挙げられそうです。
このように「xxの数字が低い」と言った場合でも、その行動の回数や頻度といった数字の奥行きまで考慮すると、解像度や判断基準が変わってくる、ということを学びました。
まとめ
ここでの話をまとめると以下について学びました。
- 数字は、その構成まで明らかにすることで判断が変わる
- 数字は、その奥行きまで考慮することで判断が変わる
恐らくもっと見るべきステータスや構造などは色々あると思います。これからも色々と手を動かして気づきや学びを得て行きたいと考えています。
3. やっぱり最高か最速か
ここで書く内容は半ば感想のような話です。
アジャイル開発 / MVP / やっていき、と何かと物事を実行する妥当性とその「速さ」について語られることが多い気がします。
Lancersの行動指針、LWayの1つにも「アクション・アジャイル」というものが含まれています。(少し前は「最高か最速か」というものがありました)
始めは「速さ」の重要性について理解できていませんでしたが、今期から色々担当するに当たり「なぜ重要か」が少し理解できたので共有します。
① 土台がないことには会話が生まれない
自分が企画考案し始めた時、正直はじめの方は (今でも?)色々と解像度が低く、的が外れていたものも多かったと思います。
それに対してはチームからFBを頂き、その会話を通して、新しい見方なども教えて頂きました。その結果解像度が上がり、いくらか的を射たものにできたかな、と感じています。
この「手順」に速さの重要性があると思っています。
人間の性質として、何か成果物があると、それにFBやレビューをしたくなるものだと思います。
ただし、そのためには会話の発端となる、何かしらの成果物が必要です。しかもそこで重要になるのは、恐らく「質」ではなく「速さ」です。
といったように、施策の質や解像度を効率的に上げるために「速さ」は重要な指標だと感じました。
② やってみないことには気づきを得れない
自分が企画考案する際、いくらか仮説とKPIを持って話を進めています (意識はしてます)。ここを改善すると、恐らくこの数字が伸びるだろう、と言った風に。
ただ実際に一通り経験してみると、そこまで予想通りに数字は動いてくれません。
ではそれが失敗だったのかと言うと、そうではなくて、分析をすると意外な数字が変化していることに気づくことがあります。
この「気づき」に速さの重要性があると思っています。
仮説や予想を掲げても、良くも悪くも予想外の変化は発生すると思います。 ただそこから気づきを得られば解像度が上がります。しかしその気付きは、一旦リリースしてみることでしか得られません。(「不確実性」と言うやつでしょうか)
「気づき」を効率的に得るために「速さ」は重要な指標だと感じました。
上記のような経験を通して、どの段階においても「速さ」は重要な指標なのだということを学びました。(質も重要だと理解した上で)
さいごに
今期からは色々と幅広く経験させて頂いていますが、やっぱり「知る・分かる・やる」は違うな、と感じてます。
今後もぐるぐる動き回って、色々学んでいければと思ってます。
明日のアドベントカレンダーは新卒同期の高橋くんです。社内でクワッスに似てると言われている高橋くんです。
最後まで読んでいただきありがとうざいました。