けけずん積読消化記録

社内の輪読会で本書を読むことになった。各自で毎週2章ずつ読み進め、各々が気になった箇所をピックアップし、輪読会の時間でそれらについて議論などしている。本書はプロダクトマネージャーが日々どういった業務を行っているのか、どういった課題に直面しどのように乗り越えるのか、という実践的な内容が記載されている。

以下は章別に気になった箇所（メモ書き）。

• P.18 プロダクトマネージャは下記のことができる必要があります
• P.28 自分自身とチームの透明性を高める〜ありません

• P.32 自分のしていることに誰も〜
• P.33 プロダクトマネージャとして〜、コンプライアンスの専門家への理解を深めることで〜
• P.38 議論ではなく選択肢を与える

• P.49 心地よい言い回し。責任回避、受動的攻撃性
• P.50 じゃじゃーん。自己卑下。作業をお願いする理由
• P.51 失敗したことをすべて自分の責任にしたら、チームから学習する機会を奪うことになる
• P.54 ステークホルダー全員にモックを送りつけ。実際には表向きの承認、自分の身を守るチェックマーク
• P.54 選択肢のある質問をする→どの程度選択肢を与えるのか、逆に幅が狭まらないか？
• P.60 コミュニケーションスタイル
• P.61 人は、自分が情報を一番〜
• P.65 立場ごとに短期のゴールを守ろうとする。このへんの具体的な話し面白すぎる

• P.78 あなたの役割がチームとステークホルダーを結びつけるのではなく、チームをステークホルダーから守ることだと思うようになる。チームを守ろうとするあまり、組織の観点では失敗
• P.79 同僚から友人になった人もいますが、ネガティブなことで共感する以外は、実はあまり共通点はない
• P.80 チームの仲間意識やつながりを作ろうとしているプロダクトマネージャは、こういった自分たち対相手の〜
• P.80 自分をチームとビジネス全体のあいだのあらゆる問題のフィルターとみなすような状況を作ってしまった

• P.100 一般論ではなく具体的な例をお願いする
• P.103 定期的にペルソナ見直すとは？？

• P.110 ベストプラクティスに従わない物事や人は全て敵に見えるようになる。責任転嫁してる
• P.112 組織全体が正しくやれているかは気にするな、というのはどうにもならないというのがわかってるのでという意味？
• P.114 制約と限界のなかでベストを尽くすところから始める
• P.118 すばやく結果を出すプレッシャーに〜
• P.122 プロダクトマネージャーの仕事は〜定常的にプロセスの調整を繰り返すということ。〜
• P.124 実験だと考えて、何が起こるかやってみる
• P.124 今やれることではなく、次にやれることにフォーカスする

• P.128 実際に正しいことをするよりも「アジャイルを正しくやる」こと
• P.129 価値の中心にあるのは、人間の独自性と複雑性を受け入れること
• P.132 組織が犯す最大の間違いは、フレームワークやベスプラを導入し、すぐにうまくいかないからと完全な〜
• P.137 価値をもたらさないでっち上げのセレモニーや儀式
• P.138 変更を記録する。やってきたプラクティスやセレモニー、目的、起きたこと
• P.139 全員嫌々立ち上がってやったことのリストを読み上げるだけ、会社のためにしたことミーティング。待ちを発生させないようにするはずだった〜

• P.147 ロードマップは約束ではなく、戦略的なコミュニケーション用のドキュメント
• P.148 〜組織の誰が何を合理的に期待できるか？てどういう意味
• P.153 長くて詳細な仕様書を書くと、プロダクトを作るために多くの仕事をしている気になる
• P.153 意図的に不完全にしたドキュメントがチームのコラボレーションを加速させた
• P.158 自分たちが使えるいちばん簡単なツールから始めて、具体的な限界を迎えた場合はもっと複雑なツールに移行する

• P.163 アウトカムに具体性がなければ、アウトプットに具体性が求められる、どういうことか
• P.164 具体的な目標があれば、それを達成するために動くのわかる
• P.169 ニーズの階層図よさそう

• P.176 データという言葉を一切使わないでください
• P.179 本当のデータドリブンの実験では、直感に従い、そのあとで直感が適切かをテストするためのフィードバックループを作る
• P.180 何を計測すべきか、という質問に万能の答えはない
• P.181 サバイバル指標、現実的な底
• P.182 ユーザーが抱える解決できそうな課題を理解し、実現可能な解決策を評価するのではなく、魅力的で正当化しやすそうに見えるデータを発見したときに段階を飛ばした
• P.183 価値を証明するのではなく、ユーザーに価値を提供することを目的にして実験する
• P.184 コンバージョンの話。2つのチームにとって一番意味のある指標
• P.187 意味のあるアウトカムはユーザの行動やマーケットの動向により、気が狂うほど複雑

• P.192 優先順位づけの過程では、重要な質問への答えがないことやゴールが思っていたより明確でなかったことに気づく瞬間がある
• P.194 現状プロダクトの意思決定はどのように行われている？
• P.195 チームの時間はビジネスにとってコストであり、理由を説明できない場合、ゆくゆくはチームの存在意義を説明しなければいけなくなるかもしれない
• P.197 プロダクトチームや組織が容易に「機能の製造工場」に陥る
• P.200 PMの仕事は、ステークホルダーにできる限り良い意思決定をしてもらうこと
• P.202 すべての努力はアウトカムのために
• P.204 これは緊急なんです！に対するテンプレよさそう
• P.207 意思決定について昔ぬぬるくさんから教えてもらったの思い出した。お金、時間、人、得られる効果、それらを考慮して判断する
• P.207 プロダクトマネジメントは、自分の意思決定の正しさに最大限の自信と確信を持てるなどという贅沢はさせてくれない。不快な現実を自分に有利なように使うこと。大きいものを分割し、フィードバックで再評価、微調整できるくらいに小さくする。

• P.211 小さな変更を行い、チームでそれらの変更についてレトロスペクティヴを行うという繰り返しが、いちばん持続可能な道
• P.212 地理的な場所、言語、文化を超えてコミニュケーションするには、弱みを見せることと努力が不可欠
• P.224 チームの参加意識を高めるための娯楽の強制
• P.225 自分のブレイクを忘れずに

• P.231 自分はこの役割を完璧にこなせているなどと言う人は、自分の役割をきちんと理解していない
• P.232 自分の役割のインパクトを明確に理解することは、良いプロダクトマネージャの仕事の一部
• P.233 古い行動様式を忘れ、新しい行動様式を学ぶ
• P.234 プロダクトリーダーであれば、自分自身に課す基準は自分がチームに課す基準になる
• P.235 優れたプロダクトリーダーになることは、残業時間や一生懸命さ以外の方法で自分の価値を測る術を学ぶこと
• P.236 シニアからの質問は暗黙の要求としてではなく本当の質問として扱い、自分自身の質問も同じく暗黙の要求として受け取られてるかもしれないことに気をつける
• P.237 間違った「自律」。プロダクトリーダーの欲しいものを作ることから、欲しいものを察することに変わっただけ
• P.239 「嫌な奴になるな」ではなく「フィードバックがないまま放置するな」

• P.252 自動操縦モード、成熟したプロダクト。「今のやり方」が成功の唯一の道と感じ始め、チームは閉鎖的になり、好奇心を無くし、重要な質問が放置され、機会が失われる
• P.254 プロダクトマネジメントがいちばんうまくいっているときというのは、新しい課題を積極的に探し、素直な気持ちで、好奇心を持ち、先入観なく取り組んでいるとき
• P.258 プロダクトマネージャは同僚の人生や経験に大きな影響を与えられる

• P.262 最近雇われたプロダクトマネージャ「私は毎日いったい何をやったらいいんだ？」→「どんなことでも」

本書を読んで輪読会メンバーと議論を繰り返すことで、プロダクトマネージャの仕事についての理解が深まり、プロダクトマネージャの方の気持ちを少し理解することができた気がする。一人の開発者としてプロダクトマネージャから寄り添われることを期待するのではなく、こちらからもプロダクトマネージャに関わりを持ちコミュニケーションを取り続け、良いプロダクトを作っていきたい。