Jeff Patton氏、アジャイルのプロダクトオーナシップを語る

先日のAgile Indiaカンファレンスで行った基調講演で、Jeff Patton氏は、アジャイル開発がプロダクトのオーナシップにアプローチする方法を取り上げた。氏によれば、プロダクト管理は“プロダクトオーナ”というスクラム用語が生まれる前に存在した規律であって、大部分のアジャイル組織においては、せいぜい形式的なアプローチとして採用されているに過ぎない。

氏は言う。

アジャイル開発は昔も今も、プロダクト管理に失敗しています。
アジャイル開発はソフトウェア開発において多くの問題を解決してきました。アジャイルを利用する企業はこれまでにないほど予測可能な方法で、機能するソフトウェアを提供し続けています。しかしながら、そこで開発されるソフトウェアが常に優秀か、あるいは市場で成功を収めているかと言えば、必ずしもそうではありません。それは、プロダクトを成功させるために必要なことが、アジャイル開発に組み込まれていないからです。それどころか、一般的なアジャイルプラクティスを厳格に守ることで、逆に製品が悪化する可能性さえあるのです。

一般的なアジャイル開発アプローチは、アジャイル活動以前にあった数多くのプロダクト管理の規律を等閑にしている、と氏は指摘する。“生産関連の人たちがアジャイルを嫌うのは、顧客と話し合わないから”だ、と氏は感じている。顧客の代理たるプロダクトオーナは実質的な役割ではないため、結果としてユーザのニーズに合わない製品が生まれているのだ。プロダクト管理コミュニティと大部分の一般的なアジャイルアプローチとの間に亀裂が生じている、と氏は言う。氏に限らず、アジャイルにプロダクト管理の規律を含むように主張する人は少なくない。

アジャイル開発を採用する企業が自らの開発する製品を、より成功し、よりユーザニーズに合致したものにするためには、重視しなければならないことがいくつかある、と氏は言う。

• ソフトウェアの迅速な提供を重視しないこと。ポイントやベロシティに固執してはいけない — 必要なのはデリバリのスピードではなく、問題を解決することなのだ。
• 製品を開発する上で意図した成果(顧客のメリット)と影響(顧客の成果による自社の長期的かつ持続可能なメリット)を特定し、それを評価すること。アウトプットは必要だが(製品は作らなくてはならない)、目指すべきは成果(outcome)と影響(impact)である。

開発チームが他のビジネス領域からサプライヤとして扱われている現状に対して、氏は異議を唱えた — このようなクライアント/ベンダ間の関係は、購入する製品が完全に説明されていて、すでに完成している場合において意味をなすものだ。仕様書作成者と製造者が同じ組織で作業するような状況下では、これは“考え得る最悪の状況”であり、結果としてユーザニーズを満足しない、基準以下の製品が出来上がることになる。このパターンがアジャイル開発には織り込まれている — プロダクトオーナが“ビジネス側”の代理となり、バックログの作成と優先順位の判断を行うために必要なことを正確に理解するように求められる一方で、チームが時間とコスト、開発範囲を担当する。これが事実として、プロダクトオーナとチームの間に、クライアント/ベンダの関係を生み出している。

氏はこのアプローチを、プロダクト管理(Product Management)と比較した。プロダクト管理におけるプロダクトマネージャには、幅広い視点をまとめ、チームと協力して問題解決のための最善策を見つけ出すことによって、価値のある、有用性と柔軟性を備えた、持続可能な製品を作り上げることが求められる。プロダクトマネージャは、エンジニアリング、ユーザエクスペリエンス、製造、法律およびコンプライアンス、セキュリティ、品質保証、競合分析など、製品提供に必要なスキルをすべて備えたクロスファンクショナルなチームを率いる。

“チームは人ではなく製品を所有している”のだから、プロダクトオーナという役割は理に適っていない、と氏は言う。

製品のニーズを調査する上で得られら無数のアイデアはおそらく間違っているという事実を、プロダクトマネージャは受け入れなくてはならない — 新製品のほとんどは失敗し、製品に組み込まれる機能のほとんどは利用されない。従って、詳細な要件を定義するのではなく、ニーズは仮説として表現されるべきなのだ — “このタイプの人にこの機能ないし性能を提供すれば、このタイプのメリットがあって、我々の企業の影響を与えると思われる”、それに従ってチームは、仮説の立証方法を定義し、その仮定をできる限り短期間で検証ないし否定可能なものを、可能な限り低コストで構築する。それが正しいと証明できれば能力を増幅し、そうでなければその仮説を捨てて新たな仮説を探るのだ。

この仮説駆動のアプローチのためには、プロダクトマネージャとチームがビルディングを出る必要がある — ユーザが製品を使っている環境に出向き、ユーザのエクスペリエンスを十分に理解し、共感し、痛みを経験するのである。

氏は最後に、５つの重要なアドバイスをまとめて、自身の講演を締め括った。

1. アウトプットを最小化し、成果と影響の最大化と評価を行うこと。
2. プロダクトオーナとプロダクトマネージャはクロスファンクショナルなコア製品チームを指導して、チーム全体を製品決定に参加させること。チームが製品を所有するのだ。
3. 製品の“賭け(bet)”を伝えること。不確実性を避けるためには、小さな賭け(実験、テスト、学習の各アクティビティ)を使うこと。
4. 共感と洞察を構築するために、全員がユーザと顔を合わせる時間を持つこと。
5. 探索活動はチームワークである。計画し、可視化し、見直し、反映すること。