スクラムで最後に残る役割は、プロダクトオーナー、開発チーム、それともスクラムマスター?

やや物騒なタイトルだが、スクラムチームが成熟したら、最終的にどうなるかを考えてみよう。

まず、タイトルにもある「スクラムチーム」には、以下の役割がある。

プロダクトオーナー
開発チーム
スクラムマスター

ややこしいが、「スクラムチーム」の中に「開発チーム」がある。
「開発チーム」は「スクラムチーム」の役割のひとつで、9人以内のメンバーで構成される。

では、それぞれの役割を、おさらいも兼ねて振り返ってみよう。

以下は、スクラムガイド最新版からの抜粋である。訳者は角征典氏である。

スクラムガイド全文はこちら

ーーーーーーーーーーーーーーーーーーーーーーー

プロダクトオーナー

プロダクトオーナーは、開発チームから生み出されるプロダクトの価値の最大化に責任を持つ。組織・スクラムチーム・個人によって、その方法はさまざまである。

プロダクトオーナーは、プロダクトバックログの管理に責任を持つ 1 人の人間である。プロダクトバックログの管理には、以下のようなものがある。

• プロダクトバックログアイテムを明確に表現する。
• ゴールとミッションを達成できるようにプロダクトバックログアイテムを並び替える。
• 開発チームが行う作業の価値を最適化する。
• プロダクトバックログを全員に見える化・透明化・明確化し、スクラムチームが次に行う作業を示す。
• 必要とされるレベルでプロダクトバックログアイテムを開発チームに理解してもらう。

上記の作業は、プロダクトオーナーが行う場合もあれば、開発チームが行う場合もある。
いずれの場合も、最終的な責任はプロダクトオーナーが持つ。

プロダクトオーナーは 1人の人間であり、委員会ではない。委員会の要求をプロダクトバックログに反映することもあるだろうが、プロダクトバックログアイテムの優先順位の変更については、プロダクトオーナーと相談しなければいけない。

プロダクトオーナーをうまく機能させるには、組織全体でプロダクトオーナーの決定を尊重しなければいけない。プロダクトオーナーの決定は、プロダクトバックログの内容や並び順という形で見える化されている。異なる要求の作業を開発チームに強制することは誰にもできない。

開発チーム

開発チームは、各スプリントの終了時にリリース判断可能な「完成」したプロダクトインクリメントを届けることのできる専門家で構成されている。
「完成」したインクリメントは、スプリントレビューに必要である。インクリメントを作成できるのは、開発チームのメンバーだけである。

開発チームは、自分たちの作業を構成・管理するために、組織から体制と権限を与えられている。その相乗効果によって、開発チーム全体の効率と効果が最適化される。
開発チームには、以下のような特徴がある。

• 自己組織化されている。プロダクトバックログをリリース判断可能な機能のインクリメントに変える方法は、誰も（スクラムマスターでさえも）教えてくれない。
• 機能横断的である。インクリメントを作成するスキルをチームとしてすべて備えている。
• ある人にしかできない作業があったとしても、スクラムにおける開発チームのメンバーに肩書きはない。 • テスティング、アーキテクチャ、運用、ビジネス分析のような専門領域であっても、スクラムは開発チームのサブチームを認めていない。
• 開発チームのメンバーに専門能力や専門分野があったとしても、最終的な責任は開発チーム全体が持つ。

スクラムマスター

スクラムマスターは、スクラムガイドで定義されたスクラムの促進と支援に責任を持つ。
スクラムマスターは、スクラムの理論・プラクティス・ルール・価値基準を全員に理解してもらえるように支援することで、その責任を果たす。

スクラムマスターは、スクラムチームのサーバントリーダーである（訳注：メンバーが成果を上げるために支援や奉仕をするリーダーのこと）。
スクラムマスターは、スクラムチームとやり取りをするときに役に立つこと／立たないことをスクラムチームの外部の人たちに理解してもらう。スクラムマスターは、こうしたやり取りに変化をもたらすことで、スクラムチームの作る価値を最大化する。

スクラムマスターはプロダクトオーナーを支援する

スクラムマスターは、さまざまな形でプロダクトオーナーを支援する。

• スクラムチームの全員がゴール、スコープ、プロダクトのドメインを可能な限り理解できるようにする。 • 効果的なプロダクトバックログの管理方法を探す。
• 明確で簡潔なプロダクトバックログアイテムの必要性についてスクラムチームに理解してもらう。
• 経験主義におけるプロダクトプランニングについて理解する。
• 価値を最大化するためのプロダクトバックログの調整方法をプロダクトオーナーに把握してもらう。
• アジャイルを理解・実践している。
• 必要に応じてスクラムイベントをファシリテートする。

スクラムマスターは開発チームを支援する

スクラムマスターは、さまざまな形で開発チームを支援する。

• 自己組織化・機能横断的な開発チームをコーチする。
• 開発チームが価値の高いプロダクトを作れるように支援する。
• 開発チームの進捗を妨げるものを排除する。
• 必要に応じてスクラムイベントをファシリテートする。
• スクラムがまだ完全に適用・理解されていない組織環境で、開発チームをコーチする。

スクラムマスターは組織を支援する

スクラムマスターは、さまざまな形で組織を支援する。

• 組織へのスクラムの導入を指導・コーチする。
• 組織へのスクラムの導入方法を計画する。
• スクラムや経験的プロダクト開発を社員やステークホルダーに理解・実施してもらう。
• スクラムチームの生産性を高めるような変化を促す。
• 他のスクラムマスターと一緒に組織におけるスクラム導入の効果を高める。

ーーーーーーーーーーーーーーーーーーーーーーー

では、スクラムチームの各役割をおさらいしたところで、冒頭の話に戻ろう。

スクラムチームで最終的に生き残るのは誰か。

それは、「開発チーム」であろう。

説明しよう。

最初にいなくなるのは「スクラムマスター」だ。
あなたも異議のないところであろう。

スクラムマスターの役割は支援である。
対象はプロダクトオーナー、開発チーム、そして組織と多岐にわたるが、あらゆるコトが円滑に進むよう、ファシリテートする役割である。

プロダクトオーナーが自立し、開発チームが自己組織化し、組織のアジャイル支援体制が確立すれば、スクラムマスターの作業は、徐々に落ち着いていく。
複数のチームのスクラムマスターを兼務した後、やがて完全に手が離れることになるだろう。

プロダクト開発に、なにかしらの障害や調整事はつきものである。だから、「スクラムマスターは永遠に不滅だ」と説く人もいる。あなたがスクラムマスターなら、さみしいと感じるかもしれない。

だが、スクラムマスターがチームを卒業するということは、それだけスクラムチームが成長し、強力になった証しだ。
チームの自律化が進んだ後も支援を続けることは、チームの為にならない。チームの甘えを誘発するだけである。

次にいなくなるのは、プロダクトオーナーである。

スクラムガイドには次の文がある。

上記（プロダクトオーナーの役割責任）の作業は、プロダクトオーナーが行う場合もあれば、開発チームが行う場合もある。いずれの場合も、最終的な責任はプロダクトオーナーが持つ。

英語の原文も載せておこう。

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

「最終責任はプロダクトオーナーにあるけど、作業自体は開発チームに任せてもよい」と説いている。

開発チームは、専任の安定したチームだ。だから、扱うドメイン知識を、どんどん吸収し、蓄積していく。
最初は、プロダクトオーナーにプロダクトバックログを明確化してもらったり、プロダクト・ニーズの背景やコンテキストを詳細に説明してもらわないといけないだろう。
だが、プロダクトを学び、インクリメントを実装していく過程で、開発チームは、やがてプロダクトのドメインエキスパートになる。

開発チームは、自己組織化されているから、自分達で思考し、実験し、改善していく。そして、自己組織化は、実装作業にとどまらない。

プロダクトオーナーとのコラボレーションを通して、ニーズの源流である利害関係者との人間関係も構築するようになる。
プロダクトオーナーから、ニーズの集め方、プロダクト・ビジョンとの整合性の取り方、プロダクトのデモ会（おさわり会）での利用者フィードバックの獲得方法、今後のバックログの優先順位付けを学ぶ。
開発チームは自己組織化したチームとして、経験的プロセスを駆使し、ドメイン領域も学び、できることをどんどん増やしていく。

やがて、開発チームもプロダクト・マインドを備えるようになる。
そして、機能横断的なチームとして、PO関連の作業を誰もができるようになっていく。

ここまで来ると、スクラム3つの役割全てを、開発チームが単独でこなせるようになる。

組織として、現場へのエンパワメントを継続し、開発チームが究極まで自己組織化したら、開発チームがスクラムチームになるだろう。

スクラムの究極的なカタチとして、私の考えはこれだ。

最終的に、開発チームという名の、自己組織化された多能工チームが残る。