及川卓也のレビュー一覧
-
Posted by ブクログ
ネタバレ非常に参考になった。
前提として、自分が今いる業界がIT業界ということもあるかと思うが、
以下の３点が特に自分の頭の中が整理されて気持ちよかった。
1.ソーシャルDRM
2.ネット時代のメディア戦略
3.スキームを変える
これ以外にも感銘を受ける内容が盛りだくさんでした。
ブログの記事を再編されたということでしたが、書籍（紙の質感、読み進め、しおりを入れる感覚）にされたからこその目で読む以外に手で読むことのリアルな良さも相まって、文章が上手に整理され付加価値は十分にあったと思います。
非常に論理的かつ感情的（なんだか矛盾するようですが、ある意味人間らしい）な表現の両面で書かれており、著者がバランス感覚の良い人であることが読み取れます。
また、今の世の中をITという切り口で考察されていますが、ITという枠に捕われているわけではなく、全ての考察は、人と社会を中心とした視点で書かれており、「何のために生きるのか」という問いに対する答えが各エピソードの根底にあるように感じました。
注釈は配慮されたくさん入れられていますが、それだけ専門的な領域の内容なため、スラスラと読み進めることは読者の知識に左右され、読む人を選ぶ本かもしれません。
自分には読むことで、仮説・検証をしているような感覚と
そうそうと共感できる内容がたくさんありました。
また、読み直そうと思いました。 -
-
-
-
-
-
Posted by ブクログ
ネタバレこのような系統の本を読んだことがない人にとっては、入門として入るにはよいのかもしれないと思いました。
ただ、ページ数が多かったりするので初学者とかは興味があるところから読みだしてもよいと思います。
他の書籍で読んだことがあるような内容が多いなという印象でしたが、何度も繰り返し訴えることが本書でいう"手の内化"には重要なのかなという考え方に至りました。
1.本書の要点、著者の主張、印象に残ったキーワード
私は著者の主張を以下のように読み取った。
- 「日本企業がバブル崩壊後の失われた30年と呼ばれる時代に、他国と比較して経済的に優位に立てなかったのは、ソフトウェアとビジネスに関する捉え方や取り組み方に問題があったからである」
- 「そのため、今後日本が再度経済的な成長期を向かえるためにはソフトウェアに対する考え方、ビジネスに関する考え方を改めることが必要である」
- 「そのために必要なのは、ソフトウェアを重要視すること、技術を理解すること(手の内化)である.」
本書の要点も上の通りであると考える。個人的な要点としては、紹介されている考え方のフレームワークやツールの方が要点であると感じた。
印象に残ったキーワードとしては、"日本の国際競争力の定価を防げなかった低下とも言える世代の一人"です。
2.企業事例の中で最も印象に残ったものとその理由
企業事例として、最も印象に残っているのはトヨタ自動車です。豊田社長の講演の中で「トヨタブランドを背負わなくても、世界で通用する人材になってほしい」という言葉が出たという言葉が紹介されていました。本書で紹介されている「手の内化」や「kaizen」など様々なフレームワークや考え方を生みだしている素晴らしい日本企業だなと感じていましたが、言われてみるとトヨタ自動車の個人を思い浮かべるようりも先に企業として、組織としてのトヨタ自動車が先に出てくるような企業だなと感じる一文でした。それが悪いことではなく、要はバランスだと私は考えているので、バランスの取れた五角形のような人間や組織の中でも輝く本書で言うところのエイリアンのような一等星が出るといいですね.
3.今後に活かしたいこと、挑戦したいこと
OKRの精神は良いなと思いましたし、今後活用していきたいなと感じました。弊社の目標設定シートも、本書で記述されている MBO(Management By Objectives: 目標による管理) の側面が強いと感じました。これは、上司や組織から振ってくる目標に即したものになることが多く、目標と個人が分離しやすいと思われるので改善してもよいと思います。それに対して、OKR(Objectives and Key Results: 目標と主要な結果)では"主要な結果"があることによって成功と失敗の判断が個人レベルで行いやすく、本書でも書かれている失敗と向きあうことがやりやすいと思いました。また、同じく本書でも書かれている"何をするか"ではなく"どうあるべきか"について議論することもできるため、目標がよりよいものになるのではないかと思います. -
-
Posted by ブクログ
プロダクトマネージャーの実態理解
日常業務の理解手段
「A Day in the Life of Product Manager」などのキーワードでYouTube検索をすることで、各社のPMの一日を知ることができる。
また、noteなどで「プロダクトマネージャーの1日」と検索するだけでも、多くの体験談や記事が見つかる。
未経験からPMになるための考え方
自分の武器を明確にする
未経験でPM職に就くには、自身の職歴や性格から「どういう点で即戦力になれるのか」を具体的に伝えることが重要。
これは選考の際に非常に大きな説得材料となる。
キャリアの動機を言語化する
現職を辞めたい理由、転職で得たいもの、関わりたいプロダクト、解決したい課題を明確にし、自分の志向性を伝えられるようにしておく。
失敗経験も伝えられるようにする
成功体験だけでなく、失敗体験を言語化し、そこから何を学んだかを伝えられることが重要。
入社後のキャッチアップと行動
組織とプロダクトの理解
戦略やロードマップの把握後は、社内のルール、開発ツール、過去のSlackのやりとりを積極的に読み、組織の進め方を学ぶ。
自分の成長計画を立てる
「自分ロードマップ」を作成し、今後のスキル習得やキャリアビジョンを整理しておく。
KPIの設定とフレームワーク活用
優先すべきKPIを関係者と協議し設定することで、日々の判断基準が明確になる。
DACIなどの意思決定フレームワークを活用して、役割分担と意思決定速度を向上させる。
ユーザー理解の深化
ユーザーインタビューやカスタマーサクセスとの連携を通じて、ユーザーが抱える課題の解像度を高める努力が重要。
マインドセットと視座
課題志向の意識
プロダクトそのものを好きになるだけでなく、「どんな課題を解決したいか」という視点を持つことが求められる。
学びの幅を狭めない
専門領域に集中することは大事だが、他領域を最初から切り捨てると学びの深度が浅くなるリスクもある。
ユーザー理解を軸としたビジョン設定
ユーザー理解に基づいたプロダクトビジョンを再設定することが、初期フェーズでの大事な取り組みになる。
学習手段とスキル証明
書籍・学習機関
『イノベーションのDNA』などの書籍を活用した学びや、社会人大学院での体系的学習も選択肢に入る。
資格・検定
人間中心設計推進機構（HCD-Net）が提供する「人間中心設計専門家」や「UXスペシャリスト」、UX検定などがスキルの可視化に役立つ。
自己表現とキャリア設計
マインドセットの共有
自分のありたい姿や目指すマインドセットを、周囲に宣言・共有することで行動に一貫性を持たせる。
たとえばオフサイトミーティングで発表するのも効果的。
自分の強みを明示する
戦略設計、組織構築、グロースなど、プロダクトマネジメントの広い業務の中で、自分がどのフェーズに強みを持つのかを明確にしておく。 -
-
Posted by ブクログ
■GO株式会社プロダクト責任者黒澤隆由
BtoCプロダクトは、BtoBプロダクトと比較してスイッチングコストが低く、他社プロダクトと併用されやすいという特徴があるため、しっかり自社プロダクトの強みをつくっていくことが何よりも重要です。その難易度は非常に高いのですが、ここがBtoCのプロダクト開発においてもっとも汗をかかないといけない部分であり、ここから逃げてしまってはだめです。
ユーザーの満足感を満たすうえでは、細かな使い勝手のよさやデザインなどのつくりこみがとても重要であることは事実ですし、細かな改善の方が短期間・低コストで実現できて結果もすぐ見えます。だからこそ往々にしてそういう開発ばかりをしたくなってしまいがちですが、そういう細かな改善だけをやり尽くしても決して強いプロダクトにはなりません。バリュー・プロポジション(ユーザーに提供する独自の価値)は必ずユーザーの根強いペインに紐づいていて、大体そういう難しい問題は他社も含めて解けていないものです。
だからこそ、そういう問題を「正しく」解決するためのプロダクトアイデアをプロダクトマネージャーがしっかり提示し、それを自社の技術力で着実に実現していくことが求められます。加えて、ユーザーに愛着をもって使い続けてもらえるプロダクトづくりが重要になってきます。ユーザーと真摯に向き合って、「クール」とか「イケてる」とか主観的な自己満足を満たすためでなく、ただただよりよいユーザー体験を提供するために、細部までこだわってプロダクト設計することが求められます。こうした点がBtoCのプロダクトマネージャーの難しさであり、やりがいでもあると感じますし、複数の選択肢がある中で「第一の選択肢になれる」「ユーザーのお気に入りのプロダクトになれる」という喜びはとても大きいと感じます。
■プロダクトマネージャーになりたての人が最初にぶつかる5つの壁
・決断の場面が多い
・多職種との連携がうまくいかない
・正解がわからなさすぎる
・真の課題かどうかの判断
・チームメンバーに対面で会えない
■RICE
RICEスコア＝ユーザー到達度×影響度×確度÷労力 -
-
-
-
-
-
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) 意思決定のフローやドキュメントのルールを共通化する
プロダクトマネージャーが複数人いる場合、プロダクトを考える方法やプロダクトマネージャーの仕事の範囲の認識が違うことが起こりうる。もちろん、プロダクトマネージャーの強みに合わせて仕事の範囲を割りふるのはよいが、その前提となる意思決定のフローや、プロダクトチームとしてのドキュメント管理のルールなどは揃えておくとよい。
隣のプロダクトのことはまったく知らないといった状況にはせず、互いにプロダクトを成長させるためのツールやフローについても議論を重ねることができる関係が好ましい。 -
Posted by ブクログ
私には難しかった。
ソフトウェアの会社で働いているがプログラミングの知識は素人、しかしプログラミングのテストや仕様書作成などの仕事をしているので何かの助けになればと手に取った。
途中までは読みながら頭で整理しつつ読み進めたが、気づいたら何だかよく分からなくなり、結局すっきりしないまま本を閉じた。
索引があったら良かったかも。
ソフトウェアやプログラミングは日に日にアップデートされ、エクセルさえ使えればいいよと言われた時代は古代のよう。
何が分からないのか、何を学べばいいのか、実体があるようなないような、ふんわりモヤモヤした状態が続いている。
様々なものが自動化され、小学校からプログラミングを学ぶ時代。
一度置いていかれると、聞くに聞けない状態になるし、私もプログラミングの授業を受けたい！
マンガは不要だったという意見もあるけど、私は和んだし、ワン吉派だな...
「やさしい」「入門」「マンガ」などに希望を持って手に取る本が、ことごとく難しくて沈むわ～！
この本はまだ私には高度だということが分かったので、もう少し昭和のアナログ淑女向けの本を探そうと思う。 -
Posted by ブクログ
伝統的な製造業でのデジタライゼーションをどうするか、という視点で学べるところがないかという気持ちで読んだ。
結論としては、ソフトウェアを内製化する組織体を作れ、それを支持する人を増やせ、ということになるのだろうが、ではソフトウェアに何ができるのか、何をソフトウェアで実現するのか、という部分は、当たり前だけど個々の現場によって異なる。
現実の問題をどのようにデジタル、ソフトウェアでより良くしていくことが可能なのか？という問いに対しての答えがある程度見通せないことには人を雇って内製化して、などというステップには進むことはできない。
検品のための画像処理のような個別の分野はわかりやすい例としては挙げられるだろうが、もっと大掛かりな事業オペレーション全体のようなものの問題をどう切り分けてソフトウェア視点の課題に落とし込むのか、というところが悩ましい。
そこがMicrosoftやGoogleのようなプロダクトそのものがソフトウェアという著者の経験ではカバーされないのではないかと感じてしまう。 -
Posted by ブクログ
OKRのストーリーと解説の本
ストーリ仕立てのビジネス本は海外が主流かな。イメージしやすくて良い。短いけどもとがシンプルなのでしょうがない
objective：成し遂げたいこと、 key results：できたか判断するための指標
達成できない理由①ゴールの優先順位がない②ゴールを伝えてない③プランがない④時間を用意しない⑤再挑戦しない
難しいが不可能ではないKRを作る
①今週の優先事項：やるべき仕事を3,4個
②今後4週間：周囲に知らせるべき予定
③OKR自信度状況：自信度50％からの変化
④健康健全性指標：結果達成の間に守りたいもの