今回は、株式会社ココペリでプロダクトマネージャーを務める蛭子さん（以下蛭子）に仕事内容やキャリアについて伺いました。 これまでの経験から、プロダクトの進化について深く掘り下げ聞いていきたいと思います。
営業からデジタル支援まで、なんでもやっていたのがスタートだった
-----プロダクトマネージャーとしてのキャリアのスタートについて教えてください。どのようにしてこの職業に進むことになりましたか？
蛭子：個人的な感覚値にはなりますが、「プロダクトマネージャー」という言葉というか定義が明確になってきたのが、2018年ぐらい。その前から似たようなことをやっていました。前々職では新規事業の立ち上げをうごいていて、システムの企画のところから、マネタイズ戦略、アライアンス営業から、プロダクトマネージャートライアングルの全てをやっていた気がしますね。そこがプロダクトマネージャーのキャリアのスタートと考えても良いかもと今は思っています。-----そこに至るまで、いろいろなことをやっていたのでは？
蛭子：その前はメディアのコンサルやシステムのコンサルのお仕事もしていました。ToC向けからToB向けまで、色々なプロジェクトを経験させていただいたのは今に活きていると感じます。toCでやった施策をtoB向けに応用してみたり。 あと、意外に社内ステークホルダーの動き方を変える・刷新するようなプロジェクトもすごく良い経験になってます。どういう順番でどういうふうに動けばハレーションおきずに進められるとか。華々しくは見えないですが、Big Advanceのようなステークホルダーが多いプロダクト開発を進める上で、この経験はとても役立っていると感じます。
プロダクトビジョンとプロダクト戦略に沿う進め方
-----プロダクトの開発プロセスについて説明していただけますか？どのようにしてアイデアから実際の製品へと進化させるのか教えてください。
蛭子：「起案」から「製品化」までは大きく以下の2つのフェーズに分けて考えています。
企画フェーズ：
「これいけるんじゃない？」くらいのものからスタートし、ワイがや等で煮詰めていきます。いい感じに煮詰まったら、取締役へのプレゼン（社内ではサービスレビューとよんでいます）を行い、企画をGOするかどうかの判定を行なっています。ここをパスすると、足元のリソース状況・優先順位等を考慮し、大まかなロードマップを引き、次の探索フェーズに入っていきます。
探索フェーズ：
探索フェーズは大きく3stepで動いていきます。 Step1：ユーザー課題をサービス・プロダクトで解決することができるかどうかをプロトタイプ（Figma）を作成して検証。 Step2：最低限の機能を搭載したβ版を作成し、PoCとして実際に一部のユーザーに利用いただいてFBを収集。実際にプロダクトを利用して課題解決につながっているかを検証。 Step3：Step2よりもよりプロダクト・サービスバリューがでる機能を追加し、売上・コスト含め、事業としてなりたうかどうかを検証 それぞれのStepで一定の期限を設け、次のStepに進めるか進めないか、もう一回回すかを決めていきます。
ちなみに・・・「探索フェーズ」を終えると「進化フェーズ」に入っていきます。「進化フェーズ」では、ビジネスサイドでの売上・リソース計画等もすり合わせつつ、基本的にはユーザーの声・フィードバックに忠実に従って機能開発・改善を進めていきます。
-----ここはなかなか難しい質問ですね？
蛭子：もう一歩踏み込んだ「プロダクトビジョン・プロダクト戦略の策定」や「ロードマップの優先順位の決め方」とか「開発チームとの連携・スクラムの進め方」とかまで含めて語り出すと、壮大なボリュームになりますね（笑）
ステークホルダーの緊急度や温度感を鑑みる
-----プロダクトマネージャーとして、ステークホルダーとどのように連携していますか？ コミュニケーションと関係構築のアプローチを教えてください。
蛭子：ステークホルダーも大きくは社内と社外があります。
「社内」は経営層と各事業部ですね。プロダクトマネージャーとしては、経営層からのオーダーをキャッチして今のプロダクトロードマップ・プロダクト開発に落とし込んでいくようなすり合わせを行なったり、サポートやサクセス業務の効率化につながる声を拾ってきて、プロダクト開発に落とし込んでいたりします。最近だと、生成系AIを使った機能開発やサポートの業務効率を80%向上させるような開発を行なったりしました。
「社外」はサービスによって変わってきます。Big Advanceの場合はエンドユーザーとして中小企業さまがいつつ、その手前に金融機関さまがいらっしゃいますね。双方の課題・要望を集めつつ優先順位をつけてプロダクト開発に落とし込んでいます。
関係構築の観点でいうと、全ての要望を叶えてあげれば良いのですが、開発リソースは限られているので、優先順位をつける必要があります。プロダクトマネージャーで一方的につけると色々とコミュニケーションコストも高くなってしまうので、今はそれぞれの事業部で優先順位をあげていただいた上で、プロダクトマネージャーに共有いただき、最終的な優先順位をプロダクトマネージャーで決めて動かしていますね。
ビジネスモデルからソースコードの改良まで、あらゆることが魅力
-----プロダクトマネージャーの職業について、何が一番魅力的だと感じていますか？
蛭子：明確にやることが決まっていないことですね。必要なことであればなんでもやることが期待されている。「プロダクトマネージャーのしごと 第2版」にも書かれていますよね。
-----魅力に映らない人もいるような気がしますがどうでしょうか？
蛭子：カバーする領域が広いので、自分の強みと共に、周辺を加えていく、一つに決まらないところも魅力です。時にビジネスモデルからソースコードの改良まで、あくまでそこは私は魅力だと思いますね。楽して仕事したい人には向いていないと思いますが、いかに手を抜いて組織・ビジネスが回る状態を作り上げるかに興味がある方にはとても魅力ある職業だと思います。
-----若手プロダクトマネージャーに対してプロダクトマネージャーの魅力を伝えるとするならなんですか？
蛭子：いろんな人と携わって、一丸になって作り上げていく、作ったものを最後まで届けて、お客さんが喜んでくれることが魅力ですかね。
サーバーがやばいほど使ってもらえたら、嬉しい悲鳴ですね。
プロダクトマネージャーは向き不向きはあるかもしれないですね。
ココペリではメンバーを募集しています。詳しくは以下をご覧ください。
https://hrmos.co/pages/kokopelli
