元Amazon本社プロダクトマネージャーが明かす、PMの“修羅場”3選。「涙あり笑いありのPMライフ」とは！？【寄稿】

こんにちは。ゆうと申します。米国に10年以上いて、Amazon本社などでプロダクトマネージャー（PM）の仕事を経験してきました。

PMという職種、最近は日本でもかなり一般的になってきたと聞いています。それどころか、PMはいまやIT業界の花形職種としてもてはやされているらしいですね。「PMはミニCEO」とか「PMは世界で一番魅力的な職業」とか、“キラキラ”した形容を目にすることもあります。

確かに非常にエキサイティングでやりがいのある仕事ですが、 華やかな表舞台の裏側にはシビアな現実が広がっているのが、世の常。 本稿では、僕が今までに見聞きしたPMの“修羅場”について記したいと思います。

＊1 ハンドルネーム
※内容や肩書は2023年11月の記事公開当時のものです。

 

基本的に何でもやらされ……

PMの仕事内容というのは多岐にわたるもので、会社・部署・チームごとに、その役割が大きく違ったりします。同じ会社内でも、あるチームではデータ分析や収益予測に多くの時間を費やすPMがいる一方で、別のチームではひたすら仕様書を書きまくるPMがいたりするんです。

基本的には、 そのチームの中で不足している役割、誰もやる人がいない仕事は、PMが拾うことになります。 なので「PMの仕事、全て教えます」なんてうたっている人は、詐欺師か世間知らずか、あるいは“ガチですごい人”です。

これは、ゲーム系スタートアップに勤めていたAさんの話です。

Aさんの会社はスタートアップということもあり、常に人材が不足していました。Aさんは当時ようやく自分のゲームの企画が通ったものの、会社から割り当てられたリソースはエンジニア1人だけという状態で……。

Aさんは、ゲームデザイナーがいないのでゲーム内の全機能の仕様を1人で書き上げ、UI（ユーザーインターフェース）デザイナーがいないので自力でUIをデザインし、キャラクターデザイナーがいないので社外で協力してくれる人を探し当て、アートディレクションは自分で行いました。

さらにシナリオライターがいないのでキャラクターのセリフも自ら作成し、プロジェクトマネージャーがいないので自分で開発工程の進捗（しんちょく）を管理し、QA（品質保証）担当がいないので1人で全機能のテストを行いました。

晴れてゲームがリリースされると、Aさんの仕事はさらに増えました。データアナリストがいないので自分でデータ分析を行い、経営陣向けに週次でレポートを作成します。

コミュニティーマネージャーがいないので自らゲームのツイッター（現X）アカウントを開設し、日々ゲームの開発状況や不具合の情報などをツイートしました。ユーザーから寄せられたコメントにも、1件1件丁寧に対応します。Aさんはプライベートでツイッターのフォロワーが1万人以上いるなど、SNS（ソーシャルネットワーキングサービス）のセンスがあったため、その投稿はユーザーからも面白いと好評を博しました。

Aさんの頑張りもあり、ゲームが非常に良いパフォーマンスを示すようになると、会社もようやく重い腰を上げ、なんと増員を決定してくれました。エンジニアが1人だったところから一気に4人に……！

つまり、Aさんは今までの4倍の仕様書を書かないといけなくなったのです……。

せっかくアサインされたエンジニアを無駄にしてはいけないと、Aさんは仕様書を書きまくり、UIをデザインしまくり、新キャラを出しまくり、新機能のテストをしまくりました。

期待が大きくなった分、経営陣へのレポートもより詳細なものが求められるようになりました。ユーザー数が増えたので、投稿への反応も一気に増えましたが、返信に手を抜くことはありませんでした。

Aさんは頑張りました。

ただ……やがてキャパシティーの限界を迎え……。

最後は静かに会社を去っていきました。

PMは定義にいくらか曖昧さがあって、チームによってその仕事内容は大きく変わります。いろいろな仕事を任されるのはうれしくもあり、また自分のプロダクトの成長のためになると思うとついつい何でも引き受けてしまいがちですが、1人の人間がやれることには限界があります。

燃え尽きてしまう前に早めに自分の守備範囲を決めて、 他人に任せられるものは任せるのが、「真にデキる」PMだと思います。

そこかしこで板挟みになり……

PMは、時に異なる領域間の橋渡し役となることを求められる仕事です。プロダクトマネジメントトライアングル（＊2）では、PMの役割とは開発・ユーザー・ビジネスのギャップを埋めること、と定義されています。つまり、PMは必然的にさまざまなステークホルダーの間で板挟みになりやすい職種なのです。
＊2 Daniel Schmidt氏が2014年に提唱した、プロダクトマネジメントにまつわる諸要素と互いの関係性を示すフレームワーク

とあるスタートアップでPMをしていたBさんの話です。Bさんが担当していたプロダクトは、ユーザーから非常に愛されてはいたものの、マネタイズ面が弱いという問題がありました。いくつもの改善施策を繰り返し、それなりの効果はあったものの、プロダクトの継続に必要なレベルの改善には至りませんでした。

そこで経営陣は、プロダクトの思い切った方針変更を検討するよう、Bさんに命じました。いわゆるピボットというやつです。

まず反発したのは開発現場、主にエンジニアです。経営陣からの要求（命令）は、控えめに言っても既存のユーザーを無視した「改悪」でした。その上、それでマネタイズが本当に良くなるとはとても思えないものでした。エンジニアたちは、自分たちがそれまで一生懸命に作ってきてユーザーからも愛されているプロダクトが、経営陣からの一方的な、しかも全く筋の通らない要求によって台無しにされるのが我慢できなかったのです。

もちろんBさんも十分に、むしろエンジニア以上にそれを認識していて、経営陣を説得しようと試みたのですが、一向に聞く耳を持ってもらえません。

そこでBさんは、エンジニアたちに次の2つのことを説明しました。

結果、何とか開発・リリースにこぎつけたのでした。

リリース後、既存ユーザーからの反発は予想通りすさまじいものでした。元の仕様に戻さなければプロダクトの利用を止めるというユーザーが続出し、中には法的措置を取ると言ってくるユーザーまでいました。Bさんはユーザーからのクレームの矢面に立たされながら誠心誠意で謝罪し、A/Bテストの結果次第では元の仕様に戻すことを説明しました。

そして肝心のA/Bテストの結果はと言うと……まあ、微妙なものでした。

マネタイズは以前より多少良くはなったものの、目標の水準には程遠く、継続率に関しては少し下がっていました。この結果なら仕様変更は中止になるだろう、とBさんは考えていました。ところが経営陣は、その「改悪」を決めてしまったのです。

「全く希望が見えない元の仕様よりはマシだから、仕様変更が完了した後に改善していく」ということでした。結果的に、エンジニアにもユーザーに対してもうそをつくことになってしまったBさんは、失意のうちに退職を選びました。

繰り返しになりますが、PMは板挟みになりやすいポジションです。良いPMになるには、異なる視点を持つ各ステークホルダーの意見をかみ砕いて円滑な意思疎通を図るコミュニケーション能力と、相反する利害を統合してソリューションを導き出す問題解決力が不可欠です。

その上で、 ステークホルダー間で板挟みになってもつぶされない強靭（きょうじん）さ、あるいは柔軟さが、PMにとって実は最も重要な資質なのかもしれません。

権限はないのに責任だけが重くのしかかり……

「マネージャー」ではあるものの人事権があるわけではない、というのはPMの仕事を語る際によく言及されることです。 PMは人事権をちらつかせてチームメンバーを動かすのではなく、そのリーダーシップでチームメンバーを動かしていくのだと。

これ、実際にやるのはまあまあ大変なんですよね……。

有名なTech系企業でPMとして働く、Cさんの話です。Cさんのチームは、当時の売り上げ目標達成のために非常に重要な新機能のリリースに向け、日々開発に取り組んでいました。しかし進捗はかんばしくなく、スケジュール通りのリリースはかなり怪しくなってきていました。そのことをCさんの上司であるGM（ジェネラルマネージャー）に報告すると、「新しくエンジニアを1人アサインしてやるから、必ずスケジュール通りにリリースしろ」とのこと。

しかし、この新しくアサインされたエンジニア（Zさんとしておきます）が問題だったのです。

まず、合流初日にいきなり1時間遅刻してきました。聞くと、前夜遅くまで起きていて、朝起きられなかったそうです。プロジェクトの説明のために準備していたCさんと同僚エンジニアの時間が、無駄につぶれました。さらに、1時間遅れで始まったオンボーディングミーティングの中で分かったのは、Zさんはそのプロジェクトで使用している技術にはあまり詳しくないということでした。即戦力を期待していたので残念ではありますが、そこはキャッチアップしてもらうしかありません。

そしていざ仕事が始まると、またまたポロポロと問題が……。

まずZさんは、分からないことがあっても人には質問せず、自分で納得いくまで調べて考えるタイプの人でした。そのため仕事がなかなか進まず、出てきたアウトプットのクオリティーも低く、レビューのために他のエンジニアの貴重な時間がたびたび削られていきました。

また、自分のスタイルに対するこだわりが強く、他の人からのアドバイスをなかなか聞き入れず、ディスカッションに多くの時間を割く必要がありました。他にも、相変わらず遅刻はする、情報共有をしない、締め切りを守らないなど数々の問題があり、正直「いない方がマシ」というレベルでした。

CさんはGMに「Zさんがいると余計に時間がかかるからチームから外したい」と伝えたのですが、「アサインしたばかりですぐに外してはZさんに悪いし、社内にすぐ対応できる引き取り先も無いから、しばらくは置いておいてくれ」とのこと。仕方なくZさんをチームに置いてこれまで通り作業してもらいましたが、チーム全体としての効率は下がる一方……。

結局新機能のリリースは間に合わず、売り上げ目標も未達となってしまいました。CさんはPMとしてその結果の責任を取らされ、その期の評価は最低ランクに。会社の対応に失望したCさんは、最終的に辞めることを決意しました。

人事権がないということは、上から割り当てられたリソースに難があっても、その条件下で目標を達成しなければいけないということです。権限はないのに責任だけは取らされるというのでは、やってられませんよね……。

それでもPMを続けるのは……

いかがでしたでしょうか。PMの修羅場3選。“キラキラ”だけじゃない、PMのリアルな一端を紹介しました。

ただ、こんなに大変な仕事なのに僕がPMを続けているのは、やっぱりPMって楽しいからなんですよね。自分が考えた、まだこの世に存在しないアイデアが、現実のものとなってたくさんの人々に使われるのは本当に何物にも代えがたい喜びですし、そもそもみんなでワイワイガヤガヤ意見を出し合ってモノを作り上げていく過程そのものが楽しくってしょうがない。

この記事を読んでくれた“PMの卵”や現役PMのみなさん、ぜひ一緒に涙あり笑いありのPMライフをエンジョイしていきましょう！