プロダクトマネージャー（PdM）になるために #4_PdMとスケールアップする人たち
IT業界で引く手あまたのPdMについて学習しています。
前回は
・PdMが実際に一緒に働く人たちとその関わり方
について把握しました。
今回は業務を遂行しながらもビジネスを拡大するときに変化していくことについて学んでいきます。
文字数：約5,000
参考図書
② 成功するための組織と人〜スケールアップに必要な人々〜
◼️Chapter16 リーダーの役割
・リーダーの役割は「優秀な人材を採用」し「育成し、「維持する」こと
・しかしIT企業の中でも製品開発企業では、リーダーは人材開発を通り越してプロダクトの全体像の把握の領域まで至る
・スタートアップでは1つか2つのプロダクト開発チームしかないのでプロダクトの全体像を頭に入れるのはそれほど難しくない
・企業の成長に伴い開発チームの数が増えると難しくなる
＜プロダクトの全体像を把握するための3つの重要な要素＞
1、プロダクトマネジメントのリーダー
・システム全体が調和していることをビジネスの観点（プロダクトのビジョン・戦略・機能・ビジネスルール・ビジネスロジック）から確認するにはPdM組織リーダーが必要
・規模の大きい組織の場合このリーダーは取締役レベルの上級の役割
2、デザインリーダー
・最も重要な役割の1つがホリスティックなUXの責任者
・極めて多くの対話や相互依存があり、ビジネスとユーザーのカスタマージャーニーに関する非常に多くの組織的な知識が必要
3、技術組織のリーダー
・最後に技術の観点からシステム全体がうまく調和しているかを確認するリーダーが必要
・技術組織リーダーは技術的負債を管理するための明確な戦略を持っていなければならない
特に大規模で複雑なビジネスシステム、多くのレガシーシステムを持つ企業には不可欠な役割
＜ホリスティックな視点を持ったリーダーシップの役割＞
・企業が大きくなればなるほど上述した3つの役割が重要になり、その不在が明確になる
・企業の中にはリーダーの役割を属人化させないためにシステムを何らかの形で文書化することを考えるが成功した例はない。なぜならシステムが常に猛スピードで複雑化し拡大しているから
・ホリスティックな視点を持った3人のリーダーの真価は互いの連携で発揮される
＜ホリスティックなリーダーが欠けた例＞
例1）プロダクトが6つ程度の外部ベンダーによって作られ、ユーザーモデルに一貫性がなく、ユーザビリティが低い
→デザインリーダーが不在
例2）PdMが自らの判断の意味するところを理解していなかったり、開発者にコードを見てシステムが実際にどのように動作しているか聞いてプロジェクトが滞っている
→PdM組織のリーダーが不在
例3）ソフトウェアがスパゲティ状態で変更するのもままならない（＝重大な技術的負債に苦しんでいる）
→技術組織のリーダー不在
熱狂させる製品を生み出すプロダクトマネジメント
ISBN 978-4-8207-2750-7 C2034
P93〜97
◼️Chapter17 ①プロダクト開発トップの役割
＜4＋1つの行動特性＞
1、チーム開発
・PdMとデザイナーから成る強力な開発チームを作り上げること
・求人活動、トレーニング、継続的なコーチングを最優先にする
・一番してはいけないことは能力のない人を選んで昇進させ、リーダーの地位に就けること
・この地位には人材育成において確かな実績がある人物を雇う必要がある
2、製品ビジョンと製品戦略
・製品ビジョンは企業の原動力であり、企業の活力を与え、浮き沈みを超えて企業を支えるものである
・2つの異なる状況で、2つの全く違うリーダーが必要
a）製品に関して明確なビジョンを持ったCEOや創業者がいる
b）製品に関して明確なビジョンを持った人物がいない状況
・遭遇し得る非常に悪い状況
a）製品とビジョンに非常に優れたCEOが製品開発リーダーを採用しようとし、自分のイメージする人物、少なくとも自分のような明確なビジョンを持った人物を雇うべきと考えている状況
→すぐに衝突が起き短命に終わる
b）CEOにビジョンの能力がないのに、自分がイメージする人物を雇おうとする状況
→衝突は起きず人間関係はうまくいくが、ビジョンに空白が生じ、チームの士気が落ちる
・重要なことは製品開発リーダーはCEOを補完すること
3、実行力
・製品開発リーダーは近代的なプロダクトプランニング、顧客の発見、製品の発見、製品開発プロセスの専門家でなければならない
・大きな組織なるほど、実績に裏付けられた優れたスキルが必要
4、製品文化
・優れた製品開発組織は「有能な開発チーム」「明確なビジョン」「一貫した実行力」がある
・偉大な製品開発組織には確固とした製品文化がある
・製品文化とは持続的で迅速なテストと学習の重要性を理解していること
4＋1、化学反応
・製品開発リーダーは重要な取締役と個人レベルでうまくやっていくことができなければならない
熱狂させる製品を生み出すプロダクトマネジメント
ISBN 978-4-8207-2750-7 C2034
P98〜103
◼️Chapter18 ②技術部門のトップの役割
・ここで言う技術部門とは以下に責任を持つ部門
（企業のプロダクトを作り、運用する責任）
＊アーキテクチャ
＊エンジニアリング
＊品質
＊サイト運営
＊セキュリティ
＊リリース管理
＊市場投入のマネジメント
・技術部門トップ（以下CTO）はCIOの役割とは明らかに異なり、偉大なCTOはビジネスとプロダクトの*戦略的イネーブラーであり技術を求めて絶えず努力する姿勢がある
・技術的な障害を取り除き、ビジネスと製品開発リーダーのために技術による実現可能性という枠組みを拡大することを重要な目標とする
*イネーブラー（Enabler）：他人の成功・目的達成などを可能にする人・組織・要因・手段・道具・方法
＜目標達成のための6つの責任＞
1、組織
・社員のスキル向上に全力を傾け、優れた組織を作る
2、リーダーシップ
・他の幹部とともに、進路、M&A、作る・買う・提携に関して決定を助ける
3、市場投入
・市場投入されたソフトウェアの品質や信頼性に責任を持つ
・技術的負債（レガシーシステムなど）を抑制し他社と競争する能力を阻害されないようにする
4、アーキテクチャ
・成長するための、「機能性」「拡張性」「信頼性」「セキュリティ」「性能」を提供できるアーキテクチャを確実に持つ
・インフラやアーキテクチャに起因した顧客インパクトがどれだけ発生したかも計測される
5、製品発見
・エンジニアリング組織の参加によって起きたイノベーションの頻度を確認する
6、エバンジェリズム
・CTOにはエンジニアリングを代表する広報担当の役割もある
・大学連携、人材採用プログラム企画、開発コミュニティへの参加など
熱狂させる製品を生み出すプロダクトマネジメント
ISBN 978-4-8207-2750-7 C2034
P107〜110
◼️Chapter19 ③デリバリーマネージャーの役割
・成長期、成熟期において多くのPdMが、PMに費やす時間が多すぎると言っている
これにより本来の製品開発責任（作る価値のある製品をエンジニアが作れるようにする仕事）に関わる仕事が疎かになる
・デリバリーマネージャーは特別な種類のPMで、*インペディメントを開発チームから取り除くことが任務
・デリバリーマネージャーはスクラムマスターでもあり、お尻に鞭を打つのではなく、邪魔な障害物を取り除く
・デリバリーマネージャーがない企業の場合、この責務はPdMとエンジニアリングマネージャー学習担う
**インペディメント（impediment）：障害、妨害するもの◆正常な進行を妨げ、遅らせるもの。
熱狂させる製品を生み出すプロダクトマネジメント
ISBN 978-4-8207-2750-7 C2034
P111〜112
◼️Chapter20 製品開発チームを構成する原則
・プロダクト作りの仕事を分けるのは開発チームが2、3になると生じ始める
・製品開発チームを構成するレシピはない
＜製品開発チーム構成を考える10の指針＞
・以下の指針を理解し、個別の状況に合わせて選択肢に重みをつけていく
1、投資戦略との連携
・時間とリスクを軸に投資を広げる考え方は無限
・未来への投資（＝売れ筋製品への投資を減らす）に目を向ける
2、依存関係を最小化
・最小化することで、開発チームはより早く動き、より大きな自律性をもつ
3、オーナーシップと自律性
・傭兵のチームでなく、「使命感で動く伝道師のチーム」
・このマインドを導くのがオーナーシップや自律性への意識
・権限を与えられていると感じ、製品提供の重要な部分に責任を持っていると感じるべき
4、レバレッジを最大化
・組織が大きくなると共通のニーズに気付き業務を集約する重要性に気づく
・ただし業務の集約は依存関係を作り、自律性とぶつかることに留意
5、製品ビジョンと戦略
・製品ビジョンとは組織として目指している場所
・製品戦略はそこに行くための主要なマイルストーン
・一度ビジョンと戦略をもったらそれに基づいて開発チームが構成されているか確認する
6、開発チームの規模
・通常より1つの開発チームの最小サイズは「2人のエンジニアと1人のPdM」
・開発チームがユーザー向けの技術に責任を持っている場合はそこに「1人のデザイナー」
・1つの開発チームに1人のPdMは鉄則
7、アーキテクチャ連携
・多くの組織は製品ビジョン → ビジョンを実現するアーキテクチャ方針 → 方針に則った組織
8、顧客との連携
・例えば買い手側と売り手側の両方を含めたマーケットプレイスを提供している場合は、買い手に絞った開発チームと売り手に絞った開発チームを作る
9、ビジネスとの連携
・複数の事業を抱えながらも製品開発のための共通基盤を持っていることが多い
・事業部門を軸とした開発チーム構成にもメリットはあるが通常は優先度は他よりも低い
10、構成は動く指標
・組織が求めるものは時間とともに変化すべきであり、それと合わせて開発チーム構成も見直す
・開発チーム構成に正解はなく必ず何かが犠牲となる、何を優先するかの方針として以上10つの指標を理解すること
熱狂させる製品を生み出すプロダクトマネジメント
ISBN 978-4-8207-2750-7 C2034
P113〜118
◼️Chapter 20_2 スケールアップにおける自律性
・開発チームのあるべき姿は「権限を持ち」「献身的で粘り強く」「職能横断型」「協力的」
・この理想の形に至っていない時は結局以下の2つのうちいずれかに当てはまる
1、チームが経営陣に信頼されておらず、経営陣は開発チームに大きな自由を与えることに抵抗を感じている
2、リーダーたちが基盤の一部とみなしてきたものを開発チームが変えたがっている
＜２つのケースにおける最適解を導き出すための9つの重要要素＞
1、開発チームのスキルレベル
2、スピードの重要性
3、統合の重要性
・製品ポートフォリオは関連があっても一つひとつが独立した製品の集合体（統合されていない）であることが多い
4、イノベーションの源泉
5、企業の規模とロケーション
6、企業の文化
7、技術の成熟
・しばしば問題になるのは時期尚早に共通基盤の標準化を行うこと
8、ビジネスにとっての重要性
9、説明責任のレベル
・権限委譲と自律性に付随する説明責任のレベル
熱狂させる製品を生み出すプロダクトマネジメント
ISBN 978-4-8207-2750-7 C2034
P119〜124
＜成功するための組織と人〜スケールアップに必要な人々〜の所感＞
企業が大きくなれば、変わることが多くなることは当然で、先手先手で動かなければ滞りが生じることも自明です。
言うは易しでしょ、と思いながら体系的に説明してもらうことでぼんやりでも頭に入れることができました。
このセクションは何度か見直すことになりそうです。
特にチーム構成の考え方の指針は目から鱗です。
組織は生き物でずっと同じでは機能しなくなります。
組織変更しなくては・・・
と思いながら
適正な人が1名いないだけで前に進めらない・・・
結局組織を細かくしか変更できない
製品ビジョンとのGAPが埋まらない
ということがありますが、「必ずトレードオフである」と説明してくれているます。
こうしたジレンマの中で10の指針に優先度をつけて考えることが肝要であるという点が最も大きな学びでした。