読み終えた瞬間の熱い気持ちのまま感想文書こうって思ってたのになかなか書けないままだいぶ時間がかかってしまった😇
この本を手に取ったモチベーション
僕はプロダクトマネージャーではないが、良きプロダクトマネージャーの仕事については興味を持っていた。 以下のような理由による。
PdM不在のプロダクトプラットフォーム開発の立場から
業務ではプロダクトプラットフォームチームに在籍している。"Platform as Product"*1の考え方で業務に臨む一方で、PdMという専門職がチームに置かれているわけではないので、開発チームがプロダクトマネジメントを主に行っている。どのようなプロダクトプラットフォームを目指すべきかという検討にあたって、もう少しプロダクトマネジメント的な方法論を学んだ方がいいだろうか、ということを考えていた。
(各社が、プロダクトプラットフォームにおけるプロダクトマネジメントをどうやってるかは興味がある)
うちの会社では「TPM」と呼ぶけど、何が違うの？
プロダクトプラットフォームチーム所属以前は、プロダクト機能開発に携わっていたが、そこでプロダクトをマネジメントするロールは、会社における役職名として「TPM」(Technical Product Manager)と呼ばれていた。そういえば、「PdM」という言葉を日本でよく聞くようになるまで、前職ではそれらのロールは「ディレクター」と呼ばれていたことも思い出した。 こういったロールの呼ばれ方の違いは、プロダクトマネジメントという広範な業務においてどのような違いを持つのか、もう少し理解したかった。
自分って、プロダクトマネジメント方面にも意識を向けられる開発者なのかも？
プロダクトの方向性に関心を持ち、他者を巻き込み積極的に要件/仕様を詰めていく...という自身の動き方を評価してもらえることが、これまでの業務で少なくない。そういった自分の動き方を「プロダクトマネジメントもカバーする」と表現して良いのならば、自分は比較的プロダクトマネジメントも得意なソフトウェアエンジニアなのかもしれない。(とか言ってて、それは言いすぎだろという気持ちが強くある)
余談ではあるけれど、そんなロールを指して「プロダクトエンジニア」と呼ぶのかもしれないと思いつつ、あんまりこの呼ばれ方は好きではないかも。「技術」と「プロダクト」を二項対立とみなして、トレードオフスライダーを「プロダクト」に寄せている人...という印象を与えることを恐れているのかもしれない。(ただし、そういった先入観で「プロダクトエンジニア」の呼ばれ方を忌避するのは、「プロダクトエンジニア」ロールへの風評被害かもしれない)
この本のエッセンス...あるいは"原液"
読み終えてまず思い浮かべたのは、「カルピスは薄めた方がうまい」という最近聞いた言い回し。僕はこちらのツイートで知った。
あと、改めて読んでみて、ホリエモンが言う「カルピスは薄めた方がうまい」というのを思い出した
— ところてん (@tokoroten) 2024年1月15日
本質は原液すぎて飲み込めない人が多いんだけど、100倍くらいに希釈してやると、それに飲み込めるようになり、価値がある人が増え、読者の満足感が上がるというやつ
まじでコレだった、100倍希釈
ホリエモンの言う「カルピスは薄めた方が美味い」
— ところてん (@tokoroten) 2024年1月15日
blogで本質を数行だけ書くとクレームが来るが、本質をChatGPTに希釈させると、ぞれに満足する人が多い、という話
原液が濃すぎて飲めないのと、原液では満足感がない（文章を読んだという体験ができない）というなーhttps://t.co/aX0Dstn3Ls pic.twitter.com/uTKbCnwXGS
では、この本の「原液」は、というと
- あらゆることよりもプロダクトのアウトカムにフォーカスしろ
- そのためにプロダクトマネージャーは何でもする必要がある
...と、僕は読み取った。
そう書けば、「何を当たり前のことを」と思うかもしれない。だからこそ「薄める」必要がある。
この本は読みやすい軽妙な筆致で、手を変え品を変え「◯◯よりもアウトカムを優先しろ」というメッセージを繰り返す。 そして「◯◯よりもアウトカムを優先するからには、あなたの仕事はこうなるはずだ。逆に、こういうことはしてはいけない」といった具体例が多数添えられる。チャプターごとの切り口は違うので個別のテクニックについてのそれぞれの学びは得つつ「あ、結局言いたいのは、また"アウトカム"だな」と次第に"原液"の味を感じるようになってくる。牛乳で割ってもカルピスはうまいよね。
さて、この本で「アウトカムを優先すべき」とする比較対象は多岐にわたる。
「アウトプット」「社内政治」「アイデアにこめた意図」「ベストプラクティス」「アジャイル開発」「ドキュメント」「ロードマップ」「ビジョン/ミッション/達成目標」「データ」「チーム」...etc
こうやって並べてみると「アウトカムを大切にしたいからこそ、それを大切にしているんだ」や「そりゃアウトカムの方が大事にしたいけれど...現実的には難しい」と思うようなものもある。そんな現実の声をこの本も決して無視しない。むしろ、アウトカムという目的よりもそれらの手段を優先してはいないだろうかというバイアスに気づかせたり、いかにして現実的にアウトカムを優先するのかというHow toを具体的に書いたり...というのがこの本の多くを占める。
と、ここまで書いた内容でわかるかもしれないが、実はこの本は、読む以前の「モチベーション」に直接応える本ではなかった。(それには早い段階で気づいた)
自分は「プロダクトマネージャーのしごと」と銘打たれた書籍に対するイメージとして、開発フェーズごとにすべき業務や、それを支えるスキルやベストプラクティスを網羅するような本と実は思っていた。一方で、この本は以下のようなテキストから始まる。
本書は素晴らしいプロダクトを作るためのステップバイステップの手引きではないですし、ましてやプロダクトマネジメントの成功を保証するフレームワークや技術的な概念のリストでもありません。本書は、どんなツールやフレームワーク、「ベストプラクティス」でも対処できない課題をあなたが乗り越えられるようにするのを目的としています。曖昧さや矛盾、しぶしぶする妥協といった、日常的なプロダクトマネジメントの実践についての本です。端的に言えば、私のプロダクトマネージャーとしての初日に必要だった本であり、そのあとも何度も何度も必要としてきた本です。
― Matt LeMay. プロダクトマネージャーのしごと第2版 (p. 21). Kindle Edition.
言ってみれば、プロダクトマネージャーとしてのロールを担うにあたってのハードスキルの紹介を期待していたと言える。ところがこの本が2章の「プロダクトマネジメントのCOREスキル」で言うことはこれだ。
一般的にソフトスキルは、ふわふわしていて、内向きで、定量化や計測の難しい対人関係スキルとされています。一方で「ハードスキル」は、固定的で、目的がはっきりしていて計測可能と考えられがちです。たとえば、コミュニケーションや時間管理のスキルはソフトスキルとみなされますが、プログラミングや統計的分析はハードスキルとみなされます。
(中略)
プロダクトマネジメントに話を戻すと、ソフトスキルとハードスキルを区別することは特に有害になる場合があります。手短に言うと、あまりにも多くの人や組織が、ハードスキルにもとづいてプロダクトマネージャーを採用しています。しかしそれは、プロダクトマネージャーに期待される日々の仕事とはほとんど関係ありません。
― Matt LeMay. プロダクトマネージャーのしごと第2版 (p. 68). Kindle Edition.
「プログラミングはハードスキル」としたうえで、「ハードスキルはプロダクトマネージャーのしごととほとんど関係ない」と断じられる。 プログラマーとしての自分は、プログラミングを軽視するようなプロダクトマネージャーが推奨されているのだとしたらどうしよう...なんて身構えるが、決してそういうことではない。
重要なのは、技術面でエキスパートであることではなく、技術的ではないことと同じように、技術のことについて探索したり学んだりするのに抵抗がないことです。
(中略)
優れたプロダクトマネージャーは、技術面以外の話題と同じように技術面にも興味を持ちます。
― Matt LeMay. プロダクトマネージャーのしごと第2版 (p. 71). Kindle Edition.
...と続き、「あぁたしかにそういう人、一緒に仕事してると楽しいんだよなぁ」なんて思ったりする。
「PdMは技術的な方法論にあまり口出ししないでほしい」と「PdMも技術を軽視しないでほしい」の両方ともプログラマーが抱きがちな感情なのではないかと思うのだけれど、こういった「好奇心」というのが、そのバランスをとるキーワードなのかもしれないとも思った。
この本では「アウトカムにフォーカス」が繰り返されると書いたが、決して、原理主義的にアウトカムのみを追い求めるプロダクトマネージャーが推奨されているわけではないことも伝わるだろうか。むしろアウトカムにこだわりたいからこそ、開発者ともうまくやるための泥臭いソフトスキルも重要視しているように思える。
印象的だった箇所
「1章 プロダクトマネジメントの実践」
プロダクトマネージャーの役割の候補者を社内で見つけたいと考えている組織から相談を受けたとき、私はよく、会社のなかでの情報伝達の経路を図にしてもらいます。これは公式の組織図ではなく、人が互いにどのようにコミュニケーションしているかを示す非公式な概略です。すると、必ずいつも中心にいる人が出てきます。情報のブローカーであり、人やものをつなげる人であり、積極的に新しい視点を求めている拡大思考の人です。
― Matt LeMay. プロダクトマネージャーのしごと第2版 (p. 38). Kindle Edition.
ハードスキルありきで、PdMというロールの適性を考えてしまいそうな自分にとって目からウロコだった。「あーそういう人いるわー」と思ったし、思い浮かべたその人は現時点でPdMでなくとも「その人がPdMやってたら確かにしっくりくるかもな」なんて妄想もした。
プロダクトマネジメントのワークショップで教えていると、ほぼ毎回最初に聞かれる質問はだいたい同じです。それは、プロダクトマネージャーと、プログラムマネージャー、プロダクトオーナー、ソリューションマネージャー、プロジェクトマネージャーの違いは何なのか、というものです。
― Matt LeMay. プロダクトマネージャーのしごと第2版 (p. 46). Kindle Edition.
ずっと増え続ける「プロなんとか」という肩書きのリストのことを「曖昧に書かれたプロダクト関連の役割（Ambiguously Descriptive Product Roles、ADPR）」だと考えることにしました。これは、日々の活動や責任についてあまり多くを語らない無数の肩書きを包含するバナーコンセプトになります。
(中略)
ADPRとして、自分の仕事は具体的に何をするのかを絶対的に明確化することはできません。たくさんの質問を投げかけ、チームと密接に仕事し、いちばんインパクトがあることにできるだけ集中しましょう。
― Matt LeMay. プロダクトマネージャーのしごと第2版 (pp. 47-48). Kindle Edition.
僕が「うちの会社は"TPM"と呼んでるけど、こういう呼び分けにはどういう意図があるのかな」なんて考えていたことに対する究極のアンサーだった😂 プロダクトマネージャーがアウトカムのために何でもしなきゃいけない人ならば、結局同じ呼び方をしていても、そのときのビジネスやチームやプロジェクトの状況に応じてやることは変わるので、些細な呼び方は気にしなくていいやと思えるようになった。
「4章 過剰コミュニケーションの技術」
ステークホルダー、特に幹部のステークホルダーは、極めて多忙です。ミーティングでうなずいても、「わかった、ありがとう」のメールも、認知されていたとはしても、あなたの懸念点に必ずしも注意が向いていることを意味しません。プロダクトマネジメントの世界では、はっきりとした承認、明示的な賛意でないものは、驚くほど危険です。その曖昧な注意を払っていない非明示的な賛意の例としていちばんに上がるのが「よさそう」という反応です。 優秀なプロダクトマネージャーは、いろんな手を使って、人が「よさそう」とは答えられないようにしています。たとえぎごちなくても、イライラさせる可能性さえあっても、必ず自由回答式の質問をします。
― Matt LeMay. プロダクトマネージャーのしごと第2版 (p. 108). Kindle Edition.
「納得は全てに優先するぜ」じゃないが、僕はなるべくステークホルダーが納得していることを確認したいし、「コンセンサスが得られた」ということを明示的に確認して仕事を進めたいタチだと思う。だからこそ、その納得を確認する行為が、消極的な「よさそう」を引き出すことで単に「言質をとった」だけになっていないかったと考えさせられた。
また、それを回避するために「Disagree & Commit」というテクニックが紹介される。これはステークホルダーひとりひとりに「Disagreeでなければ、"Commitする"とはっきりと表明してもらう。それができないなら、遠慮なくDisagreeする」というIntel発祥のもので、おもしろい取り組みだと思った。 「Commitする」を全員に表明してもらうのは、結局新たな同調圧力になってしまわないかという不安もよぎるが、その検証も含めて何かのときに試してみたい。
「7章「ベストプラクティス」のワーストなところ」
プロダクトマネジメントを再現可能なベストプラクティスの適用にすぎないとみくびってしまえば、厄介で予測不能で絶対に回避できない人間の複雑さを洗い流してしまうことになります。その複雑さのなかを進んでいくのがプロダクトマネジメントの本来の仕事であるのにです。
― Matt LeMay. プロダクトマネージャーのしごと第2版 (p. 189). Kindle Edition.
時折、仕事などで「人間という複雑系をずいぶんとシンプルなモデルで捉えたルール/進め方/オペレーション...じゃないかな」と思わされるようなやり方に出くわすことがある。これらの人間の複雑さを洗い流すことがときに効果的であることは否定しないが、そういったプラクティスの強制はサステナブルではないよなと薄々思っていた。 そんな自分の気持ちにピッタリと合うような章だった。
最近、ほとんどのプロダクトマネジメントフレームワークやモデルは、有用なフィクションと考えるとよいことに気がつきました。「有用な」も「フィクション」も同じくらい重要です。
― Matt LeMay. プロダクトマネージャーのしごと第2版 (p. 197). Kindle Edition.
「ベストプラクティス」に加えて、プロダクトネジメントの「フレームワーク」についても「フィクション」と断じる。一方で、そのうえで「有用」と判断するのがこの本のいいところなんだよなと思う。
自分たちソフトウェア開発者が普段意識するようなプログラミング技術のベストプラクティスやフレームワークは、"ハード"スキルと言うだけあってもう少し手触りがあるものだとは思うが、たとえば組織論やマネジメント論などのソフトスキル寄りの発表資料などを読んでいて「めちゃいい話だけど、うちの現場においても再現性あるかなぁ」なんて思うことはときどきある。こういったものも「有用なフィクション」と考えて接するのがちょうどいいのかもしれない。
「9章 ドキュメントは無限に時間を浪費する（そう、ロードマップもドキュメント）」
プロダクトマネージャーとして働いていたときに受けた最高のアドバイスの1つが、ロードマップはいつ何を実行するかの厳密な計画ではなく、戦略的なコミュニケーション用のドキュメントととらえることでした。
― Matt LeMay. プロダクトマネージャーのしごと第2版 (p. 244). Kindle Edition.
プロダクトの仕様書はプロダクトではない
― Matt LeMay. プロダクトマネージャーのしごと第2版 (p. 249). Kindle Edition.
最高のドキュメントは不完全
― Matt LeMay. プロダクトマネージャーのしごと第2版 (p. 252). Kindle Edition.
「いかなるドキュメントや成果物でも、チームに共有する前に1ページ、1時間以上は使いません」
― Matt LeMay. プロダクトマネージャーのしごと第2版 (pp. 254-255). Kindle Edition.
ドキュメントについて書かれた9章は、自分好みのパンチラインが頻出する章だった。 ロードマップもガントチャートも、プロダクトマネージャーが書くことになりがちなドキュメントだけれども、そこに書かれた計画そのものに価値はなく、あくまでもコミュニケーションのためのドキュメントであることに価値があると強調する。そして、コミュニケーションのためのドキュメントという意味において、最高のものは不完全のものであると指摘し(僕たちが作る「たたき台」なんてまさにそれだよなと納得した)、だからこそ「チームに共有する前に1ページ、1時間以上は使わない」という具体的なテクニックにつながっていく。
このブログ書き上げるのにめちゃ時間かけてる自分が言うのも説得力ないのだけれど、本当にこれ大事だよな〜〜〜と、いつも自戒をこめて思っている。
「10章 ビジョン、ミッション、達成目標、戦略を始めとしたイケてる言葉たち」
アウトプットに著しく集中しているように見えるチームは、多くの場合、壮大で具体性の乏しいアウトカムを目指して仕事をしていたのです。チームやリーダーたちと何度もレトロスペクティブを繰り返すうちに、これが確実性と予見性を求めてしまう人間的な反応の結果なのだと理解できるようになりました。開発内容や期日は何らかの方法で決めなければいけません。アウトカムに具体性がなければ、アウトプットに具体性が求められるようになります。アウトプットに裁量を持ち柔軟に決めたいのであれば、チームはアウトカムを具体的に決めなければいけません。これをアウトカムとアウトプットがシーソーに乗っていると見立てることもできます。片方を具体的な開発内容と期日で押し下げれば、もう片方はテーマや機会のように変更可能なもので押し上げられることになります。
― Matt LeMay. プロダクトマネージャーのしごと第2版 (pp. 266-267). Kindle Edition.
いまの自分たちの開発における「アウトプット」と「アウトカム」に求められてる具体性のバランスを考えてみる機会となる箇所だった。たとえば「窮屈な開発」が強いられてると感じるとき、言い換えればそれは「アウトプットに高い具体性が求められる状態」なのかもしれない。そして、それによってアウトカムに具体性を持たせることを回避しているのかもしれない。もしも窮屈な開発を回避したいと思うならば「具体的なアウトカム」をコミットすることを手段として考えてみてもいいのかもしれないと思った。
また、この記事は結果的に「アウトカム」を連呼するものになってしまったけれども、そもそもの「アウトカム」という言葉の定義について疑問に思われているかもしれない。 それはビジネス上の価値を指すのか、ユーザーにとっての価値を指すのか...によって、日々の業務は違ってくるという感覚が当然僕にもある。
結局、これを決めていくのもプロダクトマネジメントの一環なんだということが、特にこの章で示唆されているように思えた。だからこそ、アウトカムを具体的に定義する必要があるし、「ゴール」や「達成目標」というものも、アウトカムをとらえるための方法なんだということがこの章では触れられている。
最後に
上で引用した箇所以外にも、「アジャイル開発」に対しての8章、「データビジネス」に対しての11章、「リモートワーク」に対しての13章なんかは、わかりやすくWeb開発者の僕たちも思うところがある章かもしれない。 その他諸々、epubはハイライトだけなんだけれども、きりがないのでこのあたりで...！
総じて言えば、「いやー、読みたかった本じゃなかったけど、読みたい本だった〜！」という感想でした。
「結局、プロダクトのアウトカムこそ大事だよね」みたいなの、ともすれば青臭いきれいごとで終わってしまうけれど、そうならないような具体的な泥臭さであふれているのも好みだった。一方で、そんなきれいごとで自分の仕事を見つめ直したくなるような、初心に返らせる強さもある本だと思う。
一緒に仕事をしていたり、同じコンテキストを共有していたりする人にこの本読んでもらったうえで飲みにいったら酒が進みそう。
プログラマとしての職責に軸足を置くことを変えるつもりはないが、プロダクトマネジメントのためのハードスキルこそ持ち合わせていなくとも、アウトカムの追求のためにできることなんでもやるぞ...なんて青臭い気持ちを書いて、この感想文を終えたい。
