こんにちは、これはmikan Advent Calendar 2023 16日目の記事です。
前日は@h1joynk1sの「ロードマップしくじり先生 -大きく考えて、小さく分けて、早く実行する-」でした。今年入社した@h1joynk1sが先頭に立って進めてくれたロードマップに関して、今の形に落ち着くまでの過程が書かれているので、プロダクトの今後を考える人はぜひ読んでください！
さて、昨年自分は分析担当として、mikanのデータ分析環境やその取り組みについてお話しました。今回は1年経ってみて分析担当からPMへと会社での役割が変わってきたので、その振り返りをします。

これまでの流れ

自分はこれまでに2社経験しており、どちらも事業会社でWebサービスを運営していました。業務としては広告の運用やSEOなど集客から始まり、収益を伸ばすために分析とそのディレクションをしてきました。基本的にはアクセス解析ツールを利用したり、自社のデータ基盤にある複数データをSQLを使うことがほとんどです。システムのAPI経由でデータ取得をしたり、Webサイトへの実装依頼をすることもあるので、開発についてはほんの少し分かる程度でした。

mikanには副業から関わっており、入社してから半年程度はリリースした機能や施策の効果検証を主にしていました。そこから後は、mikan自体が新たに課金プランを追加しつつ、TOEICや英検といった問題演習へと取り組めるよう大きく変化を作っていくところです。これらのタイミングで、自身もいくつか大きな取り組みを担当することになり、それらの分析から実行まで実施することになったところから本格的に役割をPMへと移していきました。

PMになってみての難しさ

流れだけ見るとスムーズにPMへとシフトしていますが、実際にはわからないことだらけの中を進んできました。ビジネス職でやってきた自分が感じた難しさの中で、特につまずいたのは以下の3つです。

今やるべきことの見極め

mikanでプロダクト開発を進めていると、やりたい施策以外にも日々のお問い合わせや不具合への対応、技術的負債、クライアントからの要望などなど、求められるものは多岐にわたります。
その中で事業成長、サービスとしてより良くしていくためにどういった順番でmikanにあるリソースを配分するかはPMとしての悩みどころです。自分はまだ「何を今やるべきか」という判断に苦戦していています。自分の中でやるべきだと思っていたものが、相談してみたらそれって今必要なんだっけとなることもよくありました。

プロダクトへの要望を持つ人にもそれぞれの事情があるので、把握して順番をつけて説明するというのは難しくなります。
ここについてはsakuがロードマップしくじり先生 -大きく考えて、小さく分けて、早く実行する-にもあったようにロードマップを整備してくれたことで、かなり見通しが良くなりました。
自分としてのポイントは以下の2点のおかげで判断をする際の指針となっています。

• 会社としての参照点が一つになること

• 今どういった課題を解消して、どのような体験を届ける方針なのかが決まること

小さく検証すること

リニューアルなど改修範囲が大きくなればなるほど、一つの開発にあたってあれもこれもとやることが増えがちです。自分も担当するプロジェクトを進めてきましたが、ないと困るものと、あれば良いものの切り分けなどがうまくできず苦戦しました。特に施策を自分で考え推進する側になると、やりたいことが先行してしまい、施策を小さくする塩梅が難しいなと感じています。

今は理想としてやりたいこと定義をした後に小さく検証するにはという観点で絞ること、あわせてフェーズを区切ることで段階を踏むようにしています。また、開発チームとの仕様整理において、小さく検証するためにデザイナー、エンジニアとも議論するによって担保するようになりました。

求められる知識の広範さ

これまでビジネス部門で過ごしてきただけに、デザインやエンジニアリングに関する議論は本当に難しかったです。PMになったことで、改めて今までとは違う領域の知識や考え方を増やしていかねばと強く思いました。
機能や施策を考えるにあたってPM自身もイメージするものを簡単に作ってみることはありますが、自分の中での形にする流れがはっきりしなかったり、できてもなんか違うみたいにになりがちでした。また、議論をするにあたっても個人の意見ではという感覚が抜けなかったです。

これについては、自身がデザインのプロセスや情報設計に関する知識があまりなかったことも一つの原因だったので、事業責任者でありデザイナーの@3izorinにアドバイスをもらって進めました。

まずは、書籍などから体系的な知識をつけつつ、実際に手を動かしながら施策をつくっていくことで少しだけイメージが湧くようになりました。デザイナーチームが実施するペアデザインにも混ぜてもらったりと、色々と考え方を学ばせてもらっています。PMが企画時点である程度高い解像度でイメージができていれば、デザイナーとも議論をしやすいなと感じるので、引続きやっていきたいところです。

ちなみに、実際に以下の書籍はすごく役立っています。

PMになってみての所感やアナリストからの変化

難しさを色々と感じる一方で、アナリストやそれまでの事業運営の経験があったからこそ役立ったこともあります。

• 機能においての理解度を高められる

• 分析と検証のサイクルを早く進めることができる

機能においての理解度を高められる

1つ目は普段からSQLを利用していたり、アプリ内のログ設計をしていたりすることで、ほしい数値がそのまま得られるかつ早く利用できることです。ある機能の利用率や特定の困りごとに直面しているであろうお客様の数など、定量データからわかることも多くあります。主なKPIと合わせて各機能の利用率や細かい使い方も数値から見ることができるので、思っていた使い方と違うといった発見もあってかなり助かっています。

また、プロダクト開発を進めていると必ずやってくる「この機能って必要なの？」という議論ですが、mikanも運用年数が9年と長くなってきたこともあり、ちょくちょく話すことがあります。その際にも、定性的な話とあわせて数値を見ながら議論することで、実際に断捨離することにもつながりました。

分析と検証のサイクルを早く進めることができる

2つ目は数値から得られた仮説に対して、すぐにそれを実装して検証するといった仮説のアップデートを早くできることです。前職では分析チームとして、全社横断の組織で動いていたこともあり、プロダクト開発と分析の間に少し距離がありました。そうなると「仮説立案 → 実装 → リリース → 検証」の期間が伸びがちであったり、分析しているうちに優先順位がかわって仮説はそのまま、といったこともよく起こります。

自身がPMとアナリストを兼ねることで、立案したタイミングから検証する内容を織り込んで進められるかつ、リリース後の分析も早く次につなげることができるようになりました。このあたりは自分の中でも仮説に対する鮮度が高いまま取り組めるので、アナリストとしてやっていた前職からの大きく変わったところです。

おわりに

PMになってざっくり1年くらい立ちそうな自分ですが、先人たちの話でよく見た困りごとは例に漏れず悩んでいます。実際にこうした課題に現場で向き合えることはありがたいかぎりです。また、mikanには各職種において頼れるメンバーがいるので、色々教わりつつ今後もアプリを良くしていきますので、ぜひ皆さんmikanを使ってみてください！

そして、mikanでは一緒にプロダクト改善をしてくださるメンバーを絶賛募集中です。特にiOS, Backend, Designのポジションを探しているので、ぜひ気になる方はお話しましょう！