積んでいた『プロダクトマネージャーのしごと』を読み終わったので、内容を簡単にまとめます
動機
エンジニアとしてプロジェクトをリードする中で、プロジェクトマネジメントのノウハウをもっと取り入れ、エンジニアの枠を超えた働き方を目指したいと考えている。
また、プロダクトマネージャーという役割について、「具体的にどのような業務を担当するのか」「どのような姿勢で取り組むべきか」といった点を理解することで、プロダクトマネージャーとの円滑なコミュニケーションに活かしたり、エンジニアとしてより効果的にサポートできるようになりたいと思い、この本を手に取った。
印象に残ったところ
第1章 プロダクトマネジメントの実践
プロダクトマネージャーという役割には常に曖昧さが伴い、あらゆることをこなす必要がある
- 責任は大きいが権限は小さい。チームが締切を守れなければプロダクトマネージャーの責任である
- チームとプロダクトの成功のために、終わらせる必要なることはなんでもするのがプロダクトマネージャーの責任である
- プロダクトマネージャーはあらゆることの中心となる
- 優れたプロダクトマネージャーとは、人やものを繋げる中心にいる人である
第2章 プロダクトマネジメントのCOREモデル
プロダクトマネージャーに必要なCOREモデルとは、次のものである
- Communicate: ステークホルダーとコミュニケーションする
- 心地よさより明確さが行動指針。心地悪さは明確さの欠如の兆候であることが多いので、自ら心地悪いコミュニケーションをとっていく必要がある
- やっていることとその理由をチームが明確に理解しているか会話の中で確かめる
- Organize: 持続的に成功するチームを組織化する
- 自らを不要とせよが行動指針。組織化に優れたプロダクトマネージャーは自己継続的な仕組みを作る
- 今何しているのか、そしてそれはなぜかという問いにチーム全員が答えられるような状態にする
- Research: プロダクトのユーザーのニーズとゴールをリサーチする
- ユーザーの現実に生きよが行動指針
- 全てのプロダクトに対する意思決定は、ビジネスゴールとユーザーニーズに紐づいている必要がある
- Execute: プロダクトチームがゴールに到達するための日々のタスクを実行する
第3章 好奇心をあらわにする
- 好奇心を示すというシンプルな行動は、プロダクトマネージャーとしての仕事に大きなプラスの影響を及ぼす。他人に何かを求める前に関係性築いておく必要がある
- 職場の同僚を訪ねて、仕事をもっと詳しく教えてもらえないか声をかけてみる
- 同僚同士が学び合うように促し、お互いのスキルを学びたい人をペアにする
第4章 過剰コミュニケーションの技術
- 失敗するなら、コミュニケーション過剰の方に倒しておくほうが良い。
- 自分が当たり前だと思っていることも、他の人には当たり前でないことがある。当たり前のことを問うことを恐れないこと
- 心地よい言い回しをしてまわりくどい言い方をしがちだが、曖昧にするのは良くない。これは責任回避であり、悪いやつだと思われずに結果を得ようとする受動的攻撃生の表れ
- Disagree & Commit
- 集団での合意形成の際には、参加者全員の「進めてよい」という積極的なコミットメントが必要だ、ということ
- 沈黙は不合意として扱う
第5章 シニアステークホルダーと働く
上司がバカだった、という発言をすると、それは実質的にチームを壊す。シニアステークホルダーからのどんな要求であっても合理的でないとチームがみなすようになってしまうから。 プロダクトマネージャーの仕事はシニアステークホルダーからチームを守ることではなく、強力的なパートナーである。
第7章 「ベストプラクティス」のワーストなところ
ベストプラクティスを盲信すると、それに従わない人は全て敵に見えるようになってしまう。しかし、ベストプラクティスは様々なプロセス、人、運、タイミングといった様々な要素が絡んでいることを忘れてはならない - 業界トップ企業のケーススタディは、採用のためのプロパガンダであることが多いので、誇張を鵜呑みにしない - ケースバイケースの制約と限界が存在している - ベストプラクティスを実施する前に、組織特有の状況について学ぶための時間を常に取る
第8章 アジャイルについての素晴らしくも残念な真実
プロセスを内省して洗練する時間を作らなければ、形式上のセレモニーのせいで結果的にチームの士気を低下させることになりかねない。アジャイルプラクティスやセレモニーの背景にある本質や本来の目的をドキュメントに残すと良い。
第9章 ドキュメントは無限に時間を浪費する
最高なドキュメントは不完全である。不完全であることは、行動のきっかけとなる
- 意図的に不完全なドキュメントを共有した時は、チームからの質問や貢献は前に進めるために不可欠
- 他のメンバーの参加度合いやその質は完璧なドキュメントを共有した時より圧倒的に高い
- 次のミーティングでは不完全なドキュメントを持っていくことを推奨する
- 最初のドラフトは1ページで、作るのに1時間以上かけない
第12章 優先順位づけ：すべてのよりどころ
志は大きく、スタートは小さく！
- どの意思決定もトレードオフ
- その意思決定が良い結果になるかどうかはやってみないとわからない。小さく始めてフィードバックをもとに軌道修正するのが良い
- 仮説をもとに物事を進める場合はその仮説を文章化してチームと議論する
- 単独の機能ではなく、ユーザージャーニーやユーザータスクの全体を考える
- 他のプロダクトマネージャーやチームとの調整が少なくて済みそうな機能を優先しがち
- 複数チームの責任領域を跨ぐ昨日や改善こそ、一番インパクトが大きい
- 小さくはじめる & 作業の依存関係の話ではなく、どのようなゴールを目指すか、というワクワクする話から始める
第13章 おうちでやってみよう：リモートワークの試練と困難
リモートワークにおいてすぐに実践できるtipsが多く書かれていたため、多めに内容をまとめる
- 日々のコミュニケーションに対する期待があっていないことが、しばしチームの信頼関係の１番の障害になっている。コミュニケーションマニュアルを作成し、コミュニケーションの緊急度合いに対する期待値を揃えると良い
- それぞれのチャネルの非同期メッセージにどれくらい素早く反応することを期待するか？
- お互いに仕事をお願いするときに、明示すべき基準は？（例：どれくらいの期間お願いするのか、納期は、遅れることのリスクは）
- 個人とチームの仕事時間は？仕事時間以外に送受信したメッセージの扱い方は？
- まずはチームのメンバーからメッセージを受け取ったらどれくらい早く返信が来ることを期待するか、という質問から始めると良い
- 非同期コミュニケーションでは、送信する前に時間をかける
- 送信するのが一番簡単な非同期メッセージは、返信する際に多くの時間を要する
- メッセージを受け取った人は、10秒以内にとって欲しいアクションがわかるか？
- 期待する結果と納期が明記してあるか？
- メンションされている場合、なぜメンションされているかが明確か？（ccに入れられている理由など）
- フィードバックを求める場合は、どんな種類のフィードバックを求めているのか、そしてそのフィードバックを求める理由が明確になっているか？
- フォローアップや確認の場合には、どんなタイプの反応やリアクションが欲しいかを明確にしているか？
- 同期サンドイッチのススメ
- ミーティングの1日前までには事前に読む資料を非同期で送る
- タイムボックスを設定した同期ミーティングをファシリテーションし、判断を下してドキュメントを一緒に作成し、事前資料で説明された問題を解決する
- 同期ミーティングから1日以内に、次のアクションを含むフォローアップを非同期で送る
第14章 プロダクトマネージャーのなかのマネージャー（プロダクトリーダーシップ編）
プロダクトを所有しようと意地になったり、機能の押し付け合いになったりすることが多い。次の文章を本からそのまま引用する
あなたの仕事はビジネスとユーザーのためのアウトカムを届けることで、プロダクトのなるべく多くを「所有」することではないことを忘れないでください。いちばん合理的な道に集中し、「あなたが持つか、私が持つか」という二元的な考え方の枠をなるべく早く越えようと努力してください。ビジネスゴールに対して最善を尽くすために、両チームがどのように協力できるのかを話し合うために、フォローアップの会話の機会を提案することを検討してください。
感想
プロダクトマネージャーは責任が大きいが権限は小さく、プロダクトを成功させるためにあらゆることをやる人物だというのは、ある意味では酷だな、と感じた。しかし、あらゆる人をつなげてプロダクトを成功させることに熱意を感じる人であればそこに強いやりがいを感じるのだろう。
自分としては、エンジニアの立場としてプロダクトマネージャーを支えるように関わっていきたいと感じた。エンジニアとしてもプロダクトマネージャーの行動の背景・意図を知ることでよりスムーズにコミュニケーションができ、より大きなインパクトを最終的に残せるようになると思う。場合によってはプロダクトマネージャーが足りていないところに手を貸すような動きもできるかもしれない。
明日から実践できることとして、次のようなことを意識していこう
- コミュニケーションでは心地よさより明確さが重要。心地悪いコミュニケーションを率先して取っていき、明確さに欠ける部分を埋めていくようにしたい
- 失敗するならコミュニケーション過剰になる方が良い。当たり前を問うことを恐れない
- ベストプラクティスは様々な要因が重なって作られているので、盲信せずに自分の組織特有の状況を見定めたい
- 最高なドキュメントは不完全。チームに対して不完全なドキュメントを作成し、それを皆で埋めていく作業を行う
- チーム内で、非同期メッセージにどれくらい素早く反応することを期待するか聞いてみる
- メッセージには取って欲しいアクション、期待する結果と納期を明確にする
次に読みたいもの
本の中で紹介されていた『Agile Retrospectives』を読んでみたい。振り返りを行い、チームとして学び続けることで改善し続けたい。今もレトロスペクティブは行っているが、KPTを回しているだけの状況になりがちなので、体系的に学ぶことでより効果的なレトロスペクティブを開催していきたい。
