曽根原春樹のレビュー一覧
-
-
-
-
-
-
-
-
-
-
-
-
-
Posted by ブクログ
プロダクトマネージャーの仕事に必要な領域はビジネス、UX、テクノロジーの３つである。ビジネスはプロダクトが市場でユーザーを獲得し、収益を上げることができるかを判断する領域。UXはユーザーが本当に求めているものを発見し、使われる形で提供するための領域。テクノロジーはその実現可能性を判断する領域である。
■プロダクトマネージャーに必要なスキル
・計画力
・実行力
・仮説検証力
・リスク管理力
・チーム構築力
・発想力
■North Star Metric
①NSMの改善がユーザー体験の向上とリンクしている
②ユーザーがプロダクトにどのくらい定着しているかを示す
③NSMを目指すことでx軸に時間、y軸に収益や成長目標を取ったグラフが長期的には右上方向に進む
④収益に結びつくための先行指標である
⑤組織内で理解してもらいやすい
例：Zoom
①音声画像が高品質なビデオ会議をどこよりも簡単に実施できる
②１週間あたりのミーティング数は新規ユーザーや既存ユーザーが増えるに従って大きく増える
③収益KGIを達成するためには有料ユーザーが増えなければならず、１週間あたりのミーティング数が増え続けると、有料ユーザー数も増えることにつながる
④１週間あたりのミーティング数が増えないことにはそもそも収益も増えない
⑤どのようなバックグラウンドの人でもわかりやすい
・NSMを達成するための主要因の例
NSM：会員の総閲覧時間
→ユーザーが記事を読んでくれる／ユーザーが記事を元にアクションする(プッシュ通知への反応、ユーザー間の議論やコメント)／ユーザーを引きつける豊富かつ良質なコンテンツの数
…PMMは一般的にマーケティング部門の中に存在し、プロダクトマネージャーとPMMが協働し、PMMが他のマーケティング部門のメンバーと議論をしてGTMの際の制約条件や考慮すべき点などを織り込む。
■デザイン６原則
①可視性
②フィードバック
③アフォーダンス
④マッピング
⑤制約
⑥統一感
■ビジュアル階層化の５つのポイント
①サイズと色
②近接性
③並び
④繰り返し
⑤コントラスト
ウォーターフォール開発ではプロダクトのCore、Why、Whatをあらかじめ定義してから、プロダクトのHowに取りかかる。一方でアジャイル開発では本書で解説してきたフローと同様にプロダクトのCoreからHowの階層を上下に行き来しながら仮説検証をすることができる。
■プロダクトマネージャーのためのセルフチェックリスト
□プロダクトが目指すべきビジョンをもっているか?
□自社独自の価値がはっきりしているか?
□市場をつくりあげる気概をもっているか?
□ユーザーとの対話の機会をもっているか?
□ユーザーのいっていることから、なぜそれが求められているかを深く考えているか?
□チームメンバーやステークホルダーとの関係に気を配っているか?
□関係者とは調整ではなく、相談・交渉・説得できているか?
□いわれたことであっても、自分が納得したうえで実行しているか?
□Noというべきときは、Noといえているか?
□プロダクトの方向性やターゲットユーザーを考えたうえで、競合を意識しているか?
□ユーザーのニーズに合わせてプロダクトを変容させているか?
□適正価格を見つけることにしかるべき時間をかけているか?
□優先度をつけているか?
□失敗を価値ある学びに変えられているか?
□データを活用しているか?
□直感に頼る前に時間の許す限り調べたか?
□ふりかえりを続けながら磨き上げているか?
□つねに学び続けているか?
2023/2/4追記
9.1 代表的な他の役割との責任分担
一般的にプロダクトマネージャーが所属するチームは2つある。1つはプロダクトマネージャー自身が率いるプロダクトをつくるプロダクトチーム、もう1つはプロダクトマネージャー自身が所属する機能型組織である(図表9-1)。つまり、プロダクトマネージャーは2つのチームとのコミュニケーションが必要になる。Chapter9では前半で、主にコミュニケーションを取る2つのチームメンバーとの役割分担について述べ、後半ではプロダクトマネージャーが所属する機能型組織における複数人のプロダクトマネージャーと分業について解説する。
9.1.1 ステークホルダーとの関係性
プロダクトマネージャーが仕事をするうえで重要なことは、ステークホルダーとの関係性である。プロダクトマネージャーがどの範囲の意思決定ができて、何を誰と相談して決定するのかをはじめに明らかにしておきたい。CEOなどの権限をもっている人から意思決定をする権限を譲り受けることを「権限を委譲される」という。
誰が何の権限をもっているのか、意思決定にどのように関与するのかを可視化するため、DACIという手法がある。決定する事項ごとに、推進者(Driver)、承認者 (Approver)、貢献者(Contributor)、報告先(Informed)の権限を誰がもっているのかをあらかじめ合意をしておくことで、その後のコミュニケーションがスムーズになる。意思決定プロセスを明確にすることで、承認者が不明確な状態なまま進み意思決定が遅くなることや、合議制によって凡庸な結論となること、さらにはステークホルダーによる予期せぬ介入を避けることができる。
図表9-2にDACIの記載例を示す。行に検討事項、列にステークホルダーを記している。ビジョンの策定はプロダクトマネージャーが事業責任者とプロダクトマーケティングマネージャー(PMM)の力を借りながら推進し、CEOに承認をもらうことを意味している。セグメントの選定に関してはCEOの承認を得ずとも、プロダクトマネージャーの権限で意思決定をすることができる。
基本的には1人の担当者は1つの役割に専念するのが鉄則となる。推進者(D)と承認者(A)はできれば別の担当者にし、レビューを得られる体制をつくることが好ましい。しかし実際の現場においては、1人の担当者が複数の役割を担うこともある。
図表9-2ではプロダクトマネージャーが「セグメント選定」にて、推進者(D)と承認者(A)を兼任することとした。とくに小さいチームにおいてはプロダクトマネージャーが自ら推進者(D)として手を動かし承認者(A)として決定をすることもある。
ただやはり、推進者(D)と承認者(A)が同一になることで、推進者以外のチェックがされていない意思決定となるため、重要な意思決定に関しては役割を兼任しないことが望ましい。
9.1.2 プロダクトチームとの関係性
役割の認識を合わせるべき相手は、ステークホルダーだけではない。プロダクトチームのメンバーにも極限を委譲する。チームメンバーの責任分担を明確にするために、RACIという手法が存在する。タスクごとに実行責任者(Responsible)、説明責任者(Accountable)、協業先(Consulted)、報告先(Informed)を決めておく手法である。
DACIは意思決定者を明示するツールであるのに対し、RACIはタスクを完了する責任をもつ人を可視化するためのツールであるといわれる。RACIには2種類の責任者がおり、タスクが完了するまで実行することに責任をもつのが実行責任者(R)、成果物をレビューして外部に対して成果物の説明責任を負うのが説明責任(A)である。基本的に成果物をレビューする説明責任者(A)は1人でなければならないといわれている。
図表9-3にRACIの記載例を示す。プロダクトマネージャーがバックログを作成し、説明責任(A)をもち、エンジニアのリーダーとエンジニアが協業(C)し、QA担当者に報告(I)する。
工数の見積りに関しては、受け取ったバックログを元にエンジニアがQA担当者と協力(C)しながら実行(R)し、その結果をエンジニアのリーダーがレビュー(A)することを表している。
RACIにはいくつもの派生物があり、実行責任者に加えて、実際の作業を行うサポート(Support)を追加したものや、アジャイル開発手法を用いる場合にファシリテーター(Facilitator)を追加したものなどがある。プロダクトや組織に合わせて最適なものを選んでほしい。
RACIを利用してプロダクトチーム内の責任分担を議論したら、プロダクトマネージャーはなぜその人がその権限をもっているのかをチームに説明し、役割が名前だけにならないようにサポートをする必要がある。誰が何を決めることができるのか、何をするときに誰を巻き込まなければいけないのかが明確になっていない組織は拡大しない。説明責任者(A)がいるにもかかわらず、実際にはプロダクトマネージャーがすべての説明責任を負ってしまうことがないように気をつけなければならない。
RACIやDACIを活用してタスク別に責任範囲を明確にすることも必要であるが、人と人との関係性そのものを意識しておくことも重要となる。プロダクトマネージャーはコミュニケーションを取る相手がとても多いため、関係者とのコミュニケーションを戦略的に実施するために、図表9-4のように関係者間の相関を図に表しておくとよい。
関係者間の相関図には自分と相手との現在の関係の強さと、今後の改善の方針を書き込んでおけば、後ほどふりかえるときに役に立つ。たとえば、10段階で相手との関係性を評価し括弧内に今後関係性を強めたい相手にはプラス、もう少し距離を取ってもよい相手にはマイナスの数値を記す。
あまり関係性が構築できていない相手とコミュニケーションを取ることにはハードルを感じるが、数値で可視化すると自らの背中を押す効果もある。可視化を定期的にふりかえりコミュニケーションを評価しておくことで、抜け漏れなくよい関係性を維持しやすくなる。
9.1.3 プロダクトマーケティングマネージャーとの関係性
プロダクトマーケティングマネージャー(PMM)は、ビジョン達成に向けてプロダクトが提案する価値に共感するユーザーを探し、プロダクトを届ける役割である。スタートアップではプロダクトマネージャーがPMMを兼任することもあるが、組織が大きくなると独立したPMMの必要性が増してくる。
図表9-5のようにPMMは一般的にマーケティング部門の中に存在し、プロダクトマネージャーと対等な関係である。マーケティング戦略を組み立てるときにプロダクトマネージャーとPMMが協同し、PMMが他のマーケティング部門のメンバーと議論をしてGTMの際の制約条件や考慮すべき点などを盛り込む。
大きな組織ではプロダクトマネージャーがマーケティング部門の一人ひとりとコミュニケーションしたり議論したりするのは時間がかかってしまうが、PMMが最適なGTM戦略の立案や実行のためにプロダクトマネージャーと伴走する。PMMはマーケットや競合分析を手がけ、PMFを見つける部分を助けたり、プロダクト施策を考察したりする。プロダクトマネージャーはしかるべきユーザー向けによいプロダクトをつくって棚に置くのが仕事であり、PMMはしかるべきユーザーにそのプロダクトを棚から取ってもらうよう仕かけるのが仕事である。
9.1.4 その他の機能型組織のマネージャーとの関係性
プロダクトチームに属するメンバーの機能型組織のマネージャーとの関係構築もプロダクトマネージャーにとっては重要な仕事となる。プロダクトマネージャーと機能型組織のマネージャーでは責任範囲の違いから判断軸が異なることがよく起きる。たとえば、機能型組織のマネージャーであるエンジニアリングマネージャーとプロダクトマネージャーの関係を見てみる。エンジニアリングマネージャーはエンジニアリング組織の健全な成長に責任をもつ存在である。エンジニア個人の成長を促し、組織の創造性と生産性を向上させる。プロダクトマネージャーはプロダクトの成功を追求するため、何か新しい機能を実装するときにもし似た機能の実装経験をもつエンジニアがいれば、これまでの経験を活かして担当してほしいと願うのが当然である。
しかしエンジニアリングマネージャーは、そのエンジニアには別の技術を学ぶ機会を与えたいと思っていることもある。将来のためにエンジニアに新しい技術を習得させることは必要だからである。また、成長の機会が乏しい組織だとエンジニアは魅力を感じず、離職してしまうリスクもある。このように、プロダクトの成功とエンジニアリング組織もしくはエンジニア個人の成長がトレードオフになることがある。プロダクトマネージャーとエンジニアリングマネージャーの利害が対立した場合は、話し合いにより解決することになるため、つね日頃から互いに良好な関係を築いておく必要がある。
機能型組織のマネージャーと良好な関係を築くためには、まずプロダクトキームのメンバーのみならず機能型組織のマネージャーに対しても、プロダクトのビジョンやミッションを含め、プロダクトのCoreを共有する。そのうえで、各メンバーが担う役割も事前に共有することが望ましい。RACIやDACIを用いているならば、それも共有するのがよい。これにより機能型組織のマネージャーは、自分の部下がどのような役割をどのような権限で進めることが期待されているかをより理解できるようになる。
機能型組織のマネージャーもプロダクトマネージャー同等に求められる役割の範囲が広い。大規模な組織では機能型組織のマネージャーが複数のプロダクトを見ることも多いため、プロダクトマネージャーがコミュニケーションを取るべき機能型組織のマネージャーも複数人になることもあり、互いに複数人対複数人の関係になる。プロダクトマネージャーは、つねに機能型組織のマネージャーに自身の担当プロダクトの重要性や優先度を伝え続けなければならない。
また、プロダクトチームのメンバーは必ずしも、そのプロダクトの仕事に100%専念できるとは限らない。その場合、プロダクトマネージャーはそのメンバーが担うことになっている仕事の概要やスケジュールを理解し、もし他の仕事との間で稼働の調整が必要になった場合には、関係するプロダクトマネージャーとそのメンバーの機能型組織におけるマネージャーとの間で解決を図るようにする。
このような調整は多く発生する。理想としては会社全体、機能型組織、プロダクトの優先度が一致していることが望ましいが、同じ成功を見据えていても立場が異なれば乖離が発生することもある。そのため、プロダクトの成功に向けてプロダクトチームのメンバーに期待することを調整する必要が出てくる。プロダクトマネージャーとしては自分の担当するプロダクトを優先してもらうように働きかけることを厭わなくてもよいが、プロダクトのCoreとして担当プロダクトの上位のプロダクトや事業、会社全体の利益を考える視座も必要である。
本当に自分の担当プロダクトを他の仕事よりも優先させるべきと考えるならば、プロダクトマネージャー間で優先順位を決定し、その結果をもとに機能型組織のマネージャーにかけ合ってよい。機能型組織の人数が足りない場合には、そのマネージャーとプロダクトマネージャーチームで議論をして折り合いをつける。ただしその場合にも、その根拠として事業や会社への貢献をしっかりと示す必要がある。職種によっては組織内での希少な人材はチーム間で奪い合いになることもあるだろう。自分のプロダクトさえよければよいという考えは問題外であるが、本当に自分のプロダクトを優先させるべきと考えられる局面においては、きちんとかけ合うことを躊躇してはならない。
プロダクトマネージャーと機能型組織のマネージャーが協力して行っていくべきことに、プロダクトチームメンバーの人事評価が挙げられる。プロダクトマネージャーが担当するプロダクトへの関わりが強く、稼働時間も多いメンバーの場合、そのメンバーの仕事ぶりや成果が一番見えているのはプロダクトマネージャーであることも多い。
プロダクトマネージャーはメンバーの貢献度を人事上の評価者となる機能型組織のマネージャーにも伝える必要がある。時には、プロダクトチームメンバーのパフォーマンス改善を両者で考えなければならないこともある。人事権は機能型組織のマネージャーがもち、人材育成や評価も担うことになるが、日々一緒に仕事をする機会が多いプロダクトマネージャーもメンバーの育成や評価に積極的に関わることが期待される。
9.2 プロダクトマネージャーの組織
9.2.1 プロダクトマネージャーの組織で プロダクトを分担する
PARTⅠで述べた通り、プロダクト志向をチーム全員がプロダクトを自分ごととして捉え、プロダクトをよくしていくことにこだわり抜くことだと定義した。プロダクト志向チームが機能していれば、企業規模の違いによってプロダクトマネージャーに求められることに大きな違いはない。最大の違いはプロダクトマネージャーの人数と、それによるスコープの大小である。
プロダクトは複数に分割をしたり、複数のプロダクトを1つのプロダクトとして扱ったりすることができる。小さい企業の場合、プロダクトマネージャー1人もしくは少人数であることも多い。1人のプロダクトマネージャーの担当する。スコープが広く、意思決定は1人もしくは数人(2～3人)で行う。範囲も広く、幅広いスキルが求められる。
社内に十分なリソースがなく、デザイナーやデータサイエンティストがいないなどプロダクトチームが不完全な場合もある。採用したくてもすぐにできるわけではないので、プロダクトマネージャーが職務を越えて、必要ならばその役を積極的に埋めていく必要がある。
創業間もないスタートアップの場合は創業者や創業メンバーが最初のプロダクトマネージャーであることも多い。そのあとを引き継ぐときには、彼らの意思決定プロセスを踏襲しながらも、たとえばプロダクトマネージャーがプロダクトに関する一部の意思決定を担うなど、創業者の負担を減らすことが求められることもある。プロダクトが大きくなり、関係するプロダクトや組織が増えてくると１人のプロダクトマネージャーがすべてを担当することが現実的でなくなる。そのため、プロダクトを分割し、複数のプロダクトマネージャーで協業する体制をつくる必要がある。
図表9-6のようにSNSのプロダクト群はSNS、メッセンジャー、および友達管理やユーザー設定として利用される共通基盤の大きく3つのプロダクトに分割することができる。このように分割する場合、少なくとも3人のプロダクトマネスージャーを置くことになる。プロダクトの成熟度やユーザー規模によっては、3つのプロダクトをより細分化して、100人以上のプロダクトマネージャーがプロダクトに関わっていることも珍しくない。
このような大規模なプロダクトである場合、プロダクト群全体のプロダクトマネージャーは1人ないしは少数人で担当し、プロダクト群全体の大きな方向性を決める。たとえば投稿機能やチャット機能といった個別の機能はプロダクト のプロダクトマネージャーではなく、別のプロダクトマネージャーが担当する。
このようにしてプロダクトマネジメントの組織ができあがり、1つのプロダクトであっても複数人で担当することができる。プロダクトチームに参加する人や役割も増え、それぞれが自分たちの報告経路をもつ。こうした中で複数人が担当しても意思決定の軸がずれないようにする必要がある。人が足りない場合は他部署と交渉して必要な期間、必要なだけの人員を用意するために調整が必要となる。人数が増えたことによる意思決定スピードの鈍化を避けるようにする、人が増えたことによる不要な雑務が増える状態をつくらないようにする、不要な仕事やプロセスは排除しミーティングばかりしないようにする、といったことに注意をして組織が大きくなったことの弊害が生まれないようにすることが大切である。
(1) 安易に役割で分割してはならない
1つのプロダクトに複数人のプロダクトマネージャーがいる場合、ビジネスに強い人や技術に強い人などさまざまな強みや弱みをもつ人がいるだろう。ロボティクスやセンサーなどを活用するプロダクトではハードウェアまで含めた技術領城の知識が求められ、医療や物流、建設、金融などその業界独自の知識が必要である。そのため、1人の担当者ですべてに通じることは難しい。そこで1つのプロダクトに対して、ビジネスに強い人と技術に強い人の2人のプロダクトマネージャーを置くこともある。
しかし、安易に複数人の分業体制を取ることはプロダクトの方向性に一貫性をもたせられなくなったり、プロダクトのさまざまな局面における迅速な意思決定が行えなかったり、リスクを取った大胆な施策が取れなくなる危険性がある。プロダクトの意志決定をするプロダクトマネージャーは必ず1人に定め、他のメンバーはサポート役(RACIのConsult＝協業先)に徹するべきである。
(2) プロダクトマネージャー間の責任範囲を明確化する
プロダクトマネージャー同士の責任範囲についてもDACIを用いて互いの責任範囲を明確にすることが重要である。しかし実際には、明確にプロダクトマネージャー間での仕事の境界が分割できないことがある。互いに境界の認識が合っていると思っていても、実は境界にあたるところを互いに相手が担当すると思ってることもある。境界が曖昧な領域があることを前提として、積極的に曖昧な領域の整理をするとよい。
そのために必要なのは情報共有である。とくに議題がなくてもプロダクトマネージャーで集まったり、lonlをしたりするのも一案である。もちろん忙しいプロダクトマネージャーにとって目的のないミーティングは避けたほうがよいので、たとえば週に一度ランチを一緒に取ることなどが考えられる。
また、大きなビジョンを実現するためには、複数のプロダクトマネージャーが自分の担当領域での成果を積み上げていくことも必要になってくる。大きなプロダクトやプロダクト群のビジョンに対して、各プロダクトマネージャーが自分の担当領域を通じてどのように貢献するかを可視化して、その達成を互いに喜ぶことができる関係構築も欠かせない。
(3) 意思決定のフローやドキュメントのルールを共通化する
プロダクトマネージャーが複数人いる場合、プロダクトを考える方法やプロダクトマネージャーの仕事の範囲の認識が違うことが起こりうる。もちろん、プロダクトマネージャーの強みに合わせて仕事の範囲を割りふるのはよいが、その前提となる意思決定のフローや、プロダクトチームとしてのドキュメント管理のルールなどは揃えておくとよい。
隣のプロダクトのことはまったく知らないといった状況にはせず、互いにプロダクトを成長させるためのツールやフローについても議論を重ねることができる関係が好ましい。