俺たちは本当に分かり合えるのか？ ～ PdMとスクラムチームの “ずれ” を科学する

RSGT2026での講演資料です。
---
エンジニアのみなさん、プロダクトオーナーやプロダクトマネージャーと仕事をしていて、こんな経験はありませんか。

「あまり前に出ない人だけど、一緒にやっていて仕事しやすい」
「言うことは立派なのに、どうも噛み合わないんだよなぁ」

一方で、プロダクトマネージャーの側からはこんな声も聞こえてきます。

「一緒に仕事をしていても手応えが感じられない」
「きちんと説明しているつもりなのに、どうもうまく伝わらない」

私は研究者として、プロダクトマネージャー（PdM）とアジャイルチームの関係がチームのパフォーマンスに与える影響を研究しています。その中で、両者の間のこうした“ずれ”こそが大きな影響要因ではないかと考えるようになりました。

※ 本セッションでいう「プロダクトマネージャー」は「チームが何を作るかの決定に最も影響力のある人」のことを指します。よって多くのチームでは「プロダクトオーナー」も含まれます。

この仮説を検証するために、私たちはアンケート調査で“ずれ”を数値化して測定しています。そしてプレ調査での分析の結果、そこには想像以上に複雑な構造が見えてきました。端的に言えば、PdMとチームを同時に満足させるポイントが極めて限定的なのです。
“ずれ”によっては、PdMは満足するのにチームは不満を覚える、あるいはその逆という困った状況が確認されています。

現時点ではまだ十分なデータ量はありませんが、

果たして十分なデータでも同じ傾向が見えるのか？
具体的にどんな“ずれ”の構造があるのか？
双方が満足するためのヒントはあるのか？
――こうした問いと、それへの解答を当日共有します。

さらに今回は、アジャイル界隈で長く「NG」とされながら、実は科学的エビデンスが乏しかった問題にも一歩踏み込みます。たとえば：

POとPdMは別にいていいのか？
「フィーチャーファクトリー」は本当に悪なのか？
※ フィーチャーファクトリー: PdMがただ指示するとおり、ただ言われるままに機能を作るだけのチーム

本セッションでは、12月上旬時点の中間データをもとに、“ずれ”をどう測り、何が見えてきつつあるのかをお伝えします。PdMとチームにまたがるこの問題について、現場の皆さんと一緒に考えたいと思います。

Transcript

1. 俺たちは本当に分かり合えるのか？ ～ PdM とスクラムチームの “ ずれ” を科学する ぼのたけ 今井健男 2026/1/7 @ RSGT2026
2. さて皆さん 2
3. こういう経験はありませんか？ 3
4. 今回の変更、元々の戦略に沿ったもので 方針は変わってないんだけど 実装の前提がめちゃめちゃ変わってる 方針変更するならちゃんと言ってほしい 4
5. やりたいことは全部決めた 必要な情報は全部PRD に書いた PRD 読んだけど、 このへんもっと変更したいよね 注） PRD: Product Requirments Document / 製品要求仕様書 5
6. ユーザーの反応を見てると、 やっぱりこっちで攻めるべきだと思うんよ 方向性の話だけされてもわからん じゃあ何をどう実装すればいいの？ 6
7. 本日はこんな、 両者の悲しいすれ違いの話です 7
8. 今井健男（ぼのたけ） フリーランスアジャイルコーチ スクラム / アジャイル導入支援、プロダクトマネジメ ント支援、開発組織づくり チーム焼肉 ソフトウェア工学研究者 以前、某電機メーカーの研究所にて企業研究 現在、国立情報学研究所にてスクラム / アジャイルと プロダクトマネジメントの研究 8
9. おことわり１ この講演では、あくまで研究者人格のぼのたけが話します。 特に本講演で明らかにする見解や事例は全て、私が過去に研究活動の中で収集した 定量的データ を分析した結果から得られているものです。 アジャイルコーチ等の活動で関わっている特定の企業・組織を指し示すものではあり ません。 9
10. おことわり２ 本講演では、PdM とスクラムチームの関係に関する私の研究について話します。 本日お話する内容は、現時点のデータから見えてきている傾向や構造を元にした 暫定的な仮説をベースにしています。 今後の研究の進展によって、解釈や結論は変わる可能性があります。 10
11. おすすめ 現在裏番組でやっている森雄哉さんのこの講演ですが、 本講演と関係が深い内容と思われます（推測）ので、 後ほど資料や録画のチェックをおすすめします 11
12. PdM とチームはとにかく噛み合わない PdM 、チーム双方がいつもお互いの不理解を嘆いている これに対して、多くの組織では 説明を増やす コミュニケーションを増やす 資料を工夫する といった対策を取るが、それでも解消しない / すぐ再発する ケースが多い 12
13. なぜ？ 13
14. もしかすると問題は 情報量 や 伝え方 ではなく、 「そもそも同じ世界を見ていない」 ことにあるのでははないか？ 14
15. ここで、ふと思い至った 15
16. これは 環世界 の話ではないのか 16
17. 環世界（Umwelt ）とは 環世界 ... 生物学者ユクスキュルが20 世紀初頭に提唱した概念 それぞれの生物は、外界のすべてを認識しているのではなく、自身の知覚や身体 的特徴を通じて「固有の世界」を形成し、その中で生きている つまり「環世界」とは 主体ごとに異なる「その生物にとって意味のある世界」 のこと 17
18. たとえば、犬は人間と全く異なる色覚を持っており、りんごの「赤色」がわからない 18
19. 一方、犬は人間よりはるかに優れた嗅覚を持っており、 なので、人間は犬の嗅いでいる「匂い」がわからない 19
20. つまり、犬と人間は生物学的に異なる「環世界」に住んでいる 20
21. 一方、人間にとっては社会的な環世界も存在する 21
22. 例 22
24. ある公園で、女性がバナナを手に持って電話をかける仕草をしているのを見かけたら、 あなたはどう思いますか？ 24
26. 女性のそばで、小さな子供がやっぱりバナナで電話をしていたら、 あなたはどう思いますか？ 26
27. 同じ人間であっても 見えるものが変わるだけで世界は変わる 27
28. これが環世界 28
29. 参考： 「なぜイノベーションは 起こらないのか」 書名 なぜイノベーションは起こらないのか ― 真正の需要を捉えるプロダクト創出の科学 原著者 Matt Chanoff, Merrick Furst, Daniel Sabbah, Mark Wegman 訳者 今井健男 アイデアからイノベーションは生まれない？？ 世界を変えるプロダクトを作りたい方必携の書 バナナの女性の事例は、この本での環世界の解説 に使われています 29
30. 『なぜイノベーションは起こらないのか』では、 プロダクトを「使う人」と「作る人」の環世界は違うので 使う側のニーズを作る側が簡単に把握できない、としていた プロダクトを作る人間がユーザー・顧客を簡単に理解できないのは今や常識 30 使う人 作る人
31. でも、もしかすると 同じ作る側の人間でも 「PdM 」と「チーム」の環世界は違う ので お互いがお互いのことを簡単に理解できない のかもしれない 31 PdM チーム
32. では、どのように PdM とチームの「環世界」は違うのか 32
33. 分析時の経緯 当初は私自身、両者は同じ認知構造を持っていると想定していた そのうえで 「PdM がどう考えているか」 「チームがどう考えているか」 のそれぞれを PdM の視点と チームの視点 で、それぞれ分析した 単純に、その差分を測れば「ズレ」が見えると思っていた 33
34. しかし、 両者の認知の仕方が異なっていないと 説明できない現象がいくつか確認できた 34
35. もう少し詳しく見ると、 PdM の自己認識と チームのPdM に対する認識は比較的近かった 35 PdM チーム
36. 一方で、 チームに対するPdM の認識と チームの自己認識が大きくズレている現象が確認された 36 PdM チーム
37. 特に顕著だった例の１つとして、 プロダクトの開発方針（ビジョン・戦略） に関する両者の認識が挙げられる 37
38. 開発方針をめぐる対照的な見方 PdM は、チームが開発方針を 個々の機能仕様 顧客からのフィードバック と同じ文脈の中で捉えている、と思っていそうだ った 38
39. 開発方針をめぐる対照的な見方 PdM は、チームが開発方針を 個々の機能仕様 顧客からのフィードバック と同じ文脈の中で捉えている、と思っていそうだ った 一方、チームは機能仕様やフィードバックを開発 方針とは切り分けて考える傾向にあった 39
40. だから、こうなる ユーザーの反応を見てると、 やっぱりこっちで攻めるべきだと思うんよ 方向性の話だけされてもわからん じゃあ何をどう実装すればいいの？ 40
41. どうしてこんな差が生まれるのか？ 41
42. 「認知サイクル仮説」 PdM とチームは、同じ開発プロセスを 通じて、それぞれに 1. 経験する 2. 解釈する 3. 共有する 4. 次の判断につなげる という 循環的な認知プロセス を回してい るのではないか （知ってる人向け：たとえば SECI モデル） 42
43. しかし、両者の認知サイクルはずれている 43
44. PdM ：ディスカバリーに認知の重心がある 顧客課題の分析とソリューションの発見、戦略の定義 が主な関心事 ディスカバリーの過程で主に経験・解釈し、 「ここまでで意味は固まった」 という感覚を持つ デリバリーは、その感覚をチームに伝え、実装してもらうフェーズ フィードバックは、次の ディスカバリーに戻る ための材料 44
45. チーム：デリバリーに認知の重心がある 何をどう作るか、どこにどんな実装のリスクがあるか、 が主な関心事 デリバリーの過程で主に経験・解釈し、 「ここで初めて意味が確定する」 感覚を持つ リリースによって、その判断結果が正しいかという確認をする フィードバックは、次の 実装判断に直結する 刺激 45
46. このズレを表す典型的な例がPRD （PRD: Product Requirements Document / 製品要求仕様書） PdM にとってはアウトプットだが、チームにとってはインプット PRD を読み解くことはチームにとっては解釈の活動の1 つだが、 PdM にとっては伝達の作業 46
47. 開発方針の認識がどうしてズレるのか ※ あくまで現時点の仮説です PdM にとっては すべてを考慮した結果が開発方針 フィードバックは、それを確認する情報 一方、チームにとっては フィードバックは 個々のスプリントで考慮するインプット かつ 組織外からもたらされる情報 開発方針は別途、もっと大きなスパンで 組織内で 前提として共有される もの 47
48. 問題は「認知の重心がズレている」こと PdM とチームは、似たような循環を回している しかし位相 (Phase) がズレている その結果 同じスプリント 同じ会議体 同じ成果物 を共有しても 「何が分かったか」 「次に何を判断すべきか」が噛み合わない 48
49. このズレは構造的に生じうる 役割・立場・日常的に扱っている刺激の違いから自然に生じる 誰かの理解不足や努力不足によるものではない ただし、放っておくと自己強化される 49
50. PdM とチームは、異なる「環世界」を生きている。 ズレは自然に生じる。能力や意志の問題ではない。 50
51. では、どうすればいいのか 唯一絶対の正解はない ここでは 環世界をつなぐための代表的なアプローチ をいくつか示す 51
52. アプローチ1 ： 「二次観察」を意識的に行う ルーマンの社会システム理論から 一次観察：相手を観察する 二次観察：相手がどんな観点で見ているかを観察する すると、その観点から見えないもの（盲点）もわかる 相手はそれが見えていないことに気づいていない 重要なのは、相手が何を見ているかではなく、相手がどんな観点で世界を見ているか 観点の違いが、環世界の違いとして現れる 参考文献） Luhmann, N. (2012). Theory of Society, Volume 1. Stanford University Press. （原著1997 年） 52
53. アプローチ2 ：Boundary Spanner （境界連結者） OST でいう「ミツバチ」 PdM とチームの間にある構造的な距離を埋める翻訳と接続を担う役割 境界の一方で情報を選び、他方に翻訳して届ける それぞれにとっての「意味づけ」を理解する感覚が必要 参考文献） van Meerkerk, I., & Edelenbos, J. (2014). The effects of boundary spanners on trust and performance of urban governance networks. Policy Sciences, 47(1), 3-24. 53
54. アプローチ3 ：ズレを「創造的摩擦」として扱う 環世界の違いは排除すべき問題ではなく、むしろ組織に与える多様性 異なる視点があるからこそ新しい選択肢やイノベーションが生まれる 重要なのは ズレを認め合うこと ズレを放置しないこと ズレを対話可能な状態にすること 「知的コンバット」ができている組織は創造的摩擦が成立している 参考文献） ドロシー・レオナルド & スーザン・ストラウス, 「創造的摩擦」を活用するマネジメント ～ 同 質的な企業文化からイノベーションは生まれない, Harvard Business Review 日本語版, 1998 年1 月 54
55. ここまでのまとめ PdM とチームのズレは 環世界の違いから自然に生じる 解くべき問いは、誰が悪いかではなく「どうつなぐか」 環世界をつなぐためのアプローチ: 二次観察 Boundary Spanner （ミツバチ） 創造的摩擦、知的コンバット 55
56. それ以外の話題 56
59. 仮説はあるのですが、現時点ではエビデンスが十分揃っていないので、 また次回、どこかでお話させてください 59
61. フィーチャーファクトリーについて 61
62. フィーチャーファクトリー 概要 「フィーチャーファクトリー」とは、 成果（アウトカム）よりアウトプットを重視し、 ひたすら“ 指示された機能” を作り続けるだけの状態 短期的な成果が重視され、長期的な価値・学習・創造が軽視され る 結果として、次のような組織負債が発生する 機能量産プレッシャーで技術的負債が溜まる チームは受け身・受託的になりがち 『EMPOWERED 』でも「自律し価値を生み出すプロダクトチーム」 への転換が必要だと主張 62
63. ここで考えたい例 とにかく俺らが考えた機能を作ってくれれば いい 俺らはコードが書ければ十分 とりあえず機能仕様くれれば実装は任せとけ → ズレてない & フィーチャーファクトリー成立 63
64. ここで考えたい例 とにかく俺らが考えた機能を作ってくれれば いい 俺らはコードが書ければ十分 とりあえず機能仕様くれれば実装は任せとけ → ズレてない & フィーチャーファクトリー成立 ？？？ 64
65. もしかして、 PdM とチームの双方がズレてなければ フィーチャーファクトリーでも機能してしまうので は？ といった可能性をRSGT2025 で話しました 65
66. まとめると アウトプット志向なPdM アウトカム志向なPdM プロダクト志向なチーム ズレている エンパワーされたチーム 技術志向なチーム フィーチャーファクトリー ズレている クエッション（RSGT2025 での講演より再掲） 1. ズレてるチームはパフォーマンスが低くなるか？ 2. エンパワーされたチームはフィーチャーファクトリーよりパフォーマンスが高く なるか？ ※ 一部の用語は易しい言葉に置き換えています 66
67. 今回のアップデート フィーチャーファクトリーが機能するか以前に、PdM は 「チームがどこまで 　フィーチャーファクトリー的な進め方を許容できるか」 を正確に把握しづらい傾向がありそう 67
68. 現時点での理解 「チームがどう考えているか」について、PdM とチームでの認識がズレがち 従って、 「フィーチャーファクトリーか機能するかどうか」よりまず 「PdM がチームの思いをどれだけ汲み取り、反映できるか」 という両者の関係性の質のほうが課題になるかも つまり、チームの自律性より両者の環世界の接続性の方が寄与する可能性 68
69. 本日のまとめ PdM とチームは、同じ組織にいても、同じ言葉を使っていても、 異なる環世界を生きている可能性がある あくまで現時点での暫定的な結果だが、PdM とチームでは認知の構造がそもそも 異なっていそう 仮説：双方が認知サイクルを持ち、その「位相」がずれている PdM: ディスカバリー中心、 チーム: デリバリー中心 つまり、立場の違いから自然に、必然的にズレが発生する可能性 今後、この仮説を含めて検証を進めていく予定 69
70. おしまい 70