デザイナーからプロダクトマネージャーになる時にぶつかった３つの壁
はじめまして、押見です（@_oshimin）です。
現在、株式会社Zealsにてプロダクトのリーダー職の1つであるVPoP（Vice Precident of Product）をしています。
自分はデザイナー → プロダクトマネージャー → VPoPというキャリアを選んでいますが、元々の自分は経済学部でITとは無縁の生活をし、大学2年の時にZealsの立ち上げにジョインし営業をしていました。毎日100本近くテレアポしてた日々は今では信じられないです。笑
そして、デザイナーとしていくつかのアプリケーションの作っていく中で、、もっとユーザーにあった体験を作るためにUXデザインをもっとやっていきたいと思い、プロダクトマネージャーとしてのキャリアに歩みを進めました。
今回は自分と似たようなキャリアの方々が同じ失敗を辿らないよう、少しでも自分の経験がみなさんの糧になれば嬉しいと思い、この記事を書いてみました。
というのも、正直デザイナーというスキルを持っているだけでは、プロダクトマネージャーの責務を果たせるようになるには、足りないことだらけでした。
毎日わからないことだらけで、何をどう勉強したらいいのかも全くわからない。相談できる人も近くにいない。それでも、達成しなくてはいけないことが山積みで正直とても苦しい日々でした。
それでもプロダクトマネージャーを目指し続けたのは、キャリアアップの文脈はもちろん、より自分がワクワクするプロダクトを作っていくことができると考えたからです。
結論： 優秀なプロダクトマネージャーは何をしているのか？
早速結論ですが、優秀なプロダクトマネージャーが集中している3つのこと、プロダクトマネージャーとして1人前になるために乗り越えるべき3つの壁はこちらです。
優秀なプロダクトマネージャーが集中している3つのこと
つまり、デザイナーからプロダクトマネージャーにキャリアチェンジし、一人前になるためには、以下の3つの壁を乗り越えなくてはなりません。
自己紹介
そもそも、押見って誰なん？となる人が多いと思うので、まず自己紹介を手短に。
2014年: Zealsの立ち上げメンバーとしてジョインし、セールス、デザイナー、ディレクターを務める。
2017年: 新卒としてDeNAに入社。マンガボックス、エブリスタ、Pocochaにて、UI/UX デザイナーを務める。Pocochaでは同時に、初期ユーザー定着を目標としたプロジェクトの企画を担当。
2020年: ZEALSに再入社。20人から100人へ組織拡大を進めて中でプロダクトマネージャーとして、LINE MINIアプリ、RPAシステムや、チャットボットデザインの管理画面など複数機能をリード。また、組織の拡大に合わせて、SAFeをベースにしたアジャイル（スクラム）開発オペレーション、組織の設計を実行。
なぜプロダクトマネージャーを目指したのか？
自分はデザインをすることが大好きだし、これを生涯の仕事にしたいと考えています。ただ、ここでいうデザインとはクリエイティブなものを生み出すことだけを指すのではなく、“問題解決”のために、新しい課題を発見し、新しい視点を提供することです。
そのため、問題解決に近いUXデザインができるキャリアを作りたいと思い始めましたが、UX デザイナーという職種は、よほどユーザー数が多いプロダクトでない限り意味をなさないという結論に至りました。なぜなら、UXはチームで責任を持つものであるからです。
ユーザーは“点”、つまり、一機能の使いやすさではなく、“面”、つまり、プロダクトを通してユーザー自身が経験したことで判断します。ユーザーが利用する際に感じた流れが、そのまま評価に繋がるのです。
そのためにできることが、ユーザーとのタッチポイント全てに目を光らせ、最高の体験を届けるように細部までこだわり抜くこと。それこそが本質的で自分がやりたい「UX デザイン」だと気づきました。だからこそ、正しい「UX デザイン」をリードしたいのであれば、プロダクトマネージャーになるしかないと思い、目指し始めました。
プロダクトマネージャーの存在意義とは？
プロダクトマネージャーは略称としてPMと呼ばれますが、同じように略称する役割が存在しています。
PMと略称する職種
プロダクトマネージャー
プロダクトマーケティングマネージャー
プロジェクトマネージャー
プログラムマネージャー
それゆえ、「PM」の意味や求めることが会社によって異なるという問題も発生しており、PMを担うと、さまざまなスキルを組み合わせて、あらゆる障害を乗り越えるために日々奮闘していくことになります。
とはいえ、優秀なプロダクトマネージャーは以下の3つのことを必ずやっています。
この3つのことを日々やりきっていくことが、プロダクトの品質の高め、顧客に価値を届けていくことはもちろん、事業を成長や会社を向かうべき方向に導くことにも繋がります。
プロダクトマネージャーになるためのステップ
では、実際にプロダクトマネージャーになるためには、いろんな道があるかと思いますが、以下3つのステップを踏むのがベストだなと思います。
最低一つの分野でエースプレイヤーになる
マネージメントスキルやディレクションスキルを身につけ、人に仕事をお願いできるようになる。同時に、周辺にある専門領域の知識を身につける
シニアプロダクトマネージャーの業務の一部を代替し、プロダクトマネージャーとしてできることの範囲を拡大していく
このステップが取れることが遠回りに見えて、プロダクトマネージャーとしてパフォーマンスするための理想的な道だと考えています。
プロダクトマネージャーは複数の専門性による総合格闘技なので、まずは自分の柱を立てることがスタートです。自分はデザイナーから柱を立てましたが、それはビジネスでも、エンジニアでも構いません。一本柱を持つことがスタートです。なんでも求められるからといって器用貧乏だと結局成果出せないです。
デザイナーとして柱を立てた後に潜んでいるプロダクトマネージャーの３つの壁
CEOやCOOといった方々も一概にやるべきこと定義できないのと同じで、プロダクトマネジャーは、プロダクトを通じて会社の成長にコミットします。そのため、プロダクトマネージャーの存在意義は広く、曖昧です。でもそういうものだと思って下さい。そのため、正直足りないスキルは無限に湧いてきますし、それは会社やプロダクトによって異なります。
自分の場合は、to Cのアプリケーションから、to B SaaSにドメインも変えているため、その変化幅も非常に大きいものでした。
特に、to B SaaSにおいてはデータ管理や、インテグレーションの充実化など、バックエンドで処理していくものの要件を固めなくてはいけない機会が多いです。
その場合、ビジネス要件を理解するだけでは足らず、その方針で進めていくことが、正しい意思決定になっているのかテクノロジー面も理解できなくてはいけません。
正直、自分はデザインのスキルがあるからPMもやっていけるっしょくらいの気持ちでキャリアチェンジをしましたが、今ではめちゃくちゃあまちゃんな考え方だなと思います。その中でも、特に苦労したことは、「エンジニアの思考や言語の理解」です。そもそも、エンジニアへの理解がなければ、要件の作成が円滑には進みません。
自分は、デザイナーからプロダクトマネージャーにキャリアチェンジした時に3つの壁にぶつかりました。それは、
覚悟を持って「こと」にコミットできていない
プレイヤーだった今までと、プロダクトマネージャーとしてリーダーシップを発揮するためにはマインドセットを大幅に変えないと成果を出せません。
上述した通り、ここが自分がもっとも苦労しているポイントです。「甘さを捨てる」これをいうのは簡単ですが、本当に難しいです。
なによりも、自分に厳しくなくてはなりません。リーダーの行動が組織の基準を作ります。誰かに求めることはできません。
組織は生き物なので、状況に応じて変化してくるし、リーダーである自分が甘さを持っているうちは、全力で「こと」に向かうチームは作れず、ゆるい組織が出来上がります。
しかし、高い基準だけを求め続けたらチームは疲弊し、崩壊してしまいます。この緩急が大事となるので、優しいだけのリーダーにならず、高い基準を設定、コミット、要求すると同時に、チームに対して絶対的な献身ももちあわせなくてはなりません。
厳しいことを求めてきつつも、心の底から頼りになる。相反するこの2つの役割を使い分けることができるのが、本当のリーダーであると私は思います。
ただ、リーダーシップの正解はないし、状況や組織に応じてベストな方法を模索していく必要があります。きちんとチームと人間としてのつながりを持ちながら、お互いがプロフェッショナルとして向き合う信頼関係の構築が必要なのです。
これができるようになるためには、自分より2つ上のポジションの視点で物事を捉えるのが分かりやすいかと思います。
自分が新卒で入社したDeNAにはDeNA Qualityという「DeNAで働くすべての人の日々の行動や判断の拠り所とする、共有の価値観」がありますが、この中に「全力コミット」という価値観があり、この考えはそこからきてます。（ちなみに「こと」に向かうもここからきています）
1つ上だと期待値、2つ上だと期待値を超える、120%の成果や振る舞いができるようになります。
常に“自分ならどうするか”ではなく、“あの人ならこの時にどう振る舞うか？”と、常に自問自答し続け、自らにプレッシャーをかけ続けなくてはなりません。
なので、プロダクトマネージャーとしての一番大事な一歩は、自分を律し、全力で「こと」に向かい続ける覚悟を磨き、リーダーシップのマインドセットで生きる。これができるようになって初めてプロダクトマネージャーになる土台ができると言えるのだと私は思います。
「正しい」仕様を書けない
新しい価値をユーザーに提供するためには、「問題定義→解決策定義→要件定義→開発」のプロセスを進めていきますが、この問題定義こそ、「正しい」仕様を書くために一番重要になります。
私は、正しい仕様とは「最も素早く課題を解決できるもの」。この素早くには、開発工数だけの話ではなく、リリースするまでの全てのコミュニケーションコストが最小化されていたり、ユーザーのオンボーディングにかかる時間も含みます。
正しい仕様はWHYと優先順位が明確である
「プロダクトをなぜ作るのか？」それは、ユーザーに価値を届け、事業として成果を上げるためです。だからこそ、どのようなプロダクトのプロダクトマネージャーでも、あなたの好き嫌いに関係なく、熱狂してくれているユーザーと同じ熱量で語り合え、ユーザーの思いや問題を代弁していかなくてはいけません。つまり、ユーザーを自分に憑依させるスキルが必要です。
さらに、正直解決すべき問題は山ほど生まれます。全てを並行して進めていくことはできないので、適切な問題に適切なリソースを投資できるように、「優先度」を切らなくては進めることができません。
優先度の精度を上げていくためには、正しく「WHY」を理解・言語化しなくてはなりません。たとえば、以下の要素の言語化が肝です。
ユーザーとなる業界、市場の特徴や最新の情報
ユーザーから見た価値を大きくさせる要素
いつ、どういったトレンドがあるのか？などの市場の流れ
競合のプロダクトが今、使われている理由や弱み、これから取ろうとしている戦略
WHYを間違えると、作ったものが意味のないものになってしまいます。それを避けるためにも、“WHY”を徹底的に具体化し、成功角度を上げていかねばなりません。 自分もたくさんのアイデアをドキュメントに書いてきましたが、開発されていないものもたくさんあります。それはシンプルに“WHY”の部分が弱く、人を巻き込めていなかったからです。WHYを語り、チームが共感でき、一緒に同じ方向を見て走らなくてはユーザーに価値を届けることはできないのです。
正しい仕様は認識齟齬が生まれない
解決すべき問題に優先度をつけることができたら、チームと共にベストな「WHAT」を見つけにいき、要件定義書やユーザーストーリーという形で、Single Source of Truth(信頼できる唯一の情報源)に落とし込みます。
ドキュメンテーションをすることは、スピードを取る中で優先度を落としがちですが、スケールさせたいのであれば、「残す」という工程は後々効いてきます。
この内容によって作るものが決まってしまうため、戦略や何が問題なのか、ビジネスロジックをわかりやすくにまとめ、チームの見ている方向を揃えるために、一言一句こだわり抜かなくてはなりません。
厳しいことを言うと、要件定義書やUI デザインは“それだけでは”何の価値もありません。誰しも、自分のアウトプットは価値あるものと思いたいでしょうし、壊したくないかもしれません。ですが、デザインというものは開発し、ユーザーの問題を解決できて、初めて価値あるものになるのです。
そして、往々にして、最初に思いついた解決策は外します。さらに、仮説的にはベストでも、技術的に実現不可能だったり、技術的負債になるような仕様を書いてしまっては、それは「正しい」仕様とは言えないでしょう。
なので、プロダクトマネージャーとして、最短で仮説検証を回す方法を考え抜き、デザイナーやエンジニアと一緒にプロトタイプを作り、あーでもない、こーでもないと議論して、正しく「why」を解決できる「What」をできる限りシャープに研ぎ澄まさなくてはなりません。
そして、コミュニケーションは大体認識齟齬が生まれるものなので、しっかり文字に残すことで、認識齟齬の種を徹底的に潰します。チームがアライン取れているか？を常に考え抜かなくてはなりません。
プロセスやルールが作れず、コミュニケーションコストを高くしてしまう
プロダクトマネージャーにはなぜ「マネージャー」が入っているのでしょうか？
プロダクトマネージャーはリーダーとして、目標達成のために必要な全てのことにコミットし、ことを前進させ続けなくてはなりません。
その意味で、プロダクトマネージャーはプレイヤーでありません。チームを機能させ、正しい方向に進んでいるのか？そのクオリティーは十分か？スピードは適切か？そういった部分をフィードバックして、チームとしてのパフォーマンスも最大化させなくてはいけません。つまり、プロダクトマネージャーはチームを、そして人をマネジメントをしていくことが求められます
しかし、自分がスタンスをもてないことについてディレクションするのは不可能です。表面ではなく、本質的な部分を理解し、議論できるレベルまで知識を持っていないのであれば、それはただの丸投げであり、マネージャーとして機能していません。クロスファンクショナルチームを率いるプロダクトマネージャーはマネジメントするために多様な範囲の知識が求められるのはそのためです。
ちなみに、Scaled Agile, Inc.が公開してるSAFeというアジャイルフレームワークでは、機能しているアジャイルチームとは以下の特徴を持っているとされています。
© Scaled Agile, Inc.
日本語にすると
明確なゴールと目的を持つ共有ビジョンにベクトルを合わせる
恥や批判を恐れることなくリスクをとれる安全な環境
迅速で効果的な意思決定を独立して行うための多様な知識とスキル
健全な対立と他人への依存を可能にする相互の信頼
品質の高い仕事を完成させることに対する、お互いと組織への責任
コミットメントを達成する
仕事が組織に与える広範な影響を理解する
仕事とチーム関係を楽しむ
一方で「The Five Dysfunctions of a Team: A Leadership Fable」よいう書籍では、機能不全な状態にあるチームは以下の状態にあるとしています
成果にフォーカスしない
説明責任を避ける
コミットメントの欠如
対立を恐れる
信用の欠如
機能不全に陥らないようにするために、気合いと根性や、リーダーシップだけでなんとかしていくのは小さいチームであれば可能ですが、大きいチームに成長させたいのであれば、プロダクトマネージャーとして、プロダクトオペレーションとして仕組みを構築することが大事です。いわゆる、KanbanやScrum, XPなどのフレームワークを活用することはこのプロダクトオペレーションの中の一つの例です。
しかし、組織は生き物なので、フレームワークをそのまま入れ込むことはできないし、状況に応じて課題は変わります。なので、フレームワークを参考にしつつも、組織の特徴を掴んで、最適化し続けなくては、仕組みによって逆に動けなくなるという問題も発生します。
大きい組織の場合、ここは１プロダクトマネージャーの範疇ではないこともありますが、プロダクトマネージャーは常にもっとも効率よく動けているのか？を考え続け、チームが働きやすく、最速で前にすすむことができる環境を作らなくてはいけません。
結論：プロダクトマネージャーとはなんなのか？
改めて、私なりの結論をまとめると、優秀なプロダクトマネージャーはリーダーとしての覚悟を持ち、意思決定をし、チームをマネジメントし前進できるようにすることで、成果を出すためにやりきっている人です。
そして、プロダクトマネージャーとして1人前になるために、乗り越えるべき3つの壁は
長い記事でしたが、最後まで読んでいただきありがとうございました。
こういった話にはたくさんの論点があると思います。意見交換できたら嬉しいので、ぜひご連絡いただけると嬉しいです。
この記事が気に入ったらサポートをしてみませんか？