PdMのディスカバリーフェーズにおける重点領域
川東大悟氏（以下、川東）：では、次ですね。稲垣さん、ありがとうございます。「案件に寄りけりだと思いますが、ディスカバリーで一番時間をかけているところはどこですか？」。これはLegalOnさんのですね。
稲垣剛之氏（以下、稲垣）：そうですね。私から質問させてもらいました。
川東：（スライドは）このへんですね。
泉真悟氏（以下、泉）：我々は今けっこうお客さまの現場でどういうふうに使われているかとか、そういうところの仮説ですね。その仮説が正しいかどうか、そこを掘り下げるところにけっこう時間を使っていますね。
やはり法務業務というところで、例えば法務の人がどういうふうに契約書のレビューのチェックをしているかとかを弊社にいる弁護士に聞いたりします。あと、いろんなお客さんからアンケートを取ったりして、その課題抽出で、そこの解決策がいいのかというところは、やはり一番力をかけているかなと思いますね。
ディスカバリーでは実際にPdMが中心にはやっていますけど、そういうドメイン理解。けっこう業務がわからない開発者もいるので、そこのコミュニケーションも取りながら、ディスカバリーのところでどういうふうなことをやっていけばいいかを掘り下げることが、やはり注力ポイントですかね。
稲垣：なるほど。やはりディスカバリーは、うちもPdMが重要視してやっているんですけどけっこう難しいのと、どこまでお客さまの解像度と業務をハッキリさせるかが非常に難しいかなとは思います。
泉：そうですね。
松下三四郎氏（以下、松下）：Chatworkの場合なんですけれども、スライドがほぼボカシみたいになっているので申し訳ないんですけど（笑）。ちょっと進めていただいて。
川東：はい。けっこう先ですね。
松下：最後のほうですね。
川東：これですか？
松下：この次ですね。
川東：この次。はい。ワークフロー。
Chatworkのプロダクトマネジメントワークフロー
松下：ワークフローで、これは例えばプロダクトマネージャーのメンバーからの悩みで、「いつデザイナーに相談したらいいかわからない」みたいなものがあったんですね。そういった中で物事を企画化。これはどちらかというと、施策単位のディスカバリーの話ではあるんですけれど、この縦軸はフェーズで、その時の責任者と成果物というのがあって、左は案件ごとです。
例えばUIの要素というか文言だけを変えたいとか、そういった場合は一番上の列になっていて、その下にどんどん抽象度が上がっていくテーマになっています。例えば一番下は本当にWHYみたいなところから検証したい場合に、PdMとUXリサーチャーも巻き込んで、実際にはディスカバリーを問いていくという感じになっています。なので、けっこう全社単位のディスカバリーは本当にこれから仕掛けていかないとなという感じですね。
稲垣：ここまで体系ができているのはすばらしいですね。可視化というか言語化できているのは。やはりデザイナーはどのタイミングでって、けっこういろいろ課題になる部分なので、すばらしいと思いました。
松下：スクラムとかを観点にすると、デザイナーの方がどういうタイミングで入るべきかで、けっこうロールが浮いちゃう感じになっちゃうので。
稲垣：そうですよね。
松下：やはり餅は餅屋じゃないですけど、まさに今、弊社でそういったことに取り組んでいる感じです。
川東：ありがとうございます。ちょっとこれは3つ目のテーマの仕組みのところだったんですが。ごめんなさい、そもそも今日、タイムスケジュールができていなくて申し訳ないんですけど、だいぶ時間が押しているんですが（笑）。こういったものもクロスしながら話していけたらなと思っています。ありがとうございます。
PdMとPMMの役割分担
川東：引き続きチャットのほうにいきたいと思うんですけれども。これは泉さまからChatworkさんへの質問ですね。「PMMは、いないのですか？ プロダクトマネジメントのロールは幅広いと思いますが、特にどの業務を大事にしていますか？」ということで、役割のところ。
松下：作って良かったなと思ったんですけど、ちょっとペンタゴンを出してもらってもいいですか（笑）？
川東：はい。ペンタゴンですね。
松下：作って良かった。
稲垣：ペンタゴンはわかりやすいですよね。
川東：ちょっとごめんなさい。
松下：大丈夫です。
川東：これですね。
松下：この右の市場のGo to Marketと市場分析、競合分析は、今はどちらかというとPMMが担当しています。実際にいます。LegalOnさんのようにちょっと人数が少ない状況ではありますけれども、実際にいます。もともとはプレスをどうやって書くか、お客さまにどうやって伝えようかというところだったんですけど、よりVOCをどうやってデータ化していくかだったりとか、よりそこの領域が広がってきている。
2024年からですけどプロダクトマネジメントのミーティングに参加して、もっとプロダクトバックログを理解して、いつ・何が出るかをもっと早くからわかるようにするみたいなところの仕組み化をどんどん進めているという状況です。なので、少ないけれど（PMMは）います。回答としては以上です。
川東：なるほど。大丈夫ですかね？
泉：ありがとうございます。
Growth PdM Pentagonモデルの解説
川東：じゃあですね、次もまたこれもChatworkさんへのご質問ですけど、「Growth PdM Pentagonはおもしろいですね」と。「Growth Product Managerはプロダクトマネジメントトライアングルというのもありますが……」。
稲垣：すみません、それは僕の感想です（笑）。
（一同笑）
川東：質問じゃない（笑）。
稲垣：いや、プロダクトマネジメントトライアングルはけっこう採用とかで使っていたりするんですけれども。ここまでペンタゴンの状態にすると、けっこうどこが必要だったりとか役割分担とかがしやすいなと、見て非常に勉強になりました。
松下：ありがとうございます。
川東：本当にいいですよね。持ち帰りたい。
松下：トライアングルは領域の話をしていて、これはどちらかというと行動ベースで書いていますね。
稲垣：確かに。
松下：出版者の方、今日いらっしゃいましたら書籍化したいので、お願いします。
（一同笑）
川東：いらっしゃるかもしれないですね。
（一同笑）
ラクスにおけるプロジェクトマネージャーの位置づけと役割
川東：追加で質問が来ていますね。ラクスへの質問ですかね。「PjMがエンジニアのチームに含まれていましたが、PjMのJD（ジョブ・ディスクリプション）はどんな感じでしょうか？ スキルはやはりエンジニア寄りですか？ PdM寄りですか？」ということです。
稲垣：一応組織的には……。組織の部分にいってもらってよろしいですか？ ここですね。ここの開発課の組織に存在するようなかたち。モバイル開発課を含めてという感じでプロダクトマネージャーがいるようなかたちになっています。なので、エンジニア寄りのキャリアというかたちになっています。とは言ってもPdMとの連携は強いので、やはりビジネス部分だったり事業理解というところ。
あとは製品自体の理解が必要になってきますけど、一応キャリアとしてはエンジニア側に設置されているようなかたちになっています。会社によってはPdMがプロジェクトマネジメントもやるというところでいうと、当社はハッキリ分かれているので、そういう意味ではプロダクトマネージャーとしてはけっこうありがたいというか。
プロダクトマネージャーは大変だったり、いろんなことに気を遣わなきゃいけないところがあるので、そういった部分ではプロダクトマネージャーからするとけっこうやりやすいというか、ありがたいかなという感じの役割分担になっています。
当社はアジャイルではなくて完全にウォーターフォールで開発しているようなかたちを取っています。というのは、経理の方が使うような経費精算システムをアジャイルで開発すると、お客さまの経理の方が従業員の方に説明をする時にちょこちょこ変わって従業員からいろいろと問い合わせが来てしまうと困るので。
1ヶ月前、2ヶ月前ぐらいに経理の方にしっかりとどういったものを開発、UI/UXにしていくかというところをお伝えして、その上でリリースをして、経理の方が事前に準備……経理というか情シスの方が事前にしっかりと準備をしてから製品を提供していくようにしているので、アジャイルを敷いているようなかたちになっています。なので、何だろう。かなりウォーターフォール型の部分でしっかりプロダクトマネジメントしていく必要があるというところで、そういった役割分担になっています。
川東：ありがとうございます。回答になっていましたでしょうか？
顧客へのアプローチ方法と課題：LegalOn Technologiesの事例
川東：では、ちょっと時間が押していますので、次のテーマ。そうですね。たぶん1のテーマが各社の特徴が出るところかなと思っていましたのでちょっと時間を使わせていただきましたが、次のテーマにいきたいと思います。今度は顧客にどうアプローチしているかというようなお話になっているかなと思います。
これもせっかく、みなさんにスライドを作ってきていただきましたので、お客さまとどういう向き合い方をしているのかみたいなお話を少し聞かせていただけたらと思うんですけれども。まずは泉さま、よろしいでしょうか？
泉：はい。LegalOnのほうですけれども、まずは当たり前なんですけどドメイン理解をするというところで、契約とか法務がいるところでお客さまとコミュニケーション。先方もプロなので、そういう方々とコミュニケーションをするための理解をした上でというところで、そういうのがまず第一歩です。そうしないと、お客さまのペインがちゃんと理解できないと思っています。
その上で、やはり1次情報をきちんと取ることを大事にしているんですけども。先ほどしていたようにアンケート、インタビュー、商談同席とか、それをフル活用するというところですね。ただ、我々の悩みが、法務部の業務がけっこう幅広くてエンタープライズから小さいスモールのところまであるので、ここでけっこうターゲットセグメントの課題感が違うというところがあるんですね。
それで特定の顧客に寄り過ぎずに、市場のセグメントをちゃんと切って、「こういうターゲット層だったらどうなんだ」というところの仮説検証をちゃんとまとめて、じゃあどうやってやるかというのを考えたりしている最中です。その中で課題は今につながるんですけど、けっこうその営業もセグメントも普通にやっていて、やはり目の前の商談を取りたいとなりがちなので、そういうのは我々のプロダクトのビジョンやストーリーの理解をどうしていくか。
開発のほうでもですね、やはりドメインがけっこう難しいところがある。あとはどの方面に向かってやっていくのかという、ちゃんとベクトル合わせをしていくというのが1つ。あと、我々はPRDを作るんですけども、実際にそれを受けて要件定義してものを作っていくのがやはりエンジニアサイドなので、そのエンジニアの発想とか力をどうやって最大限に引き出しつつ、何を優先するのか、採用するのか。
逆にプロダクトマネジメントで何を諦めるのかというのもけっこう大事なので、そういうところの目線合わせをしていくことが、お客さま思考の時にも選択肢も多少いるので、そこはちょっと弊社の課題かなとは思っています。
川東：ありがとうございます。どうでしょうか？ 松下さん、稲垣さん、いかがですか？ なんかこのへんが気になるぞとか、質問ですとか。もしくはその課題に対して「こういうやり方はどうでしょうか？」という提案でもいいですけど（笑）。
（一同笑）
（次回へつづく）
