プロダクトマネージャーこそがリーダーだった！？ リーダーシップ論から見るPdMとスクラムのいびつな関係

Regional Scrum Gathering Tokyo 2025 での講演資料です。
---
スクラムを実践する皆さんに「あなたのチームのリーダーは誰ですか？」と質問したとします。すると多くの人は、プロダクトオーナー（PO）もしくはスクラムマスターと答えるのではないでしょうか。

しかし、ここにプロダクトマネージャー（PdM）が絡んでくると、そのリーダーシップの構図が一気に複雑になります。

私は研究者として、PdMとスクラムチームの関係を研究してきました。そこで得られた洞察のうち特に注目しているのが「実はPdMこそがチームのリーダーとして機能しているのではないか？」という仮説です。しかもPdMとPOが別々の場合、スクラムチームのメンバーは、PdMを真のリーダーと捉え、POをチーム内のリーダー、あるいは中間管理職として見てしまう傾向にある、という初期の調査結果もあります。

このようにして考えると、スクラム界隈でよく言われる「POとPdMは同一人物であるべき」という主張は、リーダーシップの観点から見ると「真のリーダーがチーム内にいるべきかどうか」という根本的なテーマに結びつく可能性があります。

現在検証中のこの仮説を基に、この講演ではスクラムチーム内でリーダーシップがどのように機能しているのか、その実態に迫ります。

また関連して、いわゆる「フィーチャーファクトリー」のような問題がなぜ発生するのかも、リーダーシップが鍵を握っているかもしれません。検証の結果次第では、そのメカニズムについてもお話しできるかもしれません。

スクラム実践者としての視点から、PdMとスクラムチームの関係性を新たに見つめ直し、あなたのチームにどのように応用できるのかを一緒に考えてみませんか？ この講演を通じて、スクラムとリーダーシップの新たな可能性を探っていきましょう。

Transcript

1. プロダクトマネージャーこそがリーダーだった！？ リーダーシップ論から見るPdMとスクラムのいびつな 関係 ぼのたけ 今井健男 2025/1/9 @ RSGT2025
2. Q. スクラムチームのリーダーは誰？ 2
3. プロダクトオーナー（PO）？ スクラムマスター（SM）？ 3
4. しかし プロダクトマネージャー （PdM）がPOの他にいると どうなる？ ... というのが本日のテーマ 4
5. ここから本編 5
6. 今井健男（ぼのたけ） フリーランスアジャイルコーチ スクラム / アジャイル導入支援、プロダクトマネジメ ント支援、開発組織づくり支援 現在は主にログラスでアジャイルコーチ、組織設計・ 運営支援など チーム焼肉 ソフトウェア工学研究者 以前、某電機メーカーの研究所にて企業研究 現在、国立情報学研究所にてスクラム / アジャイルと プロダクトマネジメントの研究 6
7. 近刊「なぜイノベーションは 起こらないのか」 書名 なぜイノベーションは起こらないのか ―真正の需要を捉えるプロダクト創出の科学 原著者 Matt Chanoff, Merrick Furst, Daniel Sabbah, Mark Wegman 訳者 今井健男 アイデアからイノベーションは生まれない？？ 世界を変えるプロダクトを作りたい方必携の書 2025年1月下旬に丸善出版より刊行予定 7
8. おことわり このセッションでは、PdMとスクラムチームの関係に関する私の研究について話 します ただし、まだ現在進行中の研究であるため、内容をすべてお話しすることはでき ません よって 現在立てている仮説を、さわりだけ その他、研究を進める上で考えたことや気づいたこと を中心にお話しします 8
9. 前回のあらすじ @ RSGT2024 V&R論文 (Verwijs & Russo, 2023) に惹かれて自分もスクラムの研究を始めたよ プロダクトマネージャー（PdM）に焦点を当てたよ 参照：Verwijs, C., & Russo, D. (2023). A Theory of Scrum Team Effectiveness. ACM Transactions on Software Engineering and Methodology, 32(3). https://doi.org/10.1145/3571849 9
10. V&R論文のモデル（Columinityモデル） スクラムチームの有効性（効果性、effectiveness）は、5つのファクターからなる以 下のモデルによって説明できる 10
11. ファクター1：応答性（responsiveness） ステークホルダーの要求に対して、チームがどの程度素早く応答できるか 11
12. ファクター2：ステークホルダーへの関心 （stakeholder concern） チームがステークホルダーに対してどの程度関心を持っているか 12
13. ファクター3：継続的改善（continuous improvement） チームが継続的に学び、自分達を改善しているか 13
14. ファクター4：チームの自律性（team autonomy） チームが自分達のやることをどの程度自分達で決めて行動できるか 14
15. ファクター5：マネジメントの支援 （management support） チームがスクラムを実践する上で、マネジメントがどの程度サポートできているか 15
16. なぜPdMに着目したか（1） 「ステークホルダー」 Columinityモデルでは、あらゆるステークホルダーが「ステークホルダー」とい うくくりでまとめられている しかし、ステークホルダーにも色々いるのでは？ 特に、チームの外にいる事業部門・ビジネス部門はチームのパフォーマンスに影 響を与えないのだろうか？ 事業部門にPdMがいる場合はどうなる？ 16
17. なぜPdMに着目したか（2）Product Mandate V&R論文においては、チー ムの自律性 から ステークホ ルダーへの関心 への寄与は 確認できなかった 17
18. なぜPdMに着目したか（2）Product Mandate 続き 論文での考察 the autonomy of Scrum teams to make decisions about how to do their work (self-management) is mainly orthogonal to their autonomy to decide what is most valuable to their stakeholders (product mandate). つまり、 i. Howの自律性（自己組織化）... どのように開発するかの判断 ii. Whatの自律性（プロダクト・マンデート）... 何を開発するか の判断 の２つは独立しているのでは？ 18
19. といったあたりを自分の手で確かめてやろうと思った 19
20. そして研究を始めた 手始めに、PO/PdMとスクラムチームのメンバー 合計14人にインタビューした インタビューがある程度終わった段階で「恐らくこんな風になってそう」という 気づきのメモを、V&R論文の著者の2人に送った すると、そのうちの1人である Christiaan Verwijs から 「それってリーダーシップ の問題なのでは？」 という返答が返ってきた（参照論文付きで） 20
21. それから 数か月ほどリーダーシップの論文を調べまくったところ、インタビューで確認できた 現象は確かにリーダーシップの概念でだいたい説明できそう、ということがわかって きた とどのつまり、POもPdMもリーダーであり、 リーダーがフォロワー（チーム）とどういう関係を結んでいるか、の問題だった 21
22. ということで、 PdMとスクラムチームの関係を リーダーシップの言葉で説明してみる というアプローチをとることになった 22
23. 更に話を進める前に そもそも、PdMとPOってどういう関係なの？ について掘り下げておきます 23
24. PdMとPOの歴史（1/2） Ken Schwaberの記した文献から、そもそもPdMとPOの関係を歴史的に探る 1995年 "SCRUM Development Process" POはまだ登場しておらず、スクラムのマネジメントはPdMのリードで行う、 というような記述がある マネジメントチームを想定するような記述もある 2004年 "Agile Project Management with Scrum" Product Owner が（初めて？）文献に登場 紹介している事例で、あるプロダクトマネージャーを「影のPO」とみなして いた、という記載がある 24
25. PdMとPOの歴史（2/2） 2007年 "The Enterprise and Scrum" "Product managers and customers are now Product Owners." という言及など があり、POはPdMが担うことがほぼ前提となっている POは（従来のPdMとは違い）プロジェクトマネジメントに責任があり、 上位のマネージャーに対して説明責任がある 、と説明 cf. 2008年 "The Scrum Primer" では「従来のPdMと違い、プロジェクトマ ネージャーに判断を委譲しない」といった趣旨の説明がされている 2009年 スクラムガイド初版 25
26. しかし現状、PdMとPOは多くの組織で併存している Toikkanen et al. (2023) POとPdMの関係は文脈依存だが、だいたい5つのシナリオにまとめられる まとめ直すと実は3つ i. POがPdMを兼務している ii. PdMがチーム外にいて、POはチームとPdMとの仲介役になっている iii. どちらかのロールが実質的に置かれていない 参照：Toikkanen, T., Hyrynsalmi, S., & Paasivaara, M. (2023). How does the role of a Product Owner relate to the role of a Software Product Manager? In Lecture Notes in Informatics (Ed.), ICSPM 2023: International Conference on Software Product Management. Gesellschaft für Informatik e.V. 26
27. 実は新しい問題ではない：代理PO（Proxy PO） 以降の例題は Alex Ballarin Latre @Scrum.org, What is a"Proxy" Product Owner? Why it is found so often? より引用 27
28. 従来型組織がありました BIZ 事業部門のマネージャー PjM IT部門のプロジェクトマネージ ャー DEV IT部門の開発者 BIZのマネージャーが作るものを 決め、IT部門に依頼 28
29. スクラムを導入しました 何かそれっぽいことをしている プロジェクトマネージャーがPO に 29
30. でも、IT部門のPOに大した権限はありませんでした 予算の配分など含め、何を作るか 決める最終権限は、事業部門のマ ネージャーが相変わらず保持 つまり、 事業部門のマネージャーが 事実上のPOで、 プロジェクトマネージャーは 代理POに 30
31. これって PdMとPOが併存する組織 の典型的なケースでは？ 31
32. 私の研究について 32
33. リサーチクエッション Q1: PdMとスクラムチームの関係を構成する要因は何か？ Q2: その関係はチームの有効性にどのような影響を与えるか？ Q2': PdMとPOが分かれていた場合、チームの有効性にどのような影響があるの か？ 33
34. しかし PdMとPOの区分けは現状かなり状況依存 そのため、「PO」は明確に扱わず、「PdM」と「スクラムチーム」の関係のみを 扱う PdMは「プロダクトマンデートを持つ人物」と定義する つまり、チームが何を作るかの決定において権限と責任を持つ人物 その人物がチーム内に1人だけいれば、それは間接的に（真の意味での）PO だろうと推測できる 34
35. リサーチクエッション 改めて Q1: PdMとスクラムチームの関係を構成する要因は何か？ Q2: その関係はチームの有効性にどのような影響を与えるか？ Q2': PdMとPOが分かれていた場合、チームの有効性に悪影響はあるのか？ Q2'': PdMがチームの外にいた場合、チームの有効性にどのような影響があるの か？ 35
36. 現在の研究の状況 Q1: PdMとスクラムチームの関係を構成する要因は何か？ → 関係の構造を表す理論モデル（以降、関係モデル）の仮説を構築、これからそ の検証をしようとしているところ Q2: その関係はチームの有効性にどのような影響を与えるか？ → 関係モデルとColuminityモデルがどのような関係にあるか？ を調査する予定 Q2'': PdMがチームの外にいた場合、チームの有効性にどのような影響があるの か？ → Q1, Q2の結果から演繹的に導けるはず 36
37. では、その仮説とは？ 37
38. では、その仮説とは？ 適合性 38
39. 適合性（congruence）とは リーダーシップにおける適合性（congruence）とは、 リーダーとフォロワーがそれぞれ持つ価値観・目標・役割期待・行動様式などの 間の整合性 のこと 39
40. 適合性の例（１）：コンティンジェンシー理論 コンティンジェンシー理論（条件適合理論） 「最適なリーダーシップスタイルはフォロワーの状況次第で変わる」という前提に立 つ理論群の総称 例： シチュエーショナルリーダーシップ / SL理論 パス＝ゴール理論 etc. ソフトウェア開発界隈で注目されている Elastic Leadership はこの影響を受けてい ると思われる 40
41. 適合性の例（２）：「価値の一致」 価値の一致（Leader-Follower Value Congruence） ... リーダーとフォロワーの価値観 の整合性のこと リーダーとフォロワーで価値観が一致することは、フォロワーの仕事への満足度 や組織への愛着にポジティブな影響がある (Byza et al., 2019) コンティンジェンシー理論とは違い、リーダー ⇔ フォロワー 間で 双方向 参考：Byza, O. A. U., Dörr, S. L., Schuh, S. C., & Maier, G. W. (2019). When Leaders and Followers Match: The Impact of Objective Value Congruence, Value Extremity, and Empowerment on Employee Commitment and Job Satisfaction. Journal of Business Ethics, 158(4), 1097–1112. 41
42. 例：技術的負債への向き合い方 1 機能リリースがとにかく優先 常にキレイなコードを維持したい → 適合しない 42
43. 例：技術的負債への向き合い方 2 品質確保のためのコストも重視 多分動くと思うからリリースしようぜ → 適合しない 43
44. 例：技術的負債への向き合い方 3 品質確保のためのコストも重視 常にキレイなコードを維持したい → 適合する 44
45. 例：失敗の許容度 1 やらかしはブランドイメージに傷がつくから 極力避けたい、なるべく今までのやり方を踏 襲 試行錯誤を通じてスキルやノウハウを蓄積し ていきたい → 適合しない 45
46. 例：失敗の許容度 2 どんどん挑戦し、チームの競争力を高めたい 他のメンバーから批判されるのが怖いし、余 計なことはしたくないな…… → 適合しない 46
47. 例：失敗の許容度 3 どんどん挑戦し、チームの競争力を高めたい 試行錯誤を通じてスキルやノウハウを蓄積し ていきたい → 適合する 47
48. PdMがチーム外にいるときの価値の一致 代理POのケースを再考す ると チームにはスクラムの価値観がイ ンストールされるが、 事業部門にいるPdMは、必ずしも スクラムの価値観を持っていない → 価値の不一致が発生しやすい のでは 48
49. 仮説を大まかにまとめると PdMとスクラムチームの間の関係を成立させる主な要因に、 価値の一致などの適合性があるのでは？ 49
50. 仮説が正しいとして チーム外にPdMがいる場合、PdMとの適合性が低くなりがちなことが問 題になるのでは 言い換えると、たとえチーム外にPdMがいたとしても適合性が高い状態 を作れれば、問題は低減するのでは 50
51. 更なる考察（１）：コミュニケーション 51
52. 代理POのケースで対策を考えてみる 根本的な解決 チーム内にPdMを配置する （≒本物のPOにしてしま う） PdMにもスクラムの価値観を インストールしてもらう ... ただ、これができれば苦労はし ない 52
53. 代理POのケースで対策を考えてみる それなりに実践的な解決 チーム内POに、プロダクトマン デートをきちんと委譲してもら う チームが何を作るのかの決 定権（と責任）をPOに委 ね、 チームメンバーでもあるPO を より適合する開発リーダ ー としていく 53
54. 代理POのケースで対策を考えてみる それもしんどい場合に、 少しでも適合性を上げる 方法 コミュニケーションを質・量 ともに増やす 「距離」 を縮める 54
55. 適合性を左右するかもしれない2つの要素 1. コミュニケーションの質と量 十分なやりとりの場がないと、お互いの背景や意図を理解しづらい 雑談やミーティングの 「質」 が適合性の形成に大きく関わる可能性 2. 組織における 距離（認知的・文化的・社会的） 思考様式や専門知識、企業文化、雇用形態などの違い 距離が大きいほど、「共通認識」づくりに時間・労力がかかる 55
56. 「距離」の考え方 リーダーシップにおいて、複数の「距離」の概念が存在し、適合性とも関連 認知的距離 開発プロセス・アジャイル理解度の差 専門知識のレベル差 使用する用語の理解度の差 文化的距離 トップダウン vs ボトムアップなどの組織文化 コミュニケーションスタイル（ドキュメント重視 vs 口頭での対話重視） 権力格差（Power Distance） 社会的距離 正社員 vs 業務委託 人事制度での等級、社内でエラい人 vs エラくない 人 雇用形態の違いや物理的条件で生じる溝 56
57. 例：正社員 vs 業務委託 インタビュー調査でも、正社員と業務委託の区別を意識する発言が本人含む複数人からあった 社会的距離（Social Distance） 集団・階層・雇用形態などの違いによって感じる心 理的・物理的な「壁」 「私たち vs. あなたたち」という 内集団 / 外集団 の意識 例）会社内での「正社員 vs. 業務委託」による 疎外感 「外部の人」という印象から、業務委託エンジ ニアは発言を遠慮しがち 文化的距離（Cultural Distance） 国・地域・組織などがもつ価値観・慣習の違いによ る距離 例）日本独特の SI 文化 SE（上流）＞プログラマ（下流）の水平分割 コーディングを"軽視"する風潮 57
58. Power Distance Power Distance（権力格差） は文化的距離の要素の一つ 不平等や上下関係を「当然」と受け入れる度合い 日本は欧米に比べ power distance が大きい 傾向 → 下請け（or 業務委託）は「言われるままの作業」になりがち 58
59. 距離を縮める手段 学術的にも効果が確認されているもの リフレクション / リフレクティビティ いわゆるふりかえりだが、レトロスペクティブと違って学び・気づきを重視 チーム・組織単位で行うことで、認識のズレを縮める効果 心理的安全性 「何を言っても他者から責められない」と感じられる心理的環境 率直なコミュニケーションの促進、チームワーク・仲間意識の醸成 59
60. 更なる考察（２）：フィーチャーファクトリー 60
61. フィーチャーファクトリーとは John Cutler が提唱した概念で、プロダクトの価値やアウトカムを考えることなく、た だ機能を作り続ける組織の状態のこと。 アウトカムよりもアウトプット重視 短期的成果重視 ただ、長期視点で顧客の不満増大やプロダクトの複雑化、市場とのミスマッチが起こ りやすい。いわゆる「ビルドトラップ」とも関連が強い。 また、常に新機能を作り続けることへの過度なプレッシャーによって技術的負債を貯 め込みやすい。 61
62. ただし、 アジャイルのコミュニティでフィーチャーファクトリーが話題になるときは、それ以 外にも 主にチームの状態のことで、 チーム外から飛んでくる機能開発の指示をただ受け入れるだけになっている状態 のこと を指すことがある。 それは先ほどのものとビミョーに意味が異なっている。 62
63. アジャイルコミュニティと同じ用法の文献を探してみたところ、 ある書籍に行きついた 63
64. 『EMPOWERED』 　by Marty Cagan & Chris Jones 大半のプロダクト企業では、真のプロダクトリーダーシップ はほとんど見失われている。 その代わり、プロダクトリーダ ーは取りまとめ役として、社内（もっとひどい場合は外注） の 「機能工場」 に人を配置し、列車の運行管理のごとく、業 務が時間通り進行するように責任を負っている。 プロダクト組織は、他部署に従属する 機能開発工場 ではな く、組織の価値を牽引する存在でなければならないのです。 （強調は引用者。強調箇所は、原文ではいずれも "feature factory"） 64
65. そもそも『EMPOWERED』では、 プロダクト開発が成功するためには 自律し、自ら価値を創造できる「エンパワーされたプロダクトチーム」 （empowered product team）が必要であり、 多くの企業ではそうならず、ただの 「機能開発チーム」（feature team） になっ ている PdMなどのリーダーは、自律したプロダクトチームを育成・支援すべき というのが書籍を通しての主張である。 この「機能開発チーム」が、アジャイルの文脈で言う「フィーチャーファクトリー」 とほぼ同義。 65
66. 2つの「フィーチャーファクトリー」まとめ 観 点 Cutler Cagan & Jones 定 義 アウトプット・短期成果優先 の企業文化 指示された機能群を開発するだけのチーム/組 織 視 点 外部からの俯瞰的視点 プロダクト開発リーダーの視点 問 題 組織文化・事業戦略の欠如 プロダクトリーダーシップとチームのエンパ ワーメントの欠如 ただし、どちらも「機能を量産するだけで価値を創造しない」という点では同じ。 66
67. 2つの「フィーチャーファクトリー」まとめ 観 点 Cutler Cagan & Jones 定 義 アウトプット・短期成果優先 の企業文化 指示された機能群を開発するだけのチーム/組 織 視 点 外部からの俯瞰的視点 プロダクト開発リーダーの視点 問 題 組織文化・事業戦略の欠如 プロダクトリーダーシップとチームのエンパ ワーメントの欠如 ただし、どちらも「機能を量産するだけで価値を創造しない」という点では同じ。 以降は、Cagan & Jones 流の「フィーチャーファクトリー」の定義で考える 67
68. フィーチャーファクトリーと適合性（１） とにかく俺らが考えた機能を作ってくれれば いい アウトカムを考えながら開発したい → 適合しない 68
69. フィーチャーファクトリーと適合性（2） 俺たちのビジョンに従って、チーム自ら顧客 価値を探索してほしい アウトカムを考えながら開発したい → 適合する & エンパワーされたプロダクトチーム成立 69
70. フィーチャーファクトリーと適合性（3） とにかく俺らが考えた機能を作ってくれれば いい 俺らはコードが書ければ十分 とりあえず機能仕様くれれば実装は任せとけ → 適合する & フィーチャーファクトリー成立 70
71. フィーチャーファクトリーと適合性（3） とにかく俺らが考えた機能を作ってくれれば いい 俺らはコードが書ければ十分 とりあえず機能仕様くれれば実装は任せとけ → 適合する & フィーチャーファクトリー成立 ？？？ 71
72. もしかして 適合性に基づくPdMとチームの関係モデルは、 フィーチャーファクトリーを否定しないのでは？ 72
73. むしろ、 適合性があればフィーチャーファクトリーでも 機能してしまうのでは？ 73
74. Cagan & Jones の主張が正しいと仮定するなら 「エンパワーされたプロダクトチーム」と「フィーチャーファクトリー」のどち らでも適合性が高い状態は作れそう ただし「エンパワーされたプロダクトチーム」は、Columinityモデルが示す効果 的なチームと符合する点が多い つまり、関係モデルとColuminityモデルを組み合わせて考えることで、Cagan & Jones の妥当性を示せるかもしれない 74
75. でも、Cagan & Jones の主張は本当に妥当なの？ 指示的なPdMと指示に従うだけのチームで本当にパフォーマンスは悪くなるの か？ PdMがWhatを担当し、チームがHowを担当して何がまずいのか？ POがWhatを担当し、開発者がHowを担当するのは割と一般的 PdMとチームが1つのチームのように適合すれば問題ないのでは？ 適合性とエンパワーメントの度合いとどちらが支配的か？ 75
76. まとめると アウトプット志向なPdM アウトカム志向なPdM プロダクト志向なチーム 適合しない エンパワーされたチーム 技術志向なチーム フィーチャーファクトリー 適合しない クエッション 1. 適合しないチームは有効性が低くなるか？ 2. エンパワーされたチームはフィーチャーファクトリーより有効性が高くなるか？ 76
77. 結局、科学的に実証してみるしかない と思っています 77
78. ご清聴ありがとうございました 78