1. LeSS Framework
  2. プロダクトオーナー

プロダクトオーナー

LeSSでのプロダクトオーナーは、基本的に 1team Scrumと同じです。しかし、規模拡大により視点が少し変わり、 常に全体像を意識しながら投資対効果(ROI)を最大化することが求められます。

LeSSのプロダクトオーナー

大規模開発では、様々な人が集められ、様々な分野に送り込まれてサブグループを作るため、部分最適に走ってしまうことがよくあります。LeSSでは、1人のプロダクトオーナーが1つのバックログをメンテナンスすることで、プロダクト全体思考を補助します。

大規模なプロダクトを扱う従来型のグループでは、外部に目を向けるグループ（たいていはプロダクトマネージャ）と内部に目を向けるグループ（たいていは開発者）の2つに別れます — そして両者は協調しません。
LeSSにおいては、1人のプロダクトオーナーは外の事象（顧客と彼らの持つ優先順位）に集中するのに十分な時間が有るので、チームの中の事象にもある程度目を向けることが出来ます。プロダクトオーナーがチームと 顧客/ユーザとの接点となることで、チームがより顧客思考になります。

他の大規模スクラムのアプローチと比べて、LeSSはプロダクトオーナーひとりでも規模拡大を効果的に行えます。なぜなら、役割が少ないことで、複雑さも減らせるからです。

明確化より優先順位づけを

スクラムにおいて、プロダクトオーナーに関係する情報は主に2つです。

(1) プロダクトバックログにおけるアイテムの優先度（順序）
(2) プロダクトバックログにおけるアイテム内容の明確化

前者(優先度)は、収益、顧客戦略、ビジネスリスク、およびその他のビジネス上の懸念などを分析した情報が関係してきます。後者(明確化)は、品質と機能、UX、およびその他の機能設計に関する問題が詳細に求められます。

LeSSのプロダクトオーナーは 優先順位付けには注力しますが、明確化についてはチームの力を借りて協力しながら行います。そのために、プロダクトオーナーはチームがエンドユーザや顧客と直接対話することを推奨し、手伝います。プロダクトオーナーは つなぎ役であって、仲介者にはなりません。

なぜ、チームと顧客/ユーザの直接対話を促すのでしょうか。
理由は以下のとおりです。

(1) 伝言ゲームによる情報欠落を減らす
(2) 顧客の真の問題に対する解決策の共創を促進する
(3) 直接協力することで、チームのやる気を高め、顧客との一体感を醸成する。

チームがPBIの明確化に注力すれば、プロダクトオーナーは時間と精力を全体像や継続的な優先順位付けに集中でき、
新たな戦略的機会を開拓します。

開発タイプに応じたプロダクトオーナー

Step 1: 開発タイプを把握する

プロダクトオーナーのあるべき像はやろうとしている開発のタイプに依存して変わります。

  • プロダクト開発：外部の市場や顧客に対する開発。
  • 内部（プロダクト）開発：社内のユーザに対する開発。開発グループはたいてい、IT部門 または システム開発などと呼ばれる。
  • プロジェクト開発：大抵はひとつの外部顧客に対する開発。プロジェクト開発は、ある種のプロジェクトとして組織、運営される。ただし必ずしも、スコープ、期間、コストが契約で決まっているプロジェクトである必要はない。開発会社は大抵、外部委託かSI業者になる。顧客、またはクライアント企業は、購入部門と利用者の両方に該当するが、同じ部署とは限らない。

Step 2: 適切なプロダクトオーナーを見つける

プロダクト開発—プロダクト開発をおこなう会社では、以下のどちらかを持つことになります。
(1) プロダクトの主導権を握るビジネス部門
(2) 主導権を握るプロダクト管理部門
従来のプロダクトマネジメントは顧客・競合分析、プロダクトの方針、荒い粒度での機能の取捨選択と優先順位付け、プロダクトロードマップ、及び他の技術的ではない活動に責任を持ちます。彼ら従来のプロダクト管理部門は従来の開発グループの仕事には関与しません。

LeSSを適用したグループのプロダクトオーナーはどうやってみつければ良いのでしょうか？
もし、プロダクト管理部門があるなら、プロダクトマネージャーをプロダクトオーナーにするのは良い選択です。あるいは、ビジネス部門から主導権を握れる人を探しましょう。重要なのは、プロダクトオーナーはビジネスサイドの人間だということです。

内部（プロダクト）開発—LeSSで内部(プロダクト)開発をする場合のプロダクトオーナーは以下のような人が適任です。
(1)そのシステムを使うグループの人
(2)開発するシステムが関与する実業務について、経験があり、習熟している人。実ユーザに限りなく近い人。

プロジェクト開発—キーポイントは プロダクトオーナーが システムを発注する側の出身であることです。
内部開発同様に、実業務について知識、経験を持っており、ユーザに近い立場であることがキーとなります。

内部開発、プロジェクト開発に共通する変動要素として、システムが複数の部門で使われる可能性があげられます。経験豊富で、主要なユーザ部門出身で手を動かしたことが有り、政治的力もあり、プロダクトオーナーの役割に関心がある人を選ぶのが良いです。

以下の図に、各組織で誰をプロダクトオーナーにすべきかを示します。

全てのケースで、良いプロダクトオーナーはプロダクトに対する情熱を持っています。

すぐに適切なプロダクトオーナーを見つけることが出来ないとしても、一時的なプロダクトオーナーを置くことでLeSSを始めることは出来ます。一時的なプロダクトオーナーは何が起きているかと、どう振る舞うべきかを理解していれば、ビジネス側の人でなくて構いません。一時的なプロダクトオーナーの元で、チームに何回かのSprintを実施させます。Sprintは、主立ったひずみが解消され、開発チームが本来のdone、出荷可能なインクリメント(ここ重要)を毎Sprint届けられるようになるまで続けます。何故でしょうか。プロダクトチームが目に見えるビジネス上の利益をもたらす新機能を示すことが出来れば、本来の、一時的でないプロダクトオーナーを触発し、見つけやすくすることが出来るからです。全員が、一時的なプロダクトオーナーはプレースホルダーに過ぎないと言うことを理解しておくことが重要です。我々は、この一時的なプロダクトオーナーが如何に危険かを示すため、偽りのプロダクトオーナー（Fake product owner) という単語をよく使います。なぜなら、偽りのプロダクトオーナーはベストなプロダクトオーナーではないだけでなく、資格がないままプロダクトオーナーを務めることで損害すら与えうるからです。偽りのプロダクトオーナーは、可能な限り早く交代し、二流のプロダクトを作るリスクを回避すべきです。

Step 3: 真のプロダクトオーナーに権利と責任を

プロダクトオーナーは従来のプロジェクトマネージャ（スコープと進捗を管理する人）の呼び換えではありません。むしろプロダクトオーナーは、コンテンツ、リリース日、優先順位、ビジョンなどを決めたり変更したりする、独立した権限を持っています。もちろんプロダクトオーナーはステークホルダーと協調しますが、真のプロダクトオーナーは最終決定権を持ちます。

5つの関係

プロダクトオーナーはLeSSを適用することで影響を受ける、５つの関係性を理解し、それらの関係改善に向けて働く必要があります。

  • プロダクトオーナー<–>チーム
    チームはプロダクトオーナーが顧客に向けて実現可能な最高のプロダクトを作れるよう支援します。チームは次に何を作るのかと既に作ったものが成功したかどうかを知る必要があります。プロダクトオーナーはチームを支援するために、彼らに必要なモノが何かを知る必要があります。

  • プロダクトオーナー<–>顧客
    プロダクトオーナーとチームは顧客のために、実現可能な限り最高のプロダクトを作れるよう努めます。顧客は、自分たちが気にしている機能がいつ手に入るのか、そしてその背景（優先順位づけの理由）を知る必要があります。透明性を確保することで、顧客を最大限巻き込むことができます。プロダクトオーナーは顧客の真のゴールや問題を学び、（あるいは彼らのビジョンのさらに向こうにあるものを想像し）優先順位付けに必要な情報を集める必要があります。

  • チーム<–>顧客
    チームは顧客に向けて実現可能な最高のプロダクトを作れるよう努力しています。彼らは機能の背景や、その分野の詳細な知識を知る必要があります。理想的には、チームは顧客の本質的な（表面的でない）ゴールと問題を把握し、顧客と一緒にソリューションを作り上げるべきです。チームは、自分たちが顧客と共に明らかにした要望を完全に理解しているか、顧客に確認する必要があります。

  • プロデューサー<–>上級管理職
    プロダクトグループの上にいる上級管理職（ポートフォリオマネージャ、経営幹部など）はプロダクトオーナーをプロダクトの成功に関する決定権と説明責任を持つ存在と見なすべきです。プロダクトオーナーは、プロダクトが与える影響（例えばROIやマーケットシェア）を最適化するため、開発状況の可視化と、より経営レベルの(大抵暗黙な)任務を遂行させる必要があります。プロダクトオーナーはスクラムマスターのサポートを受けながら、組織構造を改善するために、上級管理職の支援を求めます。

  • プロダクトオーナー<->スクラムマスター
    ここまでに述べた関係性は、プロダクトオーナーシップと直接関連しますが、 プロダクトオーナーとスクラムマスターの関係はこれらとは異なります。スクラムマスターとの関係性は、プロダクトオーナーの知識と振る舞いに関連します。スクラムマスターはプロダクトオーナーを支援するために、プロダクトオーナーの悩み、疑問、障害を知る必要があります。良いスクラムマスターは、親身にプロダクトオーナーの話を聞き、プロダクトオーナーが辛いときには肩を貸します。スクラムマスターはプロダクトオーナーが適応できるよう、教育し、フィードバックを与えます。

LeSS ミーティング

私たちがLeSSを紹介するときに良くある質問として、「どうやって一人のプロダクトオーナーが全てのチームの全てのミーティングに参加するの？」というものがあります。幸いに、この質問は誤解に基づくものです。一人のプロダクトオーナーは、LeSSで複数チームがあっても、1つのミーティングにしか参加しません。そして、このミーティングに参加するチームメンバーの数は管理可能です。もし２チームしかないのであれば、全員が参加しても効果的でしょう。たくさんチームがあるのであれば、各チームから２人の代表者が参加すると良いでしょう。

プロダクトオーナーはどのミーティングに出るのでしょうか。2週間Sprintだったら平均どのぐらいの時間を費やすのでしょうか。

つまり、2週間スプリントでは、平均8時間ぐらいが、プロダクトオーナーがLeSSイベントに費やす時間です。

プロダクトオーナーはチームごとのミーティング(Sprint プランニング 2、 デイリースクラム、 チームプロダクトバックログリファインメント、 チームふりかえり)には出ません。