『プロダクトマネジメント』を半分読んだ感想
2020/01/10
どうも@kaori_choです！ステイホームの3連休！
『プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける」を読んでいる感想です。
3行まとめ
- アウトプットではなく「アウトカム(成果・結果・ビジネス価値） 」に注目せよ！
- ちょいむずな本。プロジェクトリーダーなど、コーディング＋責任者の仕事をしたことがある人が読むと「あれってそれだったのか！」的な発見がありそう
- プロダクトマネージャーは"問題の見極め"と"人に影響を与える"の両方ができる人が向いてる
こんな人におすすめ
コーディングしていたらプロジェクトリーダーやプロジェクトマネージャー、プロダクトオーナーなど、気付いたら昇進していた系の人におすすめ。実は（いや、みんな知っての通り）、コーディングができるスキルと、プロダクトマネジメントのスキルはまったく別物だからだ。プロジェクトマネージャーやオーナーとの棲み分け（違い）についても触れられているので、特に全ての中間管理職エンジニアは読んで損はないと思う。
教科書的な部分もあるが、架空の会社で起きた出来事としてストーリー形式で書いてある部分も多いので、自分の会社と比較したり、感情移入したりしながら読める本。
感想
ビジネス力、テクノロジー力、コミュニケーション力を最大限発揮して、「適切な問題を解く」ことに人生を捧げたい人はプロダクトマネージャーに向いているのかもしれない。私たちは仕事において、ソリューションどころか解くべき問題自体を間違えていることが実は多々ある。「いま、どの問題を解くべきか」「それはなぜか」を考え続けるのがPdMの役割だ。決して生易しい道ではない。だが、これができればチーム、組織全体、会社全体が同じ方向に向かい、アウトカムを最大化できる。
みたいなことが半分くらい読んで書いてあったと思う。
正直、後半はまだ私には少し難しくて、流し読みした。私はプログラマーとマネージャーの間でゆれているところなので、こんなキャリアもあるのか〜と参考になった。一方、「俺はプログラマーとして一生コードを書いていたいんや！チームのマネジメントとかそういうのは頼んだ！」という人にとっては「ビルドトラップ」という言葉だけ知っておけば、後半は読まなくても良いかも。
メモ
以下は例によって自分の気になったところをピックアップ。
ビルドトラップ
はじめに xiii
本書は、優れたプロダクトマネジメントによってビルドトラップから抜け出すためのガイドです。
p.1
ビルドトラップとは、組織がアウトカムではなくアウトプットで成功を計測しようとして、行き詰まっている状態のことです。
結構ふつうにあると思うの。個人の短期目標をたてて仕事するうえで、「xxの機能をリリースする」とかって書くこと。よくあるよね？根本にはエンジニアの成果の評価が難しい（どうしても目に見える成果だと「リリースになりがち）というのもあると思う。例えば「障害対応ができるスキル」は障害対応すると露呈するけど、「障害が起きないように設計・実装できるスキル」とかってどう評価するのよ、とか。
ところで「ビルドトラップ」という言葉の意味を知っておくだけでも、「こんなに頑張って色々作っているのに、なんかがおかしい」となった時に「これビルドトラップかも？」と思えるという利点がありそう。
それにしても最初からハッとさせられる書き出し。
1章 価値交換システム
p.11
開発者はコードをたくさん書くと評価されます。...プロダクトマネージャーは長い仕様書を書いたり、アジャイル用語でいうバックログをたくさん作ったりすることで評価されます。チームはリリースした機能が多いほど評価されます。このような考え方が広まっていますが、これは有害です。
もちろんアウトプットすること全てが悪いという文脈ではないんだけど、なかなかに耳が痛い。有害ですって言い切っているし。
話それますが、実は私前職で３ヶ月くらい、「コードを消し続ける仕事」をして３０万行くらい無心に葬った時期があり。この時期書いたコードで評価されてたら私クビですね！一行もcommitしてなかったから！（引越し前の断捨離的な位置付けで、必要な作業でした）動いているアプリケーションのコードを消すのって、意外と神経使うんですよ。動いている部分を消してしまうと当然障害になりますし。「コードを葬る技術」っていう本Zennで書こうかな。
まだ最後まで読んでないけど、じゃあエンジニアの成果を何で評価すると良いのかってこの本に書いてあるのかな？？
5章 私たちが知っていること、知らないこと
p.22
プロダクトマネジメントには、既知の未知を認識して調査することと、未知の未知を減らすことの双方が含まれます。...ですが、膨大な量の情報をふるいにかけ、いつ、どんな質問をするかをあきらかにするには、一定のスキルが必要になります。
プロダクトマネージャーはビジネス目標を達成できて顧客の問題を解決できる機能やプロダクトを特定します。つまり価値交換システムを最適化します。
セールスやマーケティングからテクノロジー、デザインまで、企業におけるさまざまな役割について考えてみてください。これらの多くはテクノロジー面かビジネス面のどちらか一方しか見ていません。プロダクトマネージャーはテクノロジーとビジネスのあいだにいて、ビジネスを維持して成長させながら、顧客のニーズをプロダクトに変換するという役割を担っています。
ちょっと難しい表現をしているが、有名な絵の「顧客が本当に欲しかったもの」を探せる人と解釈した。顧客「速い馬が欲しい」PdM「それなら自動車でどうですかね？」の提案や会話ができることがプロダクトマネージャーとして必要なスキルなのかなあ。
1ページ前の既知と未知の図がへぇ〜となった。
確かにエンジニアのキャリアの最初って、テクノロジー面を重点的に学ぶしそっちのスペシャリストになる人も多いよね。テクノロジーのスペシャリストをPdMにしても機能しない一番の理由は「ビジネス面をみてきた経験がそもそもないから」逆にエンジニアの経験がない人をPdMに当て込んでも機能しないのは「テクノロジー面の経験がないから」なかなかどうして難しい。
つまり例えると、戦士（ビジネス）と魔法使い（テクノロジー）のスキルを両方一定レベルまで備えて初めて魔法戦士（PdM)になれるのに、バトルマスター（戦士の進化系）や賢者（魔法使いの進化系）をプロダクトマネージャーとして据え置いてもそりゃあうまくいかねえよ、というそういう話ですかね？私のドラクエ歴は7のみだけなので、記憶あやふやです。
7章 優れたプロダクトマネージャー
この章学びが多い。「プロダクトマネージャー」という肩書きで働いた経験はないが、あ〜わたしがやってきた一部のことはプロダクトマネージャー的な視点でやってきたことだったな〜という気付きがあった。なぜ？から始めるとか。
p.35
「プロダクトマネージャー」という名前そのものが誤解を招きます。プロダクトマネージャーはマネージャーではありません。このポジションに直接的な権限はあまりありません。...プロダクトマネージャーは自分たちが作っているものが正しいことをチームにも会社全体にも納得させなければいけません。人に影響を与えるというスキルはプロダクトマネージャーに不可欠です。
なるほど。翻訳者・通訳のような感じなのかな。
後のページに「開発者と会話したりトレードオフの判断ができるレベルの技術理解ができればよく、必ずしもコードを書ける必要はない。また、マーケットについても学ぶことができるスキルがあれば良い。」的なことが書いてあり、例えるなら賢者やバトルマスターと対等に会話できるスキルが大事って感じなのかー。（この例え気に入った）
8章 プロダクトマネージャーのキャリアパス
今の時代、賢者やバトルマスターは転職しやすいと思うんだけど、プロダクトマネージャーって結局なにができるん？と。
この章ではいくつかの型が示されていて（CPO、最高プロダクト責任者というのもある！聞いたことないけど！）もしかすると、すでに自分の経験を振り返ると会社の中でこういう役割果たしてたな？という方もいるかも。職務経歴書にカッコよく書きたい時に読み返しにこよう。
13章 戦略的意図
あ〜、これひとつのissueを提案する時にも使える視点〜！と思ったのでメモメモ。
p.91
価値検討フレームワーク（図）
収益を増やす
収益を守る
コストを減らす
コストを避ける
よく「改善幅」とか「見込まれる利益」とかで収益を増やす開発や、コストを減らす開発をやることはある。が、収益を守る（収益やマーケットシェアを維持する）、コストを避ける（現状発生していないが将来発生するかもしれないコストを避ける）、っていうのは確かに良い視点だな〜！と。
やっぱりどうしても新しい収益を生む開発って目立つしそれをしているエンジニアは花形〜！って感じがする。それに比べてリファクタリングや既存の機能改善は地味だし裏方感がすごいけど、コストを減らす・避ける点できちんとアウトカムを生んでいるな、と自信が湧いた。
22章 安全と学習
かなり流し読みだが良いこと書いてあった。
p.177
理想的には、プロダクトマネージャーはリスクを減らす人であるべきです。「いちばんお金がかかるのは、作るべき適切なプロダクトなのかを知らないで作ってしまうことです。作るべきものなのかどうか、自分たちは本当にそれが欲しいのかを確認するにはどうすればよいでしょうか？ 多額の投資をする前に、自信を持って正しい方向に進んでいると思えるようにするにはどうしたらよいでしょうか？」などと言える人が理想なのです。
熊とワルツをも読んで、リスクマネジメント意外と身についておるやん、と思った時と同様に、もしかしてプロダクトマネジメントスキルの芽も、自分の中にあるかも、とポジティブな発見があった。
2019年に登壇した時に話した"一番時間がかかるのは手戻りなので、「なぜそれをやるか」を必ず聞くこと。これをやったらそもそも開発しなくて良いものだとわかった。"のエピソードがあるのですが、まさにこれやん。
ただこれ信頼関係がない状態でやると依頼者との確執を生むだけだったり、信頼関係あっても勇気がいることだ。だって
顧客「近くの街まで行きたいので、速い馬をちょうだい！」
PdMの私「いや速い馬はいりません。車でどうでしょう？車があれば、近くの街にも、遠くの街にも行けます。」
と時に突拍子もない「車」を提案して、要望にない「遠くの街」まで持ち出して顧客と対話しないといけない。顧客は車を見たことがないかもしれない。「エンジンって何？」「ガソリンてなに、コストかかるじゃん」それでもメリットがあることを説明し続け、理解と信用を得ないといけない。話を大きくしたから関係者は増えて調整コストも増える。失敗すれば顧客の気持ちは「だから速い馬って言ったのに」となる。
それでもやる勇気を持つこと。いつも成功できなくても、学びつつけること。つまり一朝一夕ではできない。でも正しい方向へ進んでる、という感触を得るために、プロジェクト1つ乗り越えるごとに読み返したい本だなあ。
ーーー
後半は流し読みであまりちゃんと読めてないので、いつか2周目読んだら追記したいな〜
ーーー
そんなことを考えながら、読みましたとさ。
よかったら、いいね！シェアいただけるとありがたいです。
@kaori_choでした！
Discussion