専門用語が1つも分からない。そのときPdMは何をKPIにするか？「会話時間」から始まる信頼構築の3フェーズ
こんにちは、株式会社ラクスでプロダクト部 部長をしている稲垣です。
これはpmconfの動画やスライドを見て、自分なりの感想や考え、あるいは今のラクスのプロダクト部に適用できそうなことをまとめた、シリーズでのnote企画の第十弾です。
はじめに
第十弾は、
「知識の非対称性を越える ― PdMがエキスパートと築く、信頼と対話の『意思決定の技術』」
登壇者：
・坂田太駿さん 株式会社enechain テクノロジー本部プロダクトマネジメントデスク シニアプロダクトマネジャー
坂田さんは新卒以降、エウレカやメルカリなどtoCサービスを中心にPdMをやってきた方。それが2024年にenechainへ入り、電力卸取引という極めて専門的な領域に飛び込みました。今回の発表は、その圧倒的な知識差の中でどう戦ってきたかの記録です。
※先日、坂田さんとお話しする機会がありました。
発表の核心を一言で
「分かってないものを分かったと思い込んで進めるのが、いちばん危険」
enechainは電力の卸取引マーケットプレイスを中心に、電力業界向けサービスを展開している会社です。電力価格の激しい変動を、事業者にヘッジ取引の機会を提供することで安定させる。そういう事業です。
坂田さんは発表の中で、仕様書のごく一部の概念説明を会場に見せました。そして「あんまり分からないと思うんですね」と言います。自身もプロジェクトに入ったときは、単語も分からないし何をしたいのかも全く分からない状態だったと。
知識もない、そのプロジェクトでの信頼もない。だからPdMとして意思決定できる余地がほぼない。ここからのスタートでした。
この状況を、坂田さんは3つのフェーズに分けて整理しています。知識ギャップがありすぎて議論ができない段階、議論はできるが詳細がすり合わない段階、そしてすり合ったはずの内容が実は違っていた段階。それぞれで「信頼」と「対話」と「意思決定」の関係が変わっていく、という構造です。
フェーズ1：KPIは「会話する時間」
まず驚いたのが、このフェーズで坂田さんが自分に課したKPIです。
会話する時間。
進捗でも成果でもなく、エキスパートと会話した時間を指標にした。恥ずかしがらずに図々しくエキスパートの時間を取って、教わる。そういう時期を意識的に作ったという話でした。
ここで坂田さんはAIについても触れています。今なら複雑な用語をAIに解説してもらうこともできる。でも、その用語が使われているコンテキストが違ったり、「このケースではこう見なければいけない」という業界固有の勘所は、AIを100%信じられるものではない。だからエキスパートの時間をもらって確認する。
そしてこの「教わる」という行為が、単なるインプットで終わらないのがポイントです。理解した自分を見せることが信頼の獲得につながり、学んだことを周りにシェアして暗黙知を言語化して整理すれば、それ自体がチームへの貢献になる。
信頼はゼロイチの構築フェーズ。意思決定は焦らず、自分の限界を見極めて土台を整える時期。この割り切りが潔いと感じました。「まだ意思決定しない」と決めることも、PdMの判断のひとつなのだと。
フェーズ2：具体と抽象の「中間物」で暗黙知を引き出す
議論ができるようになると、次の壁が来ます。議論はできるのに、詳細がすり合わない。
坂田さんが挙げた例が分かりやすかったです。「書類の処理フローは、作成して承認・企画ができればいいんですよね」という抽象レベルでは合意できる。ログが残ればOKですね、と仕様策定を進める。ところが後から「企画されるパターンって全然違うものもあるけれど、この値だけ直したいときって複製できるんでしたっけ？」と言われる。そういうユースケースがあったのか、と。
抽象的な言葉では概念的に理解して合意できていても、具体的な挙動に落とし込んだ瞬間にズレが露出する。この構造は、業務プロダクトを作っている人なら誰でも心当たりがあるはずです。
ここで坂田さんが打った手が、具体と抽象の中間になるものを作ることでした。全体図やフロー図を作って要素を洗い出し、叩き台としてエキスパートに当てる。
フェーズ1の勉強会形式だと、エキスパートが主体で話すので「頭の中でメインになっているもの」は出てきます。でもイレギュラーなケースや、エキスパート自身が想像しきれていなかった部分は出てこない。叩き台があると、そこを起点に分岐やレアケースの話が引き出される。
実際に見せていた成果物は、1つの値のパターンを細かく分けた表、卸取引の売り買いパターンを整理して「このパターンはやらないよね」まで明示した図、1つの業務のステータス遷移を細かく書き出したフローなど、かなり地道なものでした。
このフェーズでは信頼が「拡大」します。作った中間成果物はチーム内の認識をすり合わせるツールになり、後の開発工程でも役立つ資産になる。そして整理ができてくると「このパターンは相当レアケースなのでフェーズ1から落としましょう」という優先度の意思決定もできるようになる。
最も刺さったポイント：フェーズ3の「ズレの出し方」を設計する
このセッションで一番持ち帰りたかったのが、フェーズ3の話です。
丁寧にすり合わせても、後半で必ずズレが出る。「このパターンってないんだっけ？」「あ、この間の図で整理したけど入ってなかったですね」というやりとりは、ドメインを問わず起きます。enechainのケースでは、整理したタイミングから営業活動を通じて要件が変わり、それが反映されずパターンから漏れた、ということがあったそうです。
ここまで来るとPdMはPRDのオーナーです。つまり、これまで「教わる立場」だったのが、自分からズレを指摘し修正していく立場に変わる。だから、信頼が崩れやすいフェーズなのだと坂田さんは言います。
この指摘に唸りました。信頼を積み上げてきた先に、信頼を失いやすい局面が待っている。しかもそれはPdMが役割を果たそうとするからこそ訪れる。
対策として挙げられたのが、人ベースではなく成果物ベースですり合わせることでした。成果物を定義し、レビューのタイミングを明確に設けてアサインする。
坂田さんの説明で特に共感したのが、この精神面の話です。進捗確認ミーティングの途中で「あれ、ここの仕様漏れてない？」と言われたり、Slackで唐突に「これってこういうパターンないんでしたっけ？」と来ると、受け手にとってはネガティブなサプライズになる。でもレビューのタイミングが明確に設けられていれば、ズレを出すこと自体がポジティブに捉えられる。
「ズレは出るもの」という前提に立ち、そのズレをどう生み、どう扱うかをPdMがコントロールする。同じ指摘でも、いつどこで出すかで受け取られ方が変わるという話は、仕様レビューに限らずマネジメント全般に効く視点だと思いました。
そしてこのフェーズの意思決定は、PdMが1人でポンと決めるものではなく、ズレの発見を通じてチームでブラッシュアップし、納得度の高い結論に持っていくものになる。信頼を「維持」しながら品質を上げる、という整理です。
この整理の強さと、残る問い
3フェーズの構造の強さは、「信頼」という曖昧なものを、フェーズごとに違う課題として扱えるようにしたことだと思います。獲得する、拡大する、維持する。それぞれで打つべき手が違う。この解像度があれば、自分が今どこにいるのかを確認できます。
坂田さん自身も最後に「図で整理して、人から教わって、レビューしましょう、というある種かなり当たり前の話」と認めていました。その誠実さが、逆に説得力になっていたと感じます。
一方で残る問いもあります。この3フェーズを進むには、それなりの時間が必要です。フェーズ1で「KPIは会話時間」と割り切れたのは、組織がその時間を許容したからでもある。短期の成果を求められる状況で、新任PdMにこの助走をどう確保するかは、本人の努力だけでなくマネジメント側の設計の問題でもあります。これは自分の側の宿題だと受け取りました。
ラクスへの示唆
私がラクスのプロダクト部として持ち帰った問いは2つです。
「新しくドメインに入るPdMに、教わる時間を正当な仕事として与えられているか？」
楽楽精算や楽楽明細のような業務プロダクトは、税法や電子帳簿保存法への対応、企業ごとに違う経理・請求の実務といった深い専門性の上に成り立っています。電力卸取引ほど特殊ではないにせよ、新任のPdMやデザイナーから見れば十分に高い壁です。
坂田さんの「KPIは会話時間」を自分に引き寄せると、これは組織側の問いになります。入って間もないメンバーが業務のプロに時間をもらい続けることを、遠慮せずできる空気になっているか。そして「分かったふり」をせずに済む状態を作れているか。オンボーディングの設計として、ここは伸ばしていける余地があると感じました。
「私たちは、ズレの出し方を設計しているか？」
これはもっと日常的な話です。仕様の抜け漏れや認識違いは必ず出る。問題はそれがいつどこで発覚するかで、進捗会議の雑談やSlackの唐突な一言で出てくると、指摘した側もされた側も消耗します。レビューのタイミングと成果物を先に定義しておくだけで、同じ指摘が「事故」から「予定通りの発見」に変わる。今期テーマの「スピード感」は、こういう摩擦を減らす設計の積み上げでも作れるはずです。
そして坂田さんの締めの主張、AIが正解を出せない領域こそPdMの価値が出るという話は、楽楽シリーズにも当てはまります。会計・税務・企業ごとの運用が掛け合わされた領域は、一般論では答えが出ません。そこに向き合えることを、むしろ面白がれる組織でありたいと思います。
まとめ
知識の非対称性は、専門領域のPdMだけの話ではありません。転職しても、異動しても、新規プロジェクトに入っても、誰もが最初は分からない側に立ちます。
このセッションが示してくれたのは、その状態を恥ずかしがらずに引き受け、教わる時間をKPIにし、図を作って暗黙知を引き出し、ズレの出し方まで設計するという、地道で具体的な手順でした。
分かったふりをしないこと。それが専門家と対等に議論するための、いちばん遠回りで確実な道なのだと思います。
以上、シリーズ10本目でした。
ここまで読んでくださり、ありがとうございます。「専門性の高いドメインで、PdMがどう信頼を獲得していくか」という問いに、ラクスのプロダクト部もいま向き合っています。こうしたテーマを一緒に面白がれる方と、ぜひ一度お話ししてみたいです。
ラクスの開発組織やカルチャーは、こちらから覗いてみてください。
