【翻訳】ハイパフォーマンスチームを作るためにプロダクトオーナーがすべき10のこと
みなさんこんにちは。@ryuzeeです。
スクラムにおいて、スクラムチーム全体のパフォーマンスをどのようにして上げていくかは難しいテーマですが、プロダクトオーナーの視点でこれを捉えた「10 things you must do to build high-performing Scrum Teams as a Product Owner」という記事が良い記事だったので、翻訳したものをご紹介します。
翻訳に際しては、著者のMaarten Dalmijnさんに快諾いただきました。 なお、著者のMaartenさんはほかにもプロダクトオーナーに関する有用な記事を書いているので、参考にするとよいかと思います。
プロダクトオーナーの開発チームへの関わり方は、開発チームのパフォーマンスにおいてとても重要です。ダメなプロダクトオーナーだと、ハイパフォーマンスチームを簡単に潰してしまう可能性があります。
私は、長年に渡って、たくさんの会社でたくさんのチームを立ち上げてきました。チームが機能していないときに、チームが私に修正や改善を求めてきたことも多々ありました。その結果、ハイパフォーマンスのスクラムチームを作るためにプロダクトオーナーとしてできる重要なことは何なのかがわかりました。
以下では、私の経験を踏まえて、ハイパフォーマンスなスクラムチームを作る上でやるべきことを10個紹介します。あわせて理解を深めて、最初の一歩を踏み出すのに役立つ25個以上の記事を紹介します。
1. 顧客の痛みとニーズを理解する
プロダクトではなくユーザーをアップグレードしよう。良いカメラを作るのではなく、良い写真家を作ろう
キャシー・シエラ
そもそも人はあなたのプロダクトが欲しいわけではありません。自分たちの生活をよくしてくれること、つまりプロダクトが提供する進歩を求めています。
顧客の痛み、欲求、願望、問題点を理解することに焦点を当てなければいけません。
あわせて読もう
- Jobs To Be Done theory helps you to create better products
- LinkedIn Gets Jobs to be Done
- A Script to Kickstart Your Jobs To Be Done Interviews
- Jobs to be done personas
2. 価値の提供をチームの仕事にする
価値あるプロダクトを届けるのはチームとしての仕事です。スクラムチーム全体として、どうやって顧客とビジネスに価値を届けるかを確実に理解しておかなければいけません。最高の結果を出すには何を作るとよいかを決めるときには、スクラムチームを積極的に議論に参加させてるようにしてください。
チームをフィーチャーファクトリーのように扱えば、フィーチャーファクトリーになります。価値を提供できるかどうかわからない機能を一生懸命作ってしまいます。
あわせて読もう
3. 失敗しても安全な環境を作る
失敗という選択肢がないなら、成功も選択肢にはない。
セス・ゴーディン
どのスプリントでもチームが失敗する可能性はあります。失敗したときにチームをどう扱うかが成功への分かれ道です。将来の成功に役立つ学びを得ようとしているのであれば、失敗は問題ないはずです。
パトリック・レンシオーニによるチームの5つの機能不全のモデルでは、ハイパフォーマンスチームを作る上でなぜ心理的安全性が必須なのかを説明しています。心理的安全性があることでチームメンバーは安心してリスクを取ったり、みんなに対して自分の弱いところを見せたりできるようになります。
チームの5つの機能不全のモデルは、グーグルのプロジェクト・アリストテレスでも裏付けが取れています。このプロジェクトの調査結果によると、心理的安全性はチームにスーパースターがいることよりも重要です。
スクラムを機能させる上でも、心理的安全性は不可欠です。プロセスのフレームワークは、実験や失敗を許容する心理的安全性の土台があるからこそ、より良い作業プロセスにつながるのです。
あわせて読もう
- Lencioni’s 5 Dysfunctions of a Team
- re:work: research from Project Aristotle at Google
- If you are not flexible, you are not doing Scrum
- Valuable Failures
4. 適切なところに労力を集中する
シンプルであることは、複雑であることよりもむずかしいときがある。物事をシンプルにするためには、懸命に努力して思考を明瞭にしなければならないからだ。だが、それだけの価値はある。なぜなら、ひとたびそこに到達できれば、山をも動かせるからだ。
スティーブ・ジョブズ
プロダクトオーナーのいちばん大事な仕事は、フォーカスを作り出すことです。重要なものが目立つようにするため、重要でないものを排除してください。そうしないと、重要でないものがプロダクトの価値を薄めてしまいます。
スクラムでは、スプリントごとに明瞭なスプリントゴールを用意するように言っています。これによってプロダクトオーナーが集中しやすくなります。
しかしスプリントゴールだけでは不十分です。複数のスプリントゴールの一貫性を保つためには、包括的なプロダクトビジョンやプロダクト戦略が必要です。
あわせて読もう
- WTF is Strategy?
- What is Product Vision?
- The only thing that matters when planning a Sprint
- Apply FOCUS to set great Sprint Goals
- The Sprint Goal
5. デリバリーを始める前にディスカバリーを行う
多くの企業でいまだにフィーチャーファクトリーのモードにはまっています。そこでは、チームが新しい機能を量産することが良しとされています。ですが、誰かが頼んだからといって、すぐに機能を作るという誘惑には負けないでください。学習が最初で、作るのはそのあとです。学習を優先してください。そうすれば成功のために実際に必要な機能がわかります。
機能を作る前に、顧客が必要としていることをなるべくたくさん知れるように、実験してエビデンスを集めましょう。小さくてより良いものを目指してください。ときには作るのと学習するのを同時にやるのが理にかなっていることもあります。
いきなり作るというのは、それが適切なものを作れる可能性を増やせる最善の方法だと判断できるような、意図的な場合だけにしてください。
いったん機能がプロダクトのなかに組み込まれたら、それが削除される可能性はどれくらいでしょうか?これが新しい機能を作るときに十分に注意しなければいけない理由です。仮説を作るところから始めて、途中で目標を達成できたかどうかを評価してください。
あわせて読もう
- 14 Signs you’re working in a Scrum Feature Factory
- Professional Scrum UX
- Here is how UX Design Integrates with Agile and Scrum
- Agile vs Lean vs Design Thinking
6. プロダクトバックログを短く保つ
プロダクトバックログを単なる思いつきややりそうもないことで汚染すべきではありません。プロダクトバックログは牛乳のように扱ってください。直近で十分なだけの量にして、それ以上は不要です。そうしないとプロダクトバックログは陳腐化して、新鮮な状態に戻すのに労力が必要になってしまいます。
あわせて読もう
7. プロダクトバックログアイテムを一生懸命書きすぎない
多くのプロダクトオーナーはプロダクトバックログアイテムを書くのにとても多くの時間を使っています。こんなことはしないでください!時間のムダですし、これはスクラムチームにとって価値はありません。何かを適切に作るのには役に立ちますが、適切なものを作る役には立ちません。経験上、プロダクトオーナーは自分の時間の20%の時間をデリバリーに使い、80%はディスカバリーと検証に使うべきです。
解決しようとしている問題を理解することに集中し、情報を開発チームにも伝えましょう。それから一緒にプロダクトバックログアイテムを作ってください。そうすることであなたの頭のなかにしかないプロダクトではなく、スクラムチーム全体の動作するプロダクトになります。みんなで一緒にやることで、共通理解を持てるようになり、必要なことを忘れずに済むようになります。
最後に。書いてあることは重要ではありません。開発チームがどう理解しているかこそが重要です。
あわせて読もう
8. 使われていない機能、価値を生まない機能をプロダクトから取り除く
すべての機能はプロダクトに価値を与えてその役割を果たすものでなければいけません。自分の重さを支えられないような機能は、プロダクトの価値を薄めてしまいます。もっと酷いかもしれません。使われていない機能は、生きていくためにお金を燃やしてしまう寄生虫のようなものです。これには、新しいバージョンのプロダクトを動かすためのインフラのコスト、本番環境での障害への対応コスト、保守コストなども含まれます。こんな寄生虫が足手まといになっていては、アジャイルではいられません。
こういった寄生虫の機能は速やかに削除してください。そうすればもっと価値があることに取り組む余裕ができて、多くのお金を節約することができます。
使われていない機能の削除は以下の2つの理由から大変です。
- プロダクトのどの機能が本当に重要なのかを把握するのが難しい。とくに顧客に対してどうやって価値を届けているかを理解できていない場合はそれが顕著
- 人は新しいものを手に入れることより、今あるものを失うことを嫌う。これは損失嫌悪と呼ばれる。なのでほんの少しの顧客しか、あるマイナーな機能を使っていなくても、持っているものを失うのが嫌という理由で声を荒げてしまう
あわせて読もう
9. チームにソリューションを考えてもらいつつ、チームに問いを投げかける
プロダクトオーナーは、解決したい問題を説明することに集中すべきです。技術的なソリューションを考えるのはあなたの仕事ではありません。しかし技術的なソリューションこそがほとんどの価値を届けていることを認識しておかなければいけません。
チームが複雑すぎるソリューションを考えてきた場合には、その複雑さが本当に必要なのか問いを投げかけてください。ソリューションはできる限りシンプルなものにすべきです。
あわせて読もう
10. ステークホルダーは管理するのではなく巻き込む
ステークホルダーが不幸だと、あなたのプロダクトオーナーとしての仕事が不可能になってしまう可能性があります。そのため、ステークホルダーが幸せであり続ける方法を見つけることは本当に重要です。いちばん良い方法は、ステークホルダーを管理するのではなく、巻き込むことです。いちばん重要なステークホルダーを巻き込む簡単な方法は、次回のスプリントレビューに招待することです。
あわせて読もう
それでは!
SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発
- 著者/訳者:西村 直人、 永瀬 美穂、 吉羽 龍太郎
- 出版社:翔泳社
- 発売日:2020-05-20
- 単行本(ソフトカバー):288ページ
- ISBN-13:9784798163680
- ASIN:4798163686
みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた
- 著者/訳者:Matt LeMay、 及川 卓也(まえがき)、 吉羽 龍太郎、 永瀬 美穂、 原田 騎郎、 有野 雅士
- 出版社:オライリージャパン
- 発売日:2020-03-19
- 単行本(ソフトカバー):216ページ
- ISBN-13:9784873119090
- ASIN:487311909X
レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
- 著者/訳者:David Scott Bernstein、吉羽 龍太郎、永瀬 美穂、原田 騎郎、有野 雅士
- 出版社:オライリージャパン
- 発売日:2019-09-18
- 単行本(ソフトカバー):300ページ
- ISBN-13:9784873118864
- ASIN:4873118867