プロダクトマネジメントの成長痛を解消する
こちらは「CADDi プロダクトチーム Advent Calendar 2024」の11日目の記事になります。他の記事とあわせてぜひご覧下さい！
ということで改めまして、キャディでProduct Opsをしております江種（えぐさ）です。よろしくお願いします。
今回はこちらの記事で、「プロダクトマネジメントの成長痛を解消するためのProduct Opsという選択肢」についてお伝えできればと思っております。もう少し噛み砕くと以下2点になります。
Product Opsとは？
キャディでのProduct Opsの取り組み
少しでも興味を持って頂けましたら、ぜひ最後までご覧頂けると嬉しいです！
Product Opsの夜明け
2022年6月に図面データ活用クラウドCADDi Drawerを提供開始してから、執筆時点（2024年12月）で2年半の月日が経つことになります。
現在では当事業の構想は「製造業AIデータプラットフォームCADDi 」と呼んでいるものに昇華しており、上記CADDi Drawerをデータ基盤として中心に置きつつ、その周辺にアプリケーションを配置したプラットフォームの形を取っております。
組織も拡大してきました。PdMは約20名在籍しており、100名以上のTechメンバー（エンジニアやデザイナーなど）と共に、プラットフォーム構想を担う各種サービスの開発に励んでおります。
成長痛の発症
上記のようなプロダクトの多角化や組織の拡大に伴い、組織としてプロダクトマネジメントを推進していく中で、以下のような課題が生まれてきました。
問い合わせ対応などの周辺業務に追われ、本来集中すべき業務に十分な時間を割けていない
プロダクトマネジメントプロセスで未整備な部分があり、アウトプットが各PdMの裁量に任されてしまっている（再現性がない）
開発チーム間での開発アイテムの依存関係の調整が大変
リソースアロケーションが適切に行えていない
組織/事業が小さかった頃は問題にならなかったであろう、成長と共に表面化してきた課題 = 成長痛が至る所で観測されるようになってきました。
Product Opsチームの誕生
前述した課題を解決すべく、特定のメンバーが各種施策に取り組んでいたのですが、その中で生まれた「これって世の中でいうProduct Opsのことでは？」という気づきから、最終的にキャディでもProduct Opsチームが立ち上がることになります。
その際、チームのミッションは以下のように定義されました。
PdMをプロダクト開発・ユーザーへの価値提供に集中させることで、プロダクト開発サイクルの生産性を最大化する
そもそもProduct Opsとは？
ここで、世の中一般的にProduct Opsがどのようなものと定義されているのか、いくつか整理しておきたいと思います。
Pendo社の定義
プロダクトオペレーションとは、プロダクト、エンジニアリング、カスタマーサクセスが交差する部分を最適化する業務機能です。研究開発チームと市場参入担当者をサポートし、プロダクトに関連する調整、コミュニケーション、プロセスを改善します。
開発チームだけでなく、市場参入担当者（翻訳元だとgo-to-market counterparts）もサポートするとあります。
キャディの組織構成も、Product OpsチームとGTMを担うPMMチームが二人三脚のような体制になっており、通じるものがあります。
なぜ、企業にはプロダクトオペレーションが必要なのでしょうか？
プロダクトオペレーションを設立する主な理由は、プロダクトマネージャーからオペレーション（そして時間のかかる）タスクを取り除き、顧客を喜ばせるプロダクト作りに集中できるようにすることです。これにより、コミュニケーションと効率も向上します。
キャディのProduct Opsチームのミッションとかなり合致しており、PdMをいかに本質的な業務に集中させられるか、がキーのようです。
プロダクトオペレーションの責任は、次の5つの中核的な分野に分類されます。
・ツール：他のオペレーションの役割と同様に、プロダクトの技術スタックを管理し、社内のベストプラクティスを確立し、チームメンバーが効果的にツールを使用できるようにします。
・データ：プロダクトオペレーションは、定量的および定性的なプロダクトデータを収集、整理、分析し、組織全体がインサイトを最大限に活用できるようにします。データには、プロダクトの使用状況、ネットプロモータースコア（NPS）、プロダクトの粘着性、顧客フィードバック、機能リクエスト、サポートチケットなど、あらゆるものが含まれます。
・実験：プロダクトの実験プロセス内の摩擦を排除するために、プロダクトオペレーションはすべての実験を追跡、順序付け、実行し、効率を高めるプロセスを作成します。
・戦略：プロダクトオペレーションは、プロダクトに関する部門間のコラボレーションを促進し、プロダクトのインサイトを使用して、改善すべき領域を特定し、ビジネス上の意思決定に情報を提供します。
・信頼できるアドバイザー：主要な意思決定者にプロダクト情報を提供することにより、プロダクトオペレーションはCPO、プロダクト担当VP、およびその他のR&Dリーダーシップに対する重要なアドバイザーになります。
具体的な業務内容は、ツールやデータの活用促進から意思決定に関わる情報提供まで、幅広いものとなっております。
Product Operations本の定義
Product Operations is the discipline of helping your Product Management function scale well. Surrounding the team with all of the essential inputs to set strategy, prioritize, and streamline ways of working.
上記は、おそらくこの界隈で一番有名な書籍である『Product Operations: How successful companies build better products at scale』の紹介文を引用したもので、かの有名なビルドトラップ本を執筆されたMilissa Perri氏が出された新作でもあります。
Product Opsは、戦略策定、優先順位決め、業務プロセスの効率化の観点で、プロダクトマネジメント機能を拡張させるための手法だと述べられています。
The Three Pillars of Product Operations: Data and Insights; Customer and Market Insights; and Process and Governance
また、Product Opsの3つの柱は、データとインサイト、顧客とマーケットのインサイト、プロセスとガバナンスであるとしており、事業のフェーズによって重点が変わってくるとも述べられていました。（下のPodcastより）
キャディでのProduct Opsの取り組み
ではここからは、私達が実際に行なってきた取り組みを一部紹介させて頂きます。
ちなみに、キャディでのProduct Opsの取り組みは大きく以下の2つに分けられると思っており、
A. 量を減らす（PdMから低付加価値業務を巻き取る）
B. 質を上げる（PdMの高付加価値業務をレベルアップさせる）
いずれも、「PdMをプロダクト開発・ユーザーへの価値提供に集中させることで、プロダクト開発サイクルの生産性を最大化する」というチームミッションに繋がっています。
A-1. 問い合わせ対応プロセスの整備
幸いなことにサービス開始当初からたくさんの引き合いを頂いており、ユーザー数と共に増える社内外からのお問い合わせに対応するためのプロセス整備を急速に進める必要がありました。
具体的には、IntercomやJira Service Managementを駆使した問い合わせ対応プロセスを整備すると同時に、以下のようなLayerの概念を導入し、いかにL3に問い合わせを流さないかを目標に置いて、連結する各種取り組みを進めています。
L0（=Layer 0）: ユーザーが自己解決
L1: カスタマーサポートで対応
L2: Product Opsで対応
L3: PdM/Techメンバーで対応
その連結する取り組みのひとつが、次項の「ナレッジマネジメント」になります。
A-2. ナレッジマネジメント
前項のお問い合わせ内容をナレッジとして蓄積し、同じ問い合わせの発生を防ぐ取り組みを進めています。
具体的には、RAGベースのボットを活用した社内のナレッジ管理です。ボットの情報源となるドキュメントに、過去のお問い合わせ内容やリリース情報を定期的に反映していくことで、社内の誰もが手軽に最新の情報にアクセスできる環境を整えています。
A-3. セキュリティチェックのBPR
私達が提供しているのはITサービスなので、お客様から頂くセキュリティチェックにも対応していかなければなりません。そしてこれがまた、受注数に比例してどんどん増えていきます。
そもそも、セキュリティチェックに回答するにはセキュリティの専門知識が必要な上、自社サービスのセキュリティ周辺の実装状況を常に把握しておく必要があり、基本的にはPdMやエンジニアが対応する形になります。
まずはProduct Ops内で専門人材を育成し、基本的に全ての回答を巻き取った上、今後のセキュリティチェック数の増加を見越し、自社回答フォーマットの作成やアルバイトさんでも回答可能な体制作りなどの対応キャパ拡張施策を進めていっております。
A-4. リリースプロセスの整備
リリースプロセスとは、新機能やアップデートのリリースが確定してから、実際にリリースされるまでの一連の流れを指します。
新機能やアップデートをトラブルなくリリースし、情報を確実に共有することを目的に、タスクの整理や関係者の適切な巻き込みを行っています。
CADDi Drawerのローンチから2年半が経過し、多くの機能が追加されてきたことで、機能同士の依存関係が複雑化。チーム構成も目まぐるしく変わり、関係者の数も急激に増加しています。その結果、リリース作業が1つのチームだけで完結することは少なくなり、全体を横断的に把握し、調整を行う役割が必要になりました。この部分を現在Product Opsチームが担っています。
B-1. インテイクマネジメントプロセスの整備
インテイクマネジメントとは、社内外からの要求事項を整理し、優先順位をつけてプロダクトに反映していく一連のプロセスのことで、全社でプロダクトマネジメントを推進していくための非常に重要なドライバーです。
特に、VoC（Voice of Customer）に関しては、Bizサイド × Productサイドが連携してロードマップの検討スコープに取り込み、プロダクトの顧客価値最大化を実現していく必要があります。
しかし、キャディではこの辺りのプロセスが未整備であり、VoCの扱いも各PdMの裁量によってバラツキがある状態でした。
そこで、Bizサイドも巻き込みながら全社でプロダクトマネジメントを推進していくためのモメンタムを作りつつ、VoCの回収からロードマップ反映までを体系的に進めていくために、上図のようなプロセス整備を進めていっております。
終わりに
いかがでしたでしょうか？
各施策は現時点でもまだ道半ばではありますが、プロダクトマネジメントの成長痛を着実に解消しつつあり、PdMが本来集中すべき業務の質が高まってきていると感じております。
そもそもProduct Opsという職種自体がまだふわっとしている面がありますが、今後も他社さんの事例も参考にさせて頂きながら試行錯誤していければと思っていますし、逆にこの記事が少しでもどなたかの役に立てれば書いた甲斐があったなという気持ちです。
各取り組みに関しては、ここでは書き切れなかった部分もたくさんありますので、また後日、各取り組みの深掘りnoteを出したいなと思っています。
ぜひフォローして頂き、楽しみにお待ち頂ければと思います。
P.S.
現在、キャディでは絶賛採用強化中です！
特にPdMはまだまだ採用していきますし、キャディのミッション（=モノづくり産業のポテンシャルを解放する）をグローバルスケールで成し遂げていくためには、むしろ、もっともっと成長痛を起こしていく必要があると思っております。Product Opsチームをさらに忙しくしてくれる方大募集です！
もし少しでも興味を持って頂けましたら、まずはぜひカジュ面でもしましょう。ご連絡お待ちしております！