プロダクトおよびソリューション管理

意思決定を分散する

─SAFeのリーン-アジャイルの第9原則

プロダクトおよびソリューション管理の概要

リーン-アジャイルな企業は、最高の品質を持つ適切なソリューションを最短のリードタイムで顧客に納品することを重視する。動的な環境でこれを行うには、明確な内容に関する権限の保有者が、要求の定義、優先順位付け、検証を、責任を持って継続的に行う必要がある。統合された短い学習サイクルで開発者と緊密に協力し、顧客の声を開発者に届けたり、開発者の声を顧客に届けたりする。

意思決定を分散する」の原則に沿って、SAFeでは、内容に関する権限を持つ役割を、3つのレベルで規定している。ソリューション管理は、価値のストリームの構成要素であるソリューションを指導する責任を持つ。プロダクト管理は、プログラムのビジョンとバックログに責任を持つ。そしてプロダクトオーナーは、アジャイルチームに代わってローカルの内容に関する意思決定を素早く行う。

このページでは、SAFeにおいてプロダクト管理とソリューション管理が果たす重要な役割について説明する。この2つの役割は、ほとんどの面でよく似ているが、担当するソリューションのレベルや管理対象の事柄が異なる。

詳細

ソリューション管理とプロダクト管理は、SAFeにおける主要な内容に関する権限の保有者であり、それぞれ価値のストリームレベルプログラムレベルを指導し、価値のストリームのバックログとプログラムバックログについて一番に責任を負う。ビジョンを作成し、顧客と協力してそのニーズを理解し、要求を定義し、価値のストリームとプログラムのカンバンを通して作業を進める。WSJFを使って作業の優先順位を付け、ロードマップを使ってリリースのスケジュールを立て、顧客の反応を検証し、素早くフィードバックする。

リーン-アジャイルな内容管理の方法

SAFeで内容と呼んでいるものは、従来は、マーケティングの要求文書や、プロダクト要求文書、システム/ソフトウェア仕様として表現されていた。ウォーターフォール開発では、これらの仕様は通常、事前に作成された。すべての要求をソリューション開発が始まる前に確定できると期待してのことである。しかし、思うようにことは運ばず、主にそれが理由でリーン-アジャイルのパラダイムへの移行が行われている。システムの要求や設計やアーキテクチャーに関する想定事項はすべて、実際の開発やテストや実験を通して検証する必要があり[1]、素早くソリューションにフィードバックできる知識が現れたら、チームはそれを受け入れなければならないということが、現在では理解されている。

ソリューションの意図で説明したように、ソリューションの要求の中には、最初から十分に理解され確定しているものもあるだろうが、まだまだ変動する可能性があり、開発プロセスを進めなければ理解できないものも存在する。この動的な新しいパラダイムを管理することが、プロダクト管理とソリューション管理の一番の責務である。リーンな企業では、表1に示すように、非常にアジャイルな方法でこの責務を果たさなければならない。

責務 従来 アジャイル
顧客のニーズの理解 事前。非連続。 絶えずやり取りが行われる。顧客は価値のストリームの一員である。
要求の文書化 文書で完全に推敲する。引継ぎ。 高いレベルのビジョン。プロダクトバックログおよびソリューションバックログの持続的な手入れ。アジャイルチームと直接会って行う非公式のコミュニケーション。
スケジュール 最初にロードマップとマイルストーンを作成してしっかりと確約する。 短期的なロードマップを継続的に作成する。
要求の優先順位付け まったく行わないか、行っても1度だけで、多くは要求文書の形態で行われる。 PI境界ごとにWSJFを使って優先順位を付けなおす。定期的にスコープを見直す。
要求の妥当性の確認 該当なし。QAの責任。 主要な役割。反復とPIのシステムデモに関与する。受け入れ基準を盛り込む。目的適合性を理解する。
納品スケジュールの管理 通常は1度だけ。事前に固定する。 十分な価値が作成されたらいつでも、頻繁にリリースする。
変更管理 変更を避ける。週次の変更管理ミーティング。 変化を受け入れる。PIと反復の境界で調整を行う。

表1. リーン-アジャイルな企業においてプロダクト管理とソリューション管理の振る舞いがどう変わるか

プロダクト管理の責務

このセクションでは、1つのアジャイルリリース列車におけるプロダクト管理の主な責務について説明する。大きな(複数のARTを含む)価値のストリームでは、この他にも責務が必要になる。それについては後のセクションで説明する。

  • 顧客のニーズを理解し、ソリューションの妥当性を確認する。プロダクト管理は、ARTに対して顧客の意見を伝える内部の代弁者であり、顧客(やプロダクトオーナー)と協力して、そのニーズを常に理解して伝え、ソリューション案の妥当性確認に参加する。
  • ポートフォリオレベルの作業を理解してサポートする。どのアジャイルリリース列車もポートフォリオのコンテキストの中で存在するため、プロダクト管理は、次の会計期間の予算パラメータを理解し、戦略テーマが戦略の方向性にどう影響するかを理解し、エピックオーナーと協力して自分のARTに影響するエピックのビジネス企画を作成する責任を負う。
  • プログラムのビジョンとロードマップを作成して伝える。プロダクト管理は、継続的に、ビジョンを作成して開発チームに伝え、システムのフィーチャーを定義する。システムおよびソリューションアーキテクト/エンジニアリングと協力して、非機能要求(NFR)の定義と保守も行い、関連する標準やその他のシステム品質要件をソリューションが満たしていることを確認する。また、ロードマップ(フィーチャーを時間軸上でどう実装していくかの予定を高いレベルで示したもの)についても責任を持つ。
  • 作業のフローを管理し優先順位を付ける。プロダクト管理は、プログラムカンバンを通ってプログラムバックログに入る作業のフローを管理する。準備の整ったフィーチャーが常にバックログ内に十分含まれるようにする責任を負う。準備の整った状態にするには、フィーチャーが完了の定義を満たしていることを確認するために使用できるフィーチャー受け入れ基準を作成しなければならない。また、どのフィーチャーを選んでどの順に実施するかが各ARTの経済性を大きく左右するため、PI計画セッションの前に毎回、WSJFを使ってバックログの優先順位の見直しを行う。
  • PI計画策定に参加する。毎回のPI計画セッションにおいて、プロダクト管理はビジョンを提示する。そこには、ソリューションのフィーチャー案と、関連するマイルストーンが近づいている場合にはそれが明示される。また、プロダクト管理はたいていは列車のビジネス責任者として参加し、PI目標の承認やビジネス価値の設定を行う。
  • リリースとプログラムインクリメントを定義する。何を開発するか」に責任を持つということは、プロダクト管理がリリースの定義に関しても大きな責任を持つことを意味する。これには、新しいフィーチャーやアーキテクチャー、技術的負債への処理能力の割り当てなどが含まれる。これは一連のプログラムインクリメントとリリースによって実現されるが、それらの定義やビジネス目標もプロダクト管理が決定する。プロダクト管理は、必要に応じてリリース管理と協力して、顧客にリリースするに値する十分な価値が累積したかを判断する。
  • システムアーキテクト/エンジニアリングと協力して働き、イネイブラー作業を理解する。技術面での意思決定をすることは、プロダクト管理には期待されていない。期待されているのは、今後のイネイブラー作業のスコープを理解することや、システムおよびソリューションアーキテクト/エンジニアリングと協力し、新しいビジネス機能を動かすための主要な技術インフラについて意思決定や順序付けを支援することである。そのためには、プログラムバックログのページで説明するように、処理能力の割り当てを決定するのが最善であることが多い。
  • デモや検査と適応のワークショップに参加する。プロダクト管理は、2週間に一度行われるシステムデモ(PIの終わりに実施される集約したものも含む)に積極的に参加する。また、得られたビジネス価値と計画の比較といったメトリックスの評価に加わったり、検査と適応のワークショップに積極的に参加したりもする。
  • 有能なプロダクト管理者/プロダクトオーナーチームを構築する。プロダクトオーナーとプロダクト管理者の役割が別の内部組織に所属している場合もあるが、開発を効率的かつ効果的に行うには、組織をまたいだ有能なプロダクト管理/プロダクトオーナーチームを構築することが重要である。このようなチームがあると、確約した品質とビジョンに沿って定期的に納品する優秀なチームの一員になることで得られる仕事に対する満足度も、大きく向上する。

大きな価値のストリームへのプロダクト管理の関与

上のセクションでは、ARTというコンテキストにおけるPMの役割について説明した。複数のARTが参加する価値のストリームソリューションを構築しているチームの場合、プロダクト管理はさらに次の責務を負うことになる。

  • ソリューション管理と協力する。価値のストリームレベルでは、ソリューションを対象に、ソリューション管理が同等の役割を果たす。ただし、この2つの役割が効果的に協力できなければ、ソリューションの構築を効果的に行うこともできない。この協力には、プロダクト管理が価値のストリームのバックログの手入れや優先順位付けに参加したり、システム能力をフィーチャー(や場合によってはNFR)に分割したりすることが含まれる。
  • PI計画前/後ミーティングに参加する。プロダクト管理は、PI計画前ミーティングにも参加し、価値のストリームの利害関係者と協力して、後に続くPI計画セッションに向けて入力情報、マイルストーン、高いレベルの目標を定義する。PI計画後ミーティングでは、計画策定の結果を、合意済みの価値のストリームのPI目標にまとめるのを手助けする。
  • ソリューションデモに参加する。プロダクト管理はソリューションデモに参加して、たいていは、自分のARTがかかわったシステム能力のデモをしたり、他のARTの成果をレビューしたりする。これは常に、システム的な視点を持ち、目的適合性を考慮して行う。
  • リリース管理と協力する。大規模なシステムでは、リリース管理も重要な役割を果たす。プロダクト管理は、主要利害関係者と協力して、担当するソリューション要素の進捗、予算、リリース戦略、リリースのしやすさを扱う。

ソリューション管理の責務

ソリューション管理は、価値のストリームレベルにおいて、プロダクト管理と同様の役割を果たす。ソリューション管理は、非常に重要なトロイカ(ソリューション管理、価値のストリームエンジニアソリューションアーキテクト/エンジニアリング)の一員として、ソリューションを成功させる責務の多くを担う。ソリューション管理は、ソリューションの意図(固定および変動のソリューションレベルの振る舞いをまとめて文書化したもの)について責任を持つ。また、必要に応じてリリース管理とも協力する。

ポートフォリオの利害関係者や顧客やARTと協力して、ニーズを理解し、ソリューションバックログを作成して優先順位を付けることも、ソリューション管理の責務の一部である。ビジョンや、ロードマップ、価値のストリームカンバン、ソリューションデモなどの作業も同様に行う。

ソリューション管理は、PI計画前/後ミーティングや価値のストリームの検査と適応ワークショップでも、重要な役割を担う。さらに、サプライヤーと協力することで、サプライヤーが納品するシステム能力の要求が正しく理解されていることを確認し、それらに関して概念的な整合が取れるよう手助けする。


さらに知りたい場合

[1] Ries, Eric.The Lean Startup:How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses.Crown Business, 2011.(邦訳:「リーン・スタートアップ」、日経BP社、2012)

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

Last update:21 August 2015