【翻訳】ダメなプロダクトマネジメントの7つの特徴〜スクラムチームが能力を最大限に発揮できるプロダクトマネジメントとは〜
こんにちは！最近Mediumでプロダクトマネジメントの記事を読むのがブームの杉浦です。
今回はプロダクトマネジメントがチームの力を制限してしまう状況の特徴を書いているとても良い記事があったので、翻訳させていただきました。
記事の翻訳については、著者のDavid Pereiraさんから快諾いただきました。
なお、Davidさんはスクラム、プロダクトマネジメントに関する素晴らしい記事をこの他にもいくつも書いています。興味のある方は是非チェックしていただけたらと思います！
以下翻訳です。
なぜ企業は優秀なプロフェッショナルを採用するのでしょうか？
答えは簡単なはずですが、実際には複雑です。
私は、多くの優秀な人材がビジネスの世界で能力を発揮できずに窮地に立たされているのを見てきました。
理由は無限にありますが、よくあるのは次のようなものです。
・ スキルのないマネージャーが指示することで才能を制限する。
・ 複雑なプロセスと官僚主義によって、才能のある人がすべきことが妨げられる。
・ 確実性にこだわるあまり、会社のビジネスにとってより良い方法を発見することができない。
・ 未知のものを受け入れようとしないことで、最適ではない段階的な改善が行われる。
多くの企業では、人に力を与える（エンパワー）のではなく、人を陥れているように感じます。
その結果、才能が無駄になり、遅かれ早かれやる気を失って新しい機会を探し、同じサイクルを繰り返すことになります。
そして、離職率が上昇していくのですが、企業は自分たちに問題があることを受け入れられず、無視してしまうのです。
今回の記事では、私が感じた「ダメなプロダクトマネジメント」の兆候をご紹介します。
このコンテンツを読んで、あなたの状況に合わせたプロダクトマネジメントのスキルを強化する機会を見つけていただければと思います。
Photo by Torsten Dederichs on Unsplash
1.問題の理解よりソリューションを求める
ダメなプロダクトマネジメントの環境では、ソリューションがすべての焦点となります。
例えば、ロードマップには実装すべきソリューションのみが記載されており、プロダクトバックログアイテムにはソリューションが参照され、リファインメントでは開発者がソリューションの実装について議論するなどです。
要するに、ソリューションを正しく実装することが重要になっているのです。
しかし、ソリューションが解決すべき問題は、しばしば無視されます。
何日か前に、ジョン・カトラー《John Cutler》の質問を偶然見つけましたが、彼はこう言いました。
「質問ではなく答えを持ってきてくれ 」と言われたら変ですよね。私たちは「良い質問」を大切にしているようです。
しかし、なぜか「問題ではなくソリューションを持ってこい」が一般的です。なぜでしょうか？
なぜ私たちは、問題ではなくソリューションを求めるのでしょうか？
私にとっては、問題を知らずにソリューションを語っても意味がありません。
2. アウトカムよりアウトプットを重視する
次の質問のうち、どちらを聞くことが多いでしょうか？
・ 次はどのような機能を提供すべきか？
・ どのようなインパクトを与えたいのか？
私の経験では、最初のものが一般的です。
ほとんどの会話は、機能についての、何を提供すべきか、何を提供してはいけないか、などを中心に行われます。
残念ながら、これには落とし穴があります。機能に注目すると、最も重要な部分、つまりアウトカムを見逃してしまうのです。
すべての機能は、ユーザー価値とビジネス価値を生み出せないなら意味がありません。
3. ゴールよりロードマップを重視する
ここではまず、ロードマップとは何かを理解することから始めましょう。
私にとってロードマップとは、ゴールや望ましいアウトカムを定義した時間ベースの戦略的計画のことです。
意味あるロードマップは、チームがどこに向かうべきか知る案内をしてくれます。
そのため、どうやってそこに辿り着くか判断を下すことができるのです。
ロードマップは集中力を高めるために欠かせないものですが、しばしば誤った使い方をされています。
プロダクトマネジメントの成熟度が低い環境では、ロードマップは厳しい期限で提供すべき機能のセットになってしまいます。
さらに悪いことに、ゴールが存在しない。残念ながら、スクラムチームはフィーチャーファクトリーとなり、約束されたものを急いで提供するしかないでしょう。
私は、マーテン・ダルミン《Maarten Dalmijn》が「ロードマップは企業のアジリティの成熟度を定義するもの」という言葉が好きです。
彼の投稿の一部をご紹介します。
冗談を言ったとして、必ずしも笑ってもらえないのと同じで、機能を提供したからといって、価値を提供したことにはなりません。
お客様が機能をどのように受け取り、それがお客様の目標達成に役立つかどうかが重要なのです。
Maarten Dalmijn, Why roadmaps reflect the level of Agile inadequacy
4. 不滅の機能
2つの質問をさせてください。
・ 最後に機能を廃止したのはいつですか？
・ 今提供している機能の妥当性をどのくらいの頻度で見直していますか？
もしこれらの質問に答えるのに苦労したら、それはプロダクトマネジメントが弱いことの証です。
機能は単なる手段であり、重要なのは価値を届けることです。そのために役立たない機能は捨てるべきです。
しかし、なぜチームは機能を削除するのに苦労するのでしょうか？
誰だろうと何かを無駄にしている感覚は好きではないでしょう。機能を稼働させ続けるには、努力と時間が必要です。
私にとって、最初の損失は常に最も小さいものです。
価値を生まない機能を見つけたら、自分自身に問いかけてみてください。
その機能を製品に残しておくことのメリットは何か？
残しておくとどうなるのか？
将来にわたって、メンテナンス、サポート、手直し、などが起こりえます。
要するに、結局は無意味な機能に時間を費やすことになるのです。だからこそ、それらを取り除き、価値を生み出すことに時間を使ってみてはどうでしょうか。
5. ユーザーフィードバックよりステークホルダーの要望によってプロダクトの方向性が決まる
プロダクトの方向性を決めるのは、ビジネスに関するステークホルダーの希望か、それともユーザーからのフィードバックでしょうか？
もしステークホルダーの希望が、フィードバックより強い場合は問題があります。
信じられないことですが、ユーザーフィードバックはしばしば無視されます。
私は多くのスクラムチームが盲目的にプロダクトに取り組んでいるのを見てきました。スプリントが始まり終わる、ステークホルダーは新機能を手に入れ、マシンは走り続けますが、それがユーザーの生活にポジティブな変化をもたらしているかどうかは誰も評価していません。
私は、ユーザーフィードバックによって方向性を変える必要性がないというのは、大きな間違いだと考えています。
ユーザーは驚くべき存在です。自分が知っていると思っていても、ユーザーはいつもあなたに衝撃を与えます。
10年以上のプロダクトマネジメント経験の中で、ユーザーのニーズに直接マッチしたものを見たことがありません。
成功するためには、常に検査と適応が重要なのです。
6. 仮説検証なしにプロダクトを作る
プロダクトマネジメントを過信すると、無謀な行動に出てしまいます。プロダクトマネジメントでは、自分の無知を受け入れることが成功するために不可欠です。
企業が自信過剰になると、現実のユーザーに検証することなくプロダクトを作ることをチームに強制することになります。
その結果、よく知られているように、企業は誰も必要としないものを作ってお金を無駄にします。
プロダクトマネジメントがしっかりしている企業は、プロダクトを作るときに確実なものはないことを知っています。
そのため、わからないことを検証することに努めています。仮説の検証が早ければ早いほど、適切なプロダクトを簡単に作ることができるのです。
"私は生きている人間の中で最も賢い男だ、なぜなら私は一つのことを知っている、それは私が何も知らないということだ"
プラトン, 『国家』
7. 2人のドライバー：プロダクトオーナーとプロダクトマネージャー
プロダクトオーナーとプロダクトマネージャーの違いは何でしょうか？
これはもう何年も前からある質問です。マーティ・ケーガン《Mary Cagan》やメリッサ・ペリ《Melissa Perri》がやってきたようにプロダクトマネジメントの世界がこの質問に答えてきました。
この質問に私の意見を加える気はありませんが、ダメなプロダクトマネジメントに対する私の視点を共有します。
私が思うに、肩書きは関係ありませんが、プロダクトの最初から最後まで責任を持つ人は一人にすべきです。
人が増えると複雑さが増し、サイロができます。責任が2人の間で共有される場合には、混乱が唯一起こる結果です。
例えば、ある人は正しいことを見つける責任があり、別の人は正しく実行する責任があります。これは災害の完璧なレシピです。
確かに一人の人間に課せられた責任は大きいです。ただしかし混沌の中に閉じ込められるよりは、重い負担を背負った方がいいですよね。
プロダクトマネジメントの成熟度が低い場合、企業はゲームに参加する人を増やすことで複雑さを解決させます。
この場合、責任を共有することでコミットメントが不足し、薄まった結果になってしまいます。
One bus, one driver.
それでは強いプロダクトマネジメントの場合は？
先ほど、私が企業のプロダクトマネジメントレベルを評価するために、どのような兆候を見ているかをお伝えしました。
ここでは、強いプロダクトマネジメントの特徴は何かをまとめてみたいと思います。
・ 何事もソリューションではなく問題の周りで起こります。問題が理解されるまで、ソリューションはどんな会話にも含まれません。
・ アウトカムが焦点となります。チームは自分たちが生み出したいインパクトを明確にします。
・ ロードマップでは、提供したい機能ではなく、追求すべきゴールを定義します。
・ 機能がプロダクトから削除されうるのは、価値を届けていないからです。
・ ユーザーフィードバックは製品の方向性に強い影響を与えます。ユーザーにとって適切でなければ、会社にとっても正しくありません。
・ 会社は、知らないことを確認することに時間を使い、そこから生まれた問いの答えを得ることに躍起になる。
・ 一人の人間が最初から最後まで責任を持ちます。その肩書きは、プロダクトオーナーの場合もあれば、プロダクトマネージャーの場合もあります。しかし両方の役割が一緒に存在することはありません。
しっかりとしたプロダクトマネジメントは複雑です。ほとんどの企業は機能不全に陥いっており、ユーザーにより早く価値を届けることに苦労しています。
私はこのようなプロフェッショナルを制限するのではなく、優秀なプロダクトオーナーを採用し、機能不全を克服してもらいたいと思っています。