ブログ

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

誰がプロダクトオーナーをやるとよいのか?

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

最近立て続けにプロダクトオーナーを誰がやるとよいのか聞かれることがあったので、パターンとメリット・デメリットを整理しておきます。 なお、組織のサイズや業種、扱っているプロダクトによっても変わってくるので、考え方のロジックとして読んでいただければと思います。

プロダクトオーナーとは?

まず最初に前提として、プロダクトオーナーの責任ややるべきことをスクラムガイド(2017)で確認しましょう。

5ページ:プロダクトオーナー

プロダクトオーナーは、開発チームから生み出されるプロダクトの価値の最大化に責任を持つ。組織・スクラムチーム・個人によって、その方法はさまざまである。 プロダクトオーナーは、プロダクトバックログの管理に責任を持つ1人の人間である。 (中略) プロダクトオーナーは1人の人間であり、委員会ではない。委員会の要求をプロダクトバックログに反映することもあるだろうが、プロダクトバックログアイテムの優先順位の変更については、プロダクトオーナーと相談しなければいけない。 プロダクトオーナーをうまく機能させるには、組織全体でプロダクトオーナーの決定を尊重しなければいけない。プロダクトオーナーの決定は、プロダクトバックログの内容や並び順という形で見える化されている。異なる要求の作業を開発チームに強制することは誰にもできない。

9ページ:スプリントプランニング(トピック1)

プロダクトオーナーは、スプリントで達成すべき目的と、完成すればスプリントゴールを達成できそうなプロダクトバックログアイテムについて検討する。スクラムチームはみんなで協力して、スプリントの作業を理解する。

10ページ:スプリントプランニング(トピック2)

プロダクトオーナーは、選択したプロダクトバックログアイテムの明確化やトレードオフを支援する。

11ページ:スプリントレビュー

プロダクトオーナーは、プロダクトバックログアイテムの「完成」したものと「完成」していないものについて説明する。 (中略) プロダクトオーナーは、現在のプロダクトバックログの状況を説明する。(必要であれば)現在の進捗から、可能性のある目標とデリバリーの日程を予測する。

12ページ:プロダクトバックログ

プロダクトバックログは、プロダクトに必要だと把握しているものをすべて順番に並べた一覧である。 プロダクトに対する変更要求の唯一の情報源である。プロダクトオーナーは、プロダクトバックログの内容・可用性・並び順に責任を持つ。

13ページ:プロダクトバックログリファインメント

プロダクトバックログに含まれるアイテムに対して、詳細の追加、見積り、並び替えをすることを、プロダクトバックログのリファインメントと呼ぶ。これはプロダクトオーナーと開発チームが協力して行う継続的なプロセスである。

13ページ:ゴールへの進捗を追跡する

プロダクトオーナーは、少なくともスプリントレビューにおいて、この残作業の合計を追跡する。プロダクトオーナーは、前回のスプリントレビュー時点の残作業の合計と比較して、希望する期日までにゴールに到達できるかどうかを評価する。この情報はステークホルダー全員に明らかにする。

雑にまとめると、プロダクトオーナーは、プロダクトの価値を最大化する責任を負い、プロダクトバックログの管理の責任を持ち、開発チームにどの順番で何を作ってもらうかを都度決定するとともに、全体の進捗を明らかにすることになります。かなり大変そうです。

では、ここからは、これを組織の誰がやると良いのか、それぞれのメリット・デメリットなどを見ていきましょう。

事業責任者がプロダクトオーナーを担う

プロダクトを開発するということは、そこに事業があります。プロダクト自体は、事業を達成するための1要素ということになり、ほかにもマーケティングやサポート、営業などさまざまな要素が登場します。 事業責任者がプロダクトオーナーを担うということは、大きい会社であれば、たとえば事業部長が担うようなものです。スタートアップであれば創業者が該当することになるでしょう。

  • メリット
    • 予算を持っており、意思決定権限が強いので、プロダクトに対する判断を素早くできる。たとえば予算やチームメンバーを追加したり、リリーススケジュールを変更したりするということも比較的容易
  • デメリット
    • プロダクト以外の仕事も多数持っていることが多いので、継続的にスクラムプロセスに関与し続けること自体が難しいことが多い。たとえばイベントにプロダクトオーナーが来れず日程調整をするようなことが増え、プロセスのリズムが悪くなったり、プロダクトバックログの手入れが十分に行き届かず見切り発車が増える
    • ほかの人に比べて立場が上であることが多く、開発チームとの間で健全な交渉が行われなかったり、フィードバックループが弱くなりやすい

個人的には、組織のサイズが小さいうちしか機能しないのではないかと思います。

ビジネスサイドの人がプロダクトオーナーを担う

たとえば、企画担当の人がプロダクトオーナーを担う例です。ある一定規模の組織になると、最初に出た事業のアイデアを具現化していくのに企画担当の人が参画して、詳細化していくことがよくあります。その上で投資判断などを経てゴーサインがかかります。このとき、引き続きその人がプロダクトオーナーになるイメージです。

  • メリット
    • ビジネスのことが分かっている(ドメイン知識がある)ので、どの順番に何をつくると良いかの判断がしやすい(意思決定の権限を事業責任者から適切に移譲されていることが前提になる)
  • デメリット
    • 技術的な知識がないことがあるため、性能やセキュリティ、運用といった非機能要件に関するプロダクトバックログアイテムを用意できなかったり重要性の判断を間違えることがある(そのためスクラムマスターや開発チームがプロダクトバックログの管理を支援するのに時間を使う必要がある)
    • 組織として企画は平行して複数進めるようになっている場合、プロダクトオーナーが忙しくなりやすい

個人的には、プロダクトが生み出す成果に焦点をあてるといちばん成果を出しやすいように思います。

UXデザイナーやアーキテクトの人がプロダクトオーナーを担う

企画が通ったあとに、それをUXデザイナーやアーキテクトなどエンジニアリングに近い人に引き渡して、進めていくやり方です。 組織構造上、企画部門と開発部門が分かれているような場合によく見られる形態です。

  • メリット
    • 全体の使い勝手や、プロダクトにあった品質やアーキテクチャの構築という観点が考慮された状態でバランスを取って開発を進められる
    • 開発チームと近いスキルセットなので、開発チームとのコミュニケーションは円滑に進みやすい
  • デメリット
    • プロダクトのビジョンを開発チームに伝え続けるのが大変
    • プロダクトバックログの並び順や、機能をどの深さまで作るのかという点をプロダクトオーナーだけで判断することができず、企画側などのステークホルダーと常時交渉と調整が必要になる。関係性によっては常時プレッシャーをかけられることもある
    • 時に、作りすぎてしまう可能性がある

顧客がプロダクトオーナーを担う

受託開発の文脈で検討することのある形態で、発注者側がプロダクトオーナーを担当し、スクラムマスターと開発チームを受注者側が担当する、というような形です。こう書いている時点で辛さが満載な気がします。

  • メリット
    • 顧客が自分自身の責任でドライブできる
  • デメリット
    • いままでのやり方と関与の度合いが変わってくるが、その時間を捻出できず、開発チームに十分な時間が使えない
    • 発注側のマインドセットのままで、対立構造となってフィードバックループが形成されない
    • プロセスを無視して、要求を押し付けてしまいやすい
    • 開発チーム側がプロダクトの価値を理解できなかったり、プロダクトバックログアイテムごとの意図が分からないままに、開発しなければいけないようなことが起こりやすい

まとめ

プロダクトオーナーはやることがたくさんあるため、ボトルネックになりやすい存在です。 プロダクトオーナーがボトルネックになるのを避けるためには、プロダクトオーナーに適切な権限を持たせることが何より重要です(なんでもかんでもステークホルダーと調整していては進まなくなります)。また、その上で、プロダクトオーナーがプロセスを理解して、継続的に関与し続けなければといけません。それができる人をプロダクトオーナーにするのが良いでしょう。

それでは。

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

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

詳細はこちら
  • スクラム実践者が知るべき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』の著者がコンパクトにまとめた変化のためのガイドブック