及川卓也のレビュー一覧

ソフトウェアファースト第２版 あらゆるビジネスを一変させる最強戦略

及川卓也

このような系統の本を読んだことがない人にとっては、入門として入るにはよいのかもしれないと思いました。
ただ、ページ数が多かったりするので初学者とかは興味があるところから読みだしてもよいと思います。

他の書籍で読んだことがあるような内容が多いなという印象でしたが、何度も繰り返し訴えることが本書でいう"手の内化"には重要なのかなという考え方に至りました。

1.本書の要点、著者の主張、印象に残ったキーワード

私は著者の主張を以下のように読み取った。
- 「日本企業がバブル崩壊後の失われた30年と呼ばれる時代に、他国と比較して経済的に優位に立てなかったのは、ソフトウェアとビジネスに関する捉え方や取り組み方に問題があったからである」
- 「そのため、今後日本が再度経済的な成長期を向かえるためにはソフトウェアに対する考え方、ビジネスに関する考え方を改めることが必要である」
- 「そのために必要なのは、ソフトウェアを重要視すること、技術を理解すること(手の内化)である.」
本書の要点も上の通りであると考える。個人的な要点としては、紹介されている考え方のフレームワークやツールの方が要点であると感じた。
印象に残ったキーワードとしては、"日本の国際競争力の定価を防げなかった低下とも言える世代の一人"です。



2.企業事例の中で最も印象に残ったものとその理由

企業事例として、最も印象に残っているのはトヨタ自動車です。豊田社長の講演の中で「トヨタブランドを背負わなくても、世界で通用する人材になってほしい」という言葉が出たという言葉が紹介されていました。本書で紹介されている「手の内化」や「kaizen」など様々なフレームワークや考え方を生みだしている素晴らしい日本企業だなと感じていましたが、言われてみるとトヨタ自動車の個人を思い浮かべるようりも先に企業として、組織としてのトヨタ自動車が先に出てくるような企業だなと感じる一文でした。それが悪いことではなく、要はバランスだと私は考えているので、バランスの取れた五角形のような人間や組織の中でも輝く本書で言うところのエイリアンのような一等星が出るといいですね.

3.今後に活かしたいこと、挑戦したいこと

OKRの精神は良いなと思いましたし、今後活用していきたいなと感じました。弊社の目標設定シートも、本書で記述されている MBO(Management By Objectives: 目標による管理) の側面が強いと感じました。これは、上司や組織から振ってくる目標に即したものになることが多く、目標と個人が分離しやすいと思われるので改善してもよいと思います。それに対して、OKR(Objectives and Key Results: 目標と主要な結果)では"主要な結果"があることによって成功と失敗の判断が個人レベルで行いやすく、本書でも書かれている失敗と向きあうことがやりやすいと思いました。また、同じく本書でも書かれている"何をするか"ではなく"どうあるべきか"について議論することもできるため、目標がよりよいものになるのではないかと思います.

ソフトウェア・ファースト

及川卓也

今の自分にはあまりピンとこなかった

ソフトウェアに対する考え方の違いが国によってある

何某かのプラットフォーマーになるべき

製品要求仕様書（PRD）
和またはワンページャー

OKRの精神

ユーザーの利用状況は宝の山

内製化は必須
マネージャーは開発経験者がなるべき

若手、中途社員のやりたいを積極的に採用する

コネティング・ザ・ドッツ

プロダクトマネージャーになりたい人のための本 エンジニアからプロジェクトマネージャー・事業企画・経営コンサルタント・デザイナー・現役PMまで

及川卓也 / 松永拓也 / 山本航 / 武田直人

プロダクトマネージャーの実態理解
日常業務の理解手段
「A Day in the Life of Product Manager」などのキーワードでYouTube検索をすることで、各社のPMの一日を知ることができる。
また、noteなどで「プロダクトマネージャーの1日」と検索するだけでも、多くの体験談や記事が見つかる。

未経験からPMになるための考え方
自分の武器を明確にする
未経験でPM職に就くには、自身の職歴や性格から「どういう点で即戦力になれるのか」を具体的に伝えることが重要。
これは選考の際に非常に大きな説得材料となる。

キャリアの動機を言語化する
現職を辞めたい理由、転職で得たいもの、関わりたいプロダクト、解決したい課題を明確にし、自分の志向性を伝えられるようにしておく。

失敗経験も伝えられるようにする
成功体験だけでなく、失敗体験を言語化し、そこから何を学んだかを伝えられることが重要。

入社後のキャッチアップと行動
組織とプロダクトの理解
戦略やロードマップの把握後は、社内のルール、開発ツール、過去のSlackのやりとりを積極的に読み、組織の進め方を学ぶ。

自分の成長計画を立てる
「自分ロードマップ」を作成し、今後のスキル習得やキャリアビジョンを整理しておく。

KPIの設定とフレームワーク活用
優先すべきKPIを関係者と協議し設定することで、日々の判断基準が明確になる。
DACIなどの意思決定フレームワークを活用して、役割分担と意思決定速度を向上させる。

ユーザー理解の深化
ユーザーインタビューやカスタマーサクセスとの連携を通じて、ユーザーが抱える課題の解像度を高める努力が重要。

マインドセットと視座
課題志向の意識
プロダクトそのものを好きになるだけでなく、「どんな課題を解決したいか」という視点を持つことが求められる。

学びの幅を狭めない
専門領域に集中することは大事だが、他領域を最初から切り捨てると学びの深度が浅くなるリスクもある。

ユーザー理解を軸としたビジョン設定
ユーザー理解に基づいたプロダクトビジョンを再設定することが、初期フェーズでの大事な取り組みになる。

学習手段とスキル証明
書籍・学習機関
『イノベーションのDNA』などの書籍を活用した学びや、社会人大学院での体系的学習も選択肢に入る。

資格・検定
人間中心設計推進機構（HCD-Net）が提供する「人間中心設計専門家」や「UXスペシャリスト」、UX検定などがスキルの可視化に役立つ。

自己表現とキャリア設計
マインドセットの共有
自分のありたい姿や目指すマインドセットを、周囲に宣言・共有することで行動に一貫性を持たせる。
たとえばオフサイトミーティングで発表するのも効果的。

自分の強みを明示する
戦略設計、組織構築、グロースなど、プロダクトマネジメントの広い業務の中で、自分がどのフェーズに強みを持つのかを明確にしておく。

プロダクトマネージャーになりたい人のための本 エンジニアからプロジェクトマネージャー・事業企画・経営コンサルタント・デザイナー・現役PMまで

及川卓也 / 松永拓也 / 山本航 / 武田直人

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

プロダクトマネージャーになりたい人のための本 エンジニアからプロジェクトマネージャー・事業企画・経営コンサルタント・デザイナー・現役PMまで

及川卓也 / 松永拓也 / 山本航 / 武田直人

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

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

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

プロダクトマネージャーになりたい人のための本 エンジニアからプロジェクトマネージャー・事業企画・経営コンサルタント・デザイナー・現役PMまで

及川卓也 / 松永拓也 / 山本航 / 武田直人

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

ソフトウェア・ファースト

及川卓也

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

プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで

及川卓也 / 小城久美子 / 曽根原春樹

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

OKR（オーケーアール） シリコンバレー式で大胆な目標を達成する方法

クリスティーナ・ウォドキー / 二木夢子 / 及川卓也

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

プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで

及川卓也 / 小城久美子 / 曽根原春樹

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

プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで

及川卓也 / 小城久美子 / 曽根原春樹

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

マンガと図解でスッキリわかる プログラミングのしくみ

大槻有一郎 / リブロワークス / 及川卓也 / 藤井昌子

私には難しかった。

ソフトウェアの会社で働いているがプログラミングの知識は素人、しかしプログラミングのテストや仕様書作成などの仕事をしているので何かの助けになればと手に取った。
途中までは読みながら頭で整理しつつ読み進めたが、気づいたら何だかよく分からなくなり、結局すっきりしないまま本を閉じた。
索引があったら良かったかも。

ソフトウェアやプログラミングは日に日にアップデートされ、エクセルさえ使えればいいよと言われた時代は古代のよう。
何が分からないのか、何を学べばいいのか、実体があるようなないような、ふんわりモヤモヤした状態が続いている。

様々なものが自動化され、小学校からプログラミングを学ぶ時代。
一度置いていかれると、聞くに聞けない状態になるし、私もプログラミングの授業を受けたい！

マンガは不要だったという意見もあるけど、私は和んだし、ワン吉派だな...
「やさしい」「入門」「マンガ」などに希望を持って手に取る本が、ことごとく難しくて沈むわ～！
この本はまだ私には高度だということが分かったので、もう少し昭和のアナログ淑女向けの本を探そうと思う。

プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで

及川卓也 / 小城久美子 / 曽根原春樹

範囲を拡げ過ぎて総花的で表層的で焦点が不明瞭になっている。結果フレームワークとコンセプト紹介がただただ400ページ続いているようになっている。パーツパーツでは有益な情報が豊富なのでWhyとHowのプロダクトマネジメントに絞ってページ数をコンパクトにしたほうが良かった気がする。PMを志す人の指南書に成りえるポテンシャルがあっただけに残念。プロダクトマネージャーになりたい人にはお勧めしにくいがビジネスの読み物としては面白い。

ソフトウェア・ファースト

及川卓也

伝統的な製造業でのデジタライゼーションをどうするか、という視点で学べるところがないかという気持ちで読んだ。
結論としては、ソフトウェアを内製化する組織体を作れ、それを支持する人を増やせ、ということになるのだろうが、ではソフトウェアに何ができるのか、何をソフトウェアで実現するのか、という部分は、当たり前だけど個々の現場によって異なる。

現実の問題をどのようにデジタル、ソフトウェアでより良くしていくことが可能なのか？という問いに対しての答えがある程度見通せないことには人を雇って内製化して、などというステップには進むことはできない。

検品のための画像処理のような個別の分野はわかりやすい例としては挙げられるだろうが、もっと大掛かりな事業オペレーション全体のようなものの問題をどう切り分けてソフトウェア視点の課題に落とし込むのか、というところが悩ましい。

そこがMicrosoftやGoogleのようなプロダクトそのものがソフトウェアという著者の経験ではカバーされないのではないかと感じてしまう。

OKR（オーケーアール） シリコンバレー式で大胆な目標を達成する方法

クリスティーナ・ウォドキー / 二木夢子 / 及川卓也

OKRのストーリーと解説の本
ストーリ仕立てのビジネス本は海外が主流かな。イメージしやすくて良い。短いけどもとがシンプルなのでしょうがない

objective：成し遂げたいこと、 key results：できたか判断するための指標
達成できない理由①ゴールの優先順位がない②ゴールを伝えてない③プランがない④時間を用意しない⑤再挑戦しない
難しいが不可能ではないKRを作る

①今週の優先事項：やるべき仕事を3,4個
②今後4週間：周囲に知らせるべき予定
③OKR自信度状況：自信度50％からの変化
④健康健全性指標：結果達成の間に守りたいもの

ソフトウェア・ファースト

及川卓也

とあるビジネス書で紹介されていたので、遅ればせながら読んでみたら、ともて良かった。会社の組織文化とか組織構造にも踏み込む内容。最近はやりのDXを考えるにあたっても前提としてぜひ理解しておきたいヒントがいっぱいあるように思いました。

EMPOWERED 普通のチームが並外れた製品を生み出すプロダクトリーダーシップ

マーティ・ケーガン / クリス・ジョーンズ / 及川卓也 / 二木夢子

これはプロダクトチームのメンバーとなる人の必読書。
勉強になった。

　最善を尽くしたにもかかわらず、あるチームメンバーについて、成功への道筋がイメージできなくなることがある。この段階に達したら、決然と行動するのが重要である。
　多くのマネジャーにとっては、この原則が最も実践しづらい。コーチングとは人を育てることなので、必然的に問題点を成長の機会として見ることになる。それ以上に、部下に仕事ができていないと伝えるのは、精神的に最もきつい会話の1つだ。いっそのこと、目を背けてサボったほうが気が楽だろう。
　しかしそうすると、マネジャーも、チームも、本人も傷つく。まず、マネジャーは他の人を犠牲にして、この人に必要以上の時間を割いている可能性が高い。次に、他のチームメンバーにはハードワークを求めながら、その人には凡庸であることを許すというシグナルを出してしまっている。それは信頼を損ない、モチベーションを失わせるための確実な道のりだ。最後に、パフォーマンスに問題のある本人が、もっと成功できる可能性のある他の職場に移るチャンスを与えられていない。

■プロダクト担当者らしい行動
　傾聴し、協力し、共同学習し、啓蒙し、鼓舞し、手柄を渡し、責めを引き受け、責任を取り、知りえないことを知り、知らないことを認め、謙虚さを示し、会社全体にわたってさまざまな関係を築き、個人レベルで顧客を知り、リーダーシップを発揮することをいう。

■マネジャーのアンチパターン
・マネジャーが無関心
・マネジャーがマイクロマネジメントに回帰する
・マネジャーが話してばかりで相手の話を聞かない
・マネジャーが厳しいフィードバックをしない
・マネジャーが不安定か、あるいは能力不足である
・マネジャーが損切りをしない

　つまり、デザイナーやエンジニアと協力して、価値、ユーザビリティー、実現可能性、事業実現性を備えたソリューションを編み出すことだ。それがプロダクトディスカバリーであり、毎日４時間専念すべき仕事である。

■プロダクトチームの４大リスク
１．顧客はこのプロダクトを買うか、あるいは選ぶか？（価値のリスク）
２．ユーザーはこのプロダクトの使い方がわかるか？（ユーザビリティーのリスク）
３．私たちはこのプロダクトを製造・構築できるか？（実現可能性のリスク）
４．ステークホルダーはソリューションを支持するか？（事業実現性のリスク）
５．私たちはこのプロダクトを製造・構築するべきか？（倫理的リスク）

■私が気に入っている面接の質問
１．実行力―どのくらいうまくものごとをやり遂げ、言われなくても正しいことを実行し、複数の目標を同時に追求できるか。
２．創造力―その場にいる人の中で、あなたが一番多くのアイデア、または最も優れたアイデアを提案できたケースはどの程度頻繁にあるか。
３．戦略―現在取り組んでいる内容を俯瞰的に、より広いマーケットやビジョンのコンテキストでとらえ、それを他の人たちに対して明確に提示することが、どのくらいうまくできるか。
４．成長―プロセスの賢い使い方やチームマネジメントなどを通じて取り組みの成果を倍増させる能力に、どのくらい優れているか。

　しかし、多くの企業にとっては、問い自体が変化している。
　いまや、私に寄せられる問いは、「プロダクトチームが分散し、一部または全体がリモートワークに従事しているという前提で、自分たちが継続的なイノベーションを起こす可能性を最大限に高めるために、ベストプラクティス（最良の方法）をどのように活用するか」に変質している。

■トポロジーとデザイン
　ほとんどの企業は、職能横断型プロダクトチーム、少なくともエクスペリエンスチームには、専任のプロダクトデザイナーが必要であることを理解しているこれは、優れたプロダクトをつくるために、プロダクトデザインがどれほど決定的に重要かという認識を示している。
　ただし、デザイン部門のリーダーが、「社内エージェンシーモデル」という別の形を好む場合もある。…
　…
　社内デザインエージェンシーモデルでは、重要な意思決定が行われるときに、デザイナーは通常その場にいない。したがって、デザイナーは―そして最終的にはユーザーが―そのツケを払うことになるのだ。
　デザインは社内サービスとして運営するには、あまりに重要だ。デザインマネジャーは、プロダクトマネジャーやテックリードと同様に、プロダクトチームの中でも特に優秀なメンバーが務めなければならない。


　スタートアップ企業の創業者やCEOの多くは、有能なエンジニアリング組織と協力して仕事をしたことがありません。そのため、テクノロジーの役割や、エンジニアがプロダクトマネジャーやプロダクトデザイナーのパートナーとして果たすべき貢献について、根本的に誤解していることが珍しくありません。

■チームに答えを導かせるほうが優れている理由
・最も適切なソリューションを判断するのに適した人々は、問題に最も近く、必要なスキルを備えた人々―つまり、プロダクトチームである。
・会社としては、求められるアウトカムを達成するために、チームに責任を持ってもらいたい。
・構築すべき機能を会社からチームに指示してしまったら、その機能が必要な結果をもたらさなかった場合に、チームの説明責任を問えない。
・解決すべき問題と、その問題を最適と思える形で解決するための余地をプロダクトチームに与えれば、チームは問題に対し、はるかに高いオーナーシップを感じるようになる。
・チームが考えついた初めてのソリューションによって求められるアウトカムが生まれなかった場合、チームは、そのソリューションを引き続き繰り返すか、別のアプローチを試すかして、求められるアウトカムを生み出すソリューションを見つけなければならない。

■実在の急成長企業の事例からの最重要ポイント
１．トポロジー、プロダクト戦略、チームの戦略から、四半期中に発生する問題や障害の臨機応変なマネジメントまで、プロダクトリーダーが果たすべき重要な役割。
２．フォーカスとインサイトに基づく真のプロダクト戦略の重要性。
３．チームの目標を積極的にマネジメントする重要性。
４．エンパワーされたチームと伝道師のチームの価値。
５．知ることができる情報とできない情報に関する制約。
６．一部しか功を奏さないとわかっていても複数の方法に賭ける、というリスクマネジメント要素。
７．インサイトを行動に変える際にチームトポロジーが与えるインパクト。
８．リーダーとプロダクトチームに必要なギブアンドテイク。
９．すべてのプロダクトチーム間のおける広範囲の戦略コンテキストの共有の重要性。
10．不確かなことは面倒で、うまくいく保証はない。しかし賢いリーダーはたいてい、うまくやる方法を見つける。それは、チームを信頼し、不確かさを受け入れ、リスクを適切に管理するからである。

■エバンジェリズム10のテクニック
１．プロトタイプを見せよう。
２．ペイン（痛み、悩み）を共有しよう。
３．ビジョンを共有しよう。
４．学びを共有しよう。
５．貢献してくれる人々の名前を気前よく共有しよう。
６．素晴らしいデモをする方法を学ぼう。
７．自己学習をしよう。
８．心の底からときめきを感じよう。
９．熱意を表に出すやり方を学ぼう。
10．プロダクトチームと時間を過ごそう。

OKR（オーケーアール） シリコンバレー式で大胆な目標を達成する方法

クリスティーナ・ウォドキー / 二木夢子 / 及川卓也

会社で取り入れようということで読んだ。

今までも様々な手法を取り入れようとしてきたが、なかなか継続できていない。ブームのように始めて気が付いたらフェードアウト。この繰り返し。

このOKRはどうだろうか。
手法自体が魔法のように効果を出すことはない。いかに自社に定着させ継続させられるかが問題だと思われる。

書かれていることは当たり前のこと。目標に向かって何をなすべきか。特に目新しいことではない。当たり前のことをやる事がいかに難しいか。

前向きに取り組んでいこう。

OKR（オーケーアール） シリコンバレー式で大胆な目標を達成する方法

クリスティーナ・ウォドキー / 二木夢子 / 及川卓也

前半はある企業でベンチャー企業を導入した際の様子が小説式で書かれている。
後半はOKRそのものの解説だ。
「Measure What Matters」も各企業のOKR例を出してくれていたが、本書は1社のみ。
しかも架空のベンチャー企業を題材としていた。
そういう意味では、「Measure What Matters」の方が現実的だし、説得力があった。
一方で、架空のベンチャー企業の物語は、それはそれでアリかもしれない。
おそらく数々の企業のエピソードを総合して物語として完結させたのだろう。
このとあるベンチャー企業の起業の様子が、違和感なく想像できたのだ。
本当に会社を運営していくのは大変だ。
そういう意味でサラリーマンというのは、何と楽なことか。（誤解を恐れずに表現してみた）
経営者というのは、胃がキリキリする思いで、毎日を過ごしているのだろう。
何でこんな思いしてまで会社経営しなければいけないんだ、と自問自答しながらの日々。
部下は想像以上にポンコツで、仕事への意欲もない。
渾身の商品も顧客にはそっぽを向かれ、売上が立つ見通しもない。
そんな日々から必死で抜け出すために、藁にもすがる思いでOKRという幻想を追い求める。
そんな頼りないものでもすがってしまうほどに、経営者というのは孤独なのだろうと思う。
しかし、決してOKRはすべてを解決する魔法の呪文ではない。
必死に前を向くため。
ともすれば忘れてしまいがちな理想の形をハッキリとさせるため。
脇目もふらずに真っ直ぐ進んでいけるように。
心が折れないように。
そんな願いが詰まっているのがOKRというものなのだということを、この本書で見ることが出来た。
だから、OKRをただの制度として取り入れようとは思わない方がいい。
そこに「思い」が無い限り、OKRは形だけのものになってしまうだろう。
不思議なもので、企業は生き物である。
根性論は否定されがちであるが、人間が集まって共同で成し遂げようとしている集団的生き物に、「思い」はものすごく大事ではないだろうか。
それら「思い」を案外と分かりやすく形にしたのがOKRなのだと思う。
だからこそ、経営トップがOKRにコミットしなければいけないし、経営トップこそがストレッチな目標を追い求めないといけない。
サラリーマン社長で、出世が人生のゴールになってしまっている経営者が、果たしてOKRを正しく運営できるだろうか。
正直難しいと思う。しかしながら、これらストレッチな目標を頑張って追い求めていける企業でないと、今後は絶対に生き残れないだろう。
これだけの時代の変化が激しい中で、一歩でも二歩でも意地でも前に進んで行ける気持ちがない限りは本当に負けるぞ。
本書を読んでそう感じてしまった。
つまり個人の人生にとっても、OKRは非常に必要なツールなのだと思った。
（2021/7/14）

プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで

及川卓也 / 小城久美子 / 曽根原春樹

タイトルに偽りなし。正に教科書として「すべて」を網羅していると思います。
ただ、PDMとして参考になるのは前1/3くらいでした。後は広く必要な知識等について説明が記載されていますが、一般的な話以上のモノは少なく、あまり参考になりませんでした。（この記載レベルならすでに知ってるという人が多そう）