要件定義以降の工数は50%減少、開発ボリューム・件数は増加　PM組織立ち上げの「現状把握」「目標設定」「問題特定」で得られた効果

現状把握のために実施したこと

じゃあ、これを基に実際にどういうふうに考えてどういうところをやってきたかをこれからお話しできればなと思います。

まず現状把握です。（スライドを示して）今見てもらっているのが、これまで自分が体験してきたり、ほかの企業の方との情報交換とかで出てきた、製品開発におけるよくある問題だと思ってもらえればと思います。みなさんもたぶん、これまでの経験の中で、こんな声や課題は、かなりあったんじゃないかなと思っています。

前職のECの経験でもこのあたりはありました。例えばシステムが肥大化して品質維持のためにかかる工数が多くて、「新規機能開発になかなか時間がかかりますよ」となったり、事業部とかから要望、HOWの指定がけっこう多くて、顧客の課題がぼんやりしていたり。

あとは、ビジネス側からすると、思ったとおりのタイミングでリリースできないことがあるとか、もっと多くの要望を実現したいかなというところが不満としてあったり。

どこの会社さんでもこういった課題はたぶんあるのかなというところで、このあたりをぼんやりと頭に入れながら、仮説を持って現状把握に臨んだようなかたちになります。

実際に現状把握はどんなことしたのかというと、入社した直後から、プロダクトチームとか、そこに関連しそうな組織とかチームのキーマンに、自己紹介を兼ねてとにかく1on1的な感じでヒアリングを実施しました。

（スライドを示して）共通して（相手に）聞いたのは、一番上に書いてあるとおり、その組織のミッションと、組織の役割とか課題、あとは製品開発の課題とか、プロダクトマネージャー組織への期待。あとは、開発とビジネス側の連携課題を、それぞれの側面にヒアリングしていくようなかたちを取っていきました。

入社してだいたい2週間ぐらいで、課長職だったりリーダークラスの10人以上のキーマンにヒアリングをするようなかたちを取っていきました。

ヒアリングをする時のコツとしては、相手によって、課題とか意見が出てくる人もいれば、なかなか出てこなかったりするところもあるので、自分の体験を基に、「一般的にはこういうことがあるけど、どうですか？」みたいな感じで聞くと、話しやすかったり意見が出てくるようだったので、そのあたりはかなり意識をしながらヒアリングをかけました。

現状把握で出てきた課題と意見

（スライドを示して）実際に出てきた課題と意見がこういったかたちになっています。ポジティブな部分、ネガティブな部分、それぞれ書いています。

ポジティブな部分でいうと、初期のヒアリングは、（自分がこの会社に）来たばっかりだったのであまりピンとは来ていなかったんですが、2年経った今振り返ると、このポジティブな意見は、あらためて実感できるかたちになっています。

ネガティブな部分でいうと、一般的に一定規模の製品開発のよくある問題と大きな差はないような感じで、15年弱運用してきて一気に成長したサービスならではの課題が出てきた意見になります。

目標としてどのようなものを設定したか

続いて目標設定です。先ほど現状把握でヒアリングをしたんですが、目標設定、つまり、あるべき姿を定義しないことには、ヒアリング内容の課題が問題であるかがはっきりしない。出てきた課題を片っ端から対応するわけにもいかないので、目標設定とあるべき姿をこのタイミングで設定したようなかたちになります。

実際に何から決めたかですが、これも特段変わったことはしていなくて。いわゆるMVV、ミッション・ビジョン・バリューの設定と、あとKGI・KPI／コンテキスト、どういうあり方でいくかのような、定性的な状態を決めました。MVVでいうと、まずミッションを決めて、その後にコンテキスト、どういうあり方かを決めていったようなかたちになります。

決める時に注意・意識した3つのこと

（スライドを示して）決める時に注意・意識した点としては書いてある3点で、どれも最初から確定するのはかなり難しいので、変化を前提に1度決めたようなかたちになっています。

今ある情報からなぜそうしたのかは、しっかり説明できるような状態で決めました。特にKGI・KPI／コンテキストは、いきなり理想で決めちゃうと現在の距離から遠すぎたりもするので、そういった部分では段階を踏んでいくようなかたちで、コンテキストとKPI・KGIを設定していきました。

初期は変化をもたらすことが重要なのかなというところがあるので、とにかくメンバーの強みを活かして変化や貢献できるもので設定したかたちになっています。

具体的に設定した目標

（スライドを示して）具体的に設定したものがこちらになります。ミッションとかビジョンとかは途中で変えたりもしましたが、現状としては、このようなかたちです。KGI・KPIは具体的に載せてはいませんが、方針やコンテキストとしては、ここに書いてある内容を取っています。

初期の時点では、時間軸は明確にしていませんでしたが、ここに書いてあるステップ1、2、3と進めることを開発内にも共有するようなかたちを取って、ほかの組織から見ても「こういった順番で解決していくんだぞ」というところがわかるようにしました。

プロダクトマネージャー自体が開発組織に所属しているので、まずは開発組織への貢献に一番意識を置き、その後に事業部側、先ほどもあったPMM（Product Marketing Manager）側が、よりGo To Marketだったり事業戦略に集中できるような環境を提供しました。

この2つでも製品への貢献はできるんですが、最後のステップ3としては、直接的に顧客製品への貢献ができるような3ステップを踏むようなかたちをあらかじめ見せることで、期待値がある程度コントロールできるかなと。こういったかたちで、開発部内、全体に対しても見せていくようなかたちを取っていきました。

ヒアリングすると「ヒアリングした内容を改善してもらえる」という意識がどうしても働いてしまう感じがあるので、期待値はコントロールしていく必要があるかなというところで、こういったかたちを見せていきました。

ヒアリングの分析から問題の特定へ

続いて、問題の特定になります。（スライドを示して）各ステップでのポイントは、こういったかたちになっています。現状把握で聞いたのはあくまで課題で、ここからはあるべき姿を設定したので、そことのギャップにフォーカスをして、ヒアリングの分析をして問題を特定するようなかたちを取っていきました。

ここでもヒアリングはするんですが、実際の事実をあらためてしっかり確認していくようなかたちで、それぞれのステップで進めていきました。

解決策の立案、実際に実行した8つのこと

（スライドを示して）じゃあ、これを基にしてどういう解決策、立案と実行したのかが、こんなかたちになっています。

解決策を立案、実際に実行したというところがこちらになっています。これ以外にもかなりいろいろ実施したり、やってみたけどやめたものだったりもあるんですが、大きくこの8つがやったことになります。

まず、ステップ1の開発組織への貢献という部分でいうと、上に書いてある2つの部分。開発部内での役割とプロダクトマネージャー自体の役割は、会社によってもかなり違ったり、求められるものも違ったりするので、まずここをしっかりはっきりさせることをしていきました。

2番の部分です。これまでPMMがPRD（Product Requirements Document）を作っていたんですが、ここをプロダクトマネージャーがしっかり作成するようにするところもやったことの1つです。

PMMの観点とプロダクトマネージャーの観点でPRDを作ってみると、開発向きに説明できるかでけっこう質も変わってくる部分があるので、これをやったことで、より開発の要件定義以降のフェーズも効率化を進めることができたかなと思っています。

次に、ステップ2の事業組織への貢献でやった部分でいうと、3番のPMMとプロダクトマネージャーの役割分担もしっかりやっていきました。

実際にどういった開発案件をしていくかの決定フローもしっかりPMMと相談をしながら決めていきました。基本的には、プロダクトマネージャーのほうで案件創出を担うように切り替えていったようなかたちです。

最後のステップ3の部分ですが、顧客や製品への貢献という部分。ここでいうと6番目、7番目、8番目です。

プロダクト開発計画の策定というところで、年間でどういった開発を進めるのかが当初はそこまで明確にはなっていませんでした。これが明確になることでより開発が進めやすかったり、開発効率が上がっていくというところもあるので、そういったものを策定するようにしていきました。

あとはプロダクトマネージャーの顧客解像度というところ。こちらも当初はあまりなかったというか、二次情報をもらってというところが多かったので、ここの解像度を上げることで、より価値につながるような製品要求が作れるのかなと。ここに関しても、実際に行動を起こしていったようなかたちです。

最後の8番目、ここはまだこれからやっていくような項目です。今もできてはいるけど、もっと洗練させていくような項目として、機能・製品の改善プロセスというところも、今後はしっかりやっていこうかなというかたちになっています。

解決策を実行して得られた結果

今のような解決策の実行をやっている途中ではありますが、実際にどうなったのかになります。

（スライドを示して）プロダクトチームとしては、現在はこうなっています。プロダクトマネージャー、PMMがそれぞれ開発側とビジネス側のハブとなるようなかたちになっています。それぞれの役割としては、プロダクトマネージャーはお客さまにどういう価値を提供するか、さらにそれを作るかというハブの部分。PMMはその価値をどうお客さまに届けるか、伝えるかというビジネスサイドのハブになる部分で役割を定義しています。

成果物は、プロダクトマネージャーとしては製品要求仕様、PRD、製品企画。PMMとしては市場要求仕様、MRD（Market Requirements Document）の作成というところを、それぞれのアウトプットとして分担していくようなかたち。つまり、それぞれの専門性が高まる部分を作っていくようなかたちで、プロダクトチームの役割を再組成しました。

事業・製品状況はどうかというところです。基本的にこれまでと変わらず順調な状況になっています。

開発項目についても、これまでよりもより事業インパクトが大きいものが増えたところは良かったかなとは思っているのと、開発ボリュームや件数も、それまでよりも増加はできたかなと思っています。

（スライドを示して）その他、副次的な効果としてどんなことがあったのかを4点書いています。まず開発効率の部分ですね。要件定義フェーズ以降の工数が50パーセント。PRDを読み解く部分だったり、手戻りが発生しなくなったので、ここの要件定義以降がかなりスムーズに進むようになりました。

あと、開発項目の優先度が属人化している部分があったところも、かなり見直しをかけたので、事業部側、開発側で認識の齟齬も基本的には起きないようなかたちにできました。

あと、それに伴って、システム改善も、生産性を上げるような開発にも着手ができるようになっているような状態です。

あと、今まで話していたんですが、プロダクトマネージャー組織はもともとは3名でしたが、現状は6名というかたちになっていて、採用応募としてもプロダクトマネージャーの役割がどういうものかの解像度をしっかり提示することができたので、そういった部分でも応募が300パーセント増と、かなり増えたようなかたちになっています。