スクラム チームとアジャイル チームのプロダクト オーナーについて知っておくべきすべてのこと

By Kate Eby | 2017年2月17日 (更新 2023年2月28日)

プロダクト オーナーは、すべての製品開発サイクルの中核を成しています。顧客が何を必要としているかを知り、製品の構想ができ、開発チームにビジョンを伝えることができます。しかし、開発におけるプロダクト オーナーの役割は、環境によって異なります。

この記事では、プロダクト オーナーが何をしているのか、プロダクト オーナーの重要な役割と責任は何か、そしてプロダクト オーナーが仕事を効果的に遂行するのに何が助けになるのかを学びます。また、スクラム フレームワークにおけるプロダクト オーナーの役割やアジャイルの手法に関する専門家のインサイトを得るとともに、プロダクト オーナー認定の価値について学びます。

プロダクト オーナーになるとは

プロダクト オーナーは、製品開発の権威であり、製品の代表者です。プロダクト オーナーはリーダーであり、製品の進捗状況を導き、成功に向かってチームを管理します。この役割は、あらゆる種類の製品開発、特にアジャイル手法において重要です。

企業は当初、特にスクラム チームによるアジャイル開発の課題に対処するために、プロダクト オーナーの役割を設けました。スクラムは一般的にソフトウェア開発で使用されるアジャイル フレームワークの一種であり、部門をまたいだ 5 ~ 11 人のチームによって、問題を解決しプロジェクトを完了します。(アジャイル プロジェクト管理の詳細とテンプレートのダウンロードについては、こちらをご覧ください。)

プロダクト オーナーがいなければ、スクラム チームは次のようないくつかの課題に直面してしまいます。

  • 目標と成果物を明確に特定するのに苦労する。

  • プロジェクトの鍵となるものを見分けることができないのに、さまざまな情報源から情報を得てしまう。

  • 大規模な組織内において、仕事を期限内に終わらせる責任を欠いてしまう。

プロダクト オーナーは、チームの集中を維持し、情報や回答を待つことによる混乱を減らすために、単一の情報のポイントを提供します。また、矛盾する優先順位も解決します。

スクラム チームでは、それ以来、プロダクト オーナーの役割が進化し、グループの共通の目標、方向性、プロセスを明確にする人物になりました。さらに、プロダクト オーナーは社内外の関係者と協力して、ビジネスが最適な製品を構築していることを確認します。

プロダクト オーナーは何をするのか

プロダクト オーナーは、製品開発プロジェクトの主要な関係者です。製品開発に関連するビジョン、戦略、戦術的実行に対する、エンドツーエンドのゲートキーパーでありマネージャーです。プログラムの優先順位を開発して設定し、プロジェクトを完了する前に解決する必要があるタスクのリストである製品 バックログ を処理します。プロダクト オーナーは開発チームと緊密に連携し、ユーザーの問題点とニーズを調査し、競合状況を分析し、機能リストを開発および改良します。また、最終的な成果物の信頼性と品質を維持する責任もあります。

プロダクト オーナーという用語は、ソフトウェアを開発するためのスクラム フレームワーク (アジャイル手法の一種) から生まれました。従来のプロジェクト管理システム (および製品マネージャー) を導入していなかった企業は、当初、スクラム アプローチを使用していました。そうした企業は、プロジェクトの特定や完了を、さまざまな部門 (スクラム) から連れてこられた小さな作業グループに任せていました。しかし、チームが作業を完了し、当初プロジェクトに設定された目標を達成する責任を、誰かに負ってもらう必要もありました。それで、製品の成功に責任を負うために、プロダクト オーナーの役割が設けられました。

一般的なスクラム開発に加えて、現在はプロダクト オーナーも、スクラムの概念と要素を、多くのチームに合わせて調整し、チームに適した方法で適用する、大規模なスクラム (LeSS) の一部になっています。小売、銀行、電子商取引など、さまざまな業界で、現在ではプロダクト オーナーを採用して製品のビジョンを明確にし、構想から完了まで推進しています。

プロダクト オーナーとスクラム チームの構造

プロダクト オーナーは、スプリントと呼ばれる短い開発サイクルでプロジェクトを完了させるよう、スクラム チームを推進します。この小さく機敏な作業グループは、通常、組織全体にまたがる 5 ~ 7 人で構成されています。各人が明確な強みと専門分野を持ち、特定の目標とタイムフレームで団結します。プロダクト オーナーは、作業を深く理解し、チームが効果的かつ効率的に作業できるようにスクラム プロセスを微調整するコーチであるスクラム マスターと協力します。

プロダクト オーナーもスクラム マスターも目標に焦点を当て、プロジェクトの範囲の変更を除外し、スプリントの開始時に特定された製品を開発するというターゲットに合わせてチームを維持します。スプリント中にアイデアが増える可能性がありますが、プロジェクトに新機能や機能性を追加する要件の変更がないようにすることは、プロダクト オーナーの役割です。

組織的には、プロダクト オーナーは製品開発の宇宙の中心と考えることができます。プロダクト オーナーは、すべての開発活動のクリアリングハウスであるため、開発チームと内部組織 (製品管理、マーケティング、セールス、カスタマーサポート、経営幹部などを含む) との間の連絡役を務めます。

 

scrum sprint

テクノロジーのプロダクト オーナーとは

プロダクト オーナーは、テクノロジーやソフトウェア開発において重要な役割を果たし、顧客の求める機能を理解し、それらの要件を開発チームに伝えます。プロダクト オーナーは、ユーザー ストーリー (顧客の視点から見たソフトウェアやアプリケーションの説明) を収集します。これらは、新しいアカウントを作成したり、ショッピング カートを編集したりする機能など、シンプルなタスクです。プロダクト オーナーは、アプリやプログラムの開発に影響を与えるストーリーに優先順位を付けます。

スクラム フレームワークでは、プロダクト オーナーが開発チームと顧客の両方と協力して、ユーザーが何を望み、開発チームが何を構築しているかを明確にします。プロダクト オーナーは、従来の要件リストに依存するのではなく、ユーザー ストーリーから取り出されたすべてのタスクに優先順位を付け、管理します。

最も重要なのは、プロダクト オーナーがテクノロジーに情熱を持ち、機能や機能性のゲートキーパーとして働いていることです。プロダクト オーナーは、バックログのすべての項目がソフトウェアまたはアプリケーションの価値を高めるようにします。

プロダクト オーナーはプロジェクト マネージャーなのか

各組織はアジャイルの実装方法の点で異なります。プロダクト オーナーかプロダクト マネージャーどちらか 1 つの役割がある組織もあれば、両方の役割を採用し、それらの間の明確な違いを特定する組織もあります。一部のチームでは、スクラム マスターがアジャイル プロジェクト マネージャーで、タスクを特定し、優先順位を付けます。また他のチームでは、プロダクト オーナーがアジャイル プロジェクト マネージャーで、プロジェクトの成功の責任を担います。

 

Roman Pichler

“Product owner” is not simply another name for project manager. Product owners typically have the authority to define and adjust the scope of the work, while project managers deliver the project already outlined by others. According to product management expert and consultant Roman Pichler, author of Agile Product Management with Scrum: Creating Products that Customers Love, the crossover between the two is inherent to the role of the product owner, with qualifiers. “A product owner is more than just a rebranded product manager,” he says. “Product owners tend to take on a wider range of duties, which makes the role multifaceted and challenging.”

また、Pichler 氏は、スクラムが 1990 年代に開発されて以来、製品管理が変わったとも指摘しています。初期の頃、製品マネージャーは事前の市場調査、製品計画、要件定義を担当していました。その後、要件仕様が、開発とテストを行ってプロジェクトを完了するプロジェクト マネージャーのところへと行きました。

2 つの役割を区別するために最も明確なのは、プロダクト オーナーが製品の声を表し、製品マネージャーが顧客の声を表す点です。

 

Product Owner Product Manager

製品開発におけるその他の役割

プロダクト オーナーはチームをリードし、プロジェクトの成功に責任を負います。同時に所有者は、作業を実行していてプロジェクトのコンポーネントに関する深い知識を持つチームと協力する必要があります。この役割では、プロダクト オーナーの職務が他のチーム メンバーの職務と重複したり、以下のような責務の一部と混同されたりします。

機能所有者またはコンポーネント所有者: 技術的なスキルに重きを置き、個々のコンポーネントと機能に焦点を当てて、あらゆる機能が目標水準に合わせて動作することを確認します。

ビジネス アナリスト: アジャイル ビジネス アナリストやビジネス システム アナリストとしても知られています。ビジネスの仕組みを理解し、ビジネス機会につながる顧客のニーズを実装するため開発者とコミュニケーションを取ります。

オンサイト カスタマー: エクストリーム プログラミング (XP) と呼ばれるシステムで顧客をチームに取り込みます。そのため、製品の開発に関する緊密な共同作業とフィードバックが得られます。このような共同作業は、顧客のニーズを満たすためのより良いソリューションを促進します。また、開発者に直接協力してもらうことで、モチベーションと顧客に対する共感を向上させることができます。

製品ディレクター: 会社のパフォーマンスとブランドを理解する組織の専門家で、開発する製品のスイートを特定します。

関係者についてプロダクト オーナーが知っておくべきこと

関係者の役割も考慮する必要があります。Pichler 氏の定義では、関係者とは、製品に利害関係を持ち、製品の影響を受け、または製品に関心を示す内部の人物 (顧客やユーザーとは対照的) です。関係者は、製品の開発、製造、納品に役立つ重要なインフラを構成しています。

製品の性質によっては、関係者のプールの構成が異なると Pichler 氏は言います。「商用製品の場合、グループにはマーケティング、セールス、サポート、経営陣の代表者が含まれる可能性が高いですが、法務、財務、人事の代表者も含まれる可能性もあります、」と彼は言います。「社内製品の場合、関係者はオペレーション、影響を受けるビジネスユニット、経営陣である可能性があります。」

プロダクト オーナーは、外部の関係者にも注意する必要があります。それらは、製品を構築する相手のクライアントや会社です。より広く言えば、顧客とユーザーです。製品がどれほど良く機能するのかについて、また顧客のままでいるのか、それともソリューションを求めて他の場所に行くのかについて利害関係があります。

プロダクト オーナーは製品に対する関係者の要望をどのように管理するか

プロダクト オーナーは関係者の管理を担当しており、製品の目標を特定し、その目標に向かい続ける権限があります。ここでは、社内外の関係者とうまく連携するためのヒントをご紹介します。

計画を知る: プロジェクトのスコープ、タイムテーブル、リソースを明確に特定していることを確認してください。戦略とロードマップをすべての関係者に明確に伝えます。

リーダーになる: プロダクト オーナーは、単に注文を受け、すべてのリクエストに対応しようとする人ではありません。リクエストがプロジェクトの範囲外になったら「ノー」と言い、リクエストがこの先の作業を改善するものなら「イエス」と言えるようにしておきます。チームの命運は、関係者の話を聞いてノイズと合図を聞き分けるプロダクト オーナーのスキルにかかっています。

顧客を支持する: プロダクト オーナーは製品を明確に理解し、説明します。またプロダクト オーナーは、アイデアが顧客の利益に最も適している場合や、製品の範囲外である場合についても明確にすることができます。

関係者との連携についての詳細は、この 記事をお読みください。

認定スクラム プロダクト オーナーとは

スクラム プロダクト オーナーとしての認定を取得することで、キャリアに対するコミットメントと仕事に対する理解を示せます。チームにとって価値を高め、他の求職者とは一線を画すことができます。認定資格では実際の専門知識は反映されませんが、より有能なプロダクト オーナーとなるためのベストプラクティスの研究に時間を費やしたことを示しています。

プロダクト オーナーの平均年間基本給は、世界の 9 万 3,000 ドル (Scrum Alliance (スクラム アライアンス)) から、米国 (Indeed (インディード)) の 10 万 1,000 ドルまでです。Scrum Alliance (スクラム アライアンス) による 2017 ~ 2018 年の State of Scrum Report (スクラム状態レポート) のデータによると、認定と長年の経験がより高額の給与につながることが示されています。

スクラム プロダクト オーナーの認定を提供している組織のいくつかは次のとおりです。

Scrum Alliance (スクラム アライアンス): Certified Scrum Product Owner® (認定スクラム プロダクト オーナー) の認定、教室での学習、グループ ディスカッション、実践的な演習を含む 2 日間の対人プログラム。

Scrum.org (スクラム.org): Professional Scrum Product Owner™ (プロフェッショナル スクラム プロダクト オーナー)、指導とチーム ベースの演習がある 2 日間の対人コース。

Scrum Inc. (スクラム インク): Certified Scrum Product Owner Training (認定スクラム プロダクト オーナー トレーニング)、スクラムの共同クリエイターである Jeff Sutherland 博士が開発した 2 日間の対面コース。

Project Management Institute (プロジェクト マネジメント協会): PMI Agile Certified Practitioner (PMI-ACP)® (PMI アジャイル認定プラクティショナー)、PMI-ACP 試験合格を含む、経験と教育の要件あり。

Roman Pichler 氏: 認定スクラム プロダクト オーナー、ドイツとロンドンでの 2 日間の対面ワークショップ。

ICAgile (IC アジャイル): ビジネス価値分析、企業製品所有権、ICAgile 認定製品所有権の専門家などを含む、認定プログラムの追跡

Scaled Agile (スケールド アジャイル): SAFe® 4 Product Owner/Product Manage (プロダクト オーナー/プロダクト マネージャー) (POPM)、Scaled Agile (スケールド アジャイル) フレームワーク専用の 2 日間のコース。

280 Group (280 グループ): Association of International Product Marketing and Management (AIPMM) (国際プロダクト マーケティングおよび管理協会) が管理する Agile Certified Product Manager and Product Owner® (ACPMPO) (アジャイル認定プロダクト マネージャーとプロダクト オーナー) 試験に備える対面およびオンラインのコース

Simplilearn Solutions (シンプリラーン ソリューションズ): CSPO 認定トレーニング、2 日間の教室でのトレーニング。

トレーニング リソースと認定の価値の詳細については、こちらをご覧ください。

プロダクト オーナーにとってもう1つの貴重なリソースは、Robert Galen 氏の著書 「Scrum Product Ownership: Balancing Value from the Inside Out」です。

製品とプロジェクト開発の種類

製品はプロダクト オーナーの仕事の中心にあります。適切なプロダクト オーナーを見つけるには、開発と製品の種類を特定する必要があります。プロダクト オーナーの役割とビジョンは、製品の種類によって大きく異なります。

商用ソフトウェアまたは製品開発: 主に外部の顧客や市場の収益を促進するために開発されます。強力な組織スキルと技術的スキルを持ち、市場とオーディエンスをしっかりと把握できるプロダクト オーナーが必要です。

社内ソリューションまたは開発: 商用ソフトウェア開発の場合と同様に、内部ソフトウェア ソリューションのプロダクト オーナーは組織的および技術的なスキルを持っている必要があります。しかし、ここでの「市場」はプロダクト オーナーの会社とその競合他社で構成され、「オーディエンス」は組織のビジネスおよび技術上の意思決定者 (BDM/TDM) と従業員です。開発グループは、情報技術やシステム開発である場合があります。

プロジェクト開発: この作業には通常、契約の一部として、1 人の外部クライアントまたは顧客が含まれます。プロダクト オーナーは通常、仕事を請け負う会社の出身であるため、ユーザー エクスペリエンスに詳しく、顧客の実践的なニーズを理解しています。

プロダクト オーナーに必要なスキルとは

プロダクト オーナーのジョブ ディスクリプションは、会社、業界、さらには地域によって異なる場合があります。しかし、すべてのプロダクト オーナーの成功には、いくつかのコア スキルが重要です。

  • 仕事をする権限: 組織は、プロダクト オーナーに対し、意思決定を行い、プロジェクトを完了できるように権限を与える必要があります。関係者や官僚は、プロダクト オーナーの権限の仕事を奪うことはできず、強力なサポート ネットワークを提供する必要があります。プロダクト オーナーは、主要なリーダーシップの完全なサポートがあることを確認する必要があります。

  • リーダーシップ:プロダクト オーナーは、プロジェクトの最初からリーダーである必要があります。プロダクト オーナーは、何を構築するか (または何を構築しないか) に関する意思決定を伝え、市場のギャップと顧客のニーズを特定し、開発チームを導くために明確で実用的なフィードバックを提供する強力な声を上げられなくてはいけません。プロダクト オーナーは、プロジェクト、ビジョン、チームの開発者でもあります。また、対応可能でいて、開発サイクルを通じて関与することによって、製品へのコミットメントを示す必要があります。

  • 意思決定: プロダクト オーナーは、迅速かつ権限を持って意思決定を行うことができる必要があります。結局のところ、プロダクト オーナーは製品の市場や環境に関する領域知識などを含む、顧客や関係者のニーズに対する深い知識を持っています。

  • コミュニケーション: プロダクト オーナーはチームを構築し、社内外の関係者と協力する必要があります。ビジョンを共有し、仕事に集中し、さまざまな顧客層とコミュニケーションを取れることが重要です。また、プロダクト オーナーは人々と情報を結び付けます。開発者は、作成しているコードについて必要な詳細を取得するために、ユーザーと直接話をしなければならない場合があります。関係者は、製品の顧客価値に関するインサイトを得るために、ビジネス アナリストと話をしなければならない場合があります。すべての会話の専門家である必要はありませんが、プロダクト オーナーは知識ブローカーです。

  • 委任: プロダクト オーナーは全体的なアウトプットを担当しますが、その作業を行っている人は他にもいます。プロダクト オーナーは、どの職務が各チーム メンバーのスキルに最も適しているかを知り、スムーズな共同作業を確保する必要があります。プロダクト オーナーは監視を行い、仕事が完了していることを確認するためのリソースを見つけます。

  • 対立の解決: 途中で何の意見の相違もなく進むプロジェクトはありません。認定スクラム トレーナー®であり、アジャイル ソフトウェア開発の 初期の先駆者の一人である Lowell Lindstrom 氏の言葉を使えば、「対立を解決できないなら、あなたは間違ったゲームに参加しています。」プロダクト オーナーは、論争を止め、解決策を見つける必要があります。ただし一部の対立はプロダクト オーナー レベルでは解決できません。紛争に指揮系統をいつ送り込む必要があるかを知ることは、何を解決すべきかを知るのと同じくらい重要です。

  • 関係者の管理: このスキルがあるかないかで、進捗と混沌の違いが生じます。優れたプロダクト オーナーは、効率的なワークフロー、明確な期待値とマイルストーン、オープンで頻繁なコミュニケーションに重きを置いています。これにより、チームが問題を迅速に特定し、解決し、目標を達成し、開発がスケジュールどおりに進むようにします。

  • 製品と開発に対する経験値: プロダクト オーナーは必ずしも訓練を受けたソフトウェア エンジニアである必要はありませんが、ソフトウェア開発に関わる基本的なプロセスを理解することは、現実的なスケジュール、ワークフロー、関係者の期待値を導き出すために不可欠です。市場やオーディエンスのニーズを認識するには、既存の製品や製品カテゴリ全体に関する経験が不可欠です。

  • 顧客および市場のインサイト: プロダクト オーナーは、機能、価格、販売予測、マーケティング戦略などを知らせるコア情報を提供します。プロダクト オーナーのビジネス手腕は、開発プロセス中に意思決定を行うのに役立ちます。顧客を満足させるためには、プロダクト オーナーが顧客のニーズを満たし、製品の価値を語る主なストーリーテラーとして行動できる必要があります。

  • 戦術的スキル: スキルの多くはリーダーシップと戦略的思考に焦点を当てていますが、成功するプロダクト オーナーには戦術的専門知識も必要です。これには、いつまでに何が行われるのかといった、日々の管理が含まれます。

プロダクト オーナーの役割と責任

Roman Pichler 氏によると、プロダクト オーナーの最終的な責任は、製品が顧客とユーザーだけでなく、会社にとっても価値を生み出すようにするということです。「プロダクト オーナーとは、製品を擁護し、製品の決定を促進し、製品に関する最終的な発言権を持つ人物だと考えてください、」と彼は言います。「これには、フィードバックを実行するかどうか、どのように実行するか、どの機能をリリースするかといった決定が含まれます。」

プロダクト オーナーの役割と責任は次のとおりです。

  • ビジョンを設定する: プロダクト オーナーは目標を設定するだけでなく、製品がユーザーのニーズを満たし、会社の戦略と一致させ、ミッションを達成するための方法を説明します。これは重要なリーダーシップの責任です。ビジョンは、チーム、関係者、プロジェクトに関わるすべての人に伝える必要があります。ビジョンとは、プロダクト オーナーが優先順位を確立し、チームの作業を指示するために使用する指導力です。プロジェクトを推進する際の、向かうべき「北極星」として、プロジェクト全体を通じてビジョンを伝える必要があります。

  • 製品ロードマップの作成: プロダクト オーナーは、短期および長期の両方の目標を満たすテクノロジー ソリューションを特定するために、ビジネス目標を製品戦略に結び付ける計画の策定に取り組んでいます。

  • 製品戦略の策定: 製品戦略は、時間の経過とともに製品のビジョンを分解し、市場、提供物、価値提案、価格、流通などを定義します。

  • 関係者、開発チーム、スクラム マスターとコミュニケーションを取る: プロダクト オーナーはステータスを伝え、関係者を教育し、予算、範囲、資金、スケジュールを交渉し、レビューを整理し、ソリューション デモを実行します。

スクラムにおけるプロダクト オーナーの役割とは

開発サイクルのプロダクト オーナーはプロジェクトの成功に責任を持ちますが、一部の役割はスクラム フレームワーク特有のもので、プロダクト オーナーがチームの主導権を持ちます。スクラムでの重要な責任は次のとおりです。

  • アジャイル スクラムで作業する理由を説明する: スクラム プロセスは、チームメンバーや関係者にとって初めての場合があります。プロダクト オーナーは、このプロセスの価値と、その成功を促進する原則を説明する必要があります。

  • スクラム スプリントの範囲を制限する: 多くの組織は、アジャイル スクラムを使用して製品を開発していると考えています。しかし実際には、一連のスプリントでシステム全体を構築しており、いずれも独立した価値を持っていません。これは、スクラムでは機能しないウォーターフォール アプローチです。スクラムは、長いプロセスの中のステップとしてではなく、定義されたアプリケーションを開発するための短いサイクルとして設計されています。目標は、ウォーターフォール アプローチを使用せず、スプリントを通じて顧客に価値を提供することです。

  • バックログの管理: バックログとは、解決する必要がある作業リクエストのリストです。バックログの管理には、すべての情報が明確で、透明性が高く、可視化されたものにするための、バックログ項目のトリアージ、追加、編集、優先順位付けが含まれます。

  • ユーザー ストーリーの作成: ユーザー ストーリーは、ユーザーの視点から書かれた機能の説明です。ユーザー ストーリーは一般的に簡潔 (1 つまたは 2 つの文) であり、製品や機能の要件を定義するのに役立ちます。多くの場合、チームは開発プロセスの一環として「ちょうどよい時に」ユーザー ストーリーを追加する必要があります。プロダクト オーナーはフィードバックの流れを管理し、必要に応じてバックログを調整します。

  • スクラム ミーティングに参加する: スクラム ミーティング (スタンドアップとも呼ばれる) は、プロジェクトのステータスと最新情報の提供に焦点を当てた、毎日の短いステータス ミーティングです。

  • リリース計画: リリース計画は、コミュニケーションを合理化し、マイルストーンと製品納品のタイムラインを確立するための、詳細な進化するツールです。

  • 開発および スクラム マスターと協力する: プロダクト オーナーは、開発チームやスクラム マスターと定期的に連絡を取り合い、安定した進捗を確保し、潜在的な障害を認識する必要があります。  

  • 関係者、スクラム チーム、ユーザーを引き込む: プロダクト オーナーは顧客の声であり、ユーザー ストーリーと開発チームの間の引き渡しで情報が失われないようにする必要があります。ユーザー ストーリーで表面化する課題を特定したら、ソリューションやチームと顧客の共同作業のため、チーム内での創造的なアプローチを必ず促すようにしてください。フィードバック ループ、スタンドアップ ミーティングなどを通じて、コミュニケーションを常にオープンにし、チームが適切な製品を開発していることを確認してください。

  • ビジネス目標を遵守し、財務を管理する: プロダクト オーナーは開発中、財務を含むすべてのリソースを担当します。これには、最適な投資収益率 (ROI) に基づいて意思決定を行い、バックログに優先順位を付ける際のコストとメリットを理解することが含まれます。

  • 最終承認を与える: プロダクト オーナーは、作業を承認し、それが受け入れ基準を満たしているかどうかを決定する責任と権限を持ちます。たとえば、スプリントの最初のユーザー ストーリーがログインする機能だったとします。プロダクト オーナーは、ストーリーを受け入れる (はい、ユーザーはログインできます) ことも、または拒否することもできます。ユーザー ストーリーに基づいて、受け入れテスト駆動開発 (ATDD) をサポートするのは、プロダクト オーナーの責任です。

  • プロジェクトのコースを変更する: スプリントの境界内で、プロダクト オーナーは、関係者のニーズや顧客のフィードバックに基づいて、チームを異なる方向に操縦できます。

  • イネーブラーの働きを理解する: イネーブラー とは、ビジネスの要件とその技術インフラをサポートするシステム アーキテクトとエンジニアです。プロダクト オーナーは深い技術的スキルを持つ必要はありませんが、スクラム チームが開発している新しいソフトウェアやアプリケーションを会社のインフラストラクチャがサポートできるように、イネーブラーと協力する必要があります。

プロダクト オーナーになる方法について詳しくは、「Best Training Resources and Courses for a Scrum Product Owner (スクラム プロダクト オーナー向けのベスト トレーニング リソースとコース)」をご覧ください。

スクラムのプロダクト オーナーとスプリント

スクラム フレームワークの目標は、すべてのスプリントで製品の増分を提供することです。プロダクト オーナーは、通常 2 ~ 4 週間続くスプリントの長さを決定し、主要な目標を達成するために必要な作業や、アウトプットをレビューに備えるために必要な作業に開発チームを導きます。プロダクト オーナーの重要な役割の 1 つは、計画、毎日のスクラム、改良、レビュー、チーム デモ、振り返り、スプリントなど、すべての開発イベントに参加することです。その過程で、プロダクト オーナーは製品を擁護し、ビジョンを促進し、チームを励まします。

スプリントが始まる前に、プロダクト オーナーは関係者やユーザーと協力してプロジェクトの目標を特定します。これは、スプリントの範囲を特定や、作業の計画に役立ちます。その後、スプリントの開始時に、プロダクト オーナーと開発チームがスプリント中に完了する作業の概要をまとめ、合意します。プロダクト オーナーは、レビューと受け入れのためにスプリントが満たす必要のある基準を確立し、プロジェクトのバックログ項目を作成します。

スプリント中、プロダクト オーナーは、観察し、進捗に遅れを取らないようにし、質問に答えるため、スタンドアップ ミーティングに出席します。プロダクト オーナーは、このフェーズで、受け入れ基準とテスト基準に基づいて、バックログ項目の受け入れ、または却下をします。スプリント中の改良セッションでは、プロダクト オーナーはバックログ項目を追加または削除したり、リード レビューを行ってフィードバックを得て開発プロセスを調整したりできます。

スプリントの終了時に、プロダクト オーナーがスプリント デモまたはレビュー ミーティングを指揮し、関係者を更新します。このレビュー ミーティングからのフィードバックは、次のスプリントを計画し、次のスプリント バックログの項目を特定するのに役立ちます。スプリントが完了すると、プロジェクトマネージャーは振り返りに参加し、プロセスを評価し、改善の余地を特定します。

 

scrum flow@2x

プロダクト オーナーにとって、スプリントの目標の概要を前もってまとめることが不可欠ですが、Pichler 氏によると、スプリントの目標の作成には注意が必要です。「残念ながら、多くのプロダクト オーナーとアジャイル チームはスプリントの目標を使用しないか 、効果的に適用しません、 」と彼は言います。「スプリントの目標にはよく、イテレーションを実行する理由ではなく、実装すべきストーリーが記載されます。」スプリントが実行される理由と目標の達成方法を定義することで、スプリントが始まる前に関係者全員が同じ認識を持つことができ、より良い結果を生み出します。

プロダクト オーナーの課題

プロダクト オーナーに求められる幅広い責任とスキルを知ると、圧倒されるような仕事に見える可能性があります。しばしば多くの課題に直面します。

  • 権限の不足: プロダクト オーナーは、経営陣や組織内の適切な人々からの十分なサポートを得られないことがあります。スクラム チームは、プロダクト オーナーが作業を推進するための真の権限を持たない場合には効果的ではありません。権限が与えられていて、社内で重要な人々のサポートと信頼を得ているかどうかを確認してください。

  • 圧倒される感覚: プロダクト オーナーは、作業に十分な時間がない、またはチームから十分なサポートを得られていないことに気づくことがあります。さらに、働き過ぎたプロダクト オーナーは、プロジェクトのボトルネックを生み出し、チームメンバーに対し常に対応可能ではなくなります。時間が問題となっている場合は、プロダクト オーナーが仕事を 1 つだけ抱えている、つまりプロダクト オーナーとして担当しているのが 1 つの製品のみであることを確認してください。企業は、正式なプロダクト オーナーなしでアジャイル チームを作成することが多く、必要に応じて別の仕事から誰かを「借りる」ことを頼りにしています。アジャイル アライアンスによると

    、製品開発チームに対するプロダクト オーナーの理想的な比率は 1:1 で、フルタイムのプロダクト オーナーは 1 つのチームに専念するのが理想です。この比率は、チームから十分なサポートを得られていないプロダクト オーナーにも当てはまります。チームにプロダクト オーナーが 1 人だけであれば、権限と意思決定が明確になります。また、プロダクト オーナーがチームのサポートを得られていない場合は、チームが作業を行うのに十分な時間があり、効果的に共同作業を行っているかどうかを確認してください。

  • 代理的なプロダクト オーナー: 企業は、スクラム ワークフローに移行する際、プロダクト オーナーを任命する前に代理的なオーナーを使用することがあります。これは、正式なプロダクト オーナーがすぐに対応できず、チーム メンバーが作業を開始した場合に発生する可能性があります。原因にかかわらず、この明確な方向性と権限の欠如は、チームに混乱を引き起こす可能性があります。

  • 部分的なプロダクト オーナー: 作業範囲全体を理解していて、その製品にすべての時間とエネルギーを注ぐための委任が会社からあることを確かめてください。これには、自分の決定を知らせるために必要な、プロジェクトの市場調査や販売数、その他のデータへのアクセスが含まれます。権限が部分的であると、プロダクト オーナーのすべての責任を担うのが難しい場合があります。

プロダクト オーナー向けのヒント
圧倒されたり、権限が与えられないと感じるようであれば、次のヒントをお試しください。

  • マネージャーのようにではなく、リーダーのように行動する: プロダクト オーナーの主な仕事は、製品の価値を最大化することです。スクラムの目標の 1 つは、チームが仕事に基づいて組織されることです。チーム メンバーを信頼し仕事を任せれば、製品が組織にもたらす価値に集中できます。

  • 成功を再定義する: プロジェクト マネージャーは、期限内と予算内でタスクを完了することに重きを置いています。プロダクト オーナーは、製品指向であり、タスクの完了だけに集中する必要はありません。製品の成功は、製品が完成したかどうかではなく、ユーザーのニーズを満たし、適切なオーディエンスに届くかどうかによって決まります。つまり、会議や分析の量や製品開発の速度ではなく、価値に焦点を当てる必要があります。

  • ユーザーに焦点を当てる: 関係者を満足させることで、行き詰まってはいけません。常にユーザーが必要としていることを聞き、それに基づいて意思決定を推進しましょう。常に顧客のフィードバックに耳を傾け、学びましょう。つまり、市場投入までの時間ではなく、学ぶ時間を改善しましょう。

プロダクト オーナーの未来

プロダクト オーナーの役割の進化は、アジャイル環境に存在するスクラム フレームワークと深く関連しています。プロダクト オーナーは、プロジェクトの成功に責任を持ち、ユーザー、開発者、関係者をつなぎ、可能な限り最高の製品を製作します。この仕事の一部はマーケティング、一部はビジネス、一部はテクノロジーです。結論としては、プロダクト オーナーは顧客向けのソリューションを構築するための最良の方法を探しているということです。

イノベーションの速度が高まるにつれ、多くの企業はユーザー エクスペリエンスをより深く理解し、デザイン思考を持つことに目を向けるようになります。ユーザーに対する情熱を持ち、チームに仕事を促すことができるプロダクト オーナーのスキルは、さらに価値が高まります。チーム、製品、市場に何が役立つのかを知っているプロダクト オーナーは、どの業界でも成功できるでしょう。

ソフトウェア開発のため Smartsheet でプロダクト オーナーのアウトプットを改善

ニーズに合わせ変化に対応できるようデザインされた、柔軟性のあるプラットフォームで、チームの能力を最大限に引き出しましょう。 Smartsheet プラットフォームなら、いつでもどこでも簡単に作業の計画、保存、管理、およびレポート作成が可能なため、チームはより効率的かつ効果的に仕事を進めることができるようになります。作業に関して主要なメトリックを表示したり、リアルタイムの可視性を提供したりするために、ロールアップ レポート、ダッシュボード、および自動化されたワークフローを作成する機能も装備されており、チーム メンバーをつないで情報共有を促進することが可能です。 やるべきことを明確にすると、チームの生産性と作業達成能力が向上します。ぜひこの機会に Smartsheet を無料でお試しください。

 

作業遂行に Smartsheet がフォーチュン 100 社の 90% 以上から信頼されている理由をご覧ください。

Smartsheet 無料お試し Get a Free Smartsheet Demo