目次
■リーダーシップとチームマネジメント
2023.11.24 2024.03.15 約4分
プロダクトマネージャーとして成功するための道を模索するあなたに贈る成長ガイド。理想と現実が交錯する厳しいフィールドで、どのようにスキルと視点を磨き、チームやプロダクトをリードするのか。その秘訣を詳細に解説します。
この記事は、2023年9月5日発売 『プロダクトマネージャーのしごと 第2版 ―1日目から使える実践ガイド』共同訳者の吉羽 龍太郎氏 による connpass勉強会 を再編集し、記事化したものです。 |
「 ◯◯の成功事例やベストプラクティスを教えて欲しい」と頻繁に質問されます。最先端の調査研究や他社の輝かしい成功事例を聞きつけると、手当たり次第に導入したくなることを「シャイニー・オブジェクト症候群」と呼びますが、人間の心理として十分に理解できる一方、まずはすべてにおいて「銀の弾丸」が存在しないことを冷静に受け入れましょう。
本書の1章では、ベストプラクティスを単なるパッケージと捉え、何も考えずに導入してもあまり意味がないという話を紹介しています。組織やチームはそれぞれ独自の前提条件と制約を持っているため、ベストプラクティスが全ての組織やチームに適用するわけではないのです。重要なのは、固有の状況に応じて柔軟に対応する能力。制約に振り回されるのではなく、ユーザーに価値を提供することに焦点を当てるべきです(ただし、簡単に変更できる制約は変えるべきです)。制約に文句を言うだけの責任転嫁ではなく、制約との適切な付き合い方が求められます。
ベストプラクティスをそのまま受け入れると・・・
|
成功事例(公開事例)もベストプラクティスと同様、すべての会社で再現可能なわけではありません。人やタイミングなど、あらゆる要素が絡み合い成功してます。本書は「公開事例は採用広告だ」とはっきり言い切っています。冒頭で紹介したシャイニー・オブジェクト症候群が良い例で、隣の芝生は青く見えるものなのです。あなたがまず実践すべきは「フレームワークは有用なフィクションであると認識し、現実を直視すること」かも知れません。
では、ベストプラクティスを起点にせず、どのように進めていくべきでしょうか。書籍『アジャイルレトロスペクティブズ』の著者であるエスター・ダービー氏が提唱した 「Seven Agile Best Practices」をヒントに解説します。
ベストプラクティスやフレームワークの適用方法
|
解決したい問題について深く考えるには、まず自組織が直面している問題をはっきりと特定することがスタート地点となります。このプロセスでは、関係者を積極的に巻き込み、効果的なコミュニケーションを実施することが重要です。重要なポイントは、問題の核心に迫るような質問をすることです。質問の仕方を変えてみることで、問題のより深い理解が可能になります。
NG | OK |
おすすめのロードマップツールは? | どのように、会社の内部・外部に次に開発する機能を説明しているか? |
おすすめのプロダクトビジョンツールは? | どのように(チームを動機づけるために)・未来のビジョンを共有しているか? |
おすすめのOKRトラッキングツールは? | どのように、会社にとって重要なこと・そうでないことを判断し、伝えているか? |
スクラムとカンバンはどっちがいい? | どのように、開発するものと開発しないものを判断しているか? |
おすすめのワイヤフレームツールは? | どのように、初期のプロダクトアイデアを伝えているか? |
複雑なシステムは多くの場合、複数の要素の相互作用によって問題が引き起こされています。一つの要素を変更すると、システム全体に影響を及ぼす可能性があります。そのため、どの要素が問題を引き起こしているのか、様々な仮説を立てて検証する必要があります。この過程で、現在のシステムや作業方法が問題とどのように関連しているかを理解することが重要です。この理解をもとに、いくつかのアクションアイテムを特定し、大規模な変更を一気に適用するのではなく、小規模な実験を行いましょう。複数の実験を通じて得られた結果を検証し、そこからさらに調整を行うことが、ベストプラクティスやフレームワークを適用する上での良いアプローチです。問題を中心に据え、小さなステップで仮説を検証しながら進めることが、適切な適用方法と言えるでしょう。
ベストプラクティスや成功事例と同様に、定義や方法に正解はないという話は、プロダクト関連の職種においても存在します。これらの職種に関する役割や責任は、企業やプロジェクトによって大きく異なるため、一概に「これが正しい」とする定義を設けるのは難しいです。 *本書でも ADPR(曖昧に書かれたプロダクト関連の役割)と紹介。
これらの職種の定義は曖昧
|
それぞれの職種の違いや役割分担について頻繁に質問されますが、実際に気になる企業の募集要項をチェックしてみてください。企業によって職種の定義にかなり曖昧性があることを確認できるはずです。肩書きごとに仕事が重複しないよう明確化しようとするよりも、協力して進めることに集中しましょう。
さて、プロダクトマネジメントにおいて「万人に適用できるフレームワークは存在しない」ことが明らかになりました。次は、これらの課題を達成するうえで、どのようなスキルが必要なのかを紹介します。本書では、4つのスキルの頭文字を取り「COREスキル」と定義しています。プロダクトマネージャーである以上、技術スキルは高い方が良いのですが、実はそれ以上にソフトスキル(知らないことを探求する精神や学ぶ姿勢)の方が重要であると考えています。
|
良いプロダクトマネージャーと悪いプロダクトマネージャーの明確な違いは、相手に伝わるコミュニケーションができるか否かです。
|
良いコミュニケーション(明確さ)とは、喋りの上手さやプレゼン資料の美しさではなく、相手に伝わるコミュニケーションを指します。皆さんが思う以上に、実は組織の中だけで浸透しているルールや言葉が存在します。自分の中では常識であっても、ユーザーやステークホルダーからすれば「?」なこともたくさんあります。
例えば、あなたの組織では、今チームで追ってるプロダクトゴールを全員が明確に答えられるでし
ょうか。プロダクトオーナーやスクラムマスター以外の人は、結構ふわっとしているかも知れません。自分自身の心地よさを優先して言葉を簡略化したり、カタカナを乱用したり、自分がイケてると思っている言葉遣いは、相手に伝わる言葉なのかを再度、考えてみましょう。
自分の意見に同調されれば、心地のよいものです。しかし、その同調はあまり深く考えず発せられたものかも知れません。相手の反応にも「心地よさより明確さ」を意識し、より深堀してみると、今まで見えて来なかった意見を聞き出せるかも知れません。
では、どのように相手の同意が真意であるかを見極めるのでしょうか。本書で紹介している「Disagree & Commit」がヒントになるかもしれません。考え方は下記の4つです。
Disagree & Commit
|
参加者の発言が無いとき一般的にそれを「賛成」と見なす風潮がありますが、Disagree & Commit では明示的な賛成のみを「賛成」とみなします。複数のステークホルダーが参加するミーティングで、この方法を使うと、これまで明らかにされていなかったインサイトに辿り着けるはずです。
プロダクトマネージャーが頻繁に関わるステークホルダーとの付き合い方のポイントは、ステークホルダーからの信頼を勝ち取ることです。最終的な決定権を持つのは、お金と権限のあるステークホルダーです。抵抗するのではなく、ステークホルダーに正確な情報を提供し、ステークホルダーから評価されるパートナーになることが鍵です。
自律的で機能するチームの構築、つまり「自分がいなくてもチームが機能し続ける」ことを目指すことが大切です。プロダクトマネージャーはチームメンバーからの依存を減らし、彼らが自分自身で問題を解決し、決定を下せるようにすることが求められます。例えば、プロダクトマネージャーが長期間休んでも、チームが効率的に機能し続けるような環境理想的といえるでしょう。
プロダクト開発は基本的にチームスポーツです。個々の能力の向上も重要ですが、チーム全体の能力を高めることが、最終的な成果の最大化につながります。チームメンバーが自己管理し、共同で目標に向かうことができるようなチーム環境を育成することが、プロダクトマネージャーにとっての重要な仕事となります。
組織化のポイント
|
長期的なプロダクト運営では、チームが「自動操縦モード」に入り、新鮮味を失うことがあります。そういった局面で新しい挑戦的なアイディアをチームに投入し、共に学習することもプロダクトマネージャーの仕事です。
またチームには良いときも悪いときもあります。困難な状況が生じた場合、プロダクトマネージャーには、チームを守る責任もあります。プロダクトが成功しない理由をチームに求めるようなマネージャーは、信頼を失います。良いチームが形成されれば、次の機会に成功する確率も上がるため、良いチームを構築することは極めて重要です。
納期の遵守やプロダクトバックログのメンテナンス、収益計算は組織にとっては重要ですが、ユーザーに直接関係するものではありません。本当に重要なのは、「このプロダクトがユーザーにとってどのような意味を持つか」ということ。プロダクトの成功は、ユーザーのニーズと目的を深く理解することから始まります。ユーザーと話した結果、次に何をすべきか決めるのは、そのプロダクト提供側が考えるべきこと。ユーザーに機能を考えさせる必要はありません。
ユーザーとのコミュニケーションの目的は、彼らに「意思決定」を強いることではありません。彼らのニーズや使用方法を学ぶことです。そのためには自分自身を賢く見せるより知らないふりをしながら彼らの話に耳を傾けることが効果的です。例えば、ユーザーに対して「足りない機能は何ですか?」と聞くのではなく「今、どのように使っていますか?」と聞くようにしましょう。
多くの企業やリーダーは、データという言葉に権威を感じ、定量化の重要性を強調します。もちろんプロダクトマネジメントにおいても、データは不可欠な要素です。しかしデータを単に収集するだけでは、意味がありません。適切な指標を選定し、それらがプロジェクトにどのように貢献するかを理解することが重要です。
「そのデータはなぜプロダクトやチームに必要なのか」を理解したうえでデータ収集しましょう。やみくもにデータ収集をしても意味がありません。なぜ重要なのかを説明できないデータは、虚栄の指標です。
「データ」という言葉を使わないで表現すると、議論がより具体的になります。虚栄の指標に惑わされることなく、実際にプロジェクトに影響を与える指標に焦点を当てることが大切です。
データは、チームの取り組みの優先順位を決定するための重要な材料です。しかし、これを個人の成功や失敗を評価するために使用するのではなく、プロジェクトの方向性や意思決定を支えるために利用します。全てのデータが常に手に入るわけではないため、時には決断し、その後で結果を検証する必要もあります。
単に頑張りをアピールするだけでは不十分です。重要なのは、その努力が実際にアウトカムに結びついているかどうかです。プロダクトマネージャーは膨大な業務の中から、実際に成果につながる業務を見極める能力が求められます。
やりたいことは多いものの、すべてを実行する時間は限られています。そのため、優先順位付けは実行において極めて重要な要素となります。優先順位をつける際には、単にチームの意見や短期的な視点に基づくのではなく、会社のゴール、戦略、プロダクトビジョン、ユーザーのインサイトなど、幅広い要素を総合的に考慮する必要があります。
ステークホルダーの意見は重要な要素ではありますが、それがユーザーにとって意味をなさない場合は、優先順位を下げる必要があります。優先順位付けは、最も価値のある成果を生み出せるように行うべきです。
実行の際には、アウトカムを中心に据えて行動することが重要です。単に作業することに注力するのではなく、その作業が最終的にどのような成果をもたらすのかを常に意識することが求められます。
本書は、現実主義に基づいています。理想と現実が大きく異なる状況でも、とにかく仕事を進めていかなければなりません。そのために、4つのCOREスキルを提案しています。今回は時間の制約からエッセンスだけを抜粋してお話しましたが、詳細はぜひ本書でご確認ください。また、あなたの会社でも是非、読書会を開いてみてください。