前提・背景
この記事はLIFULL社内で共有された感想文を少し書き換えたものです。LIFULLでは現在プロダクトマネジメントの推進やプロダクトマネージャーの役割について議論が進められていて、『EMPOWERED』はそこで話題になっていた本です。
及川さんの以下のツイートが気になって読んでみた。この本は、プロダクトマネジメント分野で有名で、社内でも最近よく読まれている『INSPIRED』の続編的な立ち位置である。
内容としては以前の記事で紹介した『ユニコーン企業のひみつ』を少し違う視点（プロダクトマネジメント寄り）で見た内容に思える。コーチングの方法などの記載が厚く、具体的にリーダーやマネジャーとして悩んでいる人は該当の章を読んでみるといいかもしれない。
この本はどういう趣旨なのか？
「機能開発チーム」と「プロダクトチーム」を比較し、一流テクノロジー企業にあるようなプロダクトチームがどのように運営されているか解説している。
- 機能開発チーム: 従来型組織で、個々のチームのアウトプット重視で動いているようなチーム
- プロダクトチーム: 一流テクノロジー企業にあるようなアウトカム重視のチーム
要するに以下の「伝道師のチーム」がプロダクトチームだと思えばいい。
有名なベンチャーキャピタリストのジョン・ドーアは、次のように好んで説明している。「私たちが求めているのは伝道師のチームだ。傭兵のチームではない」
実際にはこの他に第3のチームがあり、哲学的にも実践的にも本書とは正反対のチームである。
- デリバリーチーム（スクラムチーム、開発チームなどと呼ばれる）: 職能横断組織ですらなく、権限もないチーム。プロダクトオーナー（プロダクトバックログの管理責任者）と何人かのエンジニアが所属しており、コーディングして納品することを目標にしている。つまりアウトプットが極めて重視されている。
【感想】たしかにスクラムを教条的に行い、プロダクトオーナーだけが意思決定にコミットするような体制になるとこうなりやすいかもしれない。
プロダクトチームでは何が重視されているのか？
表でまとめておいたので、これで概要をつかんだ上で、興味のある章を読むといいと思う。
| 用語説明 | 一流のテクノロジー企業（≒プロダクトチーム） | 従来の企業（≒機能開発チーム） | |
|---|---|---|---|
| テクノロジーの役割 | - | 中核事業の実現に不可欠な存在として扱われている | やむを得ないコストとして扱われており、テクノロジーチームは真の顧客から離され、ステークホルダーを顧客だと考えさせられている |
| コーチング | 部下のスキルを開発すること | マネジャーにとって最も重要な職責である。部下に裁量権を与えずマイクロマネジメントするのではなく、部下の弱点を理解して向上の手助けをする。最低限、毎週の1on1を行おう。 | 積極的なコーチングがほとんど行われていない |
| 人事 | - | 部下を持つマネジャーはプロダクトチームの人事の責任者である。人事部はマネジャーのこうした仕事をサポートするが、いかなる形でも人事部がマネジャーの代わりに責任を負うことはできない。候補者のプールを「カルチャーフィット」で絞り込むのではなく、「イヤなやつお断り」だけをチェックして自分たちと異なる人材を探すことが薦められている。 | 必要な人員がいないという自覚はあるが、プロダクト担当者に求める資質を勘違いしている。具体的には「カルチャーフィット」を重視しているが、「自分たちと同じような外見で、同じような考え方を持った人を採用する（つまりテクノロジー業界では、一流大学の技術学位を持った男性）」ということの政治的に正しい言い換えになってしまっている。 |
| プロダクトビジョン | プロダクトビジョンは、プロダクト企業がつくろうとしている未来と、その未来が顧客の生活をどのように向上させるかを記述したものである。 | プロダクトリーダーがプロダクトビジョンをまとめている。プロダクトビジョンによって、顧客に集中し、プロダクト組織にとって共通のゴールの役割を果たしている。 | ほとんどの場合刺激的で説得力のあるプロダクトビジョンを備えていない。テクノロジーチームは機械を製造する工場で働いているように感じている |
| チームトポロジー | それぞれのチームにどのように仕事を割り振れば素晴らしい仕事ができるのかを表す用語である。チームの構造と業務の範囲、チーム同士の関係が含まれる。 | プロダクトリーダーの職責。「オーナーシップ、自律性、整合性」のバランスを取って設計する必要がある。 | チームの分け方に問題がある。他のいろいろなチームに変更を頼まなければろくに仕事ができず、従業員は巨大な組織の中の歯車にすぎないと感じている。 |
| プロダクト戦略 | ビジネスニーズを満たしつつ、プロダクトビジョンの達成をどのように計画するかを説明する。 | プロダクトリーダーの職責。絞り込んだ焦点から戦略を導き、戦略に沿ってインサイトを活用し、インサイトを行動に落とし込み、最後に仕事をマネジメントして完成まで持っていく。 ①本当に重要なことにフォーカスし、困難な選択を進んで行う ②インサイトを生み出し、特定し、活用する。インサイトはデータの分析や、顧客からの学びによって得られるものである。 ③インサイトを行動に変える ④マイクロマネジメントに陥らずに積極的なマネジメントを行う |
ほとんどの場合は戦略が無く、手持ちの人材、時間、スキルを使って、できるだけ多くのステークホルダーを満足させているにすぎない。大半の会社がサウスパークの下着ビジネス回の状況であり、まずこれを見てほしい。気が滅入るほどのムダな労力が発生し、会社が必要としている最も重要な問題に努力が払われない。 |
| チームの目標 | - | マネジャーが、それぞれのプロダクトチームに、（一般的には四半期ごとに）1つか2つの明確な目標を割り当てる。これらの目標はプロダクト戦略から直接導き、これがあることでインサイトが行動に変換される。チームは目標の説明責任を果たす。 | こうした企業もGoogleのOKRなどのテクニックを導入していることも多いが、プロダクトロードマップや社風の現状に手をつけず、その上に重ねただけだった。その結果、何週間もかけてプランニングを実施し、後はほとんど振り返らない。ほとんどのチームメンバーはOKRなどのテクニックからほとんど何も得られていないと感じている。 ミスマッチの兆候としてよくあるのが、チームが実際の問題を与えられるのではなく、作成すべきソリューション（リリース予定日やロードマップを添えて）チームに指示されている。 |
| 他部署や経営幹部との関係 | - | プロダクトリーダーは経営幹部と直接の関係を築かなければならない。顧客に愛され、ビジネスになるプロダクトを開発して顧客に奉仕することが目標であるため、ステークホルダーは協力の必要のあるパートナーになる。そのためステークホルダーの重要性は変わらないが、関係は改善する。 | 何よりもいただけないことだが、テクノロジーチームに、顧客に愛され、かつビジネスになる形で問題解決する権限がない。プロダクトマネージャーが実質的にプロジェクトマネージャーになっていて、バックログ（未処理の仕事）を管理しており、デザイナーやエンジニアはそれをこなすために存在している。当事者意識が最小限で、イノベーションもほとんど起こらない。 |
※用語
- マネジャー: 職能横断型プロダクトチームの実際のメンバーを採用し教育を行う責任者
- プロダクトリーダー: 強力なリーダーシップの目的は、組織に刺激を与え、モチベーションを上げることである
説明上は区別しているが、兼任していることも多い。リーダーにはインスピレーションが求められ、マネジャーには実行力が求められる。
どうすればエンパワーされた組織になれるのか？
大きく3つのステップに分けられる。
- 有能なプロダクトリーダーを配置しなければならない。これを行わなければ、必要なメンバーの採用やコーチングも雇えず、強固なプロダクト戦略も策定できず、リーダーやステークホルダーの信頼も得られない。だからこそ本書ではここを重視して説明した。
- メンバーの採用や教育の権限を、有能なプロダクトリーダーに与えなければならない。ほとんどの場合、プロダクトマネジャーにはさらなるレベルアップが求められるが、その他の改革が必要になる可能性もある。ただし、チーム全体を一気にレベルアップする必要はない。
- チームがプロダクトチームモデルで仕事する準備が整ったら、ビジネス全体、つまり経営陣や他部門との関係を定義しなおさなければならない。プロダクトチームでは、経営陣や他部門との関係性が変わり、協力して顧客に愛されつつビジネスとして成り立つソリューションを発案する真のパートナーになる必要がある。ここでは経営陣に歩み寄りが求められ、チームを信じて賭けてもらわなければならない。
最後にこうした組織への変革をテーマに『TRANSFORMED』という書籍を企画しているので乞うご期待、と宣伝されている😅
参考文献
- EMPOWERED 普通のチームが並外れた製品を生み出すプロダクトリーダーシップ
- HIGH OUTPUT MANAGEMENT: インテルのマネジメント方法を説明した本。90年代の内容だが、EMPOWEREDに似ている部分がかなり多い