ホーム  >   ブログ  >   エッセイ   >   僕は「世界で闘うプロダクトマネージャー」にはなれない。

2020-07-11

僕は「世界で闘うプロダクトマネージャー」にはなれない。

このエントリーをはてなブックマークに追加

以下の3点において。

  1. インタビューで「世界で闘うプロダクトマネジャーになるための本」に書かれているような質問をされたとして、答えられそうにない
  2. 属する組織の規模や仕組み、製品の種類によってプロダクトマネージャーの役割は大きく異なる。仮に今のチームで世界に轟く大きな成果を挙げたとして、次のプロジェクトで同様に活躍できる保証はどこにもない
  3. 国が違えば課題も違う。地理的な意味で、真に世界をまたにかけてプロダクトマネージャーとして仕事をするのは相当難しい

"Why a Data Science Engineer Becomes a Product Manager" に書いたとおり、今年2月にエンジニアからプロダクトマネージャー (PM) に転身した。そこから1四半期強。幸い悩む時間は無限にあったので、ここで一度振り返ってみる。

PMとしての能力を定義することの難しさ

PMに要求されるスキルとは何か?

エンジニアリング、デザイン、ビジネスの各方面に対する理解とコミュニケーション能力・・・言ってしまえば、(1)問題を深く理解し、(2)できる限り正確な見積もりを行い、(3)それに基づいて行動を起こし、(4)問題の解決に向けてチームを導くに足るあらゆる能力が求められる。

面接でこれらすべてを正確に測るのは困難だし、プロジェクトに応じてゴールや関わる人は変わるため、その都度ゼロベースでのスタートとなる。僕はといえば、なにもかもが難しすぎて、毎日コーディングよりもはるかに頭を使っている気がする。頭の全く違う部分を使っている、と言ったほうが正しいかもしれないが。

そんなわけで、フェルミ推定のような質問を含む「世界で闘うプロダクトマネジャーになるための本」で紹介されている面接をパスしたからと言って、それがプロダクトマネージャーとしての絶対的な価値を証明するわけではない1。逆もまた然り。

必読記事 "Good Product Manager/Bad Product Manager" を筆頭に、「良きPMとは何か」を論じた文章は今や無数に存在する。その議論は Good Engineer や Good Designer を語るよりもはるかに複雑であり、各人が似ていても少しずつ違う点を強調している。難しい問題だ。

では僕にとっての良いPMの指標は何か?それは「自分の意思決定・発言にどれだけ自信を持ち、仲間を信用し、信用されるか」である。これは僕がPMになってしばらくした頃に上長から与えられた、次の2つの教えに影響を受けている。

  1. PMとは、なによりも信用を勝ち取ることが重要である。
  2. PMとは、アメフトでいうところのクォーターバック的ポジションである。

ひとつ、信用がすべて。チームメンバーに自分を信用してもらえるか。自分がチームメンバーを信用できるか。

ふたつ、自分はクォーターバック、すなわち司令塔である。様々なポジションの人たちの動きを見極め、その瞬間で最良の決断を下すこと2

正直なところ、自分がPMとしてこれらをうまく実践できているかはまだよくわからない。むしろダメダメで、チームメンバーに迷惑をかけている気さえする。しかしそこで謙虚になって、一歩身を引いて「不甲斐なくてごめんなさい…」と縮こまってしまうのは絶対に違う。その瞬間にPMとしての自分は死ぬ。迷うな。自分の判断に自信を持て。根拠を持って、説得力のある意思決定をし、仲間を安心させるのがPMの責務である。

いかにして自分の判断に説得力を持たせるか?その答えは、様々な記事や書籍で語られる「良いPM像」の中にある。

「良いPMは顧客を重視する」のは、一次情報に基づいてプロジェクトがもたらす価値を正確に測り、製品要求に強い根拠を与えることができるためである。

「良いPMはエンジニアリングやデザインに対する理解と最低限の経験がある」のは、エンジニアやデザイナーの“気持ち”を汲んで会話ができることで、両者とより良い関係が築けるためであり、その結果として見積もりやマイルストーンがより強固なものになる。

そう、良いPMは情報収集とフィードバックのためのコミュニケーションを惜しまない。PMの発言の説得力とは、広範かつ徹底的な対話によってもたらされる「隙の無さ」だ。

そして信用はこれらを積み重ねた先にある。一夜にして信用が得られることはありえない。一方で、これまで積み上げた信用は僅かな不信感でいともたやすく消え去ってしまう。それを肝に銘じること。

仲間を信用する、というのはまた別の難しさがある。プロダクト“マネージャー”とは、うまく言ったものである。実際はPMなんてチームの1メンバーにすぎず、他のメンバーとの間に上下関係があるわけではない。しかし上長としてのマネージャーがそうするように、仲間のキャパシティを把握し、仕事を任せ、時には障壁を取り除くためにサポートをする必要がある。仲間を信用できず「自分でやったほうが早い」となってしまえば、いろいろな意味で終了である。

この点に関して、幸い自分は今のところ大きな問題を実感したことはない。PMという仕事のやりがいについて話すとすれば、「少し丁寧にお膳立てをしただけで、想定以上に質の高いモノがエンジニアやデザイナーから出てきたときの気持ちよさ」について語らずにはいられない。まぁでもそれはまたの機会に。

しかし組織が大きくなればなるほどメンバーのスキルや経験は多様化し、全員を信用するのは難しくなっていくのだろうなと想像する。

この組織で●●●●●PMをやりたいか?」という問い

そう、全ては組織次第。規模は?どんな製品を扱っている?PM、エンジニア、デザイナーの各チームにはどんな人がどれだけいる?チーム内・チーム間の関係は良好か?自分、あるいはチームメンバーの誰かがリモートワーカーか?3

PMとは無力な権力者である。意思決定を委ねられていて、その判断が優秀なチームメンバーたちの仕事を左右するという点において「力(発言力, 決定権)」を持った存在であることは確かだ。と同時に、単独ではプロトタイプ以上のものを作り切ることさえできないほど専門性に乏しいポジションでもある。

ゆえに、(もちろん努力で補える部分もいくらかあるかもしれないが)PMとしての自分が置かれた環境というものが職務遂行において非常に重要な意味を持ってくる。

書籍 "Inspired: How to Create Tech Products Customers Love" の第2版では、スタートアップ、グロースステージの会社、エンタープライズ企業のそれぞれでPMの役割というものが大きく異なることを冒頭で述べており、本文は「大規模エンタープライズ企業でのPM」に焦点を絞って書かれている。

組織の規模が大きくなればなるほど、社内政治に振り回され、意思決定までに必要な労力・時間は増大する。アジャイル的な小回りがきく方法でのプロジェクト推進も容易ではないはずだ。全てがうまくいったときのインパクトは計り知れないが、頼りないVPなどの上位陣やふわふわとした企業文化・ミッションの下ではPMは非常に困難な戦いを強いられるだろう。

逆にスタートアップではしがらみが少なくプロジェクトを進めやすい分、資金や人的リソースは限られている。妥協せねばならないことも増えるだろうし、もしかしたらPMなのにコードを書かなければならない状況になるかもしれない。

このあたりは一概に良し悪しを判断できるものではなく、だからこそ「自分はこの組織で●●●●●PMをやりたいか?」という点が重要なのだ。

もちろん向き不向きや得意不得意はあり、「やりたいかどうか」と「実際にやれるか」は必ずしも一致しない。それに製品の成功なんて、新型ウイルスの流行のようなどうしようもない外的要因にいとも簡単に左右されてしまう。仮に自分が「世界中の有名企業で闘ってきた歴戦のプロダクトマネージャー」であったとしても、そのスキルの一般化が難しいPMという職業においては、過去の成功体験なんてまったく当てにならないのだ。

個人の観測範囲は限られている

「自身の能力」「組織のあり方」ときて、次にPMとして意識すべきだと感じたのは「他者が持つ価値観・世界観」についてである。

そもそも、プロダクトの価値は、その製品を使う人や使われる環境に紐付いた文化や文脈に強く依存する。

「世界で闘うプロダクトマネージャー」の「世界」を地図上のそれと捉えるのなら、真に「世界」を相手に闘うことは非常に困難なことである4

幸運にも自分はいま、世界中に顧客がいるエンタープライズ製品のPMを務めるという経験ができている。先に述べたとおり顧客重視はPMのキホンであるから、世界各国に点在する顧客や仲間の意見に日常的に耳を傾けるのだが・・・これがまぁ難しい。

USのチームがXXXという機能が欲しいのだと言う。それもひとりではなく、何十人という規模で皆が口を揃えて同じことを言っている。なるほど、と思い日本側でヒアリングを行ってみると、そんなニーズ聞いたこともないし要らない機能だという。さらに、なんとかプロジェクト実行にこぎつけても、細かいところで各国に点在するエンジニア・デザイナー・PMの間で意見の一致を見ない。

これが当たり前なのだ。個人の観測範囲なんて限られているし、誰だって身近で強い意見にバイアスをうける。

ゆえに、これら全ての意見をきちんと吸い上げ、説得力を持って最良な選択を下すこと・・・それこそがPMの、PMにしかできない大変重要な仕事なのである。

僕がここ数ヶ月のあいだ朝4時起床、夜9時就寝の生活を続けていた理由のひとつはここにある。このリズムで生活をして働いていると、北米と日本のタイムゾーンを50:50で平等にカバーできるのだ。どちらか一方の国のチームの動きが過剰に目につく、という心配がない5

それでも2タイムゾーンがやっとだ。ここにヨーロッパ時間を加えればオーバーワークをする他ないし、破綻してしまう。

リモートワークが当たり前になっても時差は無くならないし、世界各国の文化・文脈は統一されるはずもなく、むしろ国をまたいだ移動が難しくなったせいで断裂は加速する一方だ。この世界をいかに生き抜くか。PM個人のみならず、それが今すべてのグローバル企業に突きつけられている課題なのかもしれない。

まぁ、楽しくはない

これだけはハッキリと言えるが、ここまでに述べてきたPMの仕事は、僕にとっては今のところ全く楽しくない。中学卒業時から「好きなことで生きていく」をゆるく貫いて守ってきたソフトウェアエンジニアリングというコンフォタブルゾーン。そこを抜けた先にあったのは、ただのアンコンフォタブルゾーンだった…正気か?

PMとしての日々はただただストレスフル。気づけば眉間にシワが寄っている。増え続ける運動量と飲酒量。朝起きて最初の感情が「つかれた」だったときは流石にヤバいと思った。

しかし同時に、今の経験が間違いなく重要なものになるという感覚がある。自分で手を動かす機会こそ限られてしまうものの、PMとは確かにビジネス・エンジニアリング・デザインの交点に立つ存在であり、これは『“じぶん”の解像度を上げる』に書いた今年の目標とその背景にあるモチベーションに合致する。

PM歴わずか1四半期。ここで何かを結論づけるつもりも資格も無いけれど、まずは与えられた責任に感謝しつつ、兎にも角にも、それを全うしよう。今この瞬間を無駄にせず、先5年間くらいの糧とするために。

僕は「世界で闘うプロダクトマネージャー」にはなれない。

でも、今この場所での闘いに最善を尽くすことはできる。

とういうわけでみなさん、明日も1日がんばっていきましょう。

1. コーディング面接も、計算量がスムーズに言えたからといってそれがエンジニアとして優れていることの絶対的な指標にはなりえない。この点においてはエンジニアもPM同じだが、そのような面接をパスできるだけの知識、技術、経験がどれほどレバレッジの効くものか―未来の日常業務で有益なものか―に関しては、両者の間に大きな差があると感じる。
2. 司令塔が下す最良な解は、必ずしも特定の誰かにとっての最適解にはなりえない。エンジニア、デザイナー、経営陣、お客様・・・基本的にみんな少しずつ違うことを言うものである。全員を100%満足させることの難しさを知れ。その意味で、今ほど“トレードオフ”という言葉の重みを強く感じたことはない。
3. リモートとオフィス勤務のメンバーが混在している場合、コンテクストの共有や情報の透明性の確保に不安が生じる。地理的に分散していて時差があれば尚更だ。
4. それに比べると、はるかに抽象化されたプログラミングというタスクでは地理的、文化的差異が問題になることは稀である。ゆえに「世界で闘うプログラマー」をイメージするのは比較的容易い。ただし、議論が「プログラム」から「アプリケーション」に発展した場合、そこには「プロダクト」と同種の問題が発生しうる。
5. 昨今の状況を受けて自由な働き方が許されるようになったこと、そして自分が元々朝型の人間だったということによる生活リズムであり、決して無理をしているわけではない。朝が早い分、夕方には仕事を切り上げているので長時間労働というわけでもない。ご安心を。

  書いた人: たくち

たくちです。トレジャーデータでデータサイエンス・機械学習のプロダクト化および顧客への導入支援・コンサルティング、そして関連分野のエバンジェリズムを担っています。趣味は旅行、マラソン、登山。コーヒーとお酒とハンバーガーが好き。長野県出身、東京都在住。ブログへのご意見・ご感想、お仕事のご依頼など、@takuti または [email protected] までいつでもお気軽にご連絡ください。

※当サイト上での発言は個人の見解です

  過去の人気記事

2017-12-16
データサイエンスプロジェクトのディレクトリ構成どうするか問題
2017-06-10
Amazonの推薦システムの20年
2017-03-31
修士課程で機械学習が専門ではない指導教員の下で機械学習を学ぶために

  サポートする

  コーヒーを贈る

  ほしい物リスト

このエントリーをはてなブックマークに追加

  あわせて読みたい

2020-09-12
なぜUI/UXデザイナーの仕事は批判の的になるのか?その謎を解明すべく我々は(以下略)
2020-05-16
データよりもストーリーを、相関よりも因果を。
2019-12-10
デザインエンジニアになろう
  もっと見る