【モノグサPdMシリーズvol.3】モノグサPdMの業務マップを作ってみた
こんにちは、モノグサでプロダクトマネージャーをしている岩楯です。vol.1以来の登場です。
モノグサPdMシリーズvol.1はこちら↓
普段、カジュアル面談や面接の場で「モノグサにおけるプロダクトマネージャーの業務範囲はどこまでですか？」と聞かれることがよくあります。
これはプロダクトマネージャーの役割期待が業界や企業、プロダクトによって異なる場合が多いことが背景にあると思います。モノグサの中にいる我々PdM5名もバックグランドが様々で、我流で業務している部分もあったので、全員で棚卸しをして業務マップに落とし込んでみました。
棚卸しにあたってはスマートバンク様の下記のブログを参考にいたしました。
この場を借りて感謝申し上げます。
モノグサプロダクトマネージャーの業務マップ
プロダクト戦略→リサーチ・要求整理→要件定義→実装→リリース→運用、という業務フローの中でPdMがどの程度関わるのかを色分けしてマッピングしています。
前提として、2023年9月現在の業務マップであり、未整備箇所含めて今後も常に流動的に変わっていくものと捉えてください。
マップ内の各箱は色別に下記のように定義しています。
PdMが担当（濃いオレンジ）
・PdMが行う業務で、他の職種が行うことは少ない業務
PdMが積極的に担当（薄いオレンジ）
・PdMも担当することが多いが他職種が担当したり協働することも多い業務
場合によりPdMが担当（黄色）
・PdMが場合によって担当することはあるが、主に他職種が担当する業務
PdMは担当しない（水色）
・基本的にはPdMは担当しない業務
以下で、マップ内の業務を説明していきます。
プロダクト戦略
プロダクトビジョンの作成
モノグサの場合、Monoxerという1プロダクトをいくつかの領域に分割して、その各領域にPdMを配置しています。
各PdMは自領域のプロダクトがどのようにあるべきか、をプロダクトビジョンとして作成します。
プロダクトロードマップの策定・更新
モノグサの場合、CTOが策定する中長期のプロダクトロードマップと経営陣が定める中期計画や年度方針にもとづいて、PdMが各領域の単年度のロードマップを策定します。
策定過程では開発メンバーや関係するBizメンバーとすり合わせを行います。
最終的にCTO含む経営陣の承認を得て確定となります。
途中で優先順位が変わりロードマップを変更する場合には、変更後改めてCTOの承認を得ます。
※領域ごとのロードマップの一例は下記となります（モザイクはご容赦を）。
リサーチ・要求整理
Jiraチケットトリアージ
モノグサではJiraの起票を職種問わず行う（Biz職やCorprate職でも）ので、日々大量のチケットが起票されています。それらについてP1〜P4（致命的なバグはP0）の間でトリアージを行います。
P4はPdMとして完全な却下の意思表明になるので滅多につくことはないです（私もP4はつけたことないです）。
施策優先順位決定
基本的にはP1>P2>P3の順番で優先度が決まりますが、P1の中、P2の中での施策の優先順位の判断もPdMが行っています。
個人的にはプロダクトロードマップ上に明記されている施策はP1として、P2以下の施策についてはBizサイドの意向を踏まえ開発メンバーと都度相談しながら判断しています。
競合調査・分析、ユーザーインタビュー
新機能開発、既存機能改善の際などに、先行事例を調査したり既存ユーザーにインタビューをして理解を深めます。
モノグサではPdMだけでなく、デザイナーが主導することも多いです。
データ分析
施策優先度を判断するために影響範囲をデータをもとに検討する、ユーザーテストの結果を分析する、といった業務はPdMが行うことがあります。
ここは正直にいうと、モノグサ社全体として未整備な部分が多く、分析基盤の整備を進めている状況です。
要件定義
コンセプトメイキング
開発着手となったタイミングで、「ユーザーをどんな状態にしたいのか」をわかりやすく伝えるコンセプトを考えます。
これは既存機能の改善よりも新規機能開発の場面で行うことが多いと思います。
Design Docの作成、レビュー・承認
モノグサでは新機能開発や複雑性の高いシステム改修などでは、Design Docを書いて関係者間の目線を合わせていくことが求められます。
Design Doc内では各施策についてWhy, What, Howを明記していきます。実際に開発着手してから認識相違が明らかになると手戻りのコストが大きくなるので、事前にドキュメントで認識をすり合わせます。
PdMはPRDを兼ねて主にWhyとWhatについて記述し、Howの詳細は開発メンバーが書くことが多いです（Whyから開発メンバーが書くこともあります）。
また、開発メンバーが書いたDesign Docのレビュー・承認をします。
※ 下記は私が作成したDesign Docの一部抜粋です。Googleドキュメントで作成し、関係者からコメントをもらいながら修正し、目線を合わせていきます（モザイクだらけで恐縮です）。
リソース調整・アサイン
ここはEMが担当することが多いですが、EMがいない領域ではPdMが担当することもあります。
私の担当しているMarketplace領域も2023年9月現在でEM不在（CTOが兼務しており絶賛採用中です！！）なので、私が担当しています。
詳細設計
詳細設計はエンジニアが主担当となります。モノグサのエンジニアはレベルが高く、詳細設計にPdMが介入する場面はほぼありません。
実装
プロジェクトマネジメント
実装フェーズではPdMは進行管理という意味でのプロジェクトマネジメントをおこないつつ、開発スケジュールや品質について関係者と意思疎通を図ります。
期待値調整
期待値調整はPdMの腕の見せどころです。期待値を低くすれば良いというわけではなく、適切に伝えることでビジネス面での機会損失を回避することも大事だと考えています。
リリース
動作確認、QA・テスト
通常PdMが行うことが多いであろう受け入れテストですが、モノグサではPdMの担当業務になっていません。代わりにQAチームが仕様通りに動作するかの確認をしています。
もちろん動作確認はしますが、PdMの確認はリリース判断に影響を与えません。
リリースタイミング調整
機能リリースと同時にプレスリリースを打つ、マスメディアでの露出に合わせるといった場合はPdMがリリースタイミングを調整します。
が、上記のような事情がない場合は特に調整することなく、週次のリリースタイミングでリリースがなされます。
リリースアナウンス
現状、ここの線引きも模索中といった感があります。社外へのアナウンスはカスタマーサポートが担当しており、社内向けアナウンスはサポート経由だったり、PdMが行ったりとケースバイケースで判断している状況です。
運用
Biz連携
モノグサでは日々なんらかの機能リリースがなされているので、仕様変更も起こります。ですので、予めBizサイドに向けて説明マニュアルを用意したり、問い合わせが来た際の対応をします。
効果測定・モニタリング
リリースして終わりではなく、効果測定して必要であれば再度の改善施策案につなげます。
仮に無風な場合はお腹が痛くなりますが、現実と向き合って不屈の精神でより良い方向を目指します。
最後に
モノグサPdMの業務マップ、いかがでしたでしょうか？前述の通り、領域ごとに担当PdMが分かれているので、領域のフェーズや各PdMの強みによっても業務内容には濃淡があります。
当然マップに書かれていることだけを行っているわけでなく、書かれていないことにも日々取り組んでいます。
むしろ最近はマップに書かれていない（書きにくい）部分にこそPdMの価値があるのでは、とも思うようになってきており、そのあたりは別の機会で文章にしてみたいと思います。
今回棚卸しをして思ったことは、「現状はこのような役割分担だけど、本当にこれがベストなのか」という点を突き詰めてブラッシュアップしつづけていくんだろうな、ということです。
会社規模や事業フェーズの進展にともなって、PdM業務も変化していくはずなので、その変化を私自身楽しんでいきたいですし、楽しめる人と一緒に働きたいと思っています。
モノグサでは私たちと一緒に働くPdMを絶賛募集中です。モノグサPdMに興味を持った方はぜひ下記からカジュアル面談等にお申し込みください！お待ちしてます！
↓↓↓