あなたに本格な専門的な支援が必要だということがよく分かったわ。

著者の前妻

プロダクト管理の概要

プロダクト管理の役目はプログラムバックログの定義と優先順位付けに関する責任を負うことである。プログラムバックログは一連のリリースを通じ、アジャイルリリース列車の価値納品を推進する唯一のバックログである。言い換えれば、プロダクト管理は列車の「内容に関する権限の保有者」の役割を果たす。組織の中では「プロダクト管理者」という特定の肩書が存在するとは限らないが、注意すべき重要なことは1人が何を実装するかに関する責任を持っていることである。何を構築するかに関する迅速、局所の意思決定ができるように権限が委譲される。もちろん、この人は意思決定時に支援がもらえる。通常これらの支援は直接な報告から、プロダクトオーナーから、また、ほかの重要な利害関係者からのインプットを収集、統合した情報から得られる。しかし、プログラムバックログに対する最終的な権限はこの1人だけである。この役割はビジョンとロードマップの作成、維持、説明に関しても責任を持つ。

詳細

役割の概要説明

プロダクト管理者はアジャイルリリース列車の「内容に関する権限の保有者」の役割を果たす。企業の技術的な目標と経済的な目標にバランスを取りながら、一連のリリースを通じ、顧客向けのフィーチャーの納品を最適化するために、プロダクト管理者はプログラムバックログの定義や優先順位付け、ビジョンロードマップの開発、また、プロダクトオーナーと一緒に作業することについて責任を持つ。

始まる前に、私たちは、この役割の遂行は標準なスクラムと明らかに異なることを言及する。スクラムでは、プロダクトオーナーは資金の確保、ROI目標の管理、リリース計画などいろいろを含む、全般なプロダクトに関する責任を持っている。しかし、企業では、通常そうではない。なぜならば、これらの責務は通常もう少し市場やビジネス向きのプロダクト管理者やビジネス分析者によって担われるからである。こういう人たちは直接ソフトウェア開発チームのメンバーではないかもしれない。プロダクトオーナーのページでは、各責務の詳細はさらなる説明と描写がある。

プロダクト管理者、あるいはビジネス分析者?

特定の役割/肩書へ割り当てる責務はSAFeを効果的にするものであるが、他の人達の肩書の使い方とはずいぶん違うかもしれない。このことは、構築されるものかの「内容に関する主たる権限の保有者」の役割を果たすというプロダクト管理の役割において特に重要である。このことにして曖昧になることはできない。さもないと、SAFeの中心的価値におけるベクトル合わせが損なわれる。さらに、この役割の肩書や、異なる具体的な責務は主に以下2つに分類される:

プロダクト指向の企業: 独立ソフトウェアベンダーや組み込みシステム開発者を含む。この場合、プロダクト管理者という肩書は一般的であるが、この役割はソリューション管理者、システムエンジニアやプログラム管理者のような他の肩書によって担当することも可能である。PDMA(プロダクト開発と管理協会-Product Development and Management Association)は通常この役割には次の責務があると考える:発見及び顧客や市場調査、開発活動と商業化、技術や知的資産管理、プロダクト戦略及び計画と意思決定、プロダクト管理組織とチーム関係、共同開発と提携、プロセスの遂行、メトリックス。

情報システム(IS)/情報技術(IT): これらの企業(また上記の企業の内部部署)では、これらの責務に関係があるもっと一般的な肩書はビジネス分析者である。IIBA(International Institute of Business Analysts)はこの役割に次の責務があると考える:内部利用の新しいソフトウェアシステムの開発、配置と維持管理、商用既製ソフトウェアのインストール、設定と維持管理、外部のパートナーと一緒に、内部開発したソリューションと購入したソリューションを統合する。これらを介して、企業がビジネス目標を達成することに役に立つ。

アジャイルではこの役割の何が違うか?

前記の定義はこの役割の主要な責務に関する従来の見方を反映したものである。役目はおおむね同じかもしれないが、この役割が果たされる方法は、アジャイルではかなり異なっている。それらのことをまとめたものが以下の表1である。

PM/BA 責務 従来 アジャイル
顧客のニーズの理解 事前で断続的 弛まない相互作用
要求の文書化 文書で完全に説明される。手渡す。 高いレベルのPSIビジョン説明会。チームとの不断のコミュニケーション
スケジュールの立案 遠い先の1回の納品を計画する 継続的な短期のロードマップ
要求の優先順位付け まったく行っていないか、プロダクト要求定義(PRD)で1回だけ行っている WSJFを介して、すべてのPSI計画セッションで優先順位を見直す。継続的にスコープの優先順位調整
要求の妥当性の確認 適用できない。QAの責務 反復システムデモと各PSIに関与し、より小さくより頻繁なリリース
変更の管理 変更を禁止する。週次の変更管理審査(CCB)打ち合わせ リリースや反復の区切りで調整する

表1. アジャイルではプロダクト管理の振る舞いと責務の変化

プロダクト管理者の責務

肩書や変更の量に関わらず、SAFeプロダクト管理者は以下の責務を持つ。

  • プログラムポートフォリオ管理(PPM)と一緒に作業をし、ARTの目標、予算、ポートフォリオとプログラムエピックを理解する。 プログラム管理は以下いくつの場でPPMと一緒に作業する。
  • プログラムのビジョンを開発し、関係者に伝える。 プロダクト管理は継続的にビジョンを開発し、開発チームに伝えなければならない。ビジョンの伝達は一般的に一連のローリングウェイブビジョン説会を介して行う。この説明は、ソリューションの提案されたフィーチャーにスポットライトを当て、各リリース計画策定セッションで行われる。ソリューションが、関連の基準や、ほかのシステム品質要求を確実に満たすように、プロダクト管理は非機能要求も定義し、維持する。
  • プロダクトのロードマップを開発し、関係者に伝える。 ロードマップは、時間軸上でフィーチャーがいつ実装されるかに関する高いレベルの計画である。ロードマップは、顧客と利害関係者に伝えなければならない主要な納品物に関するフィーチャーの高いレベルのビューを含む。不確実な将来を予測するように求める如何なるビジネス上のプレッシャーや、現在のプログラムの信頼性に基づく予想と予測できる将来に関わらず、各ロードマップは次回のプログラムインクリメント(PI)について確信度が非常に高い計画、その後のPIについて計画の意図を定義しなければならない。
  • システムアーキテクトと一緒に作業をし、アーキテクチャー作業を理解する。 プロダクト管理は、技術的意思決定を促進することが期待されていない。一方、今後のアーキテクチャー作業のスコープを理解し、システムアーキテクトと一緒に作業することによって、意思決定への支援、新しいビジネスエピックを提供するための主要な技術インフラの実装に関する作業の順序づけへの支援が期待されている。
  • プログラムバックログを管理し、フィーチャーの受け入れ基準を開発する。 この作業の結果はフィーチャーの選択、プログラムバックログという主要な成果物の優先順位付けを促進する。また、フィーチャーの受け入れ基準は、フィーチャーが「完了の定義」に満たしているかどうかを判断するために利用できるので、プロダクト管理は受け入れ基準の開発に参加する。フィーチャーの賢明な選択と順序づけは、各プログラムの主要な経済原動力であるため、このバックログに対し、リリース計画策定セッションの前にWSJFを利用し詳細化と優先順位の見直しを行う。
  • リリースとプログラムインクリメントを定義する。 「開発するもの」に責任を持つということは、プロダクト管理は、新しいフィーチャーやアーキテクチャー、技術的な負債への容量の割り当てを含むリリースの定義に関して唯一の責任を持つことを意味する。これは一連のプログラムインクリメントとリリースによって実現されるが、それらの定義とビジネス目標もプロダクト管理によって決められる。
  • リリース管理、ソリューションの妥当性確認に参加する。 プロダクト管理はリリース管理に参加し、システムデモにも関与する。PI終了時に、プロダクト管理はソリューションのデモに関与し、計画に対する達成したビジネス価値の評価を含むメトリックスの評価を行い、検査と適用に積極的に参加する。
  • 効果的なプロダクト管理者/プロダクトオーナーチームを構築する。 最後に、SAFeは1つのシステムであり、システムの全部分が機能しないとSAFeは機能しない。プロダクトオーナーとプロダクト管理者の役割は独立しており、異なる内部組織に所属するが、品質とビジョンの確約に基づいて、定期的に納品する高いパフォーマンスのチームの1員として得られた仕事に付随する満足度は言うまでもなく、効果的で効率的な開発を行う上で拡張された有効なプロダクト管理者/プロダクトオーナーチームの構築は不可欠である。プログラムにおける内容に関する最終的な権限の保有者として、プロダクト管理はビジネス上の結果を獲得するために必要な組織、ソリューションの方向性、コミュニケーションプラクティスの実装を先導する役割を担う。

より大きな価値のストリームにおけるプロダクト管理

通常、多くの場合は1つのARTに専属するプロダクト管理がある。このページでの説明はこの場合である。しかし、より大きな価値のストリームにおける内容の連携については、異なる構造と責務を持つプロダクト管理の役割が必要である。これは連携のページに簡潔的に説明する。


さらに知りたい場合

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011, 第14章(邦訳:アジャイルソフトウェア要求:チーム、プログラム、企業のためのリーンな要求プラクティス、翔泳社、2014)

Last Update 18 July, 2014

This information on this page is © 2010-2014 Leffingwell, LLC. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. For permissions, please contact permissions@ScaledAgile.com.