古財氏の自己紹介
古財怜旺氏：こんにちは。ラクサスでマーケとプロダクトマネージャーをやっています。古財です。よろしくお願いします。今日は「UXリサーチを効果的に進めるJiraの書き方」というテーマで話せればと思っています。
特に創業に携わっていないメンバーが入るスタートアップの方とか、PM（プロダクトマネージャー）以外のロールでプロダクト提案する方はけっこう（この話が）参考になるんじゃないかなと思っています。それ以外の方は「あるあるだよね」と思ってもらいながら聞いてもらえればと思います。
本題に入る前に軽く自己紹介します。2022年新卒でラクサス・テクノロジーズ株式会社に入りました。会社名を知っている方は少ないかと思うんですが、ブランドバッグのシェアリングサービス「ラクサス」を運営している会社です。
2023年で8年目になるんですが、「ファッションをこれ以上、地球のお荷物にしない」をコンセプトに多くの方に利用いただいているサービスです。今はアップセル事業を見ながら、プロダクト全体の見直しを担当しています。
一気にグロースしたことで直面していた課題とその解決策
ありがたいことに順調にサービスも伸びてユーザーも獲得できてはいるんですが、一気にグロースしてしまったので、誰のなんの課題を解決するのかを明確にしないまま、多くのユーザーさんを取り込んでしまったという課題がありました。
結果、いろいろな機能をリリースするものの、「誰が使うの？」というようになってしまったんですね。しかも課題がわからないまま機能をリリースするので、間違ったKPIを見てしまって、細かい部分の改善が続いてしまう。そんな悪循環に陥っていました。なので、これを機にプロダクト全体をイチから見直そうということになりました。
スタートアップはリソースが少ないので、大きな課題を解決しなければいけないんですが、細かい作業を続けるのはもったいないということで、これからはファクトを基に、誰のどんな課題を解決するのかを明確にしようという方針の下で動いていきました。
なにも前に進まないまま1ヶ月過ぎてわかったこと
ただ、あるあるなんですけれど、「ファクト、重要だよね」と言ったら、なんとなくM1のヒアリングを聞いてみたり、ログの分析をしてみたりして、「結局ぜんぜん前に進んでないじゃん」みたいなことが起きがちです。僕もそうなって、施策をなにも提案できずに、なにも前に進まないまま1ヶ月過ぎてしまったみたいなことになりました。
大切なのは、ファクトを集める時に粗仮説を持つことだと思います。なんでもいいんだけれど自分はどう思うのかとか、「今回のこのファクトでどんな答えになったら自分はいいのか」ということを、大雑把でもいいので持っておくのがとても大切なんだなと気づきました。
どこまでファクトを集めたらOKなのかがわからないから、ずっとファクトを集め続けるんですね。なので、ざっくりでも持つことが重要かなと思っています。
ファクトを集めるのは打率を上げることなので、十分かどうか（を見極めるに）は結局打たなきゃ意味がないというところで、素早くファクトを集めなきゃいけないということに気づきました。
Jiraにしたことで得られたメリット
最初、僕らは「Notion」を使って仮説を書いていたんですが、よくよく考えたら、「Jira」を使って施策の管理とか、あとはデータ取得を僕の入社前から行っていました。仮説をNotionに書いてJiraには結果がある状態だと、仮説と結果がひとまとめではわからない。照合しにくい。
あと弊社の場合、Jiraは上長に見せて上長承認で開発へ依頼が投げられるので、「今後こうやりますよ」「今回のこのファクトでこうなったら次、こうしますよ」という部分も含めてJiraに全部書くことで、それが承認されたということは上長の言質が取れたということで円滑に進めやすいかなということで、全部の仮説をJiraに書くようにしました。
（スライドを示して）右側が本当につい最近僕が書いたJiraです。こういうふうに、「どこまで言語化できればOKなのか」とか、「今回この数値を取ることでどういうふうに活用していくのか」みたいなことをいつも書くようにしています。これをチームでも徹底している状態です。
僕の場合はプロダクトに関する上長が執行役員なので、ミーティングとかが多くて。「次どうしたらいい」とか「こうしよう」というコミュニケーションがなかなか取りづらいんですけど、Jiraに全部書くことによって「こいつはこうやりたいんだな」とか、「こうやっていく予定なんだな」ということが上長も見えるので、そういった意味でのコミュニケーションツールとしても使えるんじゃないかなと思っています。
そのほかにJiraにしたことでのメリットは、特に「どこまで仮説検証ができているのか」がわかることだと思います。
1つの大きい項目があって、その中で小さいファクト集めの依頼があった時に、親と子という関係で紐付けができるんですね。課題感の連結ができるので、それを照合することによって、前回どこまで進めて今回はなにをするのか。これが終わったら次はどうするのかという一連のプロセスが見やすくなったという意味で、Jiraにしてすごくよかったなと思っています。
ほかには、やはり開発チームと連携がしやすくなったかなというところです。開発チームがいつもデータを取得してくれているんですが、ちゃんと目的とか、「これを基にしてどういうふうに活用するのか」というところまで丁寧に書くことによって、「あっ、この作業っていうのはこういう価値を生むんだ。だったら早めに数値を取ってあげなくちゃいけないよね」みたいな感じで、素早くファクトが集まるようになりました。ここはJiraにしてすごくよかった（ところ）かなと思っています。
今までは、1週間ぐらいしたらファクトが出てくるものが多かったんですが、こういうふうに変えたことで、2日、3日、最低でも3日あれば絶対にファクトが返ってくる感じで、リードタイムがなくファクトが素早く集まるようになりました。
粗くてもいいから、仮説をJiraに書くことから始めよう
ちょっと駆け足になりましたがまとめると、仮説を立てて共有することでファクトが素早く集まって、誰のなんの課題を解決するのかという意思決定をしやすいので、誰も使わない機能とか、あとは今やる必要のない改善が減るかなと思います。なので、まずは粗くてもいいので、仮説をJiraに書くことから始めてみてください。
以上です。ご清聴ありがとうございました。
Published at
からの記事と詳細 ( プロダクト全体の見直しに必要な粗仮説とファクトの照合 「Jira」を ... - ログミーTech )
https://ift.tt/EK6LOJw
No comments:
Post a Comment