幡ヶ谷亭直吉ブログ

娘のここねと格闘するエンジニア。

pmconf 2025 に参加しました

イベント参加
pmconf 2025 に参加しました。
昨年に続き2年連続の参加でしたが、今回も多くの学びと刺激をいただきました。
カンファレンスに参加した学びをまとめます。

イベントの概要

プロダクトマネージャー⼀⼈ひとりの成⻑と挑戦が、
新たな未来を⽣み出す。
pmconfは、それを信じています。

pmconf 2025は、プロダクトマネージャーの成⻑意欲と挑戦への
熱量がぶつかり合う場へと進化します。
登壇者は、より良い未来を切り拓く挑戦のリアルを語る
参加者は、切磋琢磨の渦に⾶び込み、挑戦のエネルギーを⾼める
スポンサーは、この挑戦の場を⽀え、熱狂を共に創り上げる

そして、ここで⽣まれる熱量が、未来を動かす原動⼒となる。

引用：

2025.pmconf.jp

イベント参加の背景

セッション

pmconf2025を楽しむために

メモ

オフラインの体験の最大化
OSTをフラクタル構造として全体に展開

二本足の自由。
学んでない、楽しくないと思ったら自由に移動してOK。
PdMとして自分という顧客の体験を最大化する。
コミュニティの一員として積極的に参加。

違うと思ったらセッションを移動。
Discuss The Speakerに浸る。
ブースをめぐる。スタンプラリーを楽しむ。
登壇者も優しく送り出す。

自分の価値を最大化する意思決定。

16:00～
・枠の都合で選出できなかった強く推された登壇者のLT大会
・PMフィッシュボウル 「PMが未来に向かう、挑むって何なんだっけ？PMの未来とは」
・OST 参加者駆動型のカンファレンス

学び

能動的な参加の推進凄い。

「旗を立て、大義で語り、ストーリーで引きつけろ」──業界の常識を変えた意思決定と覚悟の舞台裏

2025.pmconf.jp

学び

共有NGのオフライン限定セッション。
実利が伴わなくてもやらなければいけないことを選択する意思決定。
そして、いかに自分たちの目的としていけるか。
外発から内発に。管理と委譲を。迷いには旗を。
公開NGでしたが勉強になりました。

「語られた戦略」を「語れる戦略」へ──共通言語をつくるPdMの試み

2025.pmconf.jp

speakerdeck.com

メモ

どうしたら経営と現場をうまく繋いでいけるか。
経営戦略における壁。聞くと理解するでは大きな壁がある。
ビジョンミーティングという会話の機会があるが、
理解はしていても人に対して説明できるほどの解像度では理解できていない。
資料を作り込んでもうまくいかなかった。
受け取り方の差分を掘り下げていった。

コドモンが大事にしていること。
業務効率化よりすべての先生に子供と向き合う時間とこころのゆとりを。

事業。
教育・保育領域の多様なステークホルダー。
子供の育ち・学びを支えるためにデジタルでつなぐ。

戦略の理解ブレがおこる3つの要素。
横軸：価値提供の違い
縦軸：レイヤーの違い
奥行き：歴史・成熟度

・価値提供の違い
保育・学童などそれぞれ価値観が違う。
何を優先すべきかが領域ごとに違う。

・レイヤーの違い
事業（Biz/経営）：優先度→事業KPI・成長
プロダクト（PdM）：一貫性→長期価値・体験
開発（EM/エンジニア）：安全性→実用性・負債・品質

・歴史・成熟度の違い
成長フェーズ、意思決定の歴史、入社時期。
それぞれ持っている理解が違う。

ずれを可視化する仕組みを作った。
マネージャー、テックリードで理解のずれを発見する場を設けた。
理解できていないことを否定しないことを重要視した。

ズレの発見→整理→再編集の起点をつくる最小プロセスを作った。
1. 心情の発散：どこになにを感じたかを発散
2. 全体への観点：組織を伝えるときに困りそうなことを洗い出し
3. 話者への転換：自分が伝えるとしたらどのような観点を盛り込むか
4. 再編集：3までの内容を基に戦略資料をアップデート

再編集した戦略を開発部向けに再共有した。

読み合わせ：ズレ発見。
開発部向けに再共有：ずれを回収。組織のストーリーに統合。

説明する人を増やすことで組織の地盤が変わっていった。
継続して向きあうテーマ。North Star再定義。指標や基盤の再構築。

なぜ時間をかけるのか。
・誠実でありたい
ズレを放置することは負債を積み重ねることと一緒。
そうならないためにも前提を揃える。
・PdMとしての意思
自分達がどんな組織でありたいかの価値観

学び

娘の保育園でコドモンを利用しているためセッションを楽しみにしていました。
エンジニアとしてプロダクトやプロセス、仕様について語れることの重要性を感じています。
ただ、それを事業活動まで捉えることができていなかったと気付けました。
そして、与えられたものをこなすのではなく、自分たちのものとするために自分たちで語ることが重要であると感じました。
娘は来年の3月で保育園を卒園します。
今の園に入ってからは毎日何があったかの文章と写真が届き、コドモンからの通知を楽しみにしていました。
それが来年三月に終わってしまうと思うと寂しく感じます。

その決断、バイアスでは？──「思い込み」を乗りこなし、未来に挑む意思決定術

2025.pmconf.jp

メモ

バイアスとは？
SAASでの80%の機能は使われない。
ただ捨てるのは難しい。LOSS AVERSION BIAS。

認知バイアスとは？真実をゆがんで捉えること。
バイアスはバグではなく、フィーチャーである。
バイアスによってリスク管理、エネルギー節約、社会的結束を行う。
生きのこるために脳は正確さよりも、判断の速さを優先するように進化した。

プロダクトマネージャーにとって、決断疲れと時間不足がバイアスを招く。
Build-Measure-Learnサイクルでのバイアス。

レピュテーションバイアス。
未完成を出すことを恐れるバイアス。
今までやってきたことを守ることに捉われる。
それに対して、プロセスアップデートや、機能の小分けリリースや、メトリクスの変更行った。

サバイバーバイアス。
成功事例を重視し、そうではないものを軽視するバイアス。
ヘビーユーザーの声に対して偏重しがちだった。
それに対して、離脱ユーザーへのインタビューなどを行った。

確証バイアス。
データでなにがしかの分析結果を導きたくなる分析。
データを十分に長く拷問すれば何でも言わせることができる。
Data Justifiedのバイアス。Data Drivenにしていくことが重要。

コンコルド効果。
サンクコストバイアス。これだけ作ったからとリリースを強行する。
撤退基準を決める、ゼロベースで価値を再評価する、捨てることを評価する文化をつくる。

バイアスは人間の仕様。無くすことはできない。
プロダクトマネージャーに必要なのは自覚とふりかえり。

学び

バイアスを事前に知っておくことで対策ができる。
特に一度作った機能は取り消すことが難しいからこそ、バイアスからの影響を押さえ判断することが重要と感じました。

なぜ使われないのか？──定量×定性で見極める本当のボトルネック

2025.pmconf.jp

speakerdeck.com

メモ

任せられるプロダクトとは。
使いやすいプロダクト：ユーザーが迷わず操作できる
任せられるプロダクト：ユーザーが業務を任せることができる

AIを導入しても、確認工数が残り大きな効率化にはつながらない。

任せて使うことのハードル。業務を任せて使われるとは？
・業務リスクをユーザーが受け入れること。欠品リスクや過剰在庫リスクなどを受け入れてもらう必要がある。
・今まで培ってきた業務のアイデンティティを失うこと。
・欠品や在庫金額への考え方はユーザーによって大きく異なる。
・心理的・実利的ハードルの個人差が大きく個別分析が必要となる。

ユーザーに直接理由を聞いても表面的な回答しか得られない。
事前に定性・定量での仮説を構築することで、正確なユーザー理解に繋げた。
事前分析：定性・定量両面でユーザーごとに詳細に情報を把握。ドメインエキスパートと仮説構築。
ユーザーヒアリング：ユーザーは個別のファクトは正確に答えられる。その回答から抽象的なインサイトに昇華。
個別の分析を繰り返していくと、ユーザーのみ知る情報や店舗属性ごとの運用・課題が判明した。

n1分析なぜできないのか。
コストが高く他の業務が忙しい中で時間が取れない。
ROIのReturnは業務の効率化（コスト削減）ではなく、深いインサイトによるプロダクト価値の飛躍。
誰もがN1に関心を持つ組織にすることがディスカバリーの要。

学び

医療領域で業務を任せてもらうことの難しさを知りました。
また、n1分析が今の時代だからこそできるようになるイメージが持てました。
顧客課題を理解し、アプローチしていく。

Noを伝える技術2025: 爆速合意形成のためのNICOフレームワーク速習

2025.pmconf.jp

speakerdeck.com

メモ

youtu.be

speakerdeck.com


理論編。
Noと思ったらまずNotで考える。
Not Now。Not That Way。Not This Product。Not Aligned with The Vision。
ただ、Notは強力だが、万能ではない。
材料整理が下手だと精度が落ちる。合意形成には軽い。政治や感情に流される。

より重厚な説明責任が発生する場所でも活用できるようにNICOフレームワーク。
直感：Notでの分解
ロジック：3C
ストーリー：NICO

3C。素早くやる。
状況（Context）：何が起きているかを確認
対比（Contrast）：背景を数字や因果で見せる
帰結（Consequence）：Yes・Noそれぞれの影響を確認する

NICO。しっかりやる。
相手の世界、自分の世界を踏まえて整理する。
N（Need）：依頼者が期待したいニーズ・期待
I（Insight）：データや定性調査から得た事実や洞察
C（Choice-of-No）：Noの根拠とその代替案
O（Outcome）：Yes・Noそれぞれの判断によって守れる価値・得られる効果

相手に対して何をどうすればYESとなるかを示すのが重要。

実践編。
Noと言わずに作ってしまうと長期的に開発費用がかさむものもある。
営業が売れるといったものが売れる訳ではない。
期待しているインパクトとユーザーストーリーの深いところにあることの差分。
モックアップを通した検証で顧客が利用するかどうかを確認する。
Noを伝える技術だけではなく、Noの根拠を疑う技術も重要となる。
もとのINPUTが正しくないと、誤った結果となる。

学び

にこにこするためのNICOフレームワーク。
理論編ではその場でフレームワークを実践するまでの理解は難しかったですが、実践編で具体的なお話をお聞きし活用のイメージを持てました。
そして、『学びのデザインパターン』のPMJamの方たちの対話も味わうことができて嬉しかったです。
『Noを伝える技術』を読んで理解を深めます。

壁と資産をどう活かす？大企業でのPdM奮闘記

2025.pmconf.jp

学び

好きな領域に入るからこその原動力と、組織を変えていくための強さを知りました。
価値実現のために既存のやり方を変えていくことは大変そう。
ただ、小さい成功を積み重ねていくことで文化を変えていけるイメージを持てました。

LTセッション

2025.pmconf.jp

顧客の声 VS 未来に挑むプロダクト戦略

メモ

・PMとしての悩み
プロダクトは良くなっているが、要望対応の積み重ねでプロダクト改善できていない。
そもそもの顧客とは？

・そもそもどんな顧客？赴任の業界について
顧客数が少ないため構造的に個別カスタマイズが一般的。
車輪の再発明が起こりがち。

事業的には子を望む人が報われる数を重視している。
つくりたいものはいっぱいある。

・要望対応と仕込みのバランス
基本的には仕込み重視。
定性と定量での相場観と革新性で判断するようにした。

未来に挑むプロダクト戦略を重視。
顧客の要望は相場観と革新性で判断。
顧客の声には真摯に向き合い判断をする。

学び

改めてコンテキストによって求められるマネジメントの在り方が変わることを理解しました。
自分達のコアな価値を実現することと、顧客要望についても分解し扱うことの重要性を学びました。

Howを真似るな、原理を移せ！他社事例を“自社仕様化”して成果に繋げる技術「iRAFT」

メモ

他人の成功事例はそのまま真似てもうまくいかない。
iRAFT法。
まずは自社理解から始める。
・insight：顧客心理
・result：達成したい結果
その次に他社理解をする。
・abstract：成功原理の抽象化
適合検証をする。
・fit：適合確認
・test：検証と学び

この5つの視点を丁寧に扱う。

学び

5つの観点が参考になりました。
他人の成功事例を取り入れての失敗を防ぐだけでなく、自分たちでは無理だと思って控えてしまうような事例にも適用できないか試してみたい。

PdMの「責任感」がチームを弱くする？「分業型」から全員がユーザー価値に本気で向き合う「共創型開発チーム」への変遷

メモ

PdMの強い責任感がチームの成長を止めているとしたら？
PdMが頑張り過ぎる代償。
・主体性の消失と社内受託化
・PdMがボトルネック
・再現性のない脆い組織

共創型開発チームを目指した。
チーム全員で最高のユーザー体験とプロダクトを作り上げるチーム。

大きく変えたこと
・開発スタイル・MTG形式
・プロダクトレビューを増やし、PdMの観点をインストール
・PdMは方向性策定・レビュー・リリース判断に集中

結果、デリバリーのスピード向上。リリース後の障害・不具合減った。
チームで良いプロダクトを作っている感が醸成。

学び

自分達は開発者内で出来上がった機能のデモ・共有していますが、そこにPdMが加わる重要性を感じました。
実際のプロダクトの操作を通してプロダクトに対する認識をすりあわせたい。

既存プロダクトを超えていく〜医療AIパートナーユビーの軌跡〜

speakerdeck.com

メモ

新プロダクトは生成AIベースのチャットボット。医療AIパートナー。
既存プロダクトはグロース済み。
新規プロダクトはこの価値を広げて再定義する位置づけ。
そのために、
深化：既存プロダクトのKPIで上回る
拡張：新しい価値を作る

一定の期間を深化に時間を割いた。
コア価値見えるまで深化に振った。深化は客観的・相対的。
共通言語でポテンシャルを語れる状態をつくった。

深化で得たもの。
・集客の加速
・投資量の加速
・長短の明確化
・全社浸透・モメンタムの加速

推進するには胆力が重要。

学び

新しいプロダクトを開発するうえで、深化がプロダクト実現に向かっていく土台として重要だったイメージを持てました。
生成AIが開発を加速させるからこそ、土台が重要となるイメージも持てました。

エンジニア・デザイナー出身PdMが活躍し、プロダクトの増減に柔軟に対応可能な組織戦略

メモ

エンジニア * プロダクトマネジメント。
現在に至るまで計4名PdMを採用している。

プロダクトチーム全員でカスタマーサクセスを実施している。
CSは顧客のAS-IS、TO-BEを考える。エンジニアでもやるべき。
製造業は複雑なドメインだがCSを実施することでキャッチアップできる。

プロダクトチーム全員でPRDを書いている。
作る人・考える人に分かれず、全員で考えている。
エンジニアが行うことで直接のフィードバックを得ることができる。

日常的にテクノロジー、事業、UXを学んでいる。
結果、
・プロダクトマネジメント業務を柔軟にスケール可能に。
・AI駆動開発のデリバリーの速さの中で、ディスカバリーの速さを実現。

学び

エンジニアのプロダクト領域への染み出し方。
主副の役割や段階的な移譲によりエンジニアが実施しやすいイメージを持てました。

競合や要望に流されない──B2B SaaSでミニマム要件を決めるリアルな取り組み

メモ

どうしたらミニマムに開発できるか。
良いミニマムとは？ROI（保守運用含む）が見合うことと価値検証ができる。
それを見定めるために必要な観点。
・アウトカム：自分の頭で全体像をとらえ直すことが重要。
・俯瞰：ステークホルダ間でミニマムに対する想定がずれないよう整理する。
・巻き込み：ソリューションの幅を持たせるためにエンジニア、デザイナーを課題整理から巻き込む。
・自問自答：想定問答を繰り返す。whyとwhatを繰り返し見つめ直して思い込みを排除する。
要件をCSと合意するとリスクの観点で対応した方が良いリスクが現れる。
リスクを抽象的なままで捉えず、具体的な事象まで整理したうえで対応を判断する。

学び

いかに抽象的な考え方を具体に落として整理・調整するかが重要とイメージしました。
また、エンジニアを巻き込むとソリューションの幅が増える話が嬉しかったです。

八百屋がプロダクトマネジメント？食材を届ける、DXを届ける ― 食材流通の現場から考えるプロダクトマネジメント

メモ

食材流通業界。食材業界のリアル。
ベジクルのビジネス。
・主力事業：個人飲食店向け青果流通事業
・新規事業：食材流通事業者向けBPaaS

個人の飲食店の発注ツールは様々（FAX、アプリ、電話…）。
卸業者の野菜にはバーコードが無い。品質に個体差もある。
相場・量が毎日変動する。

アナログ業界におけるPM学び3選。
・現場の業務フローをそのままプロダクト要件にするべからず
・アナログとデジタルの組み合わせで効率最大化。どこをデジタル化し、どこをアナログで残すかPdMで判断。
・現場が業務ハックをしてくれることを信じるべし。業務フローを固めず現場に委ねる。

学び

プロダクトマネジメントの無い領域でプロダクトマネジメントを実現する凄さを感じました。
本日聞いた中で一番険しい環境なイメージを持てました。
そして、業務フロー固め過ぎないで余白を残すことが重要なことは今まで気付けなかった学びとなりました。

【歴史探偵】その機能はなぜ、2年間もリリースできなかったのか？急成長の過去から紐解く、未来に挑むための意思決定

メモ

急成長による複雑化。
顧客が増えたことでユースケースが増えて複雑化していた。
相次ぐ機能要望と、機能はあるけど非機能で満たせないパフォーマンス問題が発生した。
急成長によって複雑化は避けられなかった。
複雑化を避けるためにしたこと。
・注力する業務をしぼりこむ
・プロダクトを使う前後も含め深く業務を理解し要件をくみ上げる
・業務を満足に実行できる要件を非機能まで見定める

一貫した体験を非機能迄含めて定義する。

学び

ログラスさんの強さを改めて実感しました。
DDDを採用しているからこそ、複雑性をプロダクトレベルで再整理できるようなイメージを持てました。

ブース

すべてのブースに回ることができました。
昨年も思いましたが、pmconfのブースは普段通っているエンジニア向けカンファレンスと少し違う気がしています。
プロダクトについてご説明いただくのがとても興味深いです。

特にユニファさんのブースがとても興味深かったです。
未来の保育園。
子供たちの振る舞いや記録を価値ある情報として集約することで、ひとりひとりの園児に対して今まで以上に寄り添った対応ができるようになるし、そうした情報が残ることで親にも子供本人にも価値ある記録になりそうな気がします。
そして、それを人力で実現しようとすると、保育園の先生たちが忙しすぎることは分かっているため、こうしたプロダクトが解決していく意義を感じました。

unifa-e.com


エンジニア目線でははてなさんのtoittaもとても興味深かったです。
ユーザーインタビューの動画をAI解析し、細かいトピックスごとにMiro上に展開される。
自分達のバックログリファインメントとかで効果がありそうとイメージが膨らみました。
また、付箋から動画の該当箇所の再生もできるからすごい。

ja.toitta.com

 

レバレジーズさんともXP祭り以来ご挨拶させて頂けるのが嬉しいです。
メドレーさんのPM診断も面白かったです！

まとめ

昨年と違い現地セッションを浴び続けた1日でした。
ランチでもはじめましての方たちとお話しできて嬉しかったです。



改めて、プロダクトマネージャーとエンジニアは役割は違うけど、エンジニアはプロダクトマネジメントを知った方が良いと思った1日でした。
特にデリバリー領域においては、コンテキストの違いも多いけど、我々の仕事なのではと思う内容も多かったです。
プロダクトを健全に成長させていくためには、PdMもエンジニアも一緒に考えられる関係が良いと思っています。
それに加え、もしかしたらAIが作る部分の大半を担っていく近い未来においては、そういった状態が基本条件になる気もしています。

大きな刺激と学びをいただいた1日でした。ありがとうございました。