ブログ

ryuzeeによるブログ記事。不定期更新

【翻訳】ハイパフォーマンスチームを作るためにプロダクトオーナーがすべき10のこと

みなさんこんにちは。@ryuzeeです。

スクラムにおいて、スクラムチーム全体のパフォーマンスをどのようにして上げていくかは難しいテーマですが、プロダクトオーナーの視点でこれを捉えた「10 things you must do to build high-performing Scrum Teams as a Product Owner」という記事が良い記事だったので、翻訳したものをご紹介します。

翻訳に際しては、著者のMaarten Dalmijnさんに快諾いただきました。 なお、著者のMaartenさんはほかにもプロダクトオーナーに関する有用な記事を書いているので、参考にするとよいかと思います。

プロダクトオーナーの開発チームへの関わり方は、開発チームのパフォーマンスにおいてとても重要です。ダメなプロダクトオーナーだと、ハイパフォーマンスチームを簡単に潰してしまう可能性があります。

私は、長年に渡って、たくさんの会社でたくさんのチームを立ち上げてきました。チームが機能していないときに、チームが私に修正や改善を求めてきたことも多々ありました。その結果、ハイパフォーマンスのスクラムチームを作るためにプロダクトオーナーとしてできる重要なことは何なのかがわかりました。

以下では、私の経験を踏まえて、ハイパフォーマンスなスクラムチームを作る上でやるべきことを10個紹介します。あわせて理解を深めて、最初の一歩を踏み出すのに役立つ25個以上の記事を紹介します。

1. 顧客の痛みとニーズを理解する

プロダクトではなくユーザーをアップグレードしよう。良いカメラを作るのではなく、良い写真家を作ろう
キャシー・シエラ

そもそも人はあなたのプロダクトが欲しいわけではありません。自分たちの生活をよくしてくれること、つまりプロダクトが提供する進歩を求めています。
顧客の痛み、欲求、願望、問題点を理解することに焦点を当てなければいけません。

あわせて読もう

2. 価値の提供をチームの仕事にする

価値あるプロダクトを届けるのはチームとしての仕事です。スクラムチーム全体として、どうやって顧客とビジネスに価値を届けるかを確実に理解しておかなければいけません。最高の結果を出すには何を作るとよいかを決めるときには、スクラムチームを積極的に議論に参加させてるようにしてください。

チームをフィーチャーファクトリーのように扱えば、フィーチャーファクトリーになります。価値を提供できるかどうかわからない機能を一生懸命作ってしまいます。

あわせて読もう

3. 失敗しても安全な環境を作る

失敗という選択肢がないなら、成功も選択肢にはない。
セス・ゴーディン

どのスプリントでもチームが失敗する可能性はあります。失敗したときにチームをどう扱うかが成功への分かれ道です。将来の成功に役立つ学びを得ようとしているのであれば、失敗は問題ないはずです。

パトリック・レンシオーニによるチームの5つの機能不全のモデルでは、ハイパフォーマンスチームを作る上でなぜ心理的安全性が必須なのかを説明しています。心理的安全性があることでチームメンバーは安心してリスクを取ったり、みんなに対して自分の弱いところを見せたりできるようになります。

チームの5つの機能不全のモデルは、グーグルのプロジェクト・アリストテレスでも裏付けが取れています。このプロジェクトの調査結果によると、心理的安全性はチームにスーパースターがいることよりも重要です。

スクラムを機能させる上でも、心理的安全性は不可欠です。プロセスのフレームワークは、実験や失敗を許容する心理的安全性の土台があるからこそ、より良い作業プロセスにつながるのです。

あわせて読もう

4. 適切なところに労力を集中する

シンプルであることは、複雑であることよりもむずかしいときがある。物事をシンプルにするためには、懸命に努力して思考を明瞭にしなければならないからだ。だが、それだけの価値はある。なぜなら、ひとたびそこに到達できれば、山をも動かせるからだ。
スティーブ・ジョブズ

プロダクトオーナーのいちばん大事な仕事は、フォーカスを作り出すことです。重要なものが目立つようにするため、重要でないものを排除してください。そうしないと、重要でないものがプロダクトの価値を薄めてしまいます。

スクラムでは、スプリントごとに明瞭なスプリントゴールを用意するように言っています。これによってプロダクトオーナーが集中しやすくなります。

しかしスプリントゴールだけでは不十分です。複数のスプリントゴールの一貫性を保つためには、包括的なプロダクトビジョンやプロダクト戦略が必要です。

あわせて読もう

5. デリバリーを始める前にディスカバリーを行う

多くの企業でいまだにフィーチャーファクトリーのモードにはまっています。そこでは、チームが新しい機能を量産することが良しとされています。ですが、誰かが頼んだからといって、すぐに機能を作るという誘惑には負けないでください。学習が最初で、作るのはそのあとです。学習を優先してください。そうすれば成功のために実際に必要な機能がわかります。

機能を作る前に、顧客が必要としていることをなるべくたくさん知れるように、実験してエビデンスを集めましょう。小さくてより良いものを目指してください。ときには作るのと学習するのを同時にやるのが理にかなっていることもあります。
いきなり作るというのは、それが適切なものを作れる可能性を増やせる最善の方法だと判断できるような、意図的な場合だけにしてください。

いったん機能がプロダクトのなかに組み込まれたら、それが削除される可能性はどれくらいでしょうか?これが新しい機能を作るときに十分に注意しなければいけない理由です。仮説を作るところから始めて、途中で目標を達成できたかどうかを評価してください。

あわせて読もう

6. プロダクトバックログを短く保つ

プロダクトバックログを単なる思いつきややりそうもないことで汚染すべきではありません。プロダクトバックログは牛乳のように扱ってください。直近で十分なだけの量にして、それ以上は不要です。そうしないとプロダクトバックログは陳腐化して、新鮮な状態に戻すのに労力が必要になってしまいます。

あわせて読もう

7. プロダクトバックログアイテムを一生懸命書きすぎない

多くのプロダクトオーナーはプロダクトバックログアイテムを書くのにとても多くの時間を使っています。こんなことはしないでください!時間のムダですし、これはスクラムチームにとって価値はありません。何かを適切に作るのには役に立ちますが、適切なものを作る役には立ちません。経験上、プロダクトオーナーは自分の時間の20%の時間をデリバリーに使い、80%はディスカバリーと検証に使うべきです。

解決しようとしている問題を理解することに集中し、情報を開発チームにも伝えましょう。それから一緒にプロダクトバックログアイテムを作ってください。そうすることであなたの頭のなかにしかないプロダクトではなく、スクラムチーム全体の動作するプロダクトになります。みんなで一緒にやることで、共通理解を持てるようになり、必要なことを忘れずに済むようになります。

最後に。書いてあることは重要ではありません。開発チームがどう理解しているかこそが重要です。

あわせて読もう

8. 使われていない機能、価値を生まない機能をプロダクトから取り除く

すべての機能はプロダクトに価値を与えてその役割を果たすものでなければいけません。自分の重さを支えられないような機能は、プロダクトの価値を薄めてしまいます。もっと酷いかもしれません。使われていない機能は、生きていくためにお金を燃やしてしまう寄生虫のようなものです。これには、新しいバージョンのプロダクトを動かすためのインフラのコスト、本番環境での障害への対応コスト、保守コストなども含まれます。こんな寄生虫が足手まといになっていては、アジャイルではいられません。

こういった寄生虫の機能は速やかに削除してください。そうすればもっと価値があることに取り組む余裕ができて、多くのお金を節約することができます。

使われていない機能の削除は以下の2つの理由から大変です。

  1. プロダクトのどの機能が本当に重要なのかを把握するのが難しい。とくに顧客に対してどうやって価値を届けているかを理解できていない場合はそれが顕著
  2. 人は新しいものを手に入れることより、今あるものを失うことを嫌う。これは損失嫌悪と呼ばれる。なのでほんの少しの顧客しか、あるマイナーな機能を使っていなくても、持っているものを失うのが嫌という理由で声を荒げてしまう

あわせて読もう

9. チームにソリューションを考えてもらいつつ、チームに問いを投げかける

プロダクトオーナーは、解決したい問題を説明することに集中すべきです。技術的なソリューションを考えるのはあなたの仕事ではありません。しかし技術的なソリューションこそがほとんどの価値を届けていることを認識しておかなければいけません。

チームが複雑すぎるソリューションを考えてきた場合には、その複雑さが本当に必要なのか問いを投げかけてください。ソリューションはできる限りシンプルなものにすべきです。

あわせて読もう

10. ステークホルダーは管理するのではなく巻き込む

ステークホルダーが不幸だと、あなたのプロダクトオーナーとしての仕事が不可能になってしまう可能性があります。そのため、ステークホルダーが幸せであり続ける方法を見つけることは本当に重要です。いちばん良い方法は、ステークホルダーを管理するのではなく、巻き込むことです。いちばん重要なステークホルダーを巻き込む簡単な方法は、次回のスプリントレビューに招待することです。

あわせて読もう

それでは!

アジャイルコーチングやトレーニングを提供しています

株式会社アトラクタでは、アジャイル開発に取り組むチーム向けのコーチングや、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください。

詳細はこちら
  • スクラム実践者が知るべき97のこと
  • 著者/訳者:Gunther Verheyen / 吉羽龍太郎 原田騎郎 永瀬美穂
  • 出版社:オライリージャパン(2021-03-23)
  • 定価:¥ 2,640
  • スクラムはアジャイル開発のフレームワークですが、その実装は組織やチームのレベルに応じてさまざまです。本書はスクラムの実践において、さまざまな課題に対処してきた実践者が自らの経験や考え方を語るエッセイ集です。日本語書き下ろしコラムを追加で10本収録
  • プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
  • 著者/訳者:Melissa Perri / 吉羽龍太郎
  • 出版社:オライリージャパン(2020-10-26)
  • 定価:¥ 2,640
  • プロダクト開発を作った機能の数やベロシティなどのアウトプットで計測すると、ビルドトラップと呼ばれる失敗に繋がります。本書ではいかにしてビルドトラップを避けて顧客に価値を届けるかを解説しています。
  • SCRUM BOOT CAMP THE BOOK 【増補改訂版】
  • 著者/訳者:西村直人 永瀬美穂 吉羽龍太郎
  • 出版社:翔泳社(2020-05-20)
  • 定価:¥ 2,640
  • スクラム初心者に向けて基本的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。
  • みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた
  • 著者/訳者:Matt LeMay / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン(2020-3-19)
  • 定価:¥ 2,640
  • アジャイルで本当の意味での成果を出すには、開発チームだけでアジャイルに取り組むのではなく、組織全体がアジャイルになる必要があります。本書にはどうやってそれを実現するかのヒントが満載です
  • レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
  • 著者/訳者:David Scott Bernstein / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン( 2019-9-18 )
  • 定価:¥ 3,132
  • レガシーコードになってから慌てるのではなく、日々レガシーコードを作らないようにするにはどうするか。その観点で、主にエクストリームプログラミングに由来する9つのプラクティスとその背後にある原則をわかりやすく説明しています。
  • Effective DevOps ―4本柱による持続可能な組織文化の育て方
  • 著者/訳者:Jennifer Davis、Ryn Daniels / 吉羽 龍太郎、長尾高弘
  • 出版社:オライリージャパン( 2018-3-24 )
  • 定価:¥ 3,888
  • 主にDevOpsの文化的な事柄に着目し、異なるゴールを持つチームが親和性を高め、矛盾する目標のバランスを取りながら最大限の力を発揮する方法を解説します
  • ジョイ・インク 役職も部署もない全員主役のマネジメント
  • 著者/訳者:リチャード・シェリダン / 原田騎郎, 安井力, 吉羽龍太郎, 永瀬美穂, 川口恭伸
  • 出版社:翔泳社( 2016-12-20 )
  • 定価:¥ 1,944
  • 米国で何度も働きやすい職場として表彰を受けているメンローの創業者かつCEOであるリチャード・シェリダン氏が、職場に喜びをもたらす知恵や経営手法、より良い製品の作り方などを惜しみなく紹介しています
  • アジャイルコーチの道具箱 – 見える化の実例集
  • 著者/訳者:Jimmy Janlén / 原田騎郎, 吉羽龍太郎, 川口恭伸, 高江洲睦, 佐藤竜也
  • 出版社:Leanpub( 2016-04-12 )
  • 定価:$14.99
  • この本は、チームの協調とコミュニケーションを改善したり、行動を変えるための見える化の実例を集めたものです。96個(+2)の見える化の方法をそれぞれ1ページでイラストとともに解説しています。アジャイル開発かどうかに関係なくすぐに使えるカタログ集です
  • カンバン仕事術 ―チームではじめる見える化と改善
  • 著者/訳者:原田騎郎 安井力 吉羽龍太郎 角征典 高木正弘
  • 出版社:オライリージャパン( 2016-03-25 )
  • 定価:¥ 2,138
  • チームの仕事や課題を見える化する手法「カンバン」について、その導入から実践までを図とともにわかりやすく解説した書籍。カンバンの原則などの入門的な事柄から、サービスクラス、プロセスの改善など、一歩進んだ応用的な話題までを網羅的に解説します。
  • Software in 30 Days スクラムによるアジャイルな組織変革“成功"ガイド
  • 著者/訳者:Ken Schwaber、Jeff Sutherland著、角征典、吉羽龍太郎、原田騎郎、川口恭伸訳
  • 出版社:アスキー・メディアワークス( 2013-03-08 )
  • 定価:¥ 1,680
  • スクラムの父であるジェフ・サザーランドとケン・シュエイバーによる著者の日本語版。ビジネス層、マネジメント層向けにソフトウェア開発プロセス変革の必要性やアジャイル型開発プロセスの優位性について説明
  • How to Change the World 〜チェンジ・マネジメント3.0〜
  • 著者/訳者:Jurgen Appelo, 前川哲次(翻訳), 川口恭伸(翻訳), 吉羽龍太郎(翻訳)
  • 出版社:達人出版会
  • 定価:500円
  • どうすれば自分たちの組織を変えられるだろう?それには、組織に変革を起こすチェンジ・マネジメントを学習することだ。アジャイルな組織でのマネージャーの役割を説いた『Management 3.0』の著者がコンパクトにまとめた変化のためのガイドブック