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

PdMの強い「責任感」が、逆にチームの成長を止めているとしたら？

PdMが頑張れば頑張るほど、細かく入り込めば込むほど、沢山意思決定をすればするほど、デザイナーやエンジニアの主体性や独創性が失われる。

組織観点だと、職能別に役割を定義したり、組織を細分化するほど分業が進み局所最適に陥る。

一方でプロダクト運営としてはチームでアウトカムを最大化させたい。

PdMがこの悩みやジレンマとどう向き合い、半年かけでどう変えていったのかを本セッションで伝えます。

株式会社ハウテレビジョン

プロダクトマネジメント部　部長
関根 稔将

Transcript

1. PdMの「責任感」がチームを弱くする？ 「分業型」から全員がユーザー価値に本気で向き合う 「共創型開発チーム」への変遷 株式会社ハウテレビジョン プロダクトマネジメント部　部長 関根 稔将
2. プロフィール 株式会社ハウテレビジョン プロダクトマネジメント部　部長 関根 稔将 キャリア 　　DeNA→ハウテレビジョン 　　セールス・新規事業立ち上げ(3年)→PdM(6年) 現在のロール 「外資就活ドットコム」、「外資就活ネクスト」のPdMをしつつ、 プロダクト&マーケティング組織のリード Toshimasa Sekine
3. Our Products 新型質問箱 キャリア支援プラットフォーム (新卒&転職) “能力開花”の機会を創出するプロダクトを複数運営
4. PdMの強い「責任感」が、 逆にチームの成長を 止めているとしたら？ Q
5. 「責任感」のパラドックス：PdMの過度なコミットが招く3つの代償 主体性の消失と社内受託化 再現性のない「脆い」組織 PdMがボトルネックに PdMが仕様やデザインの詳細まで入り、 工夫する余地が少ない →エンジニア,デザイナーの創造性の消失 「細かな仕様」「ユーザー視点」「品 質」担保するのは全てPdM 「PdMが決めないと進まない」状況を作 り出してしまう →役割が増えると詰む 「あの人がいないと回らない」属人化 人が変われば崩壊する →チームの成長を阻害
6. 頭が痛い..... 担当のプロダクトチームが以前この状態でした 一方で当時はそれで回っていて、プロダクトも伸びていた でも再現性のあるチームじゃないし、 何より良いチームとは言えない.....
7. 当社の技術顧問とも相談し、 アドバイスももらいながら 変えていこうと覚悟を決めた エンジニアがPdMと連携できているか を主観的に感じられるかが重要 少しずつ良くしていく 筋トレみたいなもんですよ →「共創型開発チーム」を目指す
8. チーム全員で最高のユーザー 体験とプロダクトを作り上げ るチーム 共創型開発チームとは
9. 03 PdMの関わる範囲の選択と集中 01 開発スタイル・MTG形式 02 プロダクトレビューをめっちゃ増やす 大きく変えた3つ
10. 1.開発スタイル・MTGの変更 朝会(Morinig) 夕会(Evening) 【補足】従来はスクラムのフレームワークを用いていたが、エクストリーム・プログラミング（XP）の実践要素と リーン開発の思想を組み込んだプロダクトレビュー中心のスタイルに変更 　※XPの継続的フィードバックを朝会で実現。チームで品質担保。小さく作ってすぐ触る...etc 　※リーン開発思想:チーム主体で改善を回す、小さく作って早く学ぶ、フィードバックを高速で回す プロダクトのデモとレビュー 朝会の準備(PdM不参加) 開発中のものを見せ、その場でプロダ クトレビューやリリース判断を実施 開発の相談や進捗確認 デモの準備や事前確認 スクラム特有のデイリースクラムを廃止し、朝会と夕会の実施
11. 朝会では毎日エンジニアが大小問わず開発中のものをデモ
12. 2.プロダクトレビューを高頻度で行い、PdMの観点をインストール PdMの観点をインストール デモは「毎日」「複数回」 チームでより良いプロダクトを作るため に、プロダクトをより良くする引き出し や観点、考え方をプロダクトレビューを 通してチームにインストール チーム主体で改善を回す、小さく作っ て早く学ぶ
13. プロダクトレビューと動作確認は切り分ける プロダクトレビュー バグ検知・動作確認 アウトカムやユーザー体験をどう 良くできるかをレビュー 個々人やチームで担保できる状態 を目指す ただし、観点も必要なので、初期 は不具合検知含めてPdMがレビュ ーし、段階的移行 結果:夕会で「これだとレビューにならない」とエンジニア同士で確認 朝会でのバグや不具合が減るだけでなく、そもそも開発段階で気づいて最小化される状態へ
14. 3.PdMは方向性策定・レビュー・リリース判断に集中 仕様書を作らない ディレクションやらない レビューに集中 包括的なドキュメントより「動くソフト ウェア」 方向性・ユーザー体験と背景、箇条書き 程度の要件を簡潔に エンジニアとデザイナーが連携して最低 限の要素を詰める 作りながら決める 作りながらブラッシュアップしていく エンジニアに任せる。介入せず相談に乗 る そもそも朝会・夕会の仕組みがあるた め、細かくディレクションしなくて良く なる
15. 今振り返って思う大事なこと 銀の弾丸は存在しない。粘り強く、コツコツ積み重ねていくことで徐々に変わる 最初はチームメンバーもPdMも一時的に負荷が高くなるが、PdMが覚悟を持って推進 改革には一定の痛みは伴うがこれは成長痛 こう変えていきたい、なぜ変えたいかをちゃんとチームに話す とにかくプロダクトレビューの数を増やし、PdMの観点やユーザー視点をシャワーの ように浴びてもらう
16. 結果どうなったか？
17. プロダクトの変化 品質だけでなく、デリバリースピードも向上 毎日アウトプットをレビュー・その場でリリース判断してるので、テスト待ち時 間が発生しない リリース後の障害や不具合、考慮漏れの削減 毎日チーム全員で見ているので検知しやすい プロダクトレビューを円滑に進めるため、不具合や考慮漏れを開発者自身が事前 に気づいて潰す そのために必要な観点は毎日のプロダクトレビューで身につくという好循環
18. チームで良いプロダクトを作っている感が醸成され、 「共創型開発」チームに変化！！ 自律的なチーム連携 主体性と創造性を十二分に発揮 エンジニア-デザイナー間でUXを議論し ながらその場で開発 エンジニア同士で、品質やユーザー観点 を確認 仕様確認ではなく、提案に変化 こっちの方がユーザーに良いと思うの で変えました。朝会で見てください！ などの動きが爆増
19. Summery チームで プロダクトを 作るのって 楽しい！！ 03 01 02 とにかく朝会のプロダクトレビューが肝 チームがプロダクトに触れる頻度と時間を 増やす！ 魔法のような解決策は無し 愚直に継続と改善を続けていく 負荷は高いが覚悟を決める 今までの当たり前や勝ちパターンを捨てる 銀の弾丸はない PdM自身がアンラーン
20. 今日の発表を聞いて少しでも当社のプロダクトチームに興味を持って いただいた方は、こちらも是非見てください！！ 技術ブログ 採用サイト 募集求人(中途)
21. Fin