SHARE

目次

目次

SHARE

リーダーシップとチームマネジメント

プロダクトマネージャー必読!吉羽龍太郎が教える4つのCOREスキル

プロダクトマネージャー必読!吉羽龍太郎が教える4つのCOREスキル

プロダクトマネージャーとして成功するための道を模索するあなたに贈る成長ガイド。理想と現実が交錯する厳しいフィールドで、どのようにスキルと視点を磨き、チームやプロダクトをリードするのか。その秘訣を詳細に解説します。

この記事は、2023年9月5日発売 『プロダクトマネージャーのしごと 第2版 ―1日目から使える実践ガイド』共同訳者の吉羽 龍太郎氏 による connpass勉強会 を再編集し、記事化したものです。

すべてにおいて「銀の弾丸」は存在しない

「 ◯◯の成功事例やベストプラクティスを教えて欲しい」と頻繁に質問されます。最先端の調査研究や他社の輝かしい成功事例を聞きつけると、手当たり次第に導入したくなることを「シャイニー・オブジェクト症候群」と呼びますが、人間の心理として十分に理解できる一方、まずはすべてにおいて「銀の弾丸」が存在しないことを冷静に受け入れましょう。

ベストプラクティスに縛られすぎない

本書の1章では、ベストプラクティスを単なるパッケージと捉え、何も考えずに導入してもあまり意味がないという話を紹介しています。組織やチームはそれぞれ独自の前提条件と制約を持っているため、ベストプラクティスが全ての組織やチームに適用するわけではないのです。重要なのは、固有の状況に応じて柔軟に対応する能力。制約に振り回されるのではなく、ユーザーに価値を提供することに焦点を当てるべきです(ただし、簡単に変更できる制約は変えるべきです)。制約に文句を言うだけの責任転嫁ではなく、制約との適切な付き合い方が求められます。

ベストプラクティスをそのまま受け入れると・・・

  • 厄介で子測不能で絶対に回避できない人間の複雑さを見落とす
  • ベストプラクティスに従わない物事や人はすべて敵に見えるようになる
  • ベストプラクティスが組織の既存の慣習やリズムと衝突する

公開事例は採用広告である、現実を直視せよ

成功事例(公開事例)もベストプラクティスと同様、すべての会社で再現可能なわけではありません。人やタイミングなど、あらゆる要素が絡み合い成功してます。本書は「公開事例は採用広告だ」とはっきり言い切っています。冒頭で紹介したシャイニー・オブジェクト症候群が良い例で、隣の芝生は青く見えるものなのです。あなたがまず実践すべきは「フレームワークは有用なフィクションであると認識し、現実を直視すること」かも知れません。

では、どうすれば良いの?

では、ベストプラクティスを起点にせず、どのように進めていくべきでしょうか。書籍『アジャイルレトロスペクティブズ』の著者であるエスター・ダービー氏が提唱した 「Seven Agile Best Practices」をヒントに解説します。

ベストプラクティスやフレームワークの適用方法

  1. 解決したい問題について深く考える
  2. 問題の根本原因に関する思い込みに疑問をなげかける
  3. 現在のシステムと、それがどのように問題に繋がっているかを理解し、それが問題解決にどのように役立つかを理解する
  4. 状況を改善するための候補となるアクションを複数調査する
  5. より効果的に作用しより良い結果を得るために実験する
  6. 複数の実験をおこない結果を検証する。実際に得られた結果をもとに調整する
  7. これらをイテレーティブかつインクリメンタルに進める

解決したい問題について深く考える

解決したい問題について深く考えるには、まず自組織が直面している問題をはっきりと特定することがスタート地点となります。このプロセスでは、関係者を積極的に巻き込み、効果的なコミュニケーションを実施することが重要です。重要なポイントは、問題の核心に迫るような質問をすることです。質問の仕方を変えてみることで、問題のより深い理解が可能になります。

NG OK
おすすめのロードマップツールは? どのように、会社の内部・外部に次に開発する機能を説明しているか?
おすすめのプロダクトビジョンツールは? どのように(チームを動機づけるために)・未来のビジョンを共有しているか?
おすすめのOKRトラッキングツールは? どのように、会社にとって重要なこと・そうでないことを判断し、伝えているか?
スクラムとカンバンはどっちがいい? どのように、開発するものと開発しないものを判断しているか?
おすすめのワイヤフレームツールは? どのように、初期のプロダクトアイデアを伝えているか?

問題の根本原因に関する思い込みに疑問をなげかける

複雑なシステムは多くの場合、複数の要素の相互作用によって問題が引き起こされています。一つの要素を変更すると、システム全体に影響を及ぼす可能性があります。そのため、どの要素が問題を引き起こしているのか、様々な仮説を立てて検証する必要があります。この過程で、現在のシステムや作業方法が問題とどのように関連しているかを理解することが重要です。この理解をもとに、いくつかのアクションアイテムを特定し、大規模な変更を一気に適用するのではなく、小規模な実験を行いましょう。複数の実験を通じて得られた結果を検証し、そこからさらに調整を行うことが、ベストプラクティスやフレームワークを適用する上での良いアプローチです。問題を中心に据え、小さなステップで仮説を検証しながら進めることが、適切な適用方法と言えるでしょう。

「プロダクトマネジメントの定義」に正解はない

ベストプラクティスや成功事例と同様に、定義や方法に正解はないという話は、プロダクト関連の職種においても存在します。これらの職種に関する役割や責任は、企業やプロジェクトによって大きく異なるため、一概に「これが正しい」とする定義を設けるのは難しいです。 *本書でも ADPR(曖昧に書かれたプロダクト関連の役割)と紹介。

これらの職種の定義は曖昧

  • プロダクトマネージャー
  • プログラムマネージャー
  • プロダクトオーナー
  • プロジェクトマネージャー

それぞれの職種の違いや役割分担について頻繁に質問されますが、実際に気になる企業の募集要項をチェックしてみてください。企業によって職種の定義にかなり曖昧性があることを確認できるはずです。肩書きごとに仕事が重複しないよう明確化しようとするよりも、協力して進めることに集中しましょう。

プロダクトマネージャーに必要な4つのCOREスキル

さて、プロダクトマネジメントにおいて「万人に適用できるフレームワークは存在しない」ことが明らかになりました。次は、これらの課題を達成するうえで、どのようなスキルが必要なのかを紹介します。本書では、4つのスキルの頭文字を取り「COREスキル」と定義しています。プロダクトマネージャーである以上、技術スキルは高い方が良いのですが、実はそれ以上にソフトスキル(知らないことを探求する精神や学ぶ姿勢)の方が重要であると考えています。

  • Communicate:ステークホルダーとコミュニケーションする
  • Organize:持続的に成功するチームを組織化する
  • Research:プロダクトのユーザーのニーズとゴールをリサーチする
  • Execute:プロダクトチームがゴールに到達するための日々のタスクを実行する

COREスキル1「コミュニケーション」:心地よさより明確さを

良いプロダクトマネージャーと悪いプロダクトマネージャーの明確な違いは、相手に伝わるコミュニケーションができるか否かです。

  • 良いプロダクトマネージャー:当たり前のことを必要以上に明確に説明する
  • 悪いプロダクトマネージャー:当たり前のことは絶対に説明しない

自分の “常識” を疑え

良いコミュニケーション(明確さ)とは、喋りの上手さやプレゼン資料の美しさではなく、相手に伝わるコミュニケーションを指します。皆さんが思う以上に、実は組織の中だけで浸透しているルールや言葉が存在します。自分の中では常識であっても、ユーザーやステークホルダーからすれば「?」なこともたくさんあります。

プロダクトゴール、明確に言える?

例えば、あなたの組織では、今チームで追ってるプロダクトゴールを全員が明確に答えられるでし

ょうか。プロダクトオーナーやスクラムマスター以外の人は、結構ふわっとしているかも知れません。自分自身の心地よさを優先して言葉を簡略化したり、カタカナを乱用したり、自分がイケてると思っている言葉遣いは、相手に伝わる言葉なのかを再度、考えてみましょう。

相手の反応も「心地よさより明確さ」を意識すべし

自分の意見に同調されれば、心地のよいものです。しかし、その同調はあまり深く考えず発せられたものかも知れません。相手の反応にも「心地よさより明確さ」を意識し、より深堀してみると、今まで見えて来なかった意見を聞き出せるかも知れません。

沈黙イコール同意ではない「Disagree & Commit」

では、どのように相手の同意が真意であるかを見極めるのでしょうか。本書で紹介している「Disagree & Commit」がヒントになるかもしれません。考え方は下記の4つです。

Disagree & Commit

  1. 集団での合意形成の際に、全員の明示的な表明を必要とする
  2. 判断を下す前に、参加者全員が具体的で積極的なコミットメントを示す
  3. コミットメントを示せないなら、質問や反対を表明する
  4. 沈黙は暗黙の同意とみなさず、積極的なコミットメントだけを同意とみなす

参加者の発言が無いとき一般的にそれを「賛成」と見なす風潮がありますが、Disagree & Commit では明示的な賛成のみを「賛成」とみなします。複数のステークホルダーが参加するミーティングで、この方法を使うと、これまで明らかにされていなかったインサイトに辿り着けるはずです。

ステークホルダーとのコミュニケーション術

プロダクトマネージャーが頻繁に関わるステークホルダーとの付き合い方のポイントは、ステークホルダーからの信頼を勝ち取ることです。最終的な決定権を持つのは、お金と権限のあるステークホルダーです。抵抗するのではなく、ステークホルダーに正確な情報を提供し、ステークホルダーから評価されるパートナーになることが鍵です。

COREスキル2「組織化」:自らを不要とせよ

自律的で機能するチームの構築、つまり「自分がいなくてもチームが機能し続ける」ことを目指すことが大切です。プロダクトマネージャーはチームメンバーからの依存を減らし、彼らが自分自身で問題を解決し、決定を下せるようにすることが求められます。例えば、プロダクトマネージャーが長期間休んでも、チームが効率的に機能し続けるような環境理想的といえるでしょう。

プロダクト開発は基本的にチームスポーツです。個々の能力の向上も重要ですが、チーム全体の能力を高めることが、最終的な成果の最大化につながります。チームメンバーが自己管理し、共同で目標に向かうことができるようなチーム環境を育成することが、プロダクトマネージャーにとっての重要な仕事となります。

組織化のポイント

  • チームから「何をすればいいか?」と聞かれる状況は何らかの問題が存在する兆候
  • チームが自己持続的な仕組みに基づいて動けるよう、人、プロセス、ツールを整備する
  • チーム全体の能力向上こそが結果の最大化につながる

マンネリ打破もプロダクトマネージャーのしごと

長期的なプロダクト運営では、チームが「自動操縦モード」に入り、新鮮味を失うことがあります。そういった局面で新しい挑戦的なアイディアをチームに投入し、共に学習することもプロダクトマネージャーの仕事です。

チームを売るようなマネージャーになるな

またチームには良いときも悪いときもあります。困難な状況が生じた場合、プロダクトマネージャーには、チームを守る責任もあります。プロダクトが成功しない理由をチームに求めるようなマネージャーは、信頼を失います。良いチームが形成されれば、次の機会に成功する確率も上がるため、良いチームを構築することは極めて重要です。

COREスキル3「リサーチ」: ユーザーの現実に生きよ

納期の遵守やプロダクトバックログのメンテナンス、収益計算は組織にとっては重要ですが、ユーザーに直接関係するものではありません。本当に重要なのは、「このプロダクトがユーザーにとってどのような意味を持つか」ということ。プロダクトの成功は、ユーザーのニーズと目的を深く理解することから始まります。ユーザーと話した結果、次に何をすべきか決めるのは、そのプロダクト提供側が考えるべきこと。ユーザーに機能を考えさせる必要はありません。

賢く見せるより知らないふりを

ユーザーとのコミュニケーションの目的は、彼らに「意思決定」を強いることではありません。彼らのニーズや使用方法を学ぶことです。そのためには自分自身を賢く見せるより知らないふりをしながら彼らの話に耳を傾けることが効果的です。例えば、ユーザーに対して「足りない機能は何ですか?」と聞くのではなく「今、どのように使っていますか?」と聞くようにしましょう。

そのデータ、虚栄の指標かも

「データ」という言葉は、具体性がなくても権威性を持つ

多くの企業やリーダーは、データという言葉に権威を感じ、定量化の重要性を強調します。もちろんプロダクトマネジメントにおいても、データは不可欠な要素です。しかしデータを単に収集するだけでは、意味がありません。適切な指標を選定し、それらがプロジェクトにどのように貢献するかを理解することが重要です。

どの指標がなぜ重要なのか説明できなければ「虚栄の指標」

「そのデータはなぜプロダクトやチームに必要なのか」を理解したうえでデータ収集しましょう。やみくもにデータ収集をしても意味がありません。なぜ重要なのかを説明できないデータは、虚栄の指標です。

データという言葉を一切使わないで表現すると具体的になる

「データ」という言葉を使わないで表現すると、議論がより具体的になります。虚栄の指標に惑わされることなく、実際にプロジェクトに影響を与える指標に焦点を当てることが大切です。

チームの取り組みの優先順位をつけるために使う

データは、チームの取り組みの優先順位を決定するための重要な材料です。しかし、これを個人の成功や失敗を評価するために使用するのではなく、プロジェクトの方向性や意思決定を支えるために利用します。全てのデータが常に手に入るわけではないため、時には決断し、その後で結果を検証する必要もあります。

COREスキル4「実行」: すべての努力はアウトカムのために

すべての努力はアウトカムのために

単に頑張りをアピールするだけでは不十分です。重要なのは、その努力が実際にアウトカムに結びついているかどうかです。プロダクトマネージャーは膨大な業務の中から、実際に成果につながる業務を見極める能力が求められます。

絶対に必要な「優先順位」

やりたいことは多いものの、すべてを実行する時間は限られています。そのため、優先順位付けは実行において極めて重要な要素となります。優先順位をつける際には、単にチームの意見や短期的な視点に基づくのではなく、会社のゴール、戦略、プロダクトビジョン、ユーザーのインサイトなど、幅広い要素を総合的に考慮する必要があります。

ステークホルダーの意見とユーザーの視点

ステークホルダーの意見は重要な要素ではありますが、それがユーザーにとって意味をなさない場合は、優先順位を下げる必要があります。優先順位付けは、最も価値のある成果を生み出せるように行うべきです。

アウトカムを中心に据えた実行

実行の際には、アウトカムを中心に据えて行動することが重要です。単に作業することに注力するのではなく、その作業が最終的にどのような成果をもたらすのかを常に意識することが求められます。

まとめ:理想と現実は違う

本書は、現実主義に基づいています。理想と現実が大きく異なる状況でも、とにかく仕事を進めていかなければなりません。そのために、4つのCOREスキルを提案しています。今回は時間の制約からエッセンスだけを抜粋してお話しましたが、詳細はぜひ本書でご確認ください。また、あなたの会社でも是非、読書会を開いてみてください。

アーカイブはこちら

Forkwellキャリア相談

フォークウェルプレス編集部

Follow

記事一覧へ

本サイト掲載の全て記事は、フォークウェル編集部が監修しています。編集部では、企画・執筆・編集・入稿の全工程をチェックしています。

吉羽さん画像
吉羽 龍太郎
株式会社アトラクタ

取締役CTO / アジャイルコーチ / 『チームトポロジー』共訳者

野村総合研究所、Amazon Web Servicesなどを経て現職。Scrum Alliance 認定スクラムトレーナー(リージョナル)(CST-R) / 認定チームコーチ(CTC) / Microsoft MVP for Azure。著書に『SCRUM BOOT CAMP THE BOOK』(翔泳社)など、訳書に『スクラム実践者が知るべき97のこと』『プロダクトマネジメント』『レガシーコードからの脱却』など多数。