目の前のボール拾いと長期ロードマップを両立する、地図・コンパス・チームビルディング
こんにちは。LayerXのmichiru_daです。
本記事はpmconf主催のプロダクトマネージャー Advent Calendar 2023 18日目の記事です。
昨日の記事は、PaW | Yuma Konishiさんの「フリーランスPMって成り立つの？」に対する1年やってみての回答 でした。
目の前にボールがありまくる、共通管理チームの悩み
私は現在、コンパウンドスタートアップでSaaSの共通管理（認証・ユーザー情報の管理基盤）のPMをしています。
スタートアップで働いていると、「フォーカスが大事」「とはいえやりたいことはどんどん出てくる」「差し込みタスクが多く、集中出来ていない…」という状況が度々発生するのではないでしょうか。
所属している共通管理チームでも、以下の様な条件が揃い、対応しかかったイシューが山積みな状態が起きていました。
・自分含め、好奇心旺盛で「ボールを拾う人が偉い」の体現メンバーが集まる
・全ユーザーが使う機能を提供しており、想定せぬユースケースへの対処など、緊急度が高い問題が頻繁に発生
・他プロダクトのイシューにも巻き込まれがち、各種開発wgに参加しがち
各種ユースケースへの対応や各種プロダクトとの連携は、共通管理チームだからこそ価値が出せる取り組みですが、
目の前で落ちまくるボールを夢中で拾っていると、気づいた時には「当初やると決めた大玉の新機能開発が遅れがちになっている…」のような状況にも繋がってしまいます。
記事の概要と想定読者
本記事では、「効果の大きいボールを拾う」ことと、「意思をもって目の前のボールを拾わずに仕込みにリソースを注ぐこと」を両立するために、チームで意識的に工夫している仕組みと難しさ、大事にしていることをにまとめています。
特に、プロダクトマネージャーやxOpsなど、関係者が多い組織にいる方のお役にたてますと幸いです。
前提：地図とコンパスの準備
前提① 地図: 理想と実現ステップを明らかにする
まず、目標の定義と逆算したアクションプランを計画します。
弊社ではOKRで目標管理をしており、〜1年半で実現したいプロダクトバリューを半期のObjectiveにブレイクダウンし、さらにKey Resultに分解する形を取っています。
目標を定義する際は、絶対に達成する/できれば実現したい/優先度が劣後するように優先度をつけ、最優先でない事項についても、取り組み方をチーム内で具体的に合意しておきます。
例：大玉機能が最優先Aであるが、スケジュールに影響が出ない、1スプリントに1つ軽微な機能改善を行う
前提② コンパス: 定期の進捗確認・優先度やアクションの見直し
地図を定めたら、目標にむけてアクションを行いますが、その実践は定期的な見直しを伴うものでなければなりません。
進む方向の見直しのタイミングには、2週に1度のスプリントプランニングと、毎日の夕会を活用しています。
スプリントプランニングの際には必ず、四半期OKRと達成状況も確認しながらスプリントゴールを決めているほか、
毎日の夕会でも曜日ごとに定例アジェンダを設けています。
夕会での「コンパス」運用
例1：月曜→取り組むイシューの優先度を見直し
例2：水曜→採用などの重要だが後回しにしやすいアクションの進捗を確認
これらのタイミングで、大筋正しい方向に進めていることを確認しつつ、必要に応じて差し込みタスクの実施を判断しています。
が、地図とコンパスだけでは上手くいかない
言うのは易しですが、「地図とコンパスで、優先度決め→実行→見直しを徹底する」には実践の難しさもあります。
たとえば、チームメンバーが自身の関心事を追求する機会が限られることでモチベーションや満足感に影響を及ぼし得たり、
頻繁な進捗確認は、メンバーが監視・管理されていると感じてしまい生産性の低下を招く可能性もあります。
実際に、地図とコンパスを使い始めた共通管理チームでも、以下の状態が生じました。
あえて「目の前のボールをやらない」意思決定をしたときに、「大玉開発だけに集中する状態は本当に健全なのか？それしかやらなくて良いのか？」という迷いが生じた
大玉開発のプランニング・進捗確認をやろうとしたときに、開発メンバーから「計画は変更される可能性もあるが、今進捗を可視化しようとするのはなぜか？どこまで計画する必要があるのか？」という意見が出てきた
チームビルディング：仕組みより対話を通してチームが強くなる
これらの問題点にどう対応していくかですが、
結論、仕組みよりも、チームで違和感や認識ズレをいち早く察知し、都度コミュニケーションをしつづけることが大切です。
特に重要だと考えているのは以下の3点ですが、対処方法はすべて「コミュニケーションをやりきる」だと考えています。
1.目指す目標にメンバーがワクワクできる
2.目標達成のための手段に納得感がある
3.全メンバーが、日々ボトムアップ的に意見や違和感を表明できる
1.目指す目標にメンバーがワクワクできる
前提として、目指す目標は、メンバーがワクワクできるものであるべきです。
弊社のプロダクトチームでは、最終的な意思決定をプロダクトマネージャーが行うことが多いですが、過程では必ず開発チームとディスカッションを行うようにしています。
背景として、LayerXでは「disagree & commit」を大切にする文化があり、同意/違和感があれば意思表明をしたうえで、決まった決定にはコミットするスタンスが推奨されているためです。
また、人は自分の意見に耳を傾けてもらうと、最終的に自分の意見と違う決定がされてもコミットしやすい傾向*もあるそうで、目標決める過程でメンバー全員とオープンに議論を行うことで、全員のむいている方向を揃えていくことができます。
*参考:「あなたのチームは機能していますか？」
2.目標達成のための手段に納得感がある
たとえば、大きな機能を開発することになった際、達成までのマイルストーンを設定・見積りを行い、計画を可視化するのはなぜでしょうか。
これは「単にマネージャーが管理をしたいから」ではありません。
計画と現状のギャップを可視化できれば、当初の想定と違う状況が起きているときに早期検知でき、状況に応じて柔軟に戦術を変更することで理想を実現する確率を上げることができるからです。
しかし、これらは明確に言葉にしないと伝わりません。
何も言わなければ、実際に手を動かすエンジニアの目線だと「スケジュールへのコミットを強制・管理されているのではないか？」というモヤモヤを抱く可能性もあるのではないでしょうか。
自分は当たり前だと思っていることでも、立場が違えば異なる受け取られ方が生じます。
日々どのようなチーム運営を行うかも、
・WHYを明瞭にしながら施策を策定し
・フィードバックを受けながら実行する
ことで、全員が同じ目的で取り組むことができ、結果として施策の効果を最大にできるのかなと感じます。
3.全メンバーが、日々ボトムアップ的に意見や違和感を表明できる
1、2の実現のためには、チームメンバーが自分の意見や違和感をすぐに言える状態を作ることも大切です。
共通管理チームでは、各種mtgで積極的にファシリテーターからメンバーへ問いかけを行うようにしています。
これは「自分の意見はチームで受け止められ、良い意見だった場合、チーム運営にもフィードバックをかけられる」というサイクルを作るためです。
また、これらを繰り返すと、チームで計画を可視化・見直すなかで「そもそも目指したい理想ってこれだっけ？」や「最高なチームの状態は？」のような、チームビジョンをすり合わせるタイミングも生まれやすくなります。
定期mtgをきっかけに目標そのものがブラッシュアップされることもあるので、チーム全体でのフラットなコミュニケーションが中長期のアウトカム実現確度を高めると感じます。
おわりに
以上を工夫することで、共通管理チームでは、最も重要な課題に集中し、結果としてユーザー様に最速・最大の価値を届けられると信じています。
現状、LayerXでは「重要イシューにフォーカスできるチーム」づくりの真っ最中です。
本記事も試行錯誤の過程ですし、まだまだ課題は山積みなので、皆さんのお困りごとや、取り組みもディスカッションさせていただけると嬉しいです！
👇1月末に交流わいわいイベントやるよ👇
👇カジュアル面談フォーム👇