『プロダクトマネジメントのすべて』及川卓也ほか｜「ミニCEO」なのに権力を持たない人の戦い方

新しい機能の案が次々に出る会議ほど、実は誰も「そもそも誰のどんな困りごとを解くのか」を口にしていません。ヒット商品に関わる人は、機能の作り方を議論する前にいったん手を止めるといいます。

『プロダクトマネジメントのすべて』は、及川卓也さん、曽根原春樹さん、小城久美子さんの3人が、プロダクトマネージャー(PM)という職能を一冊にまとめた共著です。3人とも外資系や国内の大手IT企業でPMを経験してきました。

PMはしばしば「ミニCEO」と呼ばれます。成功の責任は負うのに、人事の権限も予算を集める権限も持ちません。その矛盾を抱えたまま、戦略の策定から実装、チーム運営までをどう回すかが本書の主題です。範囲が広いので、この記事は本の地図として使ってほしいです。

成功は三つの釣り合いで測り、すべてを仮説として扱う

本書はPMの仕事を「プロダクトを成功させること」と置き、その成功を三つの要素で定義します。

ビジョン

プロダクトを通じて実現したい未来の姿

ユーザー価値

使う人が価値を感じて使い続けること

事業収益

投資とチームを続けるための利益

どれか一つが抜けると成り立ちません。ユーザーが喜ぶ機能でも、会社の向かう先とずれていたり赤字を生んだりすれば、長くは続けられないからです。ユーザー価値と収益だけでは足りず、ビジョンの実現まで含めて成功と呼ぶところが、類書との分かれ目になります。

「プロダクトをつくることは仮説検証をすることと同義である。」

もう一本の柱がこの考え方です。未来は読めないので、「これが正解だ」と信じ込んで作るより、すべてを仮説として検証し続けるほうが外れにくいです。本書のどの章を開いても、この前提が下敷きになっています。

PMが立つ場所も三つの領域の交差点とされます。ビジネス、UX、テクノロジーです。三つにまたがるため、著者はPMを「知的総合格闘家」と呼びます。コードを自分で書く必要はありません。ただ、各分野の専門家の話を理解して的確に問い返せる程度の深さは求められます。

編集部の読みでは、この定義は「正解を知る人」ではなく「三方向の言葉を翻訳する人」としてPMを描いています。専門家に命令できない立場だからこそ、相手の話を理解できる深さが信頼の通貨になる、という含みが読み取れます。

求められるスキルは、発想力、計画力、実行力、仮説検証力、リスク管理力、チーム構築力の六つ。どれか一つが突出していれば務まる仕事ではない、というのが著者の見立てです。

四階層で考え、下から上へも検証を戻す

本書の骨格は、この四つの階層に分けて考える枠組みです。

Core

ミッションやビジョン、事業戦略といった「なぜ作るか」を扱う最上位

Why

誰をどんな状態にしたいのかと、なぜ自社がやるのかを置く

What

ユーザー体験やビジネスモデル、ロードマップを決める

How

UIや実装、市場への出し方に降りる

順序が要点です。本書の例で言えば、コーヒー飲料に「ミルクを入れるか」を最初に議論してはいけません。先に「仕事中に眠気を覚ましたい会社員」というWhyを決めれば、ブラックかカフェオレかは自然に絞られます。

Howの議論を始める前に、Whyが言葉になっているかを確かめるのが、この枠組みの使い方です。

ただし一方通行ではありません。著者は往復を勧めます。

ウォーターフォール式に要件を上から落とす進め方とは、ここが違います。

間違った仮説に気づいたときは、むしろ喜ぶべきだと著者は書きます。早く気づくほど、チーム全員の損失が小さく済むからです。

道具の紹介も具体的です。本書は図表を埋めること自体を目的にせず、階層ごとの仮説を言葉にして点検するための補助線として扱っています。次の三つが挙げられます。

リーンキャンバス

CoreとWhyを一枚に書き出す

バリュー・プロポジションキャンバス

ユーザーの課題と提供価値の整合を確かめる

カスタマージャーニーマップ

体験を時間順に並べて、必要な機能や接点を探す

インタビューの作法は特に実用的です。「この機能は欲しいですか」と聞くと、開発者を前にしたユーザーは断りにくいです。代わりに「機能を一つ外すならどれですか」と尋ねます。

また、ユーザーが知っているのは現行の機能だけなので、要望をそのまま採らず、Coreに照らして取捨選択するのがPMの仕事になります。

北極星の指標と、権力のないリーダーシップ

指標の置き方にも本書は一章を割きます。売上やPV数だけを追うのは戒められます。NSMは収益に先行して動き、チームの向きをそろえる役を担います。

挙げられる例はZoomです。売上高1800億円という大きな結果指標に対し、NSMには「1週間あたりのミーティング数」を置きました。会議を開く人が使い続けるほど有料化や企業導入が進むという筋道を、一つの数字が代表しています。

データの読み方についても、集計することそのものより、その数字が意思決定に何をもたらすかを読み取ることだと著者は述べます。NSMを決めたら、それを分解して上位のKPI、さらに下位のKPIへ落とし、ユーザーの行動と結びつけて測ります。

権力を持たないPMは、影響力で人を動かすしかありません。本書が挙げる道具のうち、インセプションデッキはプロジェクトの開始時に、チームが「なぜここにいるのか」や「やらないこと」、品質と期間と予算の優先順位を十問で確かめ合うものです。

RACIはタスクごとに、実行する人、説明に責任を持つ人、協力先、報告先を決めます。

心理的安全性の項には、読み流せない指摘があります。安全性が高まると、ミスが減るより先に、報告される件数が増えるといいます。エイミー・エドモンソン氏の調査では、それまで隠れていた医療過誤が報告され始めたためです。報告の増加を悪化と取り違えないための一例として読めます。

状況で動き方は変わり、地図にも空白は残る

終盤で本書は、そう念を押します。成長の段階で言えば、目標や課題は次のように移ります。

1. 0から1強い価値仮説を見つけてPMFに至ること
2. 1から10急に増えるユーザーと組織の期待をさばくこと
3. 10から100グローバル展開と複雑化した仕組みの管理

事業の形態でも変わります。BtoCとBtoB、ハードウェア、AIでは戦略も指標も異なり、AIには、見た目や振る舞いが人に似すぎると敬遠されるという独特の論点も加わります。

さらに、作ることだけでなく終わらせることも大事な意思決定だと説き、サンクコストに引きずられず撤退する判断が事業全体を軽くする、と述べます。

PM本人の成長モデルとして示されるのが「W型」です。

土台には好奇心の強さ、広さ、深さがあり、どの土壌で深掘りするかを自分で選ぶことが肝心だとされます。

ここからは編集部の留保になります。本書が最も効くのは「全体を一度見渡したい」という場面です。ただし示される事例の多くは、組織が大きく、PMという役割が既に置かれているIT企業の文脈に寄っています。

PMの肩書きがなく、一人で複数の役を兼ねる小さなチームでは、そのまま当てはめにくい箇所が出るでしょう。

広さの代償も明記されています。統計やSQL、スクラムの詳細といった実務の細部は専門書に譲られており、これ一冊で手が動くようにはなりません。目次を道標にして、次に深掘りする分野を見つけるための本だと考えたほうが期待とずれません。

実務の手順書を求めて開くと、どの章も入口の紹介で終わったように感じるはずです。

また、Zoomの例のように成果が見えやすい成功談が中心なので、撤退や失敗の具体的な手触りは薄いです。終わらせる判断の重要さは語られても、実際にどう切り出すかは読者が補う必要があります。

サンクコストを捨てよと言うのは簡単で、誰がいつ社内に撤退を告げるのかという生々しい部分は、権力を持たないPMにこそ重いはずです。

明日から何を変えるか

始めやすい行動は三つあります。一つ目は、いま関わっているプロダクトをCore、Why、What、Howの順に書き出すことです。リーンキャンバスで一枚にまとめ、「誰のどんな課題か」と「なぜ自社か」を最初に埋めます。Whyを飛ばしてHowから埋め始めると、軸が定まらなくなります。

二つ目は、思いついた企画を形にする前に、ターゲットに近い5人ほどへ話を聞くことです。「欲しいですか」と尋ねるのをやめ、いまの代替手段への不満や実際の行動を聞きます。

三つ目は、チームでNSMを一つ決めること。売上やPVを避け、ユーザーが価値を受け取った瞬間を示す数字を話し合って選びます。動画サービスなら総視聴時間、といった具合です。

合わせて読みたい

『起業の科学』田所雅之 本書のWhyとWhat、つまり課題と価値仮説の検証を、スタートアップの現場で回す手順まで広げた一冊。PMFに至る道筋を具体的に追いたいときに手が伸びます。

『チームが機能するとはどういうことか』エイミー・C・エドモンドソン 心理的安全性の提唱者本人による著作。権限を持たないPMがチームを動かす土台を、本書より一段厚く確かめられます。

『ジョブ理論』クレイトン・クリステンセン 人がプロダクトを雇う理由から需要を読み解く理論書。本書のWhy、つまり誰のどんな課題かを掘り当てる視点を養う一冊として読み合わせたい。