Rohini Vibhaさんは、IDEOのビジネスデザイナーです。Twitter アカウントは、@rohinivibha。本記事は、Mediumへの投稿記事をRohiniさんから許可を得て翻訳したものです。元の英語記事もどうぞ。

世の中にプロダクトマネージャーを目指す人が増えていると思うのは、私だけだろうか。私自身がプロダクトマネージャーを務めているから、そう感じるのかもしれない。それにしても、最近はコンサルタント、MBA候補生、エンジニア、誰もかれもがプロダクトマネージャーを目指している気がする。

もしこれが事実で、もし本当に、”誰も”がプロダクトマネージャーになりたいと望んでいたとしても驚くには至らない。確たる技術を極めることなく務まる役割なのだから。プロダクトマネージャーになるためにデータモデルの作り方を知っている必要はないし、コーディングができる必要もなければ、Webサイトをデザインできる必要もない。プラスにはなるけれど、必須ではない。エンジニアやデザイナーになることに比べると、プロダクトマネジャーという職種は、ある朝目覚めたらなることができてしまう。

それに、書き出してみると何とも響きがいい：

• 会社のプチCEOである
• 他のメンバーを率いる立場にある
• 業界通である
• 今日そして未来のプロダクトの外見と中身を決める立場にある
• 高給取りである
• あなたこそ、ボスである

このリストは冗談。なぜなら、プロダクトマネージャーという役割は、紙の上では語られないサプライズで満ちているからだ。あなたがまだPMではなく、またこれまでに職場でPMと深くやりとりをしたことがないなら、プロダクトマネージメントの実態は、あなたが想像するものとはきっと違うはず。

・・・

プロダクトマネージメントとは

• ユーザーの心となり、頭となり、声となること
• 部門横断的なチームワークを促進すること
• プロダクトにおけるトレードオフを行うこと
• 決まった資源と期限内に最終ゴールにたどり着くこと
• プロダクトジャーニーの中で一貫して人を率いること
• ポジティブそして実践的であること
• 微々たる情報量で難しい判断を下すこと

プロダクトマネージメントではないもの

• もっとも重要な「意見」であること
• ただ一人のアイディア考案者であること
• デザイナーであること
• プログラマーであること
• QAを管理すること
• Webサイトを最適化すること
• マーケティングに付随すること

わたしにこれがわかる理由

私がプロダクトマネージャーの職に応募したのは、思いつきでのことだった。当時、私は心理学専攻の大学4年生だった。ベイエリアにどうしても戻りたくて、でも残念ながら、仕事が溢れているのはテクノロジー業界だった。心理学という自分の専攻が笑いの種にならないよう、必死で仕事を探した。

自分でも驚くことに、技術的また文化的にも素晴らしいIntuitという企業のプロダクトマネージメントアソシエイトのオファーをもらった。自分でも驚いた。だって、プロダクトマネージャーの仕事がどんなものなのかを知らなかったのだから。「ワオ」と、採用通知書を繰り返し読みながら思った。「あの時のインタビューでは、ただ自分の情熱について語っただけだった。あれで十分だったなんて信じられない」。私の卒業論文のテーマは心理言語学で、私が知る限り、それは金融ソフトウェアとは縁遠かったはずだ。

私が初めてプロダクトマネージメントの役割を担ったのは、QuickBooksだった。年に一度リリースされるβ版の管理を任され、この時の体験のすべてが、プロダクトマネージメントにまつわるサプライズを要約するものだった。そのどれも、私の職務概要には記載がなかった。

主に4つある：

1. あなたはプロダクトを管理しているのではない。それが解決する課題を管理している

QuickBooksを任されるとわかった時、吐いてしまうかと思った。「え、QuickBooks?!」と小馬鹿にすらした。「私の祖父より高齢じゃない！」（実際には違うが、毎秒のように新たなプロダクトが生まれるシリコンバレーで、QuickBooksは父親世代のものに感じられた）。「真の」プロダクトマネージャーのような「イノベート」する仕事ができないことを悔やんだ。若くてセクシーなプロダクトを任されたかった。

この認識が、どれだけ間違っていたことか。

顧客が1人でもいるプロダクトを管理するようになると、あなたの仕事は、完全に機能がそろったプロダクトを上回る大仕事であることがわかる。プロダクトが解決しようとする課題を深く理解することこそが仕事で、それができたら、課題の一つ一つの細かなニュアンスを解決するために動く。

いつだって、機能追加の要望は溢れかえっているし、時間がどれだけあっても足りない。バグは山積みで、時間は刻一刻と過ぎていく。やることは尽きない。ユーザーがすでに習慣を築いている成熟したプロダクトの場合、また企業に独自のプロセスが出来上がっている場合、制約を乗り越えるためにより一層イノベーティブになることが求められる。

プロダクトマネージャーであることは、あなたのチームが決まった期間内に達成できることと、顧客が何がなんでも必要とするものとの間で妥協し、バランスをとることを意味する。あなたは、チーム、顧客、事業の間で起こる「時間」に対する勝ち目のないレースの中で板挟みになり続ける。それが今日誕生したプロダクトでも20年前に誕生したものでも、ささやかな勝利は、短期と長期的な商品戦略のバランスをとることにある。

2. プロダクトの良さはユーザーの認識が定める

β版を運営する中で、毎週のEメールでテスターに働きかけるだけでなく、電話でも話し、時には丸1日かけて技術的サポートを行ったりした。最初は、この現状にただがっかりするばかりだった。なぜ、私はトラブルに回答しているんだろう？プロダクトマネージャーのはずなのに！と自問自答した。

その後も顧客とのコミュニケーションを重ね、彼ら・彼女らのプロダクトの使い方を観察することで、彼女たちが「うまくいかない」と言う場合、それは彼女たちが期待するようにならないという意味であることを学んだ。顧客による認識こそが現実で、そこで「あなたのやり方は間違っている」と指摘することは私の仕事ではない。むしろ、彼女たちとやり取りし続けたことで、私自身の間違いに気がついた。私はこの気づきをエンジニアやデザイナーにフィードバックし、どうすればプロダクトの機能がユーザーにとって使えるものになるかについてブレインストームした。

最終的に、何時間、何日間という時間をプロダクトについて顧客と話すことに費やしたことが、プロダクトを救うことになった。救えて何よりだったと思う。プロダクトを任されるには、まずプロダクトが存在しなければいけないのだから。

3. プロダクトマネージャーはデザイナーでもなければエンジニアでもない

MacのApp Storeに申請する際に、併せてプロモーションのページをデザインする必要があると言われた。まだゲームに慣れきっておらず、私はそれを文字通りに受け取り、Photoshopのレイヤーやカラーパレットに自ら埋もれた。創造プロセスに伴う高揚にめまいを感じながら、苦労して完成させたページをマネージャーに送った。彼からは、私が期待した称賛とはかけ離れた返事が返ってきた。

よかった。これってデザイナーから出てきたもの？カラースキームはもう少しやりようがありそうだ。

「デザイナー？！なんのこと？！」思わず、コンピューターに話しかけてしまった。

この一件でわかったこと。それは、順調な大企業では特に、プロダクトマネージャーはビジュアルデザインを作らないということ。彼女はコードを書くこともしない。あなたのデザイナーこそがデザインの専門家で、あなたのエンジニアこそがプログラミングの専門家。そしてプロダクトマネージャーのあなたは、そのデザインと機能が、目の前にある特定のユーザーニーズに応えるものかどうかを見極める専門家だ。

4. スターになるのではないーーユニバースを任される

プロダクトマネージャーとしてQuickBooksのチームに配属された初日、マネージャーが一緒にオフィスを周ってメンバーを紹介してくれた。それも全員を。サポート、マーケティング、エンジニア、デザイン、財務。圧倒されてしまったが、それより気掛かりだったのは、時間が無駄にされていることだった。他のプロダクトマネージャーにだけ紹介してくれればいいのに、と。「きっと後で紹介してくれるんだわ」と心の中で思った。

紹介された人数の多さに驚く以上に私を不安にさせたのは、マネージャーによる私の紹介だった。「QuickBooksのローンチの責任者だよ」と。まだQuickBooksを自分のPCにダウンロードすらしていないのに、どうすればプロダクトローンチを実現できるのか謎だった。

それから数週間が過ぎて、QuickBooksのリリースは、卒業式に白い鳩が一人の手で一斉に放たれるような単独作業ではないことが明らかになってきた。私の役目は、初日に挨拶をした様々なグループ間における適切なブレインストームや会話を促進することで、ローンチに関わる様々な意思決定を行うことだった。これは目からうろこだったし、ちょっとだけ（あくまでちょっとだけ）安心もした。会議室で常にベストなアイディアを発案する必要はない。私が中から最良の案を選べるように、豊富なアイディアを育むために、それができる適切な人たちを集めることを徹底すればいい。

・・・

3年間、最小規模のスタートアップでプロジェクトマネージャーとして働いてきて、一番最初の面接の際に伝えた情熱ー他者を深く理解すること、人の生活から不便を取り除くこと、書くこと、現場で調べること、データの中にパターンやトレンドを見つけること、人のためにデザインすることーこれらこそ、面接官が探していたものだったということがわかった。なぜなら、これらこそ、優れたプロジェクトマネージャーに欠かせない要素だから。

プロダクトマネージャーとして、現在進行系で抱えている心配や不安はある。エンジニアと話す時に自分の馬鹿さ加減にうんざりしたり、Webサイトを自分でデザインできたらと願ったり、監督者である自分に嫌悪したり、JIRAの速記官程度にしか見られていないのではとふと思ったり、間違えて研究員のつま先を踏んでしまったり、なんと感謝されない役割なんだろうと自分に問いかけたりーーでも、結局、ユーザーが笑顔でプロダクトを使う姿を見ていると、そんなことを上回る価値が十分にあると思える。

プロダクトマネージャーであることは、役職に「マネージャー」という言葉がついていることに夢中になることではない。確かに、意思決定をしていくのはあなただ。でも同時に、プロダクトの全ての浮き沈みもあなたの責任だ。ユーザーがプロダクトを理解できないのは、あなたの責任であってマーケティングの責任ではない。プロダクトを市場に送り込むのが時期尚早なのは、あなたの責任であって戦略部の責任ではない。ユーザーがボタンを見つけられないのは、あなたの責任であってデザインの責任ではない。

そしてまた、ターゲットユーザーがあなたのプロダクトに用無しなのは、あなたの責任であって彼の責任ではない。

Iraとbrandongadorの協力に感謝する。

（翻訳：三橋ゆか里）