プロダクトマネジメントの感想~プロダクトオーナーはもっとチームの外のユーザに寄り添うべき
「プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける」を読んだ。
色々気づきがあったのでメモ。
「プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける」で気づきを得たことは3つある。
1つ目は、プロダクトオーナーはスクラムのチームとプロセスを外しても、スクラムに依存しない存在であり続けること。
この本では、いろんな観点や具体例から、プロダクトオーナーに必要とされる能力を描き出している。
プロダクトオーナーは、戦略に基づいてプロダクトの方向性を決めて、プロダクトを具体化する。
ただし、その実装方法まで関わらない。
2つ目は、悪いプロダクトマネージャーの典型例が面白いこと。
プロダクトマネージャーは、プロダクトのみにCEOではない。
ウェイターのように、ステークホルダーや顧客から何が欲しいのか注文を受け、開発リストを作るだけの人は、プロダクトマネージャーではない。
こういう人は、どうやって、優先順位を着けるべきか、という質問ばかりする。
それこそが彼の仕事なのに。
プロジェクトマネージャーの経験をたくさん持っている人が、その意識のままであっても、プロダクトマネージャーではない。
プロジェクトマネージャーは、いつ、という納期に責任を持つ。
プロダクトマネージャーは、なぜ、というプロダクトのビジョンに責任を持つ。
アジャイル開発では、プロジェクトマネージャーの責任はチームの中に分散され、管理責任そのものがメンバーに権限移譲されるので、プロジェクトマネージャーという存在はチーム内では不要になる。
プロジェクトマネージャーの経験が詳しくても、プロダクトマネージャーの仕事も役割も違うのだから、ビジネスや顧客、マーケット、組織を意識したマインドセットが必要になってくる。
3つ目は、SAFeを批判していること。
SAFeでは、プロダクトマネージャーはプロダクトオーナーのマネージャーであり、外部にいるユーザとの対話や管理に責任を持つ。
そして、プロダクトマネージャーは、プロダクトの要求やスコープを定義し、それをプロダクトオーナーに渡す。
SAFeのプロダクトオーナーは、内部に目を向けて、開発チームと一緒に、プロダクトバックログを作成して、その優先順位を決定することに注力する。
このやり方では、プロダクトオーナーはユーザーから切り離されて、顧客の問題を理解しようとしないから、効果的な解決策を提示できない。
プロダクトマネージャーからプロダクトオーナーへ、WF型開発のように、要求や要件が上から落ちてきて、それを詳細化していく役割に準じてしまう。
プロダクトオーナーは、そもそも、落ちてきた要件が本当に作るべきものなのか、検証することも許されていないからだ、と。
確かに、SAFeでは、複数のスクラムチームがアジャイルリリーストレインによって、リリース時期を同期させるように開発を進める。
そこでは、プロダクトオーナーもスクラムマスターも、アジャイルリリーストレインという満員電車の中に組み込まれていて、彼らが自発的に、自分たちが作っているもの自身を疑ったり、検証したりすることは推奨されていない。
そういう意味では、SAFeはトップダウン式の開発スタイルであり、スクラムの精神からズレている部分もあるのだろう。
スクラムを理解する時、プロダクトオーナーという役割は正直理解しにくいと思う。
スクラムマスターの役割は、アジャイル開発を進めていくと、そういうファシリテーターのような役割が必要になることは体験できる。
しかし、プロダクトオーナーの役割は、アジャイル開発以前に、顧客やマーケットの要求や組織のビジョンを元に、どんなグランドデザインを描いてプロダクトに落とし込むか、という別のスキルが要求されるので、難しいと感じる。
SAFeのプロダクトオーナーのように、上から滝のように落ちてきた要件を拾い集めて、優先順位付けすることが彼の役割ではないのだ。
プロダクトオーナーの役割が曖昧になりやすい理由は2つあると思う。
1つ目は、スクラムの誕生時には、スクラムマスターと開発チームは存在していたが、プロダクトオーナーが存在していなかった背景も絡んでいるのではないか。
実際、「スクラム 仕事が4倍速くなる“世界標準”のチーム戦術」では、サザーランドがスクラムを生み出した時、スクラムマスターと開発チームでアジャイルに開発を進めた経験があったが、その後の経緯から、プロダクトオーナーが生まれた、という文章があった。
2つ目は、市谷さん著作「正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について」の通り、高速にアジャイルに開発できることと、ユーザの価値を最大限に活かすような製品をリリースすることは別次元の話だから。
アジャイル開発プロセスを実践できるチームであっても、プロダクトのビジョンやプロダクトの方向性が間違っていれば、ゴミを高速に出しているのと同じ。
正しいものを作ることと正しく作ることは違うよ、と。
| 固定リンク
「Agile」カテゴリの記事
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- 概念モデリングや設計原則は進化しているのか(2023.10.21)
コメント