あなたのプロダクトマネージャーとしての「説明」を考えよう -- 書評:プロダクトマネージャーのしごと第2版

自己紹介

Woven Payment Solution開発Gの亀井です。
我々のチームの仕事を一言でいえば「Woven Cityにおける決済システムの開発」になります。
私はWoven by Toyotaというトヨタグループの別会社に出向しており、普段はそちらで活動しています。
Woven by Toyotaはいくつか事業を持っているのですが、Woven City開発はそのうちのひとつです。

この記事はプロダクトマネージャー発売記念プレゼントに応募した際の、書評を書いて公開するというお約束に対する回答でもあります。
https://www.attractor.co.jp/news/product-management-in-practice/

PdMになったきっかけ

実は私はプロダクトマネージャー(Pdm)ではありません。現時点でもPdMという肩書きはもっていません。自称PdMです。
もともとはバックエンド中心のソフトウェアエンジニアで、求めに応じてフロントエンドも書いたりするユーティリティプレイヤーでした。
コード決済システムの経験もあり、それが今の仕事にもつながっています。
その後エンジニアリングマネージャー(EM)もやってきたので、評価とか組織とか採用とかそういった仕事もできます。

ですが、このプロジェクトのために出向するにあたって私に期待されている役割は技術寄りのPdMみたいなものと言われました。
今になって思えば、この時もう少し具体的に期待値を聞いておくべきでしたが、おそらく誰も明確な答えは持っていなかったでしょう。
自分自身でもよくわからないなあと思いながら、技術選定を行い最初のプロトタイプを構築し、採用活動をしてメンバーを増やしと
リードエンジニアとEMを混ぜたようなことをやっていました。
一方で他のチームの人から質問が来ることも多く、それに対して資料を用意したり対面で会議(トヨタ用語で面着といいます)をしたりと説明することにも多くの時間を割いていました。
それでも自分で手を動かすということは続けていたのですが、メンバーが増えてくると明確に私が作業のブロッカーになりはじめました。
そこでメンバーとも話し合い、決済について知見のある自分が作るべき機能を説明して、それを他のメンバーが作るという役割分担のほうが生産性があがるだろうということになり、手を動かさないことを決断しました。
この時から自分自身でも、自分はPdMであるという自己規定ができるようになったと思います。これがだいたい一年ほど前ぐらいのことです。
手を動かすのを止めるという決断については、以前EMをやったときも似たような判断をしていたので、そこに対する葛藤はありませんでした。
また機会があれば自分で手を動かす日もくるでしょう。

この本に興味を持ったきっかけ

PdMという自覚を得たのはよいのですが、具体的にPdMって何するんだっけ？ということについて確信が持てずにいました。
目先でやることはあるので、何もしないということは無くなにかしら出来上がってはいくのですが、自分自身がどんな成果を出しているのか説明しきれないというもやもやがありました。
プロダクトマネージャーについて書かれた記事や本を乱読するもののいまいち腹落ちはできず、消化不良が続きました。
この本の第1版は読まなかったあたり、そこまで本気で調べてもいなかったともいえますが。

そんな折、この本の感想がチラチラ目に入るようになりました。どれも評価が高く、サブタイトルの「1日目から使える実践ガイド」というのも心に響いたのですが、そのうち買うかーぐらいの気持ちでした。
完全に言い訳ですが、その時みかけた感想はどれも現役バリバリのプロダクトマネージャーのもので、わかっている人に伝わるタイプの本なのかなーという疑念があったのです。
そんなときプレゼント企画を発見し、ここまで気になっていて応募しない手はないなと申し込んだのでした。

ここから書評がはじまります

結論から書くと、この本はとてもよい本です。私のようなPdMになりたての人、PdMを目指す人だけでなく、これからPdMという役割を導入したい組織にも役立ちます。
あるいは自分たちの組織にいる肩書きのないPdMを発見するのにも役立ちますし、自分たちの開発プロセスにプロダクトマネジメントを導入するためにも読んだ方がよいです。
その意味ではこの本は0日目から使えるとも言えます。

プロダクトマネジメントとは

この本の偉大なところはPdMという役割は組織によって異なり、世の中の組織が多様であるのと同様に、あるいは世の中の組織が立ち向かう問題が多様であるのと同様に、PdMに求められる役割も多様であるということを認めているところです。
ですがそれだとPdMという役割は存在しないということになってしまいます。この本ではPdMのあるいはプロダクトマネジメントの定義を断念しています。
その代わりに 説明 によってその輪郭を描こうとしています。優れた 説明 の例として別の本『プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける』から引くかたちで、『ビジネスと顧客のあいだの価値交換の管理人』をあげていますが、PdMやそれを必要とする組織はこれや他の 説明 を元に自分たちの組織にあった 説明 を構築する必要があるでしょう。

これは本には書かれていませんが、それぞれの考える 説明 が互いにマッチするかどうかというのは、PdMを採用したり内部から登用にするにあたって重要なポイントになるのだと思います。
もちろんこれは他の職種にも言えることです。ただPdMという役割は他の職種より抽象的であるだけ 説明 の重要度が大きくなると考えます。
あるPdMがどんな経歴だったとしても、 説明 にミスマッチがある組織では活躍できないでしょう。

COREスキル

ではそのような抽象的なPdMという役割にどのようなスキルが必要なのかについて、この筆者は次の4つの能力をあげています。

• Communicate (コミュニケーション)
• Organize (組織化)
• Research (リサーチ)
• Execute (実行)

そして、この4つの能力の頭文字をとって COREスキル と名付けています。
この本のほとんどはこのCOREスキルをどのように発揮するかについて書かれています。
といっても、例えば「Communicateの章」みたいなものがあるわけではありません。
開発を行う上でのあるあるネタに対して、こんな感じにCOREスキルを発揮できるといいんじゃない？みたいな 説明 がされるというのがこの本の構成です。
焦点をコミュニケーションに当てたり、組織作りに当てたりと章によってテーマはあるのですが、発揮すべきCOREスキルは混然として描かれます。

ところで自分の問題は解消されたのか

自分の肩書きはともかくとして、やっていることの半分ぐらいはPdMと言えるなという実感を持てています。それだけでもこの本を読んだ価値はありました。
チームに自分以外のPdMを入れるとしたら、こういうことをやってほしいという 説明 を作ることができたら、より 組織化(Organize) 出来そうなので、挑戦してみてもよいかもしれません。
一方でもし自分が本気で今後もPdMを続けていく、目指すというのであれば自分流のPdMの 説明 をCOREスキルを絡めて構築するとよさそうなのですが、自分の中にはまだその覚悟はありません。

おわりに

改めてこの本はPdMという役割について考える上でとてもよい導き手となってくれる良い本です。
PdMの人もそうでない人も、PdMがあるいはプロダクトマネジメントが自分たち組織にどのように関わっているのか、 説明 を構築するよい機会を与えてくれると思います。

この本というプロダクトを届けてくださった、著者の Matt LeMay 様、訳者のみなさま、O'Reilly 社様、本をプレゼントいただいた株式会社アトラクタ様ありがとうございました。