はじめに

SHIFT ASIAでプロジェクトマネージャー/スクラムマスターを務めているSONICです。
スクラムマスターの関連資格としては、Professional Scrum Master™ II (PSM II)を取得しています。

これまでに、さまざまなアジャイル開発プロジェクトにおいてスクラムの導入や運用に携わってきましたが、スクラムがうまく機能したプロジェクトもあれば、逆にうまくいかず失敗してしまったプロジェクトもあり、多くの成功と失敗を経験してきました。

こちらの記事を訪れた皆さんのなかにも、スクラムについて学んだ上で実際にプロジェクトに導入してみたものの、「スクラムが期待通りに機能しなかった」「スクラムサイクルがうまく回らず失敗してしまった」という経験をお持ちの方もいらっしゃるのではないでしょうか。

本記事では、そのようなスクラムをうまく活用できず悩んでいる方や、あるいはこれから初めてスクラムを導入するという方に向けて、私自身も経験したスクラムの失敗パターンと、その対策について詳しく解説します。
本記事で取り上げる、スクラムチームを負のサイクルへと導くアジャイルスクラム失敗パターン4選とそれぞれの対策を通じて、あなたのスクラムチームの開発オペレーションにおける失敗予防につながれば幸いです。

なお、本記事ではスクラムに関連する専門用語が多く登場するため、スクラムについておさらいしたいという方は以下の記事も併せてご参照ください。

スクラムとは｜スクラムの定義や特徴、体制とチーム内の役割
スクラムイベントとは｜スクラムにおけるスプリントと4つのイベント
スクラムの3つの作成物｜プロダクトバックログ、スプリントバックログ、インクリメントについて

アジャイルスクラムにおける失敗パターン4選とその対策

1. 直近で着手する予定のプロダクトバックログのタスクがブレイクダウンされていない

プロダクトバックログとは、簡単にいうと将来実現したいユーザーストーリーのリストのことです。通常重要度や緊急度順に並び変えられ、スプリントプランニングが実施されるタイミングでスプリントバックログに格納され、当該スプリントで成果物となっていきます。

プロダクトバックログのタスクは実現したいユーザーストーリーですので、デベロッパー（開発者）が開発に着手するまでに実際に着手可能な粒度になるまで、タスクブレイクダウン（タスクの細分化）を行う必要があります。

スクラムサイクルのリズムを保つ上で肝心なことは、タスクブレイクダウンとそのタイミングです。

次のスプリントで着手する予定のプロダクトバックログタスクがスプリントプランニングまでにブレイクダウンされていない場合、スプリントプランニング中のスクラムチームはタスクブレイクダウンに時間を割かざるをえず、プランニング中に適切なスプリントバックログを作成することができない可能性が高まります。

さらに、スプリントプランニングやスプリント期間中にタスクに関する質問が発生することでデベロッパーのタスク遂行に支障が生じ、スプリントゴールの達成が困難になってしまいます。
当該スプリントのリズムが乱れることで次のスプリントのベロシティも圧迫してしまい、次のプロダクトバックログリファインメントの時間も十分に取れなくなってしまうことで、徐々にスクラムが負のサイクルに陥ってしまう恐れがあります。

実際に、私のスクラムチームにおいてスプリントゴールを達成できなかったときのスプリントを分析した結果、「プランニング中にタスクブレイクダウンを行っていたこと」がその原因となっているケースが多いことがわかりました。

そのため、それ以降はプロダクトバックログリファインメントを定期的なイベントとして開催するようにし、スプリントプランニングに入る前に、スプリント中に仕様確認が発生しない程度にタスクのブレイクダウンが完了している状態になるようにしました。

その結果として、毎回スムーズに次のスプリントに移行することができるようになり、品質を犠牲にすることなく一定以上のベロシティを安定して実現しています。
目安としては、プロダクトバックログタスクに着手する２週間以上前にブレイクダウンを完了させるのがおすすめです。

2. スプリントプランニングで、完了の定義(品質基準)を満たすためのコストを考慮していない

スプリントの成果物には、保守性やセキュリティといった非機能部分も含めて、ステークホルダーが顕在的・潜在的に期待する以上の品質基準が満たされている必要があります。
品質基準の考慮が漏れた状態でスプリントバックログを作成してしまうと、品質を充足させるための工数が足りず、結果的に成果物の品質が低下し手戻りによる工数の浪費につながるため注意が必要です。

また、実装した時点から時間が立てば立つほど品質向上のための修正・実装に多くの時間がかかる上に、スプリントレビューではインクリメントが業務を開始・継続できるかどうかの検討にフォーカスできなくなってしまいます。

よって、スプリントプランニングの見積もりでは、スプリント期間中の実装工数だけではなく、完了の定義として「品質基準」を設けた上で、その基準を満たすための工数・コストも見積もっておくべきです。

一例として、私のチームでは完了の定義である品質基準を満たすことだけを目的に、あらかじめスプリントインターバルの20%の時間を確保しています。ウィークリースクラムであれば、月曜日から木曜日の間に実装を行い、金曜日に完了の定義を満たすために修正を行うようなイメージです。
このようにすることで、メンバーの意識に完了の定義を刷り込むことができ、また、スプリントプランニングが何らかの影響で乱れてしまった場合でも、品質基準を充足するための時間を強制的に確保することができます。

また、仮に完了の定義を満たすために確保した20%の時間が余った場合は、次のプロダクトバックログのタスクに着手すればよく、この施策による時間ロスは特に発生しません。

なるべく早い段階でプロダクトオーナーやステークホルダーと完了の定義をすり合わせることで、満たすべき品質基準を明らかにし、それを織り込む形でスプリントバックログを作成するようにしましょう。

3. スプリントレビューでデモを実施していない

システム開発の目的は、開発したシステムによってステークホルダーが業務を開始・継続できることです。開発した機能が、業務を理解しているステークホルダーによって使用できるかどうかを実際に動くものを通じて確認できるスプリントレビューは、極めてわかりやすく重要なイベントです。

十分にデモを実施できていないプロジェクトでは、これまで開発してきた成果物が業務に使用できないということがプロジェクトの終盤になって初めて判明するというリスクが付きまといます。ステークホルダーと開発チームとの間で認識に大きな齟齬が生じていると、ビジネスにおける価値提供の機会と利益を失うことにもつながります。

そのような認識齟齬を避けるためにも、スプリントレビューでデモを実施することは必須です。

しかしながら、私自身の過去の経験として、スプリントレビューの重要性を認識していながらも、そこで行われるのはデモではなく、単なる進捗報告のみとなってしまっていたプロジェクトがありました。
その原因は、他のスクラムチームや各関係者が参加する場において、進捗報告に多くの時間がとられてしまい、デモにかけられる時間が十分に確保できていなかったことにあります。

私の考えでは、スプリントレビューが適切に機能するためのポイントは、デモを行う前の進捗報告の時間を如何にして短縮するかです。

私が担当するプロジェクトでは、進捗報告の時間が10秒から数分に収まるように以下の二つの工夫を取り入れています。

一つ目は、タスクの完了基準と進捗報告フォーマットをステークホルダーと事前にすり合わせておくことです。具体的には、ステークホルダーと下記のような共通認識を持つことで、「順調」の意味合いを両者間で定義し、時間の無駄や認識の齟齬がなるべく小さくなるよう工夫しています。

二つ目は、スプリントプランニングのイベントが終了し、スプリントバックログができたタイミングで、プロダクトオーナーとステークホルダーにスプリントバックログのセットが完了したことを周知することです。

二つ目の工夫によって、プロダクトオーナーはプロダクトオーナーが想定している順序で価値が実現されていることを確認でき、ステークホルダーは次のスプリントで何が実現されるのか、すなわちタスク完了基準を事前に確認することができます。

以上二点をまとめると、一つ目で成果物の品質基準と生産性基準について共通した認識を持ち、二つ目で当該スプリントのタスク完了基準についての認識合わせができていれば進捗報告は「順調」の一言で済むようになります。
そこで節約された時間を活用して十分にデモを行うことで、成果物に対するフィードバックを集めることによりフォーカスできるようになります。

スプリントレビューにおいては、可能な限り進捗報告にかかる時間を圧縮し、重要性の高いデモの実施とフィードバックの獲得により時間を使えるように工夫しましょう。

4. アジャイルスクラムに適合したタスク管理ポリシーとタスク管理ツールを選定できていない

アジャイルスクラムとウォーターフォールに共通する特性として、タスクの完了基準を設け、ブレイクダウンしたタスクを形にしていくということが挙げられます。
一方で、アジャイルスクラムの場合はタスクのブレイクダウン・実装・検査・改善のサイクルを一定のインターバルで幾度となく繰り返す点が異なります。

見方を変えると、アジャイルスクラムではウォーターフォールに比べてコミュニケーションを取る機会が多い傾向にあるとも言えます。実は、ここにスクラムの成功を左右する秘訣が宿っていると私は考えています。

スクラムの開発オペレーションでは、確かにPDCAサイクルを回す上でコミュニケーションを取る機会が多く存在しています。特に、弊社の場合はオフショアで多国籍のチームで開発を行っていることもあり、コミュニケーションはなおさら注意が必要なポイントの一つです。

しかしながら、スクラムで行われるコミュニケーションは定型的なものが多く、タスク管理ポリシーに落とし込みやすいという性質があります。
例えば、スクラムのサイクルを振り返ってみると、次の流れの繰り返しとなっていることがわかります。

プロダクトバックログリファインメントで事前にプロダクトバックログのタスクをブレイクダウンしておき、その後は次のようにPDCAが続きます。
スプリントプランニングでスプリントバックログを作成することで完了基準をつくり(Plan)、実装し(Do)、デイリースクラムやスプリントレビューで検査し(Check)、レトロスペクティブとKPTによって改善を行います(Action)。

私のチームでは、スクラムサイクルにおけるコミュニケーションコストを最小化するように、下の二つの事項をタスク管理ポリシーに含めています。

上記のタスク管理ポリシーを適用することによって、スクラムチームはプロダクトバックログリファインメントのイベントにおいて、プロダクトオーナーの意図通りにプロダクトバックログタスクを上から順にブレイクダウン・質問・工数見積もりを行うことができます。

また、スプリントプランニングではプロダクトバックログについて上から順にスプリントバックログに移されていくため、本イベントでも優先順位にミスがなく、コミュニケーションコストを必要最小限に抑えることができます。

プロダクトオーナーが、常に適切にプロダクトバックログの順番を並び変えているという条件さえ満たせば、残りの作業はスプリントが進むにつれて習慣化されていき、コミュニケーションコストの発生元は業務要件やタスクのブレイクダウンなどに集約されていきます。

さいごに、上記のタスク管理ポリシーを効果的に適用するためのタスク管理ツールには、下記の二つの機能があることが望ましいと考えています。

アジャイルスクラムは、タスク管理ポリシーの精度によってマネジメントコストやコミュニケーションコストを最小限に抑えることができる奥が深いオペレーションです。
こちらでご紹介した情報を参考に、あなたのチームでもタスク管理ポリシーを工夫してみてはいかがでしょうか。

なお、スクラムとタスク管理ツールの効果的な活用方法については、また別の記事にてご紹介する予定です。

まとめ

本記事では、アジャイルスクラムの失敗パターンとその対策、およびタスク管理ポリシーとタスク管理ツールに必要な機能について、自身の経験を含めご紹介しました。

さいごに、まとめとしてそれぞれのポイントについて振り返りましょう。

アジャイルスクラムにおける失敗パターン4選

1. 直近で着手する予定のプロダクトバックログタスクがブレイクダウンされていないことにより、スプリント中にタスクに関する質問が発生し、デベロッパーの稼働に支障が生じてしまう
2. スプリントプランニングで完了の定義(品質基準)を満たすためのコストが考慮されていないことにより、手戻りコストが増加してしまう
3. スプリントレビューでデモが十分に実施されていないため、プロジェクト終盤で成果物が業務要件を満たさないことが発覚してしまう
4. アジャイルスクラムに適合したタスク管理ポリシーとタスク管理ツールを選定できていないため、不要なコミュニケーションコストが発生してしまう

アジャイルスクラム失敗パターン4選への対策

1. 少なくとも２週間後に着手する予定のプロダクトバックログのタスクブレイクダウンが完了している状態にするように、プロダクトバックログリファインメントを定期イベント化する
2. スプリントプランニングの見積もりでは、スプリント期間中の実装工数だけではなく、完了の定義(品質基準)を満たすためのコストも考慮に入れて見積もる。実装工数と完了の定義を満たすための期間を予め分けておくことも有効
3. スプリントレビューでデモを行いフィードバックを獲得する時間を十分に確保できるように、進捗報告のフォーマットやスプリント毎の生産性基準とタスク完了基準を関係者間ですり合わせておき、進捗報告が簡潔に終わるように工夫する
4. 不要なコミュニケーションコストを省くために、以下の二つのタスク管理ポリシーと二つの機能を持つタスク管理ツールを導入する

2つのタスク管理ポリシー

1. プロダクトオーナーのみがプロダクトバックログのタスクの順番を入れ替えられること
2. スクラムチームはプロダクトバックログタスクを上から順番に質問し、タスクブレイクダウンと工数の見積もりを行い、着手すること

2つのタスク管理ツールに必要な機能

1. ドラッグ&ドロップ機能。プロダクトバックログを上から順番に着手するというタスク管理ポリシーを適用するため
2. 子タスク管理機能。プロダクトバックログを上から順番にタスクブレイクダウン・見積もりするというタスク管理ポリシーを適用するため

本記事でご紹介した情報が、皆さんのスクラムにおける失敗を予防し、成功確度を上げるために少しでも役立てば幸いです。
ご一読いただきありがとうございました。