プロダクトマネージャになろう
はじめに
私は阪神ファンであるとともに、所属している会社ではプロダクトマネージャという役割の仕事をしています。私も良い歳なので、社内でプロダクトマネジメントとはなんぞやということを語る機会もそれなりにありまして、毎回同じことを説明している気がしたので、せっかくなので文章として公開することにしました。
私は自分が行なっている仕事がプロダクトマネジメントである、という自負がありますが、とはいえ外部の権威から何か承認を受けた事はありません。
なので世に出ている文献と異なった事が書かれていると思いますが、流派の違いだと思ってご理解いただければと思います。
ちなみにロードマップの話とかは一言もありません。
総じてぼんやりしてます。俗に言うハイレベルなドキュメントってやつです。
For English speakers. You can read this what I translated with AI.
https://medium.com/@mizzusano/how-to-be-a-product-manager-9fb01d59893b
プロダクトマネジメントとは
まず、プロダクトマネージャを語る前に、プロダクトマネジメントとは何かを書いておきましょう。
プロダクトマネジメントとは、ざっくり「製品を成長させ、ユーザに対して持続的に提供可能な状態を保つ」ことではないかと思います。
なので、プロダクトマネージャとは、プロダクトマネジメントをする人、プロダクトマネジメントに対して、責任を持つ人と言えます。
ちなみに、会社とは「事業を成長させ、持続的に社会に対して提供可能な状態を保つ」ものでありますから、会社の事業が製品開発である場合、プロダクトマネジメントとは会社の中でも重要なマネジメント部分を担っていることが多くなります。
持続的に提供するためには、保守にかかるコストを回収する必要があります。つまり、成果を出さねければならない。ということです。
プロダクトマネジメントなんて誰でもできる
さて、プロダクトマネージャはミニ CEO と呼ばれることがありますが、CEO とプロダクトマネージャの共通点はなんでしょうか。
一つあるとすれば、誰でもなれる。ということです。
誤解がないようにわざわざ書きますが、誰でも CEO として成功できる、誰でもプロダクトマネージャとして成果をあげられる、という意味ではないです。
目的があり、目的に対して解決方法の仮説を作り、それに着手すること、それ自体は誰でもできます。そのための手段の一つが起業であり、プロダクトマネジメントです。
ちなみにミニ CEO という呼び方は、私にはそれなりに違和感がありますが、それは CEO という言葉が、出来上がった組織において、よりハイレベルな情報伝達のみを仕事にしている人を想起するからでしょう。
自分が作ったばかりの会社で、従業員が一人もいない中、やらなければならないことのために自分の時間と自分のスキルを全て使う、起業直後の創業者を思い浮かべると、ミニ CEO と呼ばれるのもしっくりきますね。
起業家には誰でもなれます。
プロダクトマネージャに必要なスキルとは
たまに「プロダクトマネージャになるには何を始めればいいのか？」という質問をされることがあるのですが、けっこう難しい問題です。
先述したように、製品を成長させるために必要なこと全てがプロダクトマネージャの仕事だと言えるからです。
所属している会社においてプロダクトマネージャを名乗るために必要なことは、それぞれの会社の Job Description に書かれているでしょう。ただし、プロダクトマネージャに必要なスキルセットは、会社やプロダクトの性質、そしてプロダクトが置かれている状況と、解かなければならない問題によって全く異なるので、一概に何から学べばよい、というのが難しいのです。
とはいえ、プロダクトマネジメントを行う上で、重要な要素は絞ることができます。一つは「不確実性を取り除くこと」、もう一つは「成功の確率を上げること」。もう一つ追加するならば「成功を再現（スケール）するための方法を見つけること」です。
ただ、一番重要なのは、自分に与えられた状況で「前に進めること」だと思っています。
たとえば、専門家が三人いるチームだとしても、それぞれの専門家が自分の領域以外に対して、何も責任持てないから進められない、みたいな状態だとプロジェクトは進まないですよね。ただ、その専門家の間に入って、自分は何もわからなくても、ひたすら彼らを頼って、やりたいことを説明して、目的を達成するためにチームを前進させることができたら、それは立派なプロダクトマネジメントだと思うのです。
曖昧な課題を、具体的な解決策としてアクションまで結びつけ実行して成功させる。全ての仕事に対してこの構造は当てはまる気がしますが、この曖昧さと具体的な解決策の制限がないところが、プロダクトマネージャの難しいところなのかもしれません。基本的に仕事は役割において解決方法が制限されますが、プロダクトマネージャにはそれがありません。
前に進めるためには、やることが想像できないといけない
さて、前に進めることができればなんでもいいという話をしましたが、そもそも、彼らが言うこと聞いてくれるかわからないところからスタートしますよね。どんなお願いをすればいいのかわからない。お願いしたことがどれくらい大変でいつ終わるのかもわからない。受け取った仕事内容が最適であるかもわからない。
ただ、プロダクト開発というのは最適なタイミングで完了させることで成功するものなんです。成功要因が自分ではなく他人に依存している、というのは不安ですよね。
このわからなさを少しでも潰していくための知識と経験が、プロダクトマネージャにとって、必要なスキルです。
不確実性とは、やりたいことが実現できるのかどうか、やりたいことを実現する場合にどれくらいの時間、コストがかかるのか。
成功確率を上げるためにはプロダクトを出すタイミングと品質が重要です。
成功を再現させるためには、課題設定の方法と、解き方、そして成功の測り方が重要です。
これはどうしても経験や知識、人脈などで差が出てしまうのはしょうがないです。そして、会社としてはやっぱり成功確率が高い人に、これらを任せたい。素人には声がかからない。
なので、誰でもできるけどなるのは結構難しい。そして何から始めたらいいのかわらかないものになってしまう。
重要なのは自分は専門家と同じことができる必要はないのです。ただ専門家にプロダクトに必要な最高のアウトプットを出してもらうために、やっぱり知識は必要になるよね。という話ではあります。
さらに、プロダクトマネージャの知っている品質が、チームの専門家のアウトプットより高いことも往々としてあり得ます。本来成功に必要な品質をチームに対してフィードバックし、チームを成長させることも、しばしばプロダクトマネージャに求められる仕事です。
このあたりの品質を普通のものとしてチームに浸透させる部分は、今年阪神を38年ぶりに優勝させた、岡田監督のマネジメントで非常に興味深かった部分でして、先日 note に書きました
「普通」というのは全ての判断の基準です。それゆえに具体性のかけらもないわけですが、成果を出しているチームが「普通」にやっていることと、そうでないチームが「普通」にやっていること。それらの行動には確実に差があることでしょう。
https://note.com/mizzusano883/n/n5a00daf8c92f
あらゆるマネジメントに言えることですが、マネジメントの想像力の限界がチームの限界を決めてしまうのです。
MIN(自分の限界, メンバーの限界) の値をいかに高めることができるかが重要です。
複雑な問題を、シンプルな幾つかの問題に分割する
プロダクト開発はチームで行うことが多いでしょう。プロダクトマネージャの仕事はそれらチームの働きを最大化させる必要があります。チームにはいろいろな人がいて、全てのメンバーが職人であるとは限りません。
メンバー全員が、自分たちが何をやっているかを理解できるように、問題はシンプルであるべきです。プロダクトの成長のためにやらなければいけないことは、偶に複雑な問題として現れますが、これをそれぞれのチームが、日々の業務レベルまで落とし込めるように、幾つかの解きやすいシンプルな問題に分割するのもプロダクトマネージャの仕事です。
プロダクトマネージャを目指す方へ
最初に何から始めればいいか？について、最初のとっかかりとして、個人的には、以下のどれかに強みを持っている必要があると思います。
データ分析ができる
自分でデータを取れるプロダクトマネージャは強いです。読めるのは当たり前なので、自分でデータを取ってください。なんで自分でデータを取れると強いのかというと、他の人に頼んで、それを待つ必要がないからです。
仮説を作るのにデータは必要不可欠です。そして仮説の検証のイテレーションは早ければ早い方がいいんです。少しでも疑問に持ったことはすぐに数字で確認したほうがいいですし、とにかくデータを自分で取れる人は強いです。
デザイン UI を書くことができる
自分でデザインができるプロダクトマネージャも強いです。自分が考えているものがどのようなものなのか、実際にアウトプットする絵を描きながら考えられると、それをなすためにどのような情報が必要なのかが具体的にわかります。ワイヤーフレームはあんまり役に立ちません。実際にユーザに出すレベルまでデザインを自分で考えて、表示される画像、文言やボタンレベルの配置まで自分で考えることができると、自分がやりたいことを実現するために必要な情報が、完全に把握できるので強いです。
重要なのはプロダクト開発において、見た目は最後のユーザとのコミュニケーション手段であって、あらゆる要素の集大成が見た目である、と言うことです。なので、見た目一つで、それを実現するために作るものに、恐ろしく差が出ることもあります。なので、UI レベルまで自分で作り込めると、説明もスケジューリングもうまくいきやすいです。
ただし、注意するべきは、プロダクトマネージャが作ったイメージ図が、チームの専門家の想像力を奪ってはいけないということです。専門家は自分の想像を超えてくれます、そのアウトプットを有難く採用させてもらいたいのです。
プログラミングができる
自分でプログラムができるプロダクトマネージャも強いです。何しろこの文章で暗黙的に想像できる「プロダクト」は、ほとんどプログラムで作られているので、プログラムに関する不確実性が減るのは、ものすごく武器になります。一番手っ取り早いのは、一つプロダクトを作ってみることです。特定の技術スタックにものすごく詳しいよりは、アプリケーション、バックエンド、データベース、Web フロントエンド、全てに少し詳しい方が、実際プロダクトマネジメントをする上では便利でしょう。
バイトでもなんでもいいので、何か数字を伸ばすために試行錯誤を経験している
これはまさに、数字を伸ばすために試行錯誤して実行する、がプロダクトマネジメントのプロセスそのものだからです。これができる人は強いです。
私の尊敬する友人は、バイト時代のキャッチであったり、SNS のフォロー数であったり、数でパフォーマンスが計測可能なものに対しては、失敗の中から成功パターンを見つけ、成功パターンを繰り返すためのルーチンを見つけ、ルーチンの繰り返しによって数値を伸ばすことをしていました。
ジュニアなプロダクトマネージャについて
与えられたスコープで結果を出すことが求められます。数値を伸ばす方法としては、拡大よりも改善の方がいい経験になるでしょう。改善は短い期間で何回も繰り返すことができ、何回も失敗することができます。
拡大をしてしまうと、開発とリリースが長期化しがちです。また成功要因が曖昧になります。
限られた分母の中から、成功するための変数を改善するほうが、コントロールできる範囲のカバレッジが広いので、得られる学びは多いと思っています。また、その学びは、次の拡大にも生かされて、無駄な取りこぼしをしなくて済みます。
そもそも、ジュニアであるうちは与えられるスコープが限定的なので、あまり大きなインパクトを作ることができないことが多いでしょう。であれば、仮説検証を繰り返して、そのイテレーション手法の精度を磨くことに時間を使ってもよいでしょう。延々と同じ場所の細かい数値改善をしろ、ということではないですが、転々と違う場所の細かい数値改善を繰り返してもいいとは思います。解ける問題のパターンを増やす、ということです。
そのうち、絶対に数値改善できる箇所は後回しにする、という判断ができるようになります。絶対に数値改善できる箇所はもはや問題ではないので、必要な時に解決すれば良いという気持ちになれるはずです。
シニアなプロダクトマネージャについて
シニアなプロダクトマネージャに必要なのは、既定のプロセスを超えたインパクトを出すクリエイティビティでしょう。与えられたスコープを超えて、自分たちの仕事を再定義し、組織やプロダクトをリファクタリングし、成長要因を作り直さなければいけません。
複数の Initiative を一つにまとめ、バラバラになっている「必要なこと」を一本の必要なものとして包含して、一つの解決方法で全てを解くことができる、ドラマティックな課題を定義する Creativityこそ重要なのではないかと思います。私の尊敬する元同僚は、課題の解き方ではなく、何を課題として設定するかが最も大事である、と言っていました。
また、自分がやったら絶対うまくいくことは、極端な話、全ての工程はイメージできるし、書き出そうと思ったら書き出せるでしょう。それを誰かに任せて、もっと大きな、曖昧な課題にとりかかるべきです。
最後に
ここまで書きましたが、私はプロダクトマネージャなんて本来は必要ないと思っています。プロダクトマネージャなんて、イーロン・マスクが真っ先にクビにしそうじゃないですか。
チームメンバーがそれぞれ同じ目的のためにやれるべきことをやっていて、プロダクトが成長していたら、プロダクトマネージャなんて必要ないし、チームの中にリーダーがいるんだったら、その人がプロダクトマネジメントをやれよと思わないでもない、ということです。
なので、プロダクトマネージャって結局チームありきの役割なんですよね。なので、一番重要な仕事って、チームにやるべきことを説明すること、になりますね。
例えば自分の置かれている状況に何か不満があるとしましょう。不満というのは、知っている高みとの差分です。なので、自分がその差分を知っているおであれば、差分を言語化し、周りにその高みに追いついてもらうように振る舞うのが仕事である。というそういう途方もない話なのです。
やるべきことをわかりやすく説明し、問題と解き方を具体的にチームメイトやステークホルダーに説明する。エレガントな問題への気づき、そしてそれらを関連付けるのは自分自身の人生の経験と、野望、そして知恵から生まれる Creativity であると。それを養うには、ある程度の経験とスキルが必要になっちゃうよね、という話で、本日は終わろうと思います。