自己紹介

初めまして。株式会社ACES でACES MeetのPdM業務を担っている中川(@ShuNakagawa) です。

数年前から再開したゴルフで、フックボール（強く左に曲がるボール）に悩まされていて、ゴルフそのものが嫌いになってしまいそうです（とはいえ、ゴルフ場に行ってしまえば楽しくて、またい行きたい！と思うのですが）。仕事も出来る限り綺麗なストレートボールや、突進力の高いドローボール（緩く左に曲がるボール）で攻めていきたいです。

パットが大事？わかります。でも、私は素人ですからショットを楽しむことにします（笑）

はじめに・ACES Meetとは何か

まず、ACES Meetの紹介をさせていただきます。

ACES Meetは、書き起こしも要約も高精度なAI議事録ツールです。

AI議事録ツールは、①会議の議事録を作りたい、②会議の情報を他の活動に繋げたい、という大きく2つのニーズに別れています。

この2つのニーズは重なる部分が大きく、私たちは両方のニーズに応えられるツールにしていきたいと考え、日々開発を行っています（私は非エンジニアなので、正確には「日々開発を行ってもらっています」）。

特に、②の繋げていく他の活動は「営業活動」でして、世の中の営業生産性を大きく向上させるツールに進化させ、名実ともにAI議事録ツールからAIセールステックツールに進化させていきたいと考えています。

PdMは何をやる人なのか

さて、このブログではPdMについて書いていきますので、ACES Meetの開発におけるPdMの役割も説明します。

その前にインターネットやChatGPTにPdMの役割を聞くと、以下のようにスーパースター・こんな人いるの？年収いくらで採用できるの？と思うような広大な役割を定義してきます。

プロダクト戦略
ユーザーリサーチとニーズの把握
開発ロードマップの策定
開発チームとの協働
事業成長と収益化
ステークホルダーとの調整

特に、プロダクトを開発していく能力・スキルと、事業成長と収益化のスキルとを、同時に高度な水準で身につけることは、一般的なキャリアでは困難ではないでしょうか。

プロダクト開発の能力・スキルに限ったとしても、プロダクト戦略を立案しながら、足元のユーザーリサーチとニーズの把握や開発チームとの協働を、一人の人物が両立させ続けることは難しいケースが多いと思われます。

この様に一人でPdMの役割を取り仕切っていくのは非常に難しいと判断し、私たちは上記のPdMの役割を複数人で分担して実施することにしています。ですので、今、ACES Meetのチームには複数人のPdMが存在しており、私もその内の一人です。

恐らく、ACES Meetチームだけでなく、上記のPdMの役割を複数人で分担しながら企業・事業・チームも多いのではないでしょうか。少なくとも、厳密に全ての役割を一人で実施することは難しいと思いますので、大なり小なりは複数人で分担しているのではないかと思います。

どの様にPdMの役割を区切っているか

それでは、どの様にPdMの役割を分担・区切っているかを説明したいと思います。

大きく、A. プロダクト戦略・方針の検討に近い部分と、B. 具体的な開発テーマの検討で区切っています。

なお、「戦略」という言葉も広い意味合いがあります*1が、ACESでは「戦略＝優先順位を付けること」と定義しています。

例えば、経営戦略は「会社の成長・収益性向上のための、経営リソースの投下先の優先順位を付けること」で、プロダクト戦略は「プロダクトの成長・提供価値増大のための、開発リソースの投下先の優先順位を付けること」と考えます。

A. プロダクト戦略・方針の検討

まず、A. プロダクト戦略・方針の検討が具体的にどの様を作業しているかを説明します。

このプロダクト戦略・方針の立案は、事業全体の戦略を踏まえて、「どの様な顧客の・どの様な課題を・どの様な順番で・このくらいの経営リソースで」解けるだろう、ということを考えます。

プロダクト戦略だけでないと思いますが、戦略・方針の立案は非常に多くの情報を取捨選択しながら、それでも論理的な意思決定ができないことも多く、全ての要素を積み上げて作るものではなく、大きな要素が整合しているか・大きな方針として納得感があるかがポイントになります。

そのため、ここで想定する必要な経営リソース量は根拠があるものではないので、具体的な開発テーマ・開発計画が決まり、必要な経営リソース量が出てきた段階で、すり合わせを行い優先順位の見直しを行うことになります。

戦略・方針の検討イメージ：一見すると関係なさそうな事から、一つの方針を導き出す（ACESのコーポレートVISION）

B. 具体的な開発テーマの検討

次に、B. 具体的な開発テーマの検討ですが、開発テーマは大きく2つに分類することができます。

一つがプロダクト戦略を実現させるテーマ（B-1）。もう一つがユーザー様からのVoC*2・エラーに対応するテーマ（B-2）。

B-1. プロダクト戦略を実現させるテーマは、プロダクト戦略上で優先的に解くことになった「顧客の課題」を「どの様な業務プロセスで・どの様な機能で」解決するかを考えます。

B-2. VoCの実現・エラー対応の開発テーマは、VoC・エラーが「どこで・何が・なぜ」発生しているかを考え、不満・エラーであれば解消する仕組みを、希望であれば実現する仕組みを考えることになります。

そして、ここまで来ると必要な経営リソースが根拠のある形で見積れるので、戦略・方針の検討を行っているPdMと経営リソース・開発スケジュールのすり合わせを行います。

PdMの役割を分担してみてどうなったか

結論から言うと、複数人でPdMの役割を分担してプロダクト開発が円滑になったと感じています。

PdMの役割をプロダクト戦略の立案から具体的な開発テーマの決定まで幅広くして、一人のPdMで担当すると以下の様な不都合な事が起きていました。

PdMになるために、多くの経験やスキルが必要となり、そもそも、PdMのなり手がいない。
頭・時間の使い方が全く異なるため、A. プロダクト戦略・方針の検討と、B. 具体的な開発テーマの検討とで、何度も頭の切り替えが必要になったり、検討時間の偏りが出てしまう。
PdMに権限が集中しすぎ、様々な面で属人性が高くなってしまう。

何事も最後は誰か一人が意思決定をする必要がありますが、事業経営にはできる限り多くの視点を取り入れ、論理的・合理的にディスカッションを積み重ね、多くのメンバーの納得感を持って進めることが重要だと考えています。

実際、複数人で役割分担をするために、戦略・方針を具体的にしたり、スライドや文書を作成したしたり、メンバーに共有する活動の中で、プロダクトビジョン・ロードマップ・コアバリューなどを作ったりしました。

また、具体的な開発テーマの決定ではワークショップを実施したりするなど、様々な仕組みを作ってきました。そして、この仕組みが一定上手く回りだしてからは、チーム全体としてレベルアップできている感覚が強くなっています。

PdMの役割を分担してわかったこと

これらのPdMの役割分担を進める中で、いくつかわかった事がありますので、最後にわかった事・思っている事・今の課題を共有して終わりたいと思います。

わかった事① : 必要な作業工数の違い

1. 戦略・方針を検討するPdMの作業工数はそこまで必要ではありませんが、具体と抽象を行き来することが求められるため、進まない時は全く進みません（笑）。
逆にB. 具体的な開発テーマの決定は作業工数が膨大に必要になります。具体の世界で作業を積み上げていく必要があるので、全く進まない事は少ないですが、絶対的に作業工数が必要になります。

わかった事② : 相性が良い頭の使い方・スキルの違い

1. 戦略・方針の検討は一般的に右脳的な頭の使い方が多いと感じています。抽象的な概念で考えたり、複数の要素を統合して新しい概念を生み出すことが多く、また優先順位が論理的に決められれば良いのですが、エイヤッ!!で決める場合もあります。ですので、良い意味で真面目すぎない方が向いているのではないかと考えています。
逆にB. 具体的な開発テーマは左脳的です。具体的な目の前の課題を見つめ、具体的・現実的に業務プロセスと機能を考え、共通認識が取れる要求定義・ユーザーストーリーを作っていきます。出来る限り論理的に説明することが求められますし、真面目にコツコツと作業を積み上げられる方が向いていると考えています。

思っている事 : ACES Meetチームでの名付け方

完全にミスってしまった笑い話ですが、ACES Meetチームでは、A. 戦略・方針を検討するPdMを「左のPdM」、B. 具体的な開発テーマを検討するPdMを「右のPdM」と読んでいます。
これはPdMの役割分担を試行錯誤している際に、プロダクトビジョンや戦略から具体的な開発テーマがどの様に繋がっているかをPPTXのスライドで整理している中で、プロダクトビジョンや戦略を左側に配置し、具体的な開発テーマを右に置いていたからです。
ただし、わかった事②で記載したように、頭の使い方としては戦略・方針が右脳的で、具体的な開発テーマが左脳的で、PdMの名称と頭の使い方が逆になってしまっています。
私は密かにPPTXのスライドの左右を逆転させてやろうと目論んでいるのですが、経営会議や人事のメンバーにも共有してしまっているため、なかなかチャンスが訪れません。どうしたものか、、、といつも思っています。

今の課題 : プロダクトが成長しだしたからこその課題

PdMの役割を見直して具体的な開発テーマが決まり、開発生産性が高まってきた事もあり、ACES Meetは様々な機能リリースが実現できています。
ただし、多くの機能をリリースすればするほど、「あれ？この機能ってこちらの機能と似てない？ユーザーからするとわかりづらくない？」であったり、「このままリリースを続けるより今のUI/UXを全面的に見直した方が良いのでは？」と思う事が多く・強くなってきました。
機能が少ない段階では機能をドンドン作りリリースしていれば良かったのですが、現在では使いこなすのに時間がかかるプロダクトになってしまう懸念があります。ですが、これは開発チームが成長した事により新たに出てきた課題＝成長痛と捉えています。
この成長痛をどの様に解決していくかは、今の私たちにとって大きな挑戦です。しっかりと向かい合って、上手く乗り越えていきたいです。乗り越えられたなと感じた際には、また皆さんに共有できればと思います。