【モノグサPdMシリーズvol.4】開発プロセスにおける他職種との関わりと役割分担
こんにちは、モノグサでプロダクトマネージャーをしている伊藤卓(すぐる)です。
モノグサへの入社時点ではCustomerSuccess職でしたが、機会をいただいて2022年末頃より現職に就いています。
（経緯などは別の機会があれば書きたいと思いますが、私に限らず全社員に様々なチャンスがある会社だと思います）
面談・面接などで様々な方とお話させていただく中で、「モノグサではプロダクトマネージャーと他職種はどのように関わっていますか？/役割分担していますか？」と聞かれることがよくあります。
確かに話していくと各社それぞれ分担の仕方は違うのだろうなと感じますし、入社後の業務をイメージする上ではやはり気になるポイントだと思います。
とはいえ役割分担と一言にいっても「時と場合による」面も強く、ここでは「時と場合」をモノグサの開発プロセスとして分解して、モノグサの現状を紹介していきたいと思います。
ちなみにプロダクトマネージャー自体の具体的な業務はvol.3の岩楯さんの記事で紹介しておりますので、ぜひそちらもご覧ください。
開発プロセスの全体像
まずはモノグサでの開発プロセスの全体像(フロー)を紹介いたします。ぼかしているところがあるのはご容赦ください。
また、プロセス全体だとnoteの都合上どうしても画像の解像度が荒くなってしまうため、各プロセスの説明の際に改めて該当箇所のみを抜粋して掲載いたします。
大きなカテゴリとしては以下6つの流れで進行しています。おそらくこの粒度では、後述の役割分担を別にするとどこの会社も同じようなプロセスで開発を進行していると思います。
計画の立案
開発事項・課題の発生
優先度の設定
解決策・開発内容の検討
実装
運用・検証
この中でも、特徴がありそうなところ/モノグサとして重視しているところを(主観ですが) 2点ご紹介します。
特徴①：Mission実現に向けた開発の起票
1つ目は、「2.開発事項・課題の発生」において「Mission実現に向けた開発の起票」があるというところでしょうか。
通常のSaaS企業でも一定程度はこのような起票があるとは思いますが、特に「記憶を日常に。」というモノグサのMissionを達成するためには、現状よりもさらに多くの領域をカバーする必要があると考えております。
既にリリースしているものは数学機能や文章記憶機能ですが、このようにある程度はニーズや実現性が分かっている領域だけでなく、アイデアレベルでは「動作の記憶」、「Smart Deviceの活用」なども挙がっており、現状の機能性に縛られず、真にMission達成のために必要な開発の起票もモノグサでは重視しています。なのであえてプロセスとしても表現しております。
特徴②：優先度の再調整
2つ目は、「3.優先度の設定」で”必要に応じて”と書いておりますが、「優先度の再調整」にあります。
最初の優先度設定は各領域のPdMやTech Leadエンジニアが設定することが多いものの、場合によっては再調整の議論が行われ、優先度が上がることも(下がることも)あります。モノグサでは開発優先度は職種横断で議論する場や文化があり、メインの場は四半期に一回あるものの、それ以外のタイミングでも必要に応じて議論が行なわれます。そしてそれを歓迎しています。
役割分担とも少し関連しますが、Businessメンバーから顧客の声やビジネスインパクトが持ち込まれ、トレードオフになる項目も考慮しながら合意形成をしていくことになります。（PdMの腕の見せ所ですね）
また、モノグサのBusinessメンバーにとってはこのような営みをしつつ事業開発を推し進められることが重要な要素、かつ醍醐味でもあります。
他職種との関わり/役割分担
さて、本題の役割分担について紹介したいと思います。前項と同様にぼかしているところがあるのはご容赦ください。
※念のため一部略語の補足ですが、Corp: Corporate(部門)、Biz: Business(部門) の略です
前項の開発プロセスを横軸に置き、縦軸に関連する職種を載せた上で、それぞれの関与度合いを色で表現しています。色が濃いほど、その開発プロセスにおけるその職種の関与度合いが高い・関与する場面が多い、という感じです。
なお、表でまとめたためにそれぞれのプロセスに前後関係があるように見えますが、必ずしもそうではないため、それぞれのプロセスの関係性については前項のフローをご参照ください。
前置きが長くなりましたが、ここからカテゴリごとに役割分担を紹介していきたいと思います。フローの一つ一つを詳細に紹介はしませんが、各カテゴリにおける役割分担の全体感をお伝えできればと思います。
1. 計画の立案
塗りつぶしてしまって大変恐縮ですが、内容としてはCompany OKRの立案や、Roadmapの作成などが含まれています。
どれも最終承認は経営が行うものではありますが、特にRoadmapについてはBizの責任者クラスやPdMも積極的に関与し、モノグサのMissionや事業を考慮したり、様々な職種の意見も収集したりしながら内容を確定しています。
2. 開発事項・課題の発生
MissonやRoadmapに関する開発は少しPdMなどProductの色が濃くなりますが、基本的には課題の起票は全職種が行っています。頻度が少ないため色が入っていない箇所もありますが、関与することを否定するものではありません。
特に(比較的)短期的な課題については全職種が実際に行っているものであり、また起票内容も、担当領域など自分の関わりが強いものに限らず、課題だと思うものは何でも起票されています。(Corporate部門が使う機能もあるため、Corpにも一部色が付きます)
また、新規入社の方が新鮮な気持ちでProductを眺めた時に感じるものから起票される課題は、場合によっては既存メンバーは慣れなどから見過ごしてしまっている内容もあり、入社年次や職種などによらず課題の起票は歓迎されています。
3. 優先度の設定
ここは全般的にPdMがリードしていくところです。
MissionやRoadmapに関連する課題には経営も関与しますし、DesignerやEngineerのマネージャー(Design Mgr, Engineer Mgr)も議論に積極的に関与します。ただ、検討のリードはPdMが取る場面が多いです。
モノグサでは優先度の設定権限はPdMとTL(Tech Lead)にありますが、独断で設定することはほとんど無く、どんな課題でも基本的には何かしらの議論を経て設定されます。また、議論内容や、その結果としての優先度はJiraを用いて全社に共有されているため、透明性の高さは常に維持されています。（余談ですが、モノグサは透明性の高さに非常に強い関心を持って取り組んでおり、Product部門に限らず、経営会議やBusiness部門の重要な会議の議事録は基本的に公開されています）
主なタイミングに記載されている内容が一般名称でないものもありますので、以下にて補足します。
領域別Mtg: 各開発領域ごとに毎週行っているMtg。短期的課題は主にここで議論され、優先度が設定されます。
場合によってはBusinessメンバーが参加し、議論に参加することもあります。
BP会(Business Product会): 隔週で行っている、Business部門の各責任者とCTO・PdMとの会議の場です。
優先度に限らず、双方で連携する必要のある様々な議題を扱っています。
Planning: 四半期に一回全社で行っている、主に開発優先度の調整・決定を行う会議です。
これはモノグサの特徴・文化として採用資料でも紹介しています。
4. 解決策・開発内容の検討
こちらも全般的にPdMが関わりますが、検討内容が具体的な仕様になっていくにつれ、関与の比重がDesignerやEngineerへシフトしていきます。
以降の活動のベースとなる解決策の方針を決めるところまでは、顧客ニーズへの解像度が高いBizなど様々なメンバーと関わりつつ、PdMが検討をリードします。それ以降の仕様(Design含む)については基本的にそれぞれの職種に検討主体は任せる形となり、PdMはレビューなどを中心に関わっていくことになります。
ただ、具体的な内容になって初めて見えてくる論点などもあり、その場面ではPdMが議論のリードをすることもあります。
5. 実装
ここまで来るとPdMの関与は少なくなってきます。実装やそのレビュー、テスト・リリースなどは基本的に各担当職種がオーナーシップを持って進めています。
一方で、リリース時期が顧客の業務やビジネスに影響を与えうる場合もあるため、進捗管理や各ステークホルダーへのコミュニケーションはPdMが行います。いわゆるPJマネジメントですね。（もちろんPJマネジメントはもっと前の工程から行っています）
ただ、モノグサのメンバーは非常に頼れる方々ばかりで、細かい進捗管理は各メンバーやMgrに任せられており、PdMは最低限の関与しか要りません。（いつもありがとうございます）
6. 運用・検証
リリースしたからといってそこでPdMの仕事は終わりではありません。
いわゆる運用監視はSREなどのEngineerが行いますが、実際の利用状況を把握したり、そこから改善策などを検討するのはPdMがリードします。追加の要望(課題)の起票は、「2. 開発事項・課題の発生」と同様に様々な職種から起票されますが、特に顧客と相対し機能のFBを直接もらうことが多いBizからの関与が大きいです。ただ、実際に何をどのような優先度で行うのかなどの検討はPdMがリードします。
一旦はここまででフローは終えていますが、追加開発が始まればそのPJマネジメントを行いますし、別の課題・PJが発生したら解決策の検討などを行います。「1. 計画の立案」だけは基本的には年次で行うものですが、以降のものはより短いサイクルで行い、様々な開発を進めています。
最後に
モノグサの開発プロセスと他職種との関わり/役割分担、いかがでしたでしょうか？（手前味噌ですがわりとEMPOWEREDに近いプロセスな気もします）
ご紹介したのは代表的なケースではありつつも、モノグサでは開発領域がいくつかに分かれていますので、それぞれの領域の特徴などによってもさらに濃淡があります。(R&Dに近い領域であれば、相対的にはBizの関与度合いは薄まるなど)
今後さらにメンバーが増えたり、職種が増えたり、新領域など事業環境が変わっていくにつれて、開発プロセス・役割分担もまた変わっていくものだと思います。（現に私が入社した時点ではPdM職やQA職は存在せず、また開発プロセスも良くも悪くもシンプルなものだったと記憶しています）
なお、事業フェーズの違いによるPdMの役割分担に関連するテーマとしてvol.2ではメガベンチャーとスタートアップでのPdMの違いを扱っておりますので、メガベンチャーぐらいになるとどうなるのか（スタートアップとどう違うのか）が気になったら(気にならなくても) ぜひご覧ください。
会社規模や事業フェーズの進展にともなって、開発プロセスも変わっていき、PdM業務も変化していくはずですので、その変化を私自身楽しんでいきたいですし、楽しめる人と一緒に働きたいと思っています。
モノグサでは私たちと一緒に働くPdMを絶賛募集中です。モノグサPdMに興味を持った方はぜひ下記からカジュアル面談等にお申し込みください！お待ちしてます！
↓↓↓