アジャイル開発とスクラム
2001年にソフトウェア開発にあたり重視されるべきマインドセットを盛り込んだ「アジャイルソフトウェア開発宣言」が公開された。ここでは変化を前提とし、顧客満足を最優先とした、素早く、継続的な価値提供を目指している。この宣言は世界中のソフトウェア開発者達に支持され、今ではソフトウェア開発以外の分野においても広まっている。
アジャイル開発において最も利用されているのが「スクラム」である。スクラムチームという小規模のチームを編成し、一定期間ごとに優先順位の高い機能を盛り込んだソフトウェアを開発し評価することを繰り返す。
ユーザーやステークホルダーからの要望を迅速にフィードバックしながら計画と改善を繰り返すため、不確実な状況への対応力が高いという特徴がある。
■スクラムの3種のロール
スクラムチームにはプロダクトオーナー、スクラムマスター、開発チームの役割がある。
プロダクトオーナーはプロダクトの価値の最大化を目指すことに責任があり、プロダクトの要件となるプロダクトバックログの決定、予算の管理やステークホルダーとの調整を行う。
スクラムマスターは、プロダクトオーナーや開発チームを支援する役割であり、スクラムチームが円滑に作業を進めるために必要な支援を行う。
開発チームは実際にスクラムチームの中で開発作業を担う役割であり、プロダクト作成に必要なすべての作業を担当する。
日本のアジャイルプロジェクトでは、プロダクトオーナーをビジネス部門やクライアント、スクラムマスターと開発チームをシステム部門やITベンダーが担うことが多い。
スクラムマスターや開発チームには熟練したエンジニアが多く、スクラムプロジェクトの経験も豊富であるのに対し、プロダクトオーナーはシステム開発も初めてであるケースもあり、様々な課題が生じている。次の章で詳細を考察していく。
プロダクトオーナーの課題と提言
課題1：手法の難しさ
プロダクトオーナーが陥りがちな課題の1つは、様々な手法でプロダクトを表現・展開するが、人によって求める視点や粒度が異なるうえ、手法が正しく使えておらず、本質的ではない書き直しに工数をとられてしまうことだ。
アジャイル型の進捗管理手法・ツールは確立されつつある。プロジェクト管理ツールはAsena、Backlog、Wrikeなど、KANBAN/ガントチャートのアジャイル・ウォーターフォール両面対応が一般化し、JIRAなどアジャイル特化ツールの流通も大きい。
これらはプロジェクト開始当初にスクラムマスターが検討、提案することが多く、定型化している。
一方、プロダクトの価値を考えるアプローチは未だ決まった方法が確立されていない。
ユーザーの詳細を書き起こすペルソナや、どの程度の市場があるか、何を主眼にした製品であるかといった商品コンセプトにはビジネスモデルキャンバス、バックログを起こす際はユーザーストーリーマッピングという記載方法など、これらは一般的に広まっている。
しかしながら、1つの手法に対し何冊も書籍が出ており、それぞれ記載の粒度や優先順位の付け方などが異なり、有識者の主張・提言も統一されているわけではない。
またそれぞれの手法に対し時間をかけて経験を積まなければ、コツをつかむのも難しい。
課題2：人間関係
特にプロジェクトの初期段階におけるプロダクトの方向性は未知数である。
何ができるか、何の効果があるかわからない中で、プロダクト案を書き起こし提示したとしても、仮説やアイデアレベルであるにも関わらず、根拠や分析を求められるなど、開発チームからの疑問やステークホルダーからの指摘が多発する。
そしてプロダクトバックログの書き直しを繰り返し、開発開始までに時間を要してしまう。遂には開発チームからプロダクトオーナーの推進力の不足を嘆かれ、ステークホルダーからは「アジャイルになるとスピードが上がると思っていたが、何もできてこない」というコメントが出る状態にまで至ってしまう。ここまでくると、プロダクトオーナーが孤立感を抱いたり、当初の勢いを失ってしまうことは多い。
プロダクトオーナーは常に誰もが納得し、必ず効果が出るプロダクト案を持っているわけではない。
ましてや、日本企業においては、自身が立案していないプロダクトのオーナーに任命されることも多々ある。
プロダクトオーナーの責任はプロダクトの価値を最大化するよう、チームやステークホルダーと共に、検討を進めることである。
アジャイルやスクラムの知識が浅い関係者も含めて説明し協力を求め、関係をつくる必要がある。
プロダクトオーナーはプロダクトの中身だけでなくプロダクトに関係するメンバーが成長する環境づくりまで担わなければならない。
課題3：プロダクトオーナーのポジション
アジャイルやスクラムを介して、会社をまたがったイベントやコミュニティが盛んに作られているが、そこにプロダクトオーナー参加することはわずかである。
参加するスクラムマスターや開発チームを見ると、システム部門やITベンダーに所属しているケースが多く、システム開発の共通言語で事例やベストプラクティスの共有がなされていたり、現場における悩みの吐露や、新たなやり方・工夫を共有し合える横のつながりを得ている。
一方、プロダクトオーナーは通常、ビジネス部門からアサインされている事例が多く、事業内容や業界が異なるためプロダクトオーナー同士がつながることは稀である。
書籍から手法を学んだり、スクラムマスターや開発チームから教えてもらわざるをえない。
後者は多かれ少なかれ、教える側が動きやすいようなやり方を提案するため、プロダクトオーナーとマッチするかどうかは未知数だ。
プロジェクトと違い、プロダクトのライフサイクルは長いため、何度もプロダクトオーナーを経験するということは少ない。
したがって、主に書面上で知見を学び、実践していかざるを得ない。
提言：プロダクトオーナーはチームとして担う役割である
スクラムガイドによると、意思決定の速さや明確さが製品開発の鍵となるため、プロダクトオーナーは合議制ではなく、1名となっている。
しかし、未経験ながら発展途上の手法を学び、プロダクト構想、市場価値の分析を行ったうえで、チームやステークホルダーを導くという一連の作業をたった1人で行うというのは現実的ではない。
1人の最終決定者を据えつつも、チームとして対応していくことが望まれる。
スクラムガイドに従うと、プロダクトオーナーを支援することもスクラムマスターの役割となるが、スプリントイベントを回し、開発の課題を共に解決しつつ、市場分析まで行うのは難しい。
したがって、プロダクトオーナーを支援する役割として、プロダクトチームマスターなどを置くのが望ましいだろう。
その代わり、プロダクトチームはプロダクト企画、市場分析等の有識者をまとめ、プロダクトオーナーの意思決定をサポートする。
時に、スプリントレビューに陪席することはあるが、あくまで最終意思決定者はプロダクトオーナーとし、プロダクトチームは情報整理の支援を行う。
プロダクトの開発が波に乗ったとしても、プロダクトオーナーはプロダクトバックログの継続的な整理を行い続けることが多いため、開発を主軸としたスクラムチームを備えるとともに、構想をブラッシュアップするプロダクトチームを存続させておくことが望ましいだろう。
同時に、開発とプロダクト企画が分離しないように調整すべきだ。
スクラムマスターとプロダクトチームは共にデイリーミーティングなどを組みつつ、密な情報共有を持つことが必要である。
