マネジメントのためのScrum入門

Product Ownerに関する誤解

2022/03/26

AgileとScrumに関する再確認

そもそも日本のマネジメント層で「Agile」と「Scrum」の意味を正しく理解していない人が多いと感じます。

多くのマネジメント層は「AgileもScrumも…『ものづくりが早くなる…生産性が上がる開発手法』のこと」…という勘違いがしているケースをよく見かけます。

まずは、「Agileは顧客を巻き込む思想」であり「Scrumは実現するためのフレームワーク(形)」と理解すると整理できるかと思います。

Agile Manifesto」には「契約交渉よりも顧客との協調を」と書かれており、更に「12の原則」には「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。」「要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。」という記述があります。これを「日本に多い受託開発案件」に当てはめて顧客側が一方的に主張すると…開発側だけが辛いだけになります。しかしAgileの顧客を巻き込むというのは「顧客の要求を只々受け入れる」という意味ではありません。「顧客と一体になって…つまり発注者と受注者の関係性ではなく、一体になって価値を追求することで…本当の「顧客満足」を手に入れよう…という思想です。

12の原則もこんな風に意訳できるかもしれません。

  1. プロダクトの価値は、「最初に決めた通り正確に動くこと」ではなく、「継続的に顧客満足を提供できること」だと考えます。

  2. お客様とワンチームとなり、顧客の競争力を高めるための変更は歓迎し、スコープや納期の調整をします。

  3. 短い期間で少しずつ…動くプロダクトを試してもらうことで顧客フィードバックを受け、常に計画を見直しながら開発を進めます。

  4. 顧客と開発者は、受注者と発注者の関係ではなく、ワンチームとして働かなくてなりません。

  5. プロダクトが目指す意味に共感し、それを実現できる人材を集めてチームを作ります。チームを信頼し必要な環境や支援を与えます。

  6. 要求を集める、共有し、確認するには文書より、直接会話を時間を取る方が…最終的に効率的です。

  7. 進捗報告書か会議、新たな指標のの追加などをするより、動くソフトウェアで判断するのが最も効率的です。

  8. 無理に当初の計画に合わせるために残業する…などの行為はチームを疲弊させます。マラソンのように持続可能なペースを維持することが、最終的に最も仕事の速度を速めることになります。

  9. 様々な変化に素早く対応できるようになるためには、常に新しい技術を学び、現状を見直し続けることが必要です。

  10. 求めるべきなのは「早く大量に作れる能力」ではなく「より少量で最大の価値を産みます」ことです。

  11. 良質なプロダクトは、「言われたものを作れば良い」ではなく、自ら価値を高める方法を探すよう任されたチームから生み出されます。

  12. 短く定期的に振り返り、改善を繰り返すことで変化に対応しながらチームを成長させ続けます。

基礎知識不足から生まれるProduct Ownerの誤解

Agileの思想を理解すると、チームワークがとても大事であることが大事だとわかります。

「発注者と受注者」のマインドセットを捨て、「ワンチーム」にならないとAgileを実現するためのフレームワークとしてScrumをやってみたとしても、生み出される価値は限定的になります。

よく「Product Ownerの人選」に関する相談を受けます。

Product Ownerは

    • Product領域に関する知識

    • Productにおける判断をする権限

が必要であり

  • スコープの優先順位の定義とメンテナンス

  • ステークホルダーとの調整

  • リリース計画の立案と継続的調整

を受け持っているため、「顧客側から出してもらうべきか?」「Scrumの知識がある開発側から出すべきか?」という相談です。

必要な知識や権限がって「ワンチーム」である意識を持って(Scrumを正しく理解して)いれば…「どちら側でも良い」が回答になるかと思います。大事なことは「どちら側か?」ではなく「ワンチームであることの価値を理解して働ける人」を選ぶことが重要となります。

顧客側に「Agileのマインドセットを理解し、ScrumにおけるProduct Ownerの役割を学び…ワンチームで働くことが、自社にとってより良い結果を得られることを信じる」ことのできる人材がいれば、顧客側から出してもらうのが良いでしょう。

顧客側のステークホルダが「Agileのマインドセットを理解し、Scrumチームに任せることが、自社にとってより良い結果を得られること」を信じていて、開発側に十分なプロダクト分野に関する知識がある人材がいるなら、開発側から出してもらっても良いと思います。

こういった判断をせずに「側」で選ぶと…「発注者の立場でチーム外から関わろうとするProduct Owner」「受注者の立場で、権限を全く与えられておらず御用聞きでしかないProduct Owner」が生まれることになり、チームは機能しなくなります。

「どちらが出す」ではなく、「適切な環境と人材が整っているか?」「整っていないなら、整いそうな進め方はどちらか?」で考える必要があります。

本当に足りない人材は…?

私は、アジャイルコーチとしてチームの立ち上げに関わったり、認定スクラムマスター研修の共同トレーナーをしています。アジャイルコーチ界隈では「よいスクラムマスターが不足している」という声を良く聞きます。確かにScrum Masterは「Product Ownerを含むチーム全体」だけでなくステークホルダや組織…つまり上司にあたり人たちも含めて「コーチする(導く)」責任があります。

とはいえ…そんな簡単な話ではないですよね…。

だから私は、より多くの顧客やステークホルダ…マネジメント層に「認定Product Owner資格」を取ってもらえるようにしたいと思っています。そうすると「アジャイルな組織をどう評価すべきか?」の観点が代わり、適切な舵取りができる…本当のリーダーシップになれると思うのです。

※アジャイルな組織における評価指標の話は次回に…