PdMの責任と役割とはなにか　ラクスとLegalOn Technologiesの事例から学ぶ製品開発組織のあり方

PdMの責任と役割

川東大悟氏（以下、川東）：次にすみません、私は本日の司会を担当しています、ラクスで技術広報をしている川東と申します。よろしくお願いいたします。では3社のPdMのみなさま、ご紹介ありがとうございました。さっそくトークテーマに入っていきたいと思いますので、よろしくお願いします。

一同：お願いします。

川東：お願いします。まず最初ですね。「PdMの責任と役割」ということで何の話をするかと言いますと、ちょっと読ませていただきます。PdMの責任と役割が企業とか製品、組織フェーズによってかなり異なってくると思うんですね。先ほどのご紹介を聞いた限りでも、みなさんのPdMの出身とケースもぜんぜん異なっていたと思うんです。

このトークテーマでは、そのPdMの責任と役割に焦点を置きまして、そのプロダクト開発を取り巻くステークホルダーですね。組織の話とか、そういったものを、みなさんからお話していただけたらと思っています。

最初のインプットとして、各企業のPdMがどんな役割を担っているかという話を中心にちょっとご紹介を順番にさせていただいて、それからトークというかクロスのディスカッションというかたちで進めていけたらと思っています。じゃあ、まずはラクスのご紹介からですかね。じゃあ、稲垣さんお願いいたします。

稲垣剛之氏（以下、稲垣）：わかりました。私から当社のPdMの役割みたいなところを簡単にお話できればなと思います。

川東：お願いします。

稲垣：まずは開発の組織体制。今はPdM自体が開発の組織にいる形態を取っています。今見ていただいているのが、楽楽精算の場合で、基本的には職種別の組織で、役割別の組織を敷いているかたちで、各商材ごとでかなりこの組織の幅はあるんですけれども。楽楽精算は、今は全体で50名弱ぐらいの組織になっています。

インフラとか、デザイナーとか、フロントエンドとかは横断組織になっていまして、PdMは横断ではなく各商材にセットするようなかたちの組織形態になっています。次、お願いします。

ラクスにおけるPdMの立ち位置

稲垣：PdMの立ち位置です。当社はPdMとPMMがハッキリ分かれていて、そこがセットで動くようなかたちになっています。というのは、私が入る2年半前に開発組織にPdMが立ち上がったところもあって、それまでは今見ていただいている資料のPMM、製品企画にPdM機能があるようなかたちでした。そこに私が入って、開発側にPdMを立ち上げたので、そういった部分でハッキリ分かれるようなかたちになっています。

なので、開発側のハブになるところ、ビジネス側のハブになるところはPMMで、PMMとPdMがかなりセットになって動くようなかたちです。アウトプットでいうとPRD、製品要求仕様をPdMが作って、市場要求仕様をPMMが作ってみたいなかたちで分けています。

ただ、お客さんの解像度を上げる部分でいうと、営業側にヒアリングをかけたり、CS側に我々からヒアリングをかけるというところはやってはいるんですけど。基本的にはこういった役割で、最終的にどういったものを開発していくべきなのか、どういった方向性でいくのかは製品管理、PdMとPMMがセットで動いていくようなかたちになっています。次、お願いします。

基本的な考え方ですね。これもたぶんけっこう教科書的な部分に近いんですけど、PdMとPMMの共通部分で言うと、どういう価値が事業戦略や製品戦略上で必要なのかを共同で考えていったりとか。あとは、どの精度で、順序で取り組んでいくべきかも共同で考えていくようなかたちになります。その上でPdMがその価値をより具現化して、どのようなUI/UXでお客さまに提供するのかを担う。

PMMはその価値をどういった手段や内容でお客さまに届けるのかというところの役割分担にしています。開発とPdMの役割という部分は見ていただいているようなかたちになっています。いつまでにどういう価値や体験をお客さまに提供するのか、それをいかに効率的に作り出すのかというところは、ものづくりをしている我々組織が共通に考えている事項です。

ラクスにおけるPdMの役割

稲垣：PdMはその中でも、なぜやるのかの課題だったり、何をやるのかのスコープだったり、どうなればいいのかというゴールのところ。あとは事業・製品戦略上での優先度の提示というところはPdMが開発に共有していくようなかたちを取っています。

エンジニアやデザイナーは実現可能性の観点というところでの取り組み順の提示だったり、我々が事業戦略・製品戦略上、こういう順番でやりたい。やはり、開発の効率的には順番を変えたほうがいいんじゃないかみたいなところは、エンジニアやデザイナーから提案していただいたりとか。

あとは具体的にどういう仕様やUI/UXにしていくのか。ここの部分に関してはエンジニアやデザイナーが主体的にやっていくようなかたちになっていて、けっこう開発の中でもある程度役割分担をしっかり決めつつやっています。

逆に、けっこう定義しているので、できる範囲が限定されてしまうかなという方もいらっしゃると思うんですけれども。逆に、定義されているがゆえに専門性の部分をしっかりできるところと、特に越境してはいけないみたいなことはないので、そういう部分でいうと越境しつつ、それぞれの専門性を高めていくようなかたちで組織が組まれています。ラクスのPdMは、ざっくりとこんな感じですね。

川東：ありがとうございます。みなさん、いろいろとご質問があると思うんですけれども、ちょっとまず最初に各社の……。おぉ、もうちょっとさっそく松下さんからご質問が（笑）。

稲垣：（笑）。

川東：あとでちょっと取り上げましょう。

松下三四郎氏（以下、松下） ：あとで大丈夫です！

川東：すみません、ありがとうございます。ご視聴されているみなさんも、もしご質問がありましたらこのタイミングで書いていただけたら、後ほど取り上げたいと思いますので、よろしくお願いします。

LegalOn Technologiesにおける開発組織

川東：では次ですね、泉さま、よろしくお願いいたします。

泉真悟氏（以下、泉）：はい。じゃあLegalOn Technologiesの、まず会社の組織がどういう捉え方になっているかというところからいきますね。我々はどちらかというと会社としてはマトリクス型になっていまして、1つは事業カットですね。「こういうプロダクトを作るんだ！」というカットのアチーブメントグループとロール、職能系のプラクティスグループ。

ここに書いてある中では例えばエンジニアのWebのアプリケーションをやる人とか、プロダクトマネジメント、デザイン。そういう方たちのマトリクスになっていまして各プラクティスグループ、PGと略していますけれども、そこから各アチーブメントグループに、プロダクトごとにアサインするというかたちの組織です。次、お願いします。

我々の製品開発組織ですね。けっこういろんな役割があるんですけれども、PdMはどちらかというと、この製品開発の中心にいます。それに関連して、AI研究開発系ですね。例えば先ほどの検索もそうだし、契約書をどうやって解析するか、そういうところが研究開発的な要素の共通部分。

あとですね、これはちょっと変わっていて「法務開発（法務コンテンツ）」と書いてあるんですけど、契約書の審査をどういうふうにしたらいいんだという話だったり、それをどういう体系や分類で分けるとか。

あと、我々はサービスの中で契約書の雛形も提供しています。要は、お客さまが社内で契約書を作る時にイチから作るのは大変なので雛形も準備するんですけれども、こういう法務系のコンテンツを作るのは、どちらかというとトップには弁護士がいて、その下に関係者がいるみたいな法務コンテンツの人もいます。

あとは、データ分析ですね。KGI、KPIを立てると思うんですけれども、我々のサービスがどのくらい使われているか、そういう使用率とかKPIを測定するところで連携している分析チームもいます。こういうところとのある意味ハブになりながら、製品開発をしています。

実際に先ほどの製品開発で、アチーブメントグループ、AGにアサインされた中で、あるミッションなり、ドメインなりの機能カットで小単位の開発チームを構成しています。その中には、PdM、PMMがいる、PEMと略したりしているんですけど、プロダクトエンジニアリングマネージャー。要はプロダクトにフォーカスしているようなEMやアプリ開発のエンジニア、QAなどが含まれます。基本的にはこのチームで、この単位の企画からローンチまで完結できるような職種メンバーが集まって開発を進めています。

LegalOn TechnologiesにおけるPdMの役割

泉：次ですね。じゃあ、我々の開発フローなり、PdMの責任やロールというところでいくと、大きくはその開発でもディスカバリーですよね。お客さんのペインとかを見つけて、どういうストーリーでそのソリューションの解決を提供していくかとかですね。それで本当に課題解決できるのかとか、そういうところをPdM、あとはPMMも連携しながら課題解決を追っていきます。

次はデリバリーですね。我々PdMがPRDを作るんですけれども、それをPEMが受け取って要件定義に落として、UI/UXはデザイナーが作っています。ここは、どちらかというと先ほどのPEMが中心になってデリバリーの責任を負う大きな分担になっています。

じゃあPdMは？　というところで、ディスカバリーを中心にやっているんですけれど。まず、自分のドメイン、プロダクトで例えば新規に立ち上げたりもしますし、育てていく領域もあります。

その中で「これはちょっとビジネスサイド寄りなんじゃないか？」という話もあるんですけど。PEMの人たちと連携したりPdMが中心となったりするケースもありますが市場分析からして、どういうロードマップを敷いて製品を成長させるのか。それでKPI設定をおりまぜてやっていたりします。

ディスカバリーについては、実際にお客さまのペインを見つけて「こういうソリューションだ！」という仮説のもとで要求仕様を作ります。それをユーザーヒアリング、営業同行とか、営業の現場の実際の商談の声とかをフル活用して作ります。あと最後ですね、プロダクトのリリースにあたっても、ちゃんとQAも終わってプロダクトが出る最後まで伴走します。

そういうところは途中の製品課題で「仕様はこうなんじゃないか」というところをディスカッションしながら、けっこう最後の仕様はこうだというのはPdMが決めたりとか。あとはステークホルダーとの調整ですね。そういうところもPdMがやったりしています。

ここはちょっとPdMがけっこうオーバーラップしていてPMMというところもあるんですけど。我々はPdMのほうが人数が多くて、PMMがまだ人数が少ないので、PMMのロールをどうしていくかとか、そういう連携の仕方はパーティーとかにもよるんですけれども、こういうかたちでプロダクトマネジメントにPdMのロールを進めていますね。以上です。

川東：ありがとうございます。なんか聞きたいことがすごくたくさん出てきた気がするんですけど、いったん先に進ませていただきます。

（次回へつづく）