及川卓也のレビュー一覧

MBO(Management by Objectives)、目標による管理。このコンセプトは2つの基本原理に基づいている。
1.伝えるべきは、どうやるか。ではなく、何を求めているか。
2.パフォーマンスは結果で測る。

OKRとは、Objective 目標、KR Key Results 主な結果。つ...続きを読むまり、Oは成し遂げたいこと。KRはそれを実現できたかどうかを判断する指標。

やり遂げられない理由
1.ゴールに優先順位をつけていない。
目標ら一つだけ。その目標を測定するKRは三つだけ。
2.熱意を持ち、もれなくゴールを伝えていない。
3.やり遂げるためのプランがない。
意思力に頼らない。
4.重要事項のための時間を開けていない。
5.繰り返さずにやめてしまう。

最初に架空のスタートアップが如何にしてOKRを導入することになったか、OKRを導入してどうなったかが描かれていて面白いです。ただ、後半は同じようなことが繰り返し書かれていて退屈でした。P200あまりでサクッと読めるのと、OKRそのものは仕事でもチームでも個人の目標でも導入出来るようなので参考になりそ...続きを読むうです。

Objective一つ四半期
KR key results ３つ 四半期
週間進捗 P1 p2 ４つまで。

グーグルやインテルも、採用している目標達成のための手法。

目標管理システムOKRに関する数少ない書籍。本書は、前半では目標管理にまつわるシリコンバレー起業家の物語を、後半ではOKRフレームワークを紹介する。

OKR（Objective & Key Results）はインテルで始まったシステムで、これまでにグーグル、ジンガ、リンクトインなどが導入して迅速か...続きを読むつ継続的な成長を実現している。

従来型の目標管理MBO（Management By Objectives）の課題を克服する形で生まれた。MBOはチームや個人の目標が、会社や部門の目標と結びつかず、個人の目標達成が部門の求める課題解決に繋がらないことがしばしばあった。

OKRは3つの理念のもとにできている。
1.人を鼓舞し、効果を測定できるようなゴールを設定すること。
2.やることが他にどれだけあっても、自分のチームが常に望ましい最終形態に向けて進むようにすること。
3.チームのメンバーが目標を忘れず、かつ各メンバーが責任を自覚できるような習慣を作り出すこと。

目標を立てているにも関わらず、なぜやり遂げることができないのか。
1.ゴールに優先順位を付けていない。
2.熱意をもってもれなくゴールを伝えていない。
3.やり遂げるためのプランがない。
4.重要事項のための時間を空けていない。
5.繰り返さずにやめてしまう。


■ Oの基本
・定性的で人を鼓舞する内容にする
・時間的な縛りを作る
・各チームが独立して実行できるようにする
例）
・サウスベイ地区で法人向けコーヒー小売り直売市場を勝ち取る
・すばらしいMVPを立ち上げる
・パロアルト地区におけるクーポンの使い方の習慣を変える

■ KRの基本
Oで決めた感覚的な言葉を定量化する。どうすればOを満たしたと言えるかというシンプルな問いを立てる。ストレッチゴールにすること。
例）
・40%pのユーザーが1週間に2回以上再訪する
・製品を勧めたいかどうかのスコアとして8を獲得する
・コンバージョン率15%

ー以下、メモー
ティービー社のストーリーはケーススタディに有用そうだ。
1.目標管理が機能していない事例として取り上げられているが、他の解決策はないのだろうか。
2.自分の身の回りで目標管理が機能不全を起こしていないか。
3.自分のチームに取り入れるとしたらなにが障害となるか。

他言語の経験があるため、JavaScript自体の学習としては当然足りない。
しかし経験者ゆえに「プログラミング初心者が何をわからないのか、がわからない」という観点からは「あー、その辺も説明しなきゃいけないのか」と気づきを得ながら読めた。
経験者ならばさらっと読めるので、時間がない方で最近のJava...続きを読むScript（ES6）のさわりだけでも知りたい人にもいいかも。多分2〜3時間で読めると思う。

英語に触れる機会が少ないプログラミング初心者は、まず訳の分からない英文の並びに圧倒されてしまい苦手意識を持ちがちだと思うが、ふりがなを振ることでコードを読みやすくしよう！というのは新しい視点でとても良かった。

ProgateでJavascriptのコースを一通り終えているので、前半は復習という感じ...続きを読むだった。
ただ、わからなくてもとにかく書いて理解を進めていたProgateとは異なり、一つ一つコードの読み方から解説が載っていることで、改めてじっくり意味を確認できたと思う。
エラーメッセージは普段Google検索で解決しているが、読み解き方の解説が載っているのは、この本から入る人には親切な作りだなと感じた。

ES6で追加されたテンプレート文字列やアロー関数など個人的に知らなかったので、ES6準拠で書かれている点もよかった。

NHK「プロフェッショナル仕事の流儀」に出演されたのを見て、はるか遠くにいる人なのに、なぜか親近感を持った。番組で彼が語ったことの根っこがここに書かれていると思った。章を読み進むたびいちいち「うん、うん」とうなずいている自分がいる。久しぶりにワクワクするITの本に出会いました。

Hack for Japan の話や著者blogとその加筆。個々のエントリは散発的に思える。なにか役立つために自分に出来ることを実践する思いには共感した。また分かったつもりではいるがなかなか気がつけない変化を起こしていくことの大切さを思い起こさせる。

数年前のブログを書籍にしたとはいえ、丁寧な考察が非常に参考になる。「不連続への挑戦」は今まさに直面しているところであり、著者の強いメッセージに勇気をもらった感じ。

自分自身のプロダクトマネージャーの理解が浅く、求めていた内容と齟齬があった。自分の知らない世界の知識を得られたという点や転職で必要なことを知るという点では参考になった。

■GO株式会社プロダクト責任者黒澤隆由
　BtoCプロダクトは、BtoBプロダクトと比較してスイッチングコストが低く、他社プロダクトと併用されやすいという特徴があるため、しっかり自社プロダクトの強みをつくっていくことが何よりも重要です。その難易度は非常に高いのですが、ここがBtoCのプロダクト開発に...続きを読むおいてもっとも汗をかかないといけない部分であり、ここから逃げてしまってはだめです。
　ユーザーの満足感を満たすうえでは、細かな使い勝手のよさやデザインなどのつくりこみがとても重要であることは事実ですし、細かな改善の方が短期間・低コストで実現できて結果もすぐ見えます。だからこそ往々にしてそういう開発ばかりをしたくなってしまいがちですが、そういう細かな改善だけをやり尽くしても決して強いプロダクトにはなりません。バリュー・プロポジション(ユーザーに提供する独自の価値)は必ずユーザーの根強いペインに紐づいていて、大体そういう難しい問題は他社も含めて解けていないものです。
　だからこそ、そういう問題を「正しく」解決するためのプロダクトアイデアをプロダクトマネージャーがしっかり提示し、それを自社の技術力で着実に実現していくことが求められます。加えて、ユーザーに愛着をもって使い続けてもらえるプロダクトづくりが重要になってきます。ユーザーと真摯に向き合って、「クール」とか「イケてる」とか主観的な自己満足を満たすためでなく、ただただよりよいユーザー体験を提供するために、細部までこだわってプロダクト設計することが求められます。こうした点がBtoCのプロダクトマネージャーの難しさであり、やりがいでもあると感じますし、複数の選択肢がある中で「第一の選択肢になれる」「ユーザーのお気に入りのプロダクトになれる」という喜びはとても大きいと感じます。

■プロダクトマネージャーになりたての人が最初にぶつかる5つの壁
・決断の場面が多い
・多職種との連携がうまくいかない
・正解がわからなさすぎる
・真の課題かどうかの判断
・チームメンバーに対面で会えない

■RICE
　RICEスコア＝ユーザー到達度×影響度×確度÷労力

ザッピング
プロダクトマネージャーに転職したい人は読むと良さそう。社内異動が一番なりやすいはそうだと思う

●一分野マスター読書「DX」22冊目。まず一般ユーザーとしてITを活用することを意識することが大事か。他のDX関連本との繰り返しになるが、DXにおいては本当に顧客（従業員も）が求める価値を満たすものは何なのかを考えることが重要。

事業の発想、ブラッシュアップから運営までの時間軸とリレーションシップなどの行動面まで網羅的に書かれていてよい。

会社で使っているOKRをちゃんと運用することを考えて、読んでみました。物語と実用の二部構成。前半は、OKRでスタートアップが成功していく様子がおもしろく、わかりやすかったです。後半であるように「Oはメンバーを鼓舞する」「人事評価と切り離す」というのはできていないと感じました。たしかに、数字よりも組織...続きを読むの成長とモチベーションを高めて、結果的に達成できるようにするべきです。来期のOKRにおいては、フォーカスの意図を込めたメッセージにして定期的に経過を伝えるようにしてみようと思いました。

なんかタイトル負けしていると感じた本。
書いてある内容に否定はないんだけど、ネット記事で読んだなぁという感じも強く、全てと言われると益々という感じ。
プロダクトマネジメントの事を1mmも知らない人が読むといいのかな？それでも、この本だけでは厳しいかもしれないが。

　プロダクトマネージャーの仕事に必要な領域はビジネス、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) 意思決定のフローやドキュメントのルールを共通化する
　プロダクトマネージャーが複数人いる場合、プロダクトを考える方法やプロダクトマネージャーの仕事の範囲の認識が違うことが起こりうる。もちろん、プロダクトマネージャーの強みに合わせて仕事の範囲を割りふるのはよいが、その前提となる意思決定のフローや、プロダクトチームとしてのドキュメント管理のルールなどは揃えておくとよい。
　隣のプロダクトのことはまったく知らないといった状況にはせず、互いにプロダクトを成長させるためのツールやフローについても議論を重ねることができる関係が好ましい。