『プロダクトマネージャーのしごと』はディレクターやデザイナーにもオススメ
総評
『プロダクトマネージャーのしごと 第2版』を読みました。
言語仕様の詳解やアーキテクチャ解説の本と比べ、このような本は心を打つメッセージや過去の苦しみや現在の不安などと重なり、楽しく(?)読めるのが良いですね。
最近はO'Reilly Online Learning Platformで色々と本を読む中で、「うん、なるほど、よくわからん。」となる中で、気分転換に読むには最適でした。
PdMの定義は会社によってまちまちと思いますが、受託制作開発のディレクターやUXデザイナーが対峙する難しさに似ていると思います。エンジニアだけでなくディレクターやUXデザイナーにも是非おすすめしたい一冊でした。
ハイライトからご紹介
電子書籍はハイライトの追加や削除、感じたことのメモなどを簡単に読みながら記録できるのが嬉しいところです。
せっかくなので、記憶の新しいうちに読書中に付けたハイライト部分を追いかけながら感想文にしたいと思います。
『1章 プロダクトマネジメントの実践』から
価値交換の管理人
プロダクトマネージャーはビジネスと顧客のあいだの価値交換の管理人
なるほど、これは端的でわかりやすく、十分に良い表現だと思いました。
私は普段の仕事の中で、「公約数を求める」とか、「現時点でのベターな選択肢や道筋は何か」みたいな話をするのですが、仕事の本質である価値提供は、何をもって価値なのか、誰にとって価値なのか、というのは非常に難しい問題です。
ソフトウェアエンジニアにとっては、酷く醜いと感じる選択やコードの採用がビジネスの観点では最善と考えうることもあります。
顧客・エンドユーザ・上司、それぞれが同じ目線で同じ事象に価値を見出すということはありません。しっかりと落とし所を考え、それに向かう道を引き、皆を説得するのはとても骨の折れる作業です。
それがいかに大きくて、重要で、複雑なタスクであるかを考えれば、プロダクトマネジメントがどうしてこんなにも難しいのかがよくわかるでしょう。
文章は上記のように続きます。
読み手の興味を引く、とても良い内容なので、積読状態な人はまず1章だけ読むことを意識してみると良いでしょう。
『2章 プロダクトマネジメントのCOREスキル』から
4つのCOREスキル(コミュニケーション、組織化、リサーチ、実行)
2.2.1 コミュニケーション
心地よさより明確さ2.2.2 組織化
自らを不要とせよ2.2.3 リサーチ
ユーザーの現実に生きよ2.2.4 実行
すべての努力はアウトカムのために
この4つのCOREスキルとスローガンは特に目新しいものでもなく、言うまでもないことかもしれません。しかし、基本的すぎるが故にちょっとした拍子に簡単に見失ってしまうことでもあります。
定期的に見直したい言葉です。
で、ハードスキルについては?
重要なのは、技術面でエキスパートであることではなく、技術的ではないことと同じように、技術のことについて探索したり学んだりするのに抵抗がないことです
PjM、PdM、PLなどいろいろな呼び方がありますが、プロジェクトを統括する立場や全体を俯瞰することが求められる立場になったとき、ソフトスキル・ハードスキルの両面で自分の能力の低さにひどく悩まされることがあります。
- 求められていることを果たせるだけの前提知識が足らない
- 正しい意思決定を下せるだけの能力が不足している
- ドメイン理解が十分でない
- 自分が理解できていないことをどうやって人に依頼できるのか
ただでさえ、チームや人を動かす立場になった場合には、自分自身が一つ一つの作業に向き合い、理解している時間の確保が難しくなります。
そして、より焦りが加速するのです。
本書の中では、技術面を中心としたハードスキルに傾倒しなくてもソフトスキルによってチームを動機付けたり信頼関係・協力関係を築くことの重要性を説いています。
それが満たせていれば、引用部分のとおりで十分なのかもしれません。
心地悪い会話や時間
透明性を高めるには、たくさんの心地悪い会話をこなさなければいけない
きっとこんな事を言うと激昂するだろうな、と予めわかる中でそれを言い出さなければいけない場に立たされることがあります。
案の定、酷く詰められたり、怒鳴られたりするわけですが[1]、それを経ないと得られない協力や共通認識を手にすることができることもあります。
同僚や部下に対して、ストレスを感じさせる意思決定や発言は避けられないこともあります。
このとき私は“嫌われないかや嫌な気持ちにさせないか”、ではなく、“意義や意図がある行動”か、“説明責任を負えるか”を判断基準にしています。
心理的安全性という言葉がよく使われるようになりましたが、きっと心地悪い会話や空間を回避することではなく、透明性を高めるのが本質でしょう。
『3章 好奇心をあらわにする』から
守りの姿勢と距離を置く
何かを守るためにするすべての試みは、実際には害になる
これは本当に気をつけなければならないと思いました。
よくやってしまいがちな事ですね。
後述する “「上司が馬鹿だ」みたいなことを言った瞬間に..” の話に通じる部分があります。
『4章 過剰コミュニケーションの技術』から
言い逃れ、過剰な謝罪、自己卑下
プロダクトマネージャーには、あらゆる言い逃れ、過剰な謝罪、自己卑下の力が強く働きます。チームそしてあなたにとって、それらは危険で有害です。
これもとてもやりがちで、自分自身も陥りやすく、そしてそこに陥っている人をよく見かけるものです。
読んでいて胸が苦しくなる。
ここで紹介されているマネージャーの実例では、「ごめん、私のせい」とチームに言うほうが自分にとって簡単だったが、この自己卑下がチームとの率直な会話の妨げになっていたことを記載しています。
すべてはアウトカムのために。そう考えると自己卑下はあまり良い手段ではありません。
『5章 シニアステークホルダーと働く(ポーカーゲームをする)』から
おめでとう ―― あなたはチームを壊した
「上司が馬鹿だ」みたいなことを言った瞬間に、実質的にはチームを壊します。
本書の中で一番ドキッとし、心に焼き付いた一文です。
これは先輩エンジニアや先輩デザイナーが後輩に対して営業が馬鹿だ、とか顧客は何もわかっていないと軽視する発言をするのも同様です。
上司が馬鹿だとか、まともな判断をできる人間じゃない、発言に意味はない、要求に従う義務はないとお墨付きを与えてしまったら、一体チームはどうなるでしょうか。
シニアステークホルダーからのどんな要求でも、全部気まぐれで合理的でないとみなすようになるのです。組織のゴールに沿ったプロジェクトに取り組むために使う時間とエネルギーは、意に反するものだと感じるようになります。チームは、あなたの役割がチームとシニアステークホルダーを結び付けるのではなく、チームをシニアステークホルダーから守ることだと思うようになります。そして、チームの信頼と助けを得られるかどうかは、あなたがこの役割を忠実に果たすかどうか次第、という窮地に追い込まれます。チームを守ろうとするあまり、組織の観点では失敗するように仕向けてしまうのです。
この破壊されたチームを復元するのは非常に困難でしょう。
『7章 「ベストプラクティス」のワーストなところ』から
複雑や抽象的な問題への対峙
複雑さのなかを進んでいくのがプロダクトマネジメントの本来の仕事
近年の業務は定型業務は減り、複雑で曖昧な課題への対応が一層求められています。
これは各マネージャーに限った話ではありませんが、PdMやPjMはより顕著でしょう。
永続する「ベストプラクティス」などありません。
残念なことに銀の弾丸なんてものはありません。
フレームワークはあくまで道具でしかありません。
どうすれば自分の考えがまとまりのあるものになるか、どうすれば相手にコミュニケーションコストを与えずに意思疎通できるか、など。そもそもの起点となる欲求がない限り、道具は意味を持ちません。
「業界トップ」企業のケーススタディのほとんどは、言ってしまえば、採用のためのプロパガンダです。
これは確かにそうだなと笑ってしまいました。
モダンな技術で、スクラムマスターがプロジェクトを華麗に進めている事例を沢山発表している会社も、多かれ少なかれレガシーな部分や泥臭く混沌とした要素、広報的には見なかったことにしたい課題は存在しないなんてことは考えられません。
そして、残念なことですが、PdMやPjMが活躍を求められるのはこの混沌とした世界でしょう。
7.3 フレームワークやモデルは有用なフィクション
これは上手な表現です。
フレームワークやモデルが全く役に立たないとも思いませんが、本質的な課題解決の意思や意図がないと意味を持ちません。「有用なフィクション」と表現することで、フレームワークやモデルに求めても良い期待が的確に表現出来ていると思います。
『10章 ビジョン、ミッション、達成目標、戦略を始めとしたイケてる言葉たち』から
一番は成果
「アウトプットよりもアウトカム」
常に意識したいスローガンです。
価値提供(≒アウトカム)は、積み重なったアウトプットと正比例するとは限りません。
『11章 「データ、舵を取れ!」』から
明確な期待
何を期待していたのですか?
数値はあらゆる断面で取得可能です。
「ほら、数値が120%に増えたでしょう。」
適当な断面数値や途中式の変数を持ってきても、「一体何を期待していたか」とストーリーが噛み合っていないと意味がありません。
何かを達成するために、多くのコストを投入し長期的にも採算性が度外視された状態だったとしたら?
それでは全く意味がありませんね。
『12章 優先順位づけ:すべてのよりどころ』から
私や私たちが英雄になる必要はない
正直に言えば、私の戦略は、GMを英雄にすることです
紙類包装資材製造企業のプロダクトリーダーが語るエピソードでの上記の戦略はとても共感しました。
私たちの仕事は受託開発や制作など顧客ありきの業務が中心となりますが、プロジェクトの成功は顧客側の窓口となる担当者の協力あってこそです。
大きな仕事、不安材料がばら撒かれた道を歩んでなんとか「成功」といえる状態で終われたときに自分の成果として言ってまわりたいところですが、転職時の職務経歴書の中に留めておくと良いでしょう。
少なくとも、顧客企業の上役からは私たちが英雄として映るより一緒にプロジェクトを円滑に進めてくれた担当者が英雄に映るべきです。
『14章 プロダクトマネージャーのなかのマネージャー(プロダクトリーダーシップ編)』から
あなたがしていることはすべて間違い
さらに悪いことに、社内の別のプロダクトマネージャーは若手プロダクトマネージャーを完全に無視して、代わりにあなたの予定を確保しようとするようになりました。結局、裏で糸を引いて大きな意思決定を下すのがあなただとみんな知っているのです。
ここで書かれていることと似たような場に立たされること、そして同じ間違いを行ってしまうことは全てのマネージャーに経験があるのではないでしょうか?私も例外ではありません。
成果物が要求を満たせていない、方向性がズレている、このままでは期日に間に合わない。
自分が時間をつくればギリギリ対応できるかもしれない。
まずは、土日に予定をキャンセルして、あとは平日だと早朝3時〜6時だったらまだ時間をつくれるから…。
あぁ、良かった。なんとか間に合った。顧客も満足してくれた。
今回の案件は次に繋がっていく大事な局面でした。今後数年の会社の売上を死守できたのです。
人から仕事を取り上げることによってね。
マイクロマネジメント、人から仕事を取り上げてしまうこと、顧客を裏切らないこと、自分を殺すこと
このバランスは非常に難しく、そして密接に絡み合います。
「自分を殺すこと」を選ぶとクセになります。一番コントロールしやすく、短期的には成果につながるからです。
ここでの反省や見直しについては下記で記載しています。
実のところ、持続可能な組織づくりが十分にできているなどと今でも思えません。
一体何を落とし所にするかという問いは常に頭の中を回りながら、日々を過ごしています。[2]
そんな中で、この章は日々の生活を見直し、一歩一歩を進めるヒントになるものを感じました。
チームが本当の意味で権限委譲されるには、リーダーの考えるビジネスの背景、特にプロダクトビジョンが必要
明確なゴール、明確なガードレール、小さなフィードバックループ
『16章 どんなことでも』から
プロダクトマネジメントのやり方を築いていくなかで、あなたは例外なく失敗します。まずい失敗、ひどい失敗、恥ずかしい失敗をするでしょう。単刀直入に言うべきところで、言い逃れをしてしまいます。辛抱しなければいけないときに、衝動的にやってしまいます。「ベストプラクティス」を字面どおりにやろうとして、思いがけないしっぺ返しを食らいます。失敗は、自分自身、自分のチーム、自分の組織に、実際に悪影響を及ぼします。自分の失敗を同僚に寛容にゆるしてもらって、あなたは謙虚になります。そのうちに、自分自身もだんだんゆるせるようになるでしょう。
この最終章は少ない文章量で終わります。
上記はその中の一節ですが、本当に心に染みます。
そう、例外なく失敗します。
私はたくさん失敗しましたし、皆が例外なく失敗します。言い逃れもしてしまうでしょう。
自分自身が許せなくなることもたくさんあります。
そして、いま私は現在進行系で、だんだんとゆるせるようになってきたのです。
Discussion