スクラムにおいてプロダクトオーナーはどこまで「権限＋オーナーシップ」を持てるのか？

はじめに

今回はスクラムにおいての役割の1つであるプロダクトオーナーの「権限とオーナーシップ」について、自身の経験を踏まえて書いてみたいと思います。おそらく各組織チームによって状況も違うと思うので1つの答えは出ないと思いますが皆様の参考になれば。

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

まずはスクラムにおいてのプロダクトオーナーとは

スクラムガイド2020年11月 より

ここで定義されているように、一番の役割は「プロダクトの価値を最大化することの結果に責任を持つ」になります。主にはプロダクトバックログを管理し、優先順位を決めていきます。開発チームに対して指示は出しませんが、全体の状況把握は必要になります。

「プロダクトの価値を最大化することの結果に責任を持つ」

とっても重要そうな役割ですよね。
価値とはなんでしょうか？売上？ユーザー数？品質？ブランド力？いろいろありそうですよね。

そして企業や組織の中で、1プロダクトオーナーがここに結果責任を持つというのは果たして出来るのか？という疑問が出てきます。

とは言っても、基本的にはスクラム開発の中で、プロダクトオーナーが言葉通り「権限＋オーナーシップ」を持っていない場合はなかなかうまくいきません。

このような状況は胸が痛くなりますね…

ただ現実的には予算に対する権限を持っている、持っていないだったり、プロダクトに関する最終決定権の範囲であったりは組織や状況により様々でしょう。スクラムガイド通りにすべてがスムーズにいくことは無いかと思います。

誰がプロダクトオーナーをやるのか？パターン

ここで「どのような立場の人がプロダクトオーナーをやるのか？」を考えてみます。

• 事業責任者クラスがやるパターン

  • 小さい規模だと=社長や創業者になりますが、権限の観点でいくと一番スムーズです。
  • 一方で、そのクラスの場合他の業務も兼務していることがほとんどなので時間をどこまで避けるかが問題です。

• リーダークラスやマネージャークラスがやるパターン

  • 現実的には世の中で一番多いパターンでは無いでしょうか？
  • 現場の理解もあり、プロダクトにコミットできる立場でもありそうです。
  • ただし、実際には上に事業部長がいたり、経営陣がいたり…口出しされたりすること多いのでは無いでしょうか。

• 顧客自身がやるパターン

  • to Bビジネスだったり、社内プロダクトの場合にあるパターンです。
  • この場合オーナーシップ的にはスムーズですがスクラムチームとの意思の乖離が生まれやすいという難しさがあります。
  • プロダクトオーナーと開発チームとで主従関係が出来てしまうこともありそうです。

どのように「権限＋オーナーシップ」を発揮するのか？

実際私が5年ほどプロダクトオーナーをやっていたときは上記のリーダークラスやマネージャークラスがやるパターンでした。

組織上私には上司として事業本部長がおり、全てにおいて権限が自分にあったわけではありません。（板挟み状態も日常的！！）

そんな中でも、プロダクトオーナーとしてスクラムチームを健全に機能させるため、「権限＋オーナーシップ」を持つために工夫していたことをいくつか紹介します。

• 自分の権限は明確にしておいてチームに伝えておく

  • 実際のところ全ての権限を持っているプロダクトオーナーは稀だと思います。組織によって、プロダクトオーナーが決められる範囲=権限は様々です。
  • そのような時に「プロダクトオーナーはどこまで権限を持っているのか？」についてスクラムチームメンバーが理解していないと大きな混乱を招きます。
  • なので、プロダクトオーナーとして自分が持っている権限についてある程度は明確にして共有をおきましょう。（自分の権限が曖昧なら上司とすり合わせしましょう）
  • 私の場合は毎週上司との定例会議があったので、そこへ持っていく案件（=自分自身の権限を超えるもの）を明確にして毎週整理しながら進めていました。（変なやり方ですがプロダクトバックログとしてメンバーに見えるように案件自体を管理していました）

• オーナーシップを発揮するための各所コミュニケーション

  • 例えばプロダクトにおける新規機能の話がチーム内で出たとき。プロダクトオーナーの自分が「上司に確認しますね」と毎回毎回言っていたらどうでしょう。おそらくメンバーからすると「この人はプロダクトオーナーなのか？」と疑問が湧くはずです。
  • これを避けるためには、プロダクトの方向性や様々な可能性について日常的に上司やステークホルダーと常に共有をしておくことが大切です。
  • そこである程度合意が取れている状態をプロダクトオーナーとして醸成しておけば、オーナーシップを持って自身で判断が出来る機会が増えてくるはずです。ここのさじ加減はプロダクトオーナーとしての腕の見せどころのような気がします。

• 権限を超えた意思決定

  • これはマインド的な話になってしまいますが、プロダクトオーナーである自身もスクラムチームメンバーも、「絶対にこれは必要な機能だ！」と思えている状態　（かつ顧客のニーズも見えている）であれば、例え上司に反対されていようとも作ってしまえば良いと思います。
  • その結果失敗したらプロダクトオーナーは責任をとるべきですが、それくらいの気概を持って臨んで欲しいなと思います。プロダクトについて一番考えているのはプロダクトオーナーなはずなので。
  • ちなみに私はこれで成功したことも失敗したこともあります。

さいごに

スクラムのフレームワークは約30年の間進化しており、多くの開発チームで採用されている有益な手法だと思います。スクラムガイドに書いてあるとおり、要素を省略したり、独自のルールを採用したりはマイナスになってしまいます。
一方で組織によって個別の事象も発生してしまうことも現実かと思います。そんな中でいかにスクラムの本質に近づくことが出来るのか？を考えてトライをしていくことが大事だと思います。