[読書感想文] プロダクトマネージャーのしごと
プロダクトマネージャー的な仕事をするにあたってちょうどよいオライリーの本があったのでいつぞやか買ってみた本をじっくり読み続け、ようやく読了できた。
これを買ったとき、そういえば丸善かどっかでオライリーの本を3冊買うとTシャツプレゼントというキャンペーンをやってて、ホクホクと3冊抱えてレジに行ったら「あー、Tシャツないですね、ではお会計◯◯円になります」って言われて、いや、それはちょっとないんじゃねえの？と思った記憶が蘇った。思い出し怒り。
とはいえ、このときのキャンペーンがなければ絶対3冊も買ってないからあの店員はムカつくけど買ったことの後悔はしてない。実際、とても良い本だったし。
序文の翻訳がめちゃめちゃ直訳で不安になったが、そのあとは普通だったので安心。この序文を翻訳したのは誰だぁ！
あと、ビジネス本なので頭文字やカタカナ語が多い。SMART、CLEAR、OKR… シンプルなインパクトエフォートマトリクスでリモートチームの協働を促す… めっちゃ分かりにくいが、さすがにどうしようもないか。わからない用語は諦めよう。
今のプロジェクトにどう活かせるかを考えながら読んだ、つもり。
1章：プロダクトマネジメントの実践
プロダクトマネジメントとは、単にプロダクトを完成させるのがゴールというわけではない。
「ユーザーニーズとビジネスゴールをつなぎ、技術的実現性とユーザー体験をつなぎ、ビジョンと実行をつなぐという他に見られない役割」となる。なので、つなげようとしている人や視点、役割によって違う見え方になる。つまりはっきりとした攻略法や答えなんてものはない。
自分の場合はとにかくプロダクトそのものよりも、今はプロジェクトメンバーの理解が大事だと思っているので、そのあたりの「つなぎ」が大事かなー。
例にあったが、確かにプロダクトマネジメントの責任として「ダメだと思ったらプロダクトを完成させずにプロジェクトを破棄する」もありだな。利益にならないことがわかったらそう動かざるを得ない。が、完成させる以外の選択肢がない場合は完成させなきゃだし、役割は大きく変わってくるか。
あなたがプロダクトマネージャーとして終わらせなければいけないことのほとんどは、自分だけではできません。
プロダクトマネージャーは；
ボスではない
実際にプロダクトを作らない
誰かが指示を出してくれるわけではない
これは大事。マネージャーがモノを作っているわけではないから偉ぶるなというわけではないというのもまた大事ではあるけど。
悪いプロダクトマネージャーは；
ジャーゴンジャッキー：業界用語使いまくりおじさん
スティーブ・ジョブズ信奉者：後方腕組み偉そうなこと言うおじさん
英雄のプロダクトマネージャー：会社やプロジェクトを救うための素晴らしいアイデアを持っているので他の人の意見は聞かない
頑張り屋さん：とにかく頑張るのを目的にして、ビジネスやユーザーの目的は知ったこっちゃない
プロダクト殉教者：人生のどんなことより仕事を優先してきたことを強調
＊マイプロジェクト
自分がボスではないのは分かっているし、自分がゲームを作れるわけではないのは分かっている。というか普通に不可能。ほぼフリーランス状態なので待ってても誰からも指示は来ないので、1章が理解できているできていない関係なく、悪いプロダクトマネージャー要素に関しては… 後方腕組みしてるときあるかも。でも指示は出さないといけないから仕方がない、はず。
2章：プロダクトマネジメントのCOREスキル
COREとは；
Communicate 上司やチームとコミュニケーション
心地よさより明確さOrganize チームを組織化
自分はいらないチームを作るResearch ユーザーのニーズとゴールをリサーチ
ユーザの情報を集める。またユーザーから直接学ぶExecute ゴールに到達するためのタスクを実行
アウトプット（作業量）よりアウトカム（成果）
＊マイプロジェクト
Cについては各メンバーとオンラインキックオフミーティングしたし、折りに触れ別途ミーティングもしている。コミュニケーション大事なのは理解している。
Oは前々から思っている。自分が作業しなくても回るのが自分も楽だしチームも楽。
Rはまだ想定ユーザがわからないので未定。
Eについてはアウトプットとしてだらだら文章書きがちだが、開発が進まないと行けないのはわかっているのでアウトカム重視にしている、はず。まだ成果としてはあんまり出てないけど。
まあ、でも絶対覚えられないだろうな、COREスキルの意味と使い方…
3章：好奇心をあらわにする
既に好奇心ありありなので、内容は面白かったが新しく学ぶことはなかった。
4章：過剰コミュニケーションの技術
過剰コミュニケーションというのは言いすぎだが、プロダクトマネージャーのしごとはコミュニケーション。なので、一見過剰に思えるくらいにコミュニケーションしていくのが大事。しないとヤバいが、しすぎて損はない。
鬱陶しいくらい確認していくのが肝心。そして曖昧な言葉は避ける。
プロダクトマネジメントで一番危険な言葉「よさそう」
間違えるならコミュニケーション過剰な方を選ぶ。説明するべきか迷ったら説明する。
「あたりまえ」を問うことを恐れない。チーム全員の「あたりまえ」が当たり前かどうかなんて全くわからない。
＊マイプロジェクト
もともとだいぶコミュニケーションは過剰なほど取っていくのと、自分の常識力を信じていないので「あたりまえ」は問うぜ！
でも「よさそう」は使っちゃいそうだな。気をつけたい。
5章：シニアステークホルダーと働く
嫌なボスがいたら、それに対する愚痴をチームと共有することでチームの一体感を作り出すのは、完全に悪手。
「ネガティブな意見や上司への愚痴を共有するために同僚から友人になった人」という例はなんかわかる。自分はそもそも人の愚痴を言うくらいなら無視するので、そういう友人はいないはず… だが。
＊マイプロジェクト
そもそもシニアステークホルダーがいないから関係ない。
6章：ユーザーに話しかける
ユーザーペルソナを色々と考えるのは確かに大事。別の用語でいうとオーディエンスだろうなー。
とはいえ、現段階ではユーザーとのやり取りはないのでここもスルーで。
7章：「ベストプラクティス」のワーストなところ
仕事についてググれば大体のケースで「◯◯のベストプラクティス」という必勝法が出てくるが、そんなものは実際は存在しない。
少なくともプロダクトマネージャーに関しては「これ」をしておけば成功する！は間違い。どのプロダクト、プロジェクトも千差万別のため。
まあ、これは考えれば当たり前。
＊マイプロジェクト
そもそもゲーム開発において、他のゲームではあれをやってたから、はほとんど通用しない。
ただ、ベストプラクティスが悪いわけではない。それぞれの要素は参考になる。
PRでアレをした、ゲーム機能にコレがあるなど、そういう「ベストプラクティス」は追っていくべき。
8章：アジャイルについての素晴らしくも残念な真実
そもそもアジャイルってなんやねん；
大きな単位でシステムを区切ることなく、小単位で実装とテストを繰り返して開発を進めていく手法
アーリーアクセスみたいな感じで、アップデートを繰り返していくのに似ているか？
旧来のウォーターフォールはこちら；
＊マイプロジェクト
アジャイル開発は結局よくわからなかった。でもゲーム開発だと割と普通なのでは。一人で黙々と開発していくのがある意味ウォーターフォールなのかもしれないが、どっちかというと少数派だろうなー。
まあ、どっちにせよこれは我々が選ぶものではない。
9章：ドキュメントは無限に時間を浪費する
ペライチが大事！
というか翻訳ものでペライチという単語が出てくるとは思わず、それのせいで内容があんまり頭に入ってこなかった…
完全なドキュメントを作ってから話を始めると、そのドキュメントがプロジェクトとズレていた場合作り直しだし、作るのにまず時間かかるし、良いことは特にない。ので、ペライチを1時間で作るというのを目標にするのが良いらしい。
＊マイプロジェクト
確かに、箇条書きでもいいのでペライチまとめを作ったり、そもそもそのドキュメントが必要なのかチームと共有しておくのが大事な気がしている。とはいえ、ドキュメントが必要なのは主に自分のためでありチームは既にわかっていることが多いのでまあ、ほどほどにやろう。
10章：ビジョン、ミッション、達成目標、戦略を始めとしたイケてる言葉たち
プロダクトオーナーは成功を測るすべがなかったため、どれだけたくさん働いているか、どれだけ多くのプロダクトを抱えているかで測るしかありませんでした。なぜでしょうか？
それは、組織として目指しているゴールについての共通認識がなかったからでした。ゴールがないので、各プロダクトオーナーは、個人の想定とその場しのぎの成功指標に頼るしかなかったのです。
「アウトプットよりもアウトカム」というのは大事。こんだけやりましたよ！って言いながら一日なにも生み出していないというのは自分も覚えがあるし…
ただ、色々と出てくるビジネス用語は絶対に覚えられないし、これらをどう使うのかもわからん。でも一応メモっておく。
SMART；
Specific 具体的な
Measurable 計測可能な
Achievable 達成可能な
Relevant 関連性のある
Time-bound 期限があるもの
CLEAR；
Collborative 協調的な
Limited 範囲が限定されている
Emotional 感情に訴える
Appreciable 重要な
Refinable 洗練できる
OKRフレームワーク；
Objective 目標
Key Result 主な結果
定性的なスローガンと、正しい方向に進んでいることを示す定量的な尺度の両方が使えるから便利らしい。
例：フィンテック(金融向けテクノロジー)のスタートアップなら、「複雑な金融商品へのアクセスを民主化する」がObjective、「この四半期中に1000人の新規ユーザーを獲得する」がKey Result。
＊マイプロジェクト
そもそもこの用語が全世界共通なのかもわからないし、使うことは一生ないだろうな…
とりあえずアウトカムを大事にするのを忘れないようにしよう。
11章：データ、舵を取れ！
データという言葉を一切使わないでください
「データによると」ではなく、「私たちが実施したメールアンケートの結果によると」と言い換える。
＊マイプロジェクト
まあ、ここはあんまり関係ない。データを取って役立てられるに越したことはないけども…
12章：優先順位付け：すべてのよりどころ
どの意思決定もトレードオフ
あるユーザーに寄り添うということは、別のユーザーをないがしろにすることになるということを覚悟する。
小さく始める
アジャイル開発とか、ドキュメントはペライチというルールに沿って小さくやるのが大事
さまざまなユーザーセグメントやペルソナを念頭に置き、というそのニーズに合わせて優先順位づけする
誰が求めているのか、誰をターゲットにしているのか、というのは常に考えておかないといけない
仮説は文書化しておく
何を作ろうにもコストはかかることを覚えておく(隠れたコストでも)
これはまあ、なにをするにしても時間がかかる＝コストはかかるわけなので当たり前
何につけても優先付けは大事。自分だけではなく、メンバーそれぞれが何を優先して作業するか、それを把握しておかなきゃならない。
緊急な要件が出たとき、以下の問題を改めて考えてみることで問題を整理する。
問題は何か？
報告者は誰か？
何人のユーザーに影響するか？
この問題は収益のような全社的なゴールにどう影響するか？
この問題を半月放っておくと何が起きるか？
この問題を半年放っておくと何が起きるか？
この問題についてさらに議論したり、解決したりするときの担当は誰か？
＊マイプロジェクト
今開発しているゲームのターゲットが誰になるのかというのはずっと考え続けないといけない。既存のファンに向けてでもあるが、新規のユーザに向けたものでもある。どちらも取るのか、どちらかに重心を置くのか… 特にPRに影響する。
13章：おうちでやってみよう：リモートワークの試練と困難
プロダクトマネージメントをリモートワークで行うことについての章。
よくある課題：
レスポンス時間に対する合意が取れていない
メールやチャット、メンションが来たらどれも緊急のように思えてしまうタスクにかかる時間の期待が明確でない
相手のリクエストに対応するまでどのくらいの時間がかかるかという考えがズレていることが多いインボックスがあふれていて、新しいメッセージや重要なメッセージを見つけられない
緊急でないタスクであっても、相手が確認するまでに大量のメッセージが送られていると優先順位がつけにくい
これらの課題に対応するには、それぞれのメンバーに、アクション速度の期待がどのくらいなのか確認する。もしくは緊急なものとそうでないものをどう区別するかの方針を決める。
インパクトエフォートマトリクスとは？
インパクトと労力のマトリクス。インパクトは効果、影響。なので、最小の労力で最大のインパクトを得られるものがベスト。
ただ、人によって感じているインパクトと労力が異なるので、チーム内での理解を合わせることが大事。
誰かがインパクトはでかいが労力もでかいから避けていたタスクが、実は簡単にできることかもしれない。もしくはその逆。
非同期コミュニケーションに関するTIPS
非同期コミュニケーションは送るだけ見るだけなので簡単に思えるが、対応できないまま積み重なったりすると、内容の理解、優先順位付けなどでかなりのコミットメントが必要になる。なので…
受信者はすぐに取ってほしいアクションがわかるか？
期待する結果と納期があるか？
いついつまでに返事が欲しい
いついつにミーティングしたい複数の人が関わる場合、全員に情報共有しているか？
それぞれをメンションしているかフィードバックが欲しい場合は、どんなフィードバックを求めているか、また、フィードバックがほしい理由が明らかか？
これこれを送ったので、中身を確認して、抜けがあれば指摘ください。この内容をもとに明日ミーティングをするのでそれまでに対応お願いします。フォローアップやチェックの場合は、何を期待しているかを改めて説明する
先週のあのタスクについてどうでしょうか？ではなく、タスクの内容確認及びそれを元にしたミーティングがいついつあるので予定はどうでしょうか？みたいな感じに具体的に伝える。
＊マイプロジェクト
100%リモートワークなので、最初からこのあたりは気をつけポイントではあったため、各メンバーの作業スケジュールを確認済み。また、休みや予定がある場合はGoogle Calenderに記入してもらうようなやり方を共有済み（まだ浸透してないが）
また、時差が大きいことはわかっているので、メッセージはどれも基本的に緊急ではないということで対応している。
＊マジ緊急なものは今のところ発生していないが、そういう場合はDMで連絡するようにしている。
同期・非同期コミュニケーションについて自分のプロジェクトの場合は；
同期コミュニケーション：オンラインミーティング
非同期コミュニケーション：Discordチャンネルでのやり取り
各メンバーの理解を合わせる方法：ミーティング議事録チャンネルを作り、議事録をその都度アップロードして各自確認できるようにしている。また、翻訳して日英で提供している。
14章：プロダクトマネージャーのなかのマネージャー
出世するとか、自分への課題とかそういう内容だったのでスルー。
15章：良いときと悪いとき
プロジェクトが「自動操縦」モードで進むときがある。これはものすごく上手く行っているときもあれば、誰も周りを気にしていないからというときもある。ので、
プロダクトマネージャーの仕事が上手くいっている＝プロジェクトが上手くいっている、とは限らない。
マネジメントが一番上手くいっているのは、新しい課題を積極的に探し、素直な気持ちで、好奇心を持ち、先入観なく取り組んでいるとき。
プロダクトマネージャーの仕事とは、「間違いが起きる前に、間違いになりそうな小さなことを考えることだ」
＊マイプロジェクト
自分が新しい課題を積極的に探す必要はないんじゃないかなー。でも、「自動操縦」モード、つまりみんな黙々と仕事しているときというのが上手く行っているかどうかはわからないので、しっかりと確認していくのが大事なんだろうなー。
この記事が参加している募集
この記事が気に入ったらサポートをしてみませんか？