このブログ記事は、「プロダクトづくりのための挑戦とその成功・失敗談を綴るアドベントカレンダー powered by プロダクト筋トレ」アドベントカレンダーの22日目の投稿です。
こんにちは、ROBOT PAYMENTのたもりょう（@tamotamo97）です。
請求業務を自動化するクラウドサービス「請求管理ロボ」のPMをしています。
気づけばもう2021年も年の瀬ですね。毎年のことながらバタバタしています。
師走って昔の人は本当にうまい例えをされますね。
明日アドベントカレンダーだった進捗0％で絶望してる
— たもりょう (@tamotamo97) December 21, 2021
ブログ忘れていたわけではないですが毎日ギリギリを生きていて、この投稿も当日ギリギリとなってしまいました。1日遅れてしまいました...()すみません。
2021年はプロダクトマネジメントロールを新設して、私個人としても会社としても大きく変化した1年だったと思います。
1年間新しい仕組み作りにチャレンジしていったわけですが、この記事ではその中でも特に影響が大きかった施策の概要のみ紹介します。
プロダクトマネジメントの仕組み作りをチャレンジされている方に何かヒントになれば幸いです。
想定読者
- 組織にプロダクトマネジメントの仕組みを取り入れたい方
- プロダクトマネジメントを導入して間もない方
プロダクトマネジメントロール新設
2021年1月から新しく専任ロールの定義をしました。
弊社は大きく3つのプロダクトがあり、今までは各プロダクトのシステム責任者がTL、EM、PjM、PMロールを兼任する形でした。
開発組織や事業規模がそこまで大きくないフェーズではワークしますが、規模が大きくなるにつれ各所で様々な問題が生じます。
そしてプロダクトをグロースさせる1番の責任者が兼務状態なのも健全ではないですし、純粋にプロダクトが成長しません。
ARR1億円まではアート、1億円からはサイエンス、とよくSaaSの話で上がりますが、本当にその通りで1億円までは兼務の状態でも各所にサポートを得ながら進められますが、1億円超えてきたところで限界を感じてました。
（うちの場合は本当に周りのメンバーが優秀でアートをみんなで上手に描けたのかなと今になって思います）
結果的に作ること自体が優先され以下のような問題が発生していました。
- 具体的な戦略、プロダクトの方向性が策定できていない、また会社全体（経営層含め各メンバーまで）で認識が合っていない
- 勝てる戦略の整理ができていない
- 事業部の方針、各部署の情報を整理、指針を立てられていない
- 今の開発が何を目指しているか、現在の立ち位置含めた状況が見える化できていない
- 要求分析、要求仕様の失敗
- 開発者によしなに任せることによる負荷の増加
- 広い視野（ビジネスや運用面）での不整合や失敗の発生
- 上記に対しての責任の所在が不明
- 効果測定の失敗
- ユーザーが本当にもとめているものを作れているかわからない
- リリースしたものの効果測定ができていない
- 次の計画が立てづらい
上記を解決するために専任ロールを新設しました。
立ち上げの大枠の流れは以下になります。
- 理想の状態の定義
- 現状の課題の分析、解決策の掲示
- PMの役割の定義
- 投資対効果の説明
- 採用
- 採用できたら業務移譲
弊社の場合はいきなりPMを採用することが難しかったのでテックリード、エンジニアリングマネージャー、スクラムマスターを採用して役割に応じて移譲していきました。
PMとは何者か？
どの組織でもチームでも私(我々)は何者か、何をやる人か、ミッション、期待されていること、具体的な業務内容を明らかにして皆に伝えることが重要だと思います。
そして同時にそれはなかなか浸透しづらく難しいです。
最初に合意形成することは大事ですが継続的に啓蒙活動していくことも重要ですね。
私の場合はPMとは何をする人か、責務は何かを具体的に定義してステークホルダーと認識を合わせました。
プロダクトマネージャーの責務（請求管理ロボにおいて）
- 請求管理ロボプロダクトの責任者としてプロダクトの成功に責任を持つ
- プロダクトの企画・設計・開発・運用の全てに関わる
- ビジョンやロードマップ、KPIの設定などを行う。それらを浸透させ、目標管理を行う
- プロダクトに関する主要なデータを分析し、グロース施策の立案と実行を行う
- ユーザーインタビューや利用ログなどの分析を通じて、ユーザー理解（ユーザーインサイト）や課題発見を行う
- マーケット状況やビジネス要件なども考慮し、製品要求仕様書（PRD）に製品要求をまとめて開発チームに引き渡す
- 自らとチームメンバーの成長に対するコミット
- チームワークを重視し、チームメンバーへの敬意を持つ
マネジメントロードマップの作成
プロダクトを継続的に成長させていくためにどのように仕組みが必要かそれをいつ作るのかを先に作りました。
恒常業務POをやりながらは本当に大変です。開発チームやステークホルダーの協力を得ながら少しずつ進めていきました。
プロダクトポートフォリオ作成
1プロダクトの方向性、会社全体のプロダクトの方向性を定義するためにプロダクトポートフォリオを作りました。
そのためにインプットとして何の情報を得ればよいか、アウトプットは何になるかを整理しました。
要素を整理したら各要素の責任者をバイネームで入力して認識を合わせました。
要素ごとに資料を作って固めていきます。合わせて会議体も整理しました。
インプットの仕組み例
市場環境、競合環境の情報がリアルタイムでSlackに飛んでくるものを作りました。(ただのRSSですが）
これを月次で整理して全体で共有しています。
プロダクトビジョン
いわずもがな判断に迷った時の拠り所となるビジョン、大切ですね。事業ビジョンとプロダクトビジョンを新たに決めました。
ビジョンとか抽象度の高いものは決めるだけだとそのままで放置されやすいですね。
そこでプランニングで毎回メンバーに発言してもらうようにしました。コツは楽しく。昭和時代の言わされているただの唱和にしないことがポイントです。
開発チームは全員プロダクトビジョンを空で言えます。（当たり前？）
NSM、プロダクトKPI(トップラインメトリクス等）
プロダクトビジョンを紐解いてどのような指標が取れるかを整理しました。図見せたいですが見せれずすみません。
同時にNSMを定義して、それに紐づいて何が重要か（トップラインメトリクス）を定義しました。なるべく取得できる指標は全て取って、その中で重要なものをピックアップします。
値が多すぎると判断するのにノイズが多くなりすぎるので重要な指標はシンプルに少なくするのがおすすめです。
開発ライフサイクルの整理
改めて開発ライフサイクルの整理をしました。
いつ誰が何を決めるか、何を作るかを整理します。
継続的な価値提供をしていくのに振り返りのプロセスは非常に重要ですね。
優先度決定プロセスの変更
上記の図でメジャー、マイナー、バグ…とカテゴリが別れています。
今まではエンジニアリソースを丸っと管理して、各カテゴリを主観でバランスを取りながら何をやるかを決定していました。
結果、リソース配分の状況が見えづらく配分の判断がしづらくなっていたため、カテゴリ分けして明確にどこにリソースを投下するかを判断しやすくし結果も振り返りやすくしました。
これでこの年はまずはここに注力するという方針が立てやすくなりますし、実績も把握しやすくなります。
カテゴリ分けしてリソース配分を決めたらあとはカテゴリ内のそれぞれの担当者で優先度を決めるようにしました。これで各チームに権限移譲しやすくなります。
メジャー開発においては開発コストが大きくかかるため、開発投資判断をするための計算式を事業部長と一緒に作りました。
見積もりが難しいですが、ざっくり相対的に見積もっています。
優先度決定の一つの指標として投資倍率を利用します。優先度自体は総合的に判断します。
弊社はベンチャーでリソースも限られているので、優先度の決定は非常に重要です。
何が重要で何をやらないかを決める精度を上げるためにProduct boardを導入して来月から運用開始予定です。
ProductBoardのいいところの一つにProductPortalという機能があり、将来のロードマップの共有、要望の集約がWeb上で可能です。
将来どのような改修予定になっているかを聞かれることがよくあるのでここも解決できます。
プロダクトボードはPMの伊藤さんが構築されていて今後ブログ記事にしますのでお楽しみに。
↓2022/02/21公開されました。
プロジェクト型からプロダクト型へ
少し触れましたが、弊社はこれまでプロジェクトごとにチームを編成していました。
毎回やることも違う見るプロダクトも違うためノウハウが溜まりにくいという課題を抱えていました。
EMの白坂さん主導でミッションごとのチーム編成に変更していきました。以下ブログ参考
ナレッジも溜まり、中長期な視点を持った施策を実施しやすいようになりました。
リソース配分はチーム人数に紐付いています。
メジャー開発プロセスの整理
メジャー開発はどうしても大きい機能になってしまうので開発後考慮漏れの問題が大きく発生したり、リリース後、何を効果検証するかを明確にできていないことがありました。
細かいところは割愛しますが以下の項目を記載して確認するプロセスを設けました。
- 開発者とステークホルダーの役割を決める
- 経営上のニーズ、課題の確認
- 事業環境の調査分析
- 現行業務の調査分析
- 情報技術動向の調査分析
- 対象となる業務の明確化
- 業務の新全体像の作成
- 全体開発スケジュールの作成
- 費用とシステム投資効果の予測
- プロジェクトの目標設定
- 想定ターゲットの選定
- 開発する機能のKPI設定
PM評価
評価制度は難しいですね。
プロダクトマネジメントトライアングルをベースに15要素で評価するようにしました。
まだこれが本当に正しいかはわかっていません。やりながら調整したいと思っています。
ビジネス
- マネタイズを含めたビジネスモデル設計ができる
- 事業全体の予算を把握し、経営層、事業部長の意思決定の支援ができる
- プロダクトビジョンを掲げ、 機能開発の可能性を定量化し見極め、優先順位を付け、プロダクトロードマップを策定できる。またプロダクトKPIを設定できる
マーケット
- 市場のリサーチや分析、業界の動向、競合とのポジショニングができる
- ペルソナ設定ができる
- グロース施策の立案と実行と管理ができる
ユーザー
- ユーザーリサーチを実施して、顧客の要件とVertical Trendsを深く理解できる。
- ユーザー体験設計ができる
- ユーザー、社内からのフィードバックを集め管理できる
テクニカル
- 情報技術と既存システムの仕様を理解し、正しい意思決定ができる
- 機能要件を調査収集し、製品要求仕様書（PRD）をまとめて開発チームに連携できる。またユーザーストーリーに分解できる
- 製品開発の管理を手伝い、タイムスケジュールと成果物について開発チームと連携できる
ドメインナレッジ
- 自社、他社の現行業務の理解をし、ソリューション設計ができる
チームコラボレーション
- チームワークを重視し、チームメンバーへの敬意を持てる
- ステークホルダーから情報を広く集め交渉ができる
まとめ
一つひとつ取り組んできたことにしっかり向き合って評価していきたいと思います。
今後はさらに会社全体にナレッジを普及していく活動をしていきたいと考えています。
そして私と一緒にプロダクトマネジメント組織を作っていきたい方を募集しています。
ぜひTwitterでDMください。
それでは😃
