スクラムでの責任を明確にする重要性

スクラムチーム

スクラムチームには明確な３つの責任で構成されています。

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

スクラムチームが過度の対立や信頼の欠如に悩んでいるとき、その原因は、それぞれの責任を明確にしていないことであることがよくあります。プロダクトオーナーは、最善の意図を持っていたとしても、次のスプリントに集中しすぎ、全体像を見ることを欠いてしまうことがあります。スクラムマスターは、チームを過度に保護するようになり、開発者は、喜んでもらいたいために、より多くの作業を引き受けることになり、スプリントゴールを危うくしてしまうのです。

明確な責任の欠如を示す指標

チームにおける明確な責任の欠如は、以下ような示す指標として表れます。

• プロダクトオーナーが、プロダクトゴールを作成しない、もしくはプロダクトゴールを伝えない
• プロダクトバックログには、次のスプリントに向けた十分な作業の「準備（READY）」ができていない
• 開発チームまたはビジネスステークホルダーが、プロダクトバックログの並べ替えに対して費用対効果（ROI）の計算を求めている
• 開発者が、スプリントプランニングにおいてどれだけの作業をスプリントバックログに引き込むかの判断に不安を感じている
• ステークホルダーやITマネージャーが、よく開発者を呼び出し、スプリントに作業を追加しようとする
• スクラムマスターが、ITマネージャーがスクラムイベントに参加することを認めない
• リソースマネージャーが、スプリントごとにチームのベロシティが向上していないとスクラムマスターを批判する
• ビジネスステークホルダーが、スクラムチームに対して、どのように作業をするかについて方針を示そうとする
• アーキテクトやその他のSME（Subject Matter Experts）が、スクラムチームへの支援の仕方をわかっていない

これらの指標の1つ以上に当てはまる場合、チームにおける責任をより深く理解することで、チーム機能を改善することができます。

スクラムにおける責任の深掘り

プロダクトオーナーは何を行うのか

プロダクトオーナーは、プロダクトバックログの内容と順番によって、ビジネスまたはコミュニティのプロダクトステークホルダーの関心を表します。プロダクトオーナーは、この作業を他者に委任することはできますが、責任は持ち続けます。開発者にプロダクトバックログ以外のリストの作業を指示することは誰もできません。

何を実施するのか

プロダクトオーナーは、プロダクトゴールを作成し、伝達します。プロダクトオーナーは、プロダクトゴールに基づいてプロダクト価値の向上に必要な作業が含まれるプロダクトバックログ（または、TO-DO リスト）を作成し、並べ替えを行います。これにより、透明でアクセス可能なものになります。プロダクトオーナーは、ステークホルダーや顧客とのコミュニケーションに役立てるために、予測やロードマップを作成することもあります。

なぜ実施するのか

プロダクトオーナーは、開発者の作業によって得られるプロダクトの価値を最大化する責任を持っています。スクラムチームが次に何に取り組むかを決定する判断を持つ個人がいなければ、スクラムではゴールに集中できなくなり、価値の提供が低下してしまうことになります。

よくあるプロダクトオーナーのアンチパターン

• プロダクトゴールが定まっていない
  • 原因: プロダクトオーナーが、次のスプリントに向けた十分な「準備完了（READY）」な作業を揃えることに集中しているのかもしれません。または、単一のプロダクトゴールが必要なことを認識できていないのかもしれません。
  • 対策: 舵のない船のように、ゴールのないスクラムチームは、頻繁に方向転換してしまい、まったく価値を達成できないことがあります。プロダクトオーナーが、スクラムチームが目指すべきプロダクトゴールを作成し、伝達することで、それぞれのスプリントはそのゴールに向けたステップとなるのです。プロダクトゴールを共有する機会としては、スプリントプランニングとスプリントレビューがあります。また、プロダクトオーナーは、リファインメントやステークホルダーとの会議でもプロダクトゴールを共有することができるのです。プロダクトバックログには、プロダクトゴールが含まれています。
• プロダクトバックログに、次のスプリントに必要な作業が十分に揃っていない
  • 原因: これは、新しいスクラムチームでよく起こることです。プロダクトオーナーには、準備が整った作業のプロダクトバックログを構築する時間がなかったのでしょう。
  • 対策: プロダクトオーナーは、プロダクトバックログの内容や並べ替えに責任を持ちますが、それらのタスクを開発者や、他の人（例: ビジネスアナリスト）に委任することもできるのです。さらに、リファインメントは、プロダクトオーナーが、開発者やステークホルダーと協力して、プロダクトバックログを迅速に構築する機会にもなります。

開発者は何を行うのか

開発者は、スクラムチームの作業を見積もりし、計画し、そして、実行します。開発者は、プロダクトオーナーと協力して、プロダクトバックログの価値を最大化し、どの作業をそのスプリントに引き込むかを判断します（スプリントバックログは、開発者が責任を持ちます）。

何を実施するのか

開発者は自己管理をしています。誰も（スクラムマスターでさえも）、スプリントごとに少なくとも1つのプロダクトバックログアイテム（PBI）を有用なインクリメントにする方法を指示することはできません。一般的に、開発者は、機能横断的であり、プロダクトバックログの作業を遂行するために必要なチームとしてのすべてのスキルを持ち合わせています。開発者は、スプリントバックログを作業の計画に用い、デイリースクラムをスプリントゴールへの進捗を測るためのチェックポイントとして用います。スクラムチームの開発者の間には上下関係はありません。全員がそのスプリントで少なくとも1つは有用なインクリメントを提供する責任を共に負っているのです。

なぜ実施するのか

そのスプリントで、少なくとも1つは利用可能なインクリメントを完成し、提供するためです。

よくある開発者のアンチパターン

• 開発者、リソースマネージャー、あるいはステークホルダーが、プロダクトバックログの並べ替えにおいて特定の費用対効果（ROI）の計算を求めるかもしれない
  • 原因: プロダクトオーナーの意思決定に対する自信のなさが映し出されています。
  • 対策: プロダクトオーナーは、スクラムチームの作業から得られるプロダクトの価値を最大化する責任を持っています。プロダクトオーナーのツールの一つが、プロダクトバックログです。プロダクトオーナーは、PBI を最適と思われる方法で並べ替えることができます。例えば、いくつかの素早い成功を得ることで、顧客との信頼関係をきずくことができると判断したり、純粋に費用対効果に基づいて PBI を並べ替えることを判断したりします。プロダクトバックログのリストをどのように並べ替えるかについては、プロダクトオーナーがすべての裁量権を持っていますが、開発者を含めたステークホルダーから意見を聞くべきです。これにより、プロダクトオーナーがプロダクトバックログを並べ替える際に、十分な情報に基づき判断することはできるようになります。
• ステークホルダーやITマネージャーが開発者に電話をして、スプリントへの追加作業を依頼することが当たり前である
  • 原因: ステークホルダーやITマネージャーが、プロダクトオーナーの責任を理解していないようです。
  • 対策: 開発者は、ステークホルダーからの追加作業に関しては、プロダクトオーナーとやりとりするように促します。もしくは、スクラムマスターがステークホルダーやITマネージャーに対してコーチングを行う必要があります。プロダクトバックログの並べ替えを判断できるのは、プロダクトオーナーだけです。

スクラムマスターは何を行うのか

スクラムマスターは、『スクラムガイド』に記載されているスクラムを確立させる責任を持ちます。簡単なことのように聞こえますが、そうではありません。スクラムマスターになるには、サイエンスよりもアートが必要となるのです。完璧なスクラムチームは、一夜にして進化するものではありません。高いパフォーマンスを発揮するユニットになるまでには、何年もかかることがあります。賢明なスクラムマスターは、どのような課題に最初に取り組むべきかを知っているものです。

なぜ実施するのか

スクラムマスターは、チームのサーバントリーダーであり、その目的は、スクラムチーム自身のプラクティスを改善することでスクラムチームの効果性を高めることにあります。

よくあるスクラムマスターのアンチパターン

• スクラムマスターが、リソースマネージャーのスクラムイベントへの参加を認めない
  • 原因: 組織において、スクラムチームのメンバーは、IT部門またはその他のリソースマネージャーにレポート（報告）している場合があります。これらのマネージャーは、自身の役割やスクラムチームとの関わり方を理解していないかもしれません。
  • 対策: スクラムマスターは、マネージャーたちに対してスクラムチームとの最適な関わり方をコーチングすることができます。例えば、デイリースクラムにマネージャーが出席するときには、開発者同士が同期することができるこの毎日の機会を邪魔しないようにすべきです。マネージャーの唯一の役割は、障害物の特定と除去や、スクラムチームのメンバー間での信頼の文化を促進することであるべきなのです。
• リソースマネージャーが、スプリントごとにチームのベロシティを向上させないとスクラムマスターを批判する
  • 原因: リソースマネージャーは、スクラムチームをサポートする方法を探しているのかもしれませんが、スクラムチームとの適切な付き合い方を知らないのかもしれません。
  • 対策: ベロシティは、スクラムチームが、作業を計画・整理するために用いるスクラムチーム内部でのツールです。ベロシティは、チームの成功を測るための定規ではないのです。代替としては、プロダクトの価値を計測するバリューメトリクスを用いてください。リソースマネージャーは、Scrum.org が提供している Professional Agile Leadership Essentials 研修コースに参加して、アジャイルチームの支援やコーチングの方法について詳しく知ることをお勧めしています。
• ビジネスステークホルダーが、スクラムチームに対して、どのように作業をするべきかについて指示を出そうとする
  • 原因: ビジネス側は、アジャイルチームの成功に対して既得権を持っていますが、スクラムチームとどのように関わるのが最善かはわかっていません。
  • 対策: 誰も（スクラムマスターでさえ）、開発者に PBI を「完成した」インクリメントにする方法を指示することはできません。スクラムチームが作業を（訳註: インクリメントとして）提供するためには、自己管理することが推奨されます。チームが自分たちの作業の提供を自分たちで行えるように権限を与えることで、組織は、スクラムチームのすべてのメンバーからより大きな創造性と問題解決のスキルを引き出すことができるのです。

責任の概要

	プロダクトオーナー	開発者	スクラムマスター	スクラムチーム
WHAT	ビジネスやコミュニティのステークホルダーの関心を表現する	作業の見積もり、計画、実施 プロダクトバックログの価値を最大化するためにプロダクトオーナーと協力する どの作業をスプリント（それぞれのチームのスプリントバックログ）に引き込むかを決定する	『スクラムガイド』で定義されているスクラムを推進・支援する スクラムチームと組織に対して指導や支援を行う	プロダクトゴールに集中する ゴールの達成に確約し、お互いをサポートする 作業と課題を公開する お互いを有能で自律した人たちとして尊敬し、正しいことを行う勇気を持ち、困難な問題に取り組むことができる
HOW	ユーザーグループと協力して、どのようなユーザー昨日が必要か、いつリリースすべきかを判断する プロダクトバックログの内容の選択や並べ替えを行う プロダクトバックログを全員が利用できるようにし、スクラムチームが次に何に取り組むかを示す 何をいつリリースするかを判断する 予測（ロードマップやリリース計画）を作成する	自己管理する 機能横断的である（プロダクトバックログで定義された作業を実行するために必要なすべてのスキルを持つチーム） スプリントバックログを用いて作業の計画を立てる リファインメント、開発、テストの責任は開発者全体にある	スクラムの理論、プラクティス、ルール、価値基準に関するコーチング サーバントリーダー バックログを管理するための効果的なテクニックを見つける 開発者の自己組織化へのコーチング 開発者の進捗を妨げる障害物を取り除く	3つの責任で構成される: プロダクトオーナー、スクラムマスター、開発者 10人以下のチーム規模（スクラムマスター、プロダクトオーナーを含めて） サブチームや階層はない それぞれのスプリントで価値を作り出すだけの必要なスキルをすべて持ち合わせる機能横断的チーム 小規模チームの方がコミュニケーション能力が高く、機敏な動きができるが、スプリントでの重要な作業を完了できる十分な規模であるべきである 誰が、何を、いつ、どうやってを判断できる自己管理チーム
WHY	開発者の作業の結果として生み出されるプロダクトの価値を最大化する	それぞれのスプリントで、少なくとも1つは完成した利用可能なインクリメントを提供する	スクラムチームの生産性を向上させる変化を創り出す 組織におけるスクラム適用の効果性を高める	完成の質を高めるために、スプリントごとに価値のあるインクリメントを作る ステークホルダーとの協力 検証 メンテナンス 運用 実験 調査と開発 スプリントでの持続可能なペースでの作業により、チームの集中と一貫性を改善する