みなさんこんにちは。ジメジメとした日が続きますがいかがお過ごしでしょうか。SmartHRのプロダクトマネージャーryopenguinです。
今回は、私が複数のプロダクトチームを経験して学んだ「兼務のコツと反省」をお届けします。
「プロダクトに対してPMが少ない」「PMの採用に苦労している」といったみなさまの参考になれば幸いです。
なぜ兼務をはじめたか
2022年9月から、私はタレントマネジメントプロダクト「従業員サーベイ」と、現在未公開の新しいプロダクトのPMを兼務しています。
弊社では、単一のプロダクトに注力するのではなく、連携を前提に複数のプロダクトを提供する「マルチプロダクト」化を進めています。昨年の夏ごろ、とある新規プロダクトが必要と判断され、開発チームを組成することになりました。
弊社の新規プロダクトはSmartHR基本機能との連携が前提であり、その基礎的な知識が必要です。さらにはタレントマネジメントの理解も重要となります。
そのため新しく採用したPMではなく既存のPMからアサインする方向で検討され、私が担当することになりました。
「PMの仕事とは何か」を考え、任せる部分を決める
所属チームが2つになると、タスクやMTGが単純に2倍になり、最初のころは業務をまったく回せなくなりました。そこで、まずはPMとしての自分の仕事を棚卸し、どこまでを自分が担うべきなのかを判断することにしました。
この際、自分の業務の整理に役に立ったのが、「ダブルループ学習」という概念でした。ダブルループ学習は、組織における学習を以下の2つに分ける考え方です。
- 過去の知識から問題解決や目標達成を図り、その過程でさらに学習する「1つ目の学習ループ」
- 既存の目的や前提そのものを疑い、それらも含めて軌道修正を行う「2つ目の学習ループ」
1つ目の学習ループによって日々の行動を最適なものにしつつ、得られた知識から目的や前提そのものを問い直す2つ目の学習ループを回す。このサイクルを継続できる組織だけが競争優位を保ち続けられるとされています（参考文献1、2参照）。
図にするとこのような形です。
「PMの仕事とは何か」と悩んでいたところでこの考え方を思い出しました。そこで普段の仕事を2つの学習ループに分類してみると、うまく整理できました。
- 1つ目の学習ループ：プロダクトビジョンやOKR達成に寄与するアイテムを提供、得られた結果から学習し、目標に特に貢献するアイテムを見極める
- 2つ目の学習ループ：開発やプロダクトの提供から学習し、より良い目標を立てることで、顧客価値や競争力を最大化する
1つ目の学習ループでは、スプリントレビューやユーザーヒアリングなどの学習をもとに、目標に向けて漸進的な改善を行います。しかし、目標そのものが間違っていることはよくあることです。そこでOKRや目標の変更を2つ目のループで行います。
先ほどの図に日々の活動をプロットしてみました。
リサーチ、機能開発のプロジェクトマネジメント、目標設定…PMはループのほぼ全てのプロセスに関与しています。ダブルループを機能させるためにPMは存在するといっても過言ではないと思います。
弊社ではプロダクト開発でスクラムを用いています。リファインメント→プランニング→スプリントレビュー→レトロスペクティブというスクラムのフレームワークは、1つ目の学習ループに酷似しています。もともとスクラムは私だけでなく、開発チーム全体で回しているため、1つ目の学習ループに関連する業務はその延長で任せやすいのではないかと考えました。
一方で、目標や方向性の設定は通常スクラムを回しているだけだとなかなか本腰を入れられない、カロリーの高い業務だと思います。プロダクトビジョンについて詳しく述べた『ラディカル・プロダクト・シンキング』によれば、「リーンとアジャイルに目的地を示す力はない」とあります。よって、2つ目のループに関しては専属のオーナーがいるべきだと思われます。
そのため1つのチームでは「2つ目の学習ループ=目標設定/検査のみのオーナー」として振る舞うとよいと考えました。
兼務するチームの観察
PMのタスクを移譲すると言っても、どのチームでもいきなり業務を任せられるわけではありません。
第一の学習ループにおいても、仕様についての意思決定など、判断が求められる場面はあります。そのときのよりどころになるのが、過去の学習や経験です。多くの場合、これらの情報を持つのはPMです。PMに情報が属人化している中で1つ目の学習ループを渡したところで、ただチームが迷子になって終わると考えました。
私が兼務しているチームを比較すると、「従業員サーベイ」のチームは丸2年一緒に開発を行っています。その過程で、ほぼ毎日私が得たユーザー関連の情報や、他社プロダクトに関する分析を共有していました。一方の新しいチームは、全員が一緒に仕事をするのがはじめてのメンバーであり、ユーザーに関する情報も全てはチームに伝達し切れていない状況でした。
「サーベイ」チームへの情報伝達は兼務を想定したものではないのですが、結果的にPMに閉じた情報はかなり少なくなっていたように思います。
そこで「サーベイ」のチームに1つ目の学習ループに関する業務を任せることを決めました。
具体的な行動に移す
ここからは、「サーベイ」チームに具体的にどのような業務をお願いしたか説明します。
システムの要件にまつわる部分を可能な限りチームに任せることにしました。PMとチーム間のユーザ解像度のギャップが少なければ、PMだけが仕様を決める必要性はあまりないと考えたからです。むしろ実装のプロフェッショナルである開発者やデザイナーの方が、より良い判断をできることもあります。
スクラムイベントに関しては、リファインメントとプランニングは出ず、困ったら声がけしてもらうというスタイルにしました。また、スプリントレビュー後の対応方針の決定や仕様検討は、デザイナーに主導してもらいました。モブでの設計検討やモブデザインを取り入れるなど工夫してもらい、「仕様はチームで決めるもの」ということが徐々に浸透したように思います。
OKRやKPIの決定およびメンテナンス、開発アイテムの優先順位づけは引き続き私が担当しました。
目標決定のプロセスはブラックボックスにせず、チームを積極的に巻き込むことを意識しました。1つ目の学習ループをチームに渡すといっても、目標や方向性がインプットされていて初めて学習が進むと考えるからです。目標はコンテキスト含め丁寧にチームに伝えることを心がけました。
ロードマップ、バックログ上の開発アイテムも同様に背景からチームに説明するようにしていましたが、必ずしもうまく行っていませんでした。これについては後述します。
あとは、折に触れてコミュニケーションを取ることはやめないようにしました。自分自身チームに対して愛着があるのと、「たまにトップダウンで方針だけ言いにくる人」になりたくなかったからです。権限移譲は信頼関係があってこそだと思います。
以上のような形で、すでに半年近く兼務をしていますが、特にアウトプットのクオリティは変わりませんでした。むしろ自分が関わらなくてもユーザー理解のある仕様で機能がリリースされるようになり、感動しました。OKRの進捗や付随するKPIの面でも悪影響は見られませんでした。
自分のリソースの面では、未成熟な新しいチームとの関わりや方針検討に時間を使えたので大変助かっています。
また、「チームを不安にさせてしまうかな」という懸念があったのですが、あるアンケートで「任せてもらえると信頼されていると思え嬉しかった」というコメントをもらえました。
負担を受け入れ、前向きに業務を進めてくれたチームには感謝しかありません。
反省していること
ここまでうまくいったことばかり書いてきましたが、反省点もたくさんあります。代表的なものをご紹介します。
バックログの優先順位が曖昧に
元からいた「サーベイ」チームにタスクの大部分を任せたからといっても、決して余裕があったわけではありません。新規プロダクトのチームでは仕様と方針の両方に関与していましたし、常に忙しい状態でした。
その結果、「サーベイ」チームのバックログアイテムの優先順位付けが自転車操業状態になりました。
優先順位付けは引き続きPMが持つということにしていたのですが、リファインメントの直前に1〜2週間先のバックログアイテムだけ優先度を決めるということが常態化しました。
このせいで長期的なリリース予測ができなかったり、改善/バグチケットのうちどれを優先して実施するかわからなかったり、チームを混乱させてしまいました。
この問題への対処として、リファインメント冒頭に必ず出席し、その場で優先順位について説明するようにしました。また、より先のチケット、細かいチケットの優先度はチームで話し合うスタイルをはじめました。
要件に関する意思決定を手放したい気持ちばかりが先走ったと反省しています。優先度決定、スケジューリングはPM/POとして重要な業務です。やりきれないのであれば早く解決策を考えるべきでした。
仕様が決まらない
要件定義でも複雑なものはチームでの議論がうまく着地しないことがありました。複数の選択肢が出てもどれにするか決まらず、モブの時間を使ってもただただ不安になることもあったようです。
これに関しては、チームのヘルプを受けたタイミングで自分の考えをドキュメントにまとめることで対処しました。
しかし、ヘルプを受けてからではなく、要件についてPMが主体的に会話したり確認したりする場面を作った方が良かったと思っています。また、目標や方針として伝えるべきことを伝えていなかったのかもしれません。チームに任せつつ、抽象度や複雑度が高いものは方針を事前に整理することが重要だと思い知らされました。
マルチプロダクト化に向け、今考えていること
プロダクトマネジメントはPMによって様々な考え方があるかと思いますが、私は開発チームにどっぷりと入り込むスタイルが好きです。チームメンバーと苦楽をともにし、チームと自分の利害が完全に同一になるくらいでちょうどいいと思っています。そして、今まではこのスタイルで成果と信頼関係を獲得してきました。
しかし、弊社はマルチプロダクト化という新しいステージに立っています。1人のPMで複数のプロダクトを見ることが当たり前になるかもしれません。PMとして、チームとのあり方をアンラーンしなければならない部分も出てくると思います。
今回の記事でご説明した兼務の方法が、マルチプロダクトにおけるチームの関わり方の1事例になるといいなと思っています。
全てが上手くできたわけではありませんが、再現性を持ってワークしたと思われる部分を以下にまとめ、本稿の結びとしたいと思います。
- 兼務するしないに関わらず、PMに情報を囲い込まない
- PMだけが知っている情報をできる限り減らせば、チームが自律的に判断できる可能性が上がる
- 方針だけはグリップする
- チームが迷わないようにするために方針や目標は決定プロセスから共有した上で、責任を持つ
- チームの判断を信頼する
- チームのユーザー解像度さえ担保すれば、仕様の議論をチームに任せられる（ことが多い）
- 仕様を自ら考えてもらうことでチームの学習が進む効果もある
- 「たまに方針だけ伝えに来る人」にならない。信頼関係を作る
- PMがトップダウンで目標や方針だけを落とす人にならないよう、少しでもいいのでコミュニケーション接点を作る
PR
現在、SmartHRではテクニカルプロダクトマネージャーを募集しております！
マルチプロダクトを支える、最高に面白いポジションだと思います！エントリーお待ちしております！
エントリーはこちらから
