スクラムにおける現実的最適手段の選択 - INVEST編

スクラムは、理解は容易、習得は困難

スクラムは、理解は容易ですが、習得は困難です。基礎を学び、ルールや推奨方法を理解した後でも、実際のプロダクト開発では理想通りに進まないことが多々あります。しかし、プロジェクトを前に進めることは非常に重要です。スクラムの理想を追求しすぎてプロジェクトが進まなくなると、スクラム自体がアジャイル変革を阻害する要因になる可能性があります。そのため、常に理想を目指しつつも、現実的な最適手段を選択し、その手段が心地よく感じられるようにすることが重要です。今回は、私がさまざまなチームを見てきた中で感じた「現実的最適手段」について考えてみたいと思います。

プロダクトバックログアイテムをINVESTにしたい

INVESTはスクラムのルールからは外れるものの、理想的なプロダクトバックログアイテムの形であることは言うまでもありません。しかし、クロスファンクショナルチームであっても、固定されたスプリント期間内で潜在的にリリース可能なプロダクトインクリメントを生み出すことは困難です。プロダクトバックログアイテムをさらに細分化することが難しくなったり、解決策が見つからなかったりすることもあります。この課題はどの組織でもよく遭遇するものです。

INVESTにならないとどうなるのか？

INVESTを満たさないプロダクトバックログアイテムには以下の問題が生じます。

スプリント期間内に完了しないプロダクトバックログアイテムが常態化する

この状態では、ベロシティの計測が機能せず、経験主義的な見積もりや生産性の可視化が困難になります。スプリントプランニングが困難になり、開発者の作業量が把握できなくなります。極端に忙しくなる場合もあり、スクラムチームとしてのサポートや生産性改善活動、品質の向上などに十分な時間を割けなくなり、レトロスペクティブの機能も低下してしまいます。さらに、アイテムの完了時期が分からないため、プロダクトオーナーは中長期的なプロダクト戦略を立てることも困難になります。

プロダクトバックログアイテムがタスクリストになり、スクラムチーム全員が興味を持てない

これも致命的な問題です。プロダクトバックログアイテムが細かくタスク化されてしまうと、クロスファンクショナルチームがリファインメントに時間を費やすことが無駄に感じられますし、プロダクト戦略の考えが難しくなります。スプリントの成果が分かりづらくなり、スプリントレビューの効果も低下します。

プロダクトバックログアイテムの開発にクリエイティビティを活かせない

開発者にとって、プロダクトバックログアイテムの開発には一定の情報が必要ですが、細かすぎる指示的内容が含まれていると、開発の魅力が減じてしまいます。受け入れ条件やタスクのリストが過剰に詳細化されると、開発者の創造性や自主性が制約されてしまいます。

考えられる原因

スクラムチームの開発者がクロスファンクショナルになりきれていない

バックエンドエンジニア、フロントエンドエンジニア、ハードウェアエンジニア、UXデザイナー、UIデザイナー、QAエンジニア、ディレクター、アナリスト、研究者、カスタマーサポート、セキュリティエンジニアなどの専門家が開発者としてスクラムチームに入ったら、クロスファンクショナルチームになりフロー効率が上がるというのは、この時点では妄想にすぎません。それぞれの専門的タスクには量の違いがあり、常に毎スプリント人的リソースのコントロールも難しいし、それぞれの専門的タスク量のコントロールもできないからです。開発者それぞれが専門性の幅を広げ、ボトルネックになりそうな専門領域のタスクをこなせる人を増やしていくことが重要になります。
QAのタスクはQAエンジニアが、コーディングをするのはソフトウェアエンジニアが、データ分析はアナリストが、などと暗黙的に役割が決まっていて、そこから買われないのであればとフロー効率は改善せず、結果的にベロシティが上がらず、プロダクトバックログアイテムがスプリント期間内に終わらないということにつながります。

プロダクトバックログアイテムの分割アイデアが思い浮かばない

もちろん現実的に分割が非常に難しいパターンもあるはずですが、これ以上分割はできないだろう、という思考停止状態が一番良くない状態です。分割できないから2スプリントにまたがってやろう、ということをゆるしてしまうことで、「今回も分割できないから1スプリントで完了しない前提で計画を建てよう」という思考に引っ張られてしまいます。

待ち時間が発生するタスクが隠れていて、生産性が上がり切っていない

ステークホルダーのレビューや、組織上必要な手続きなど、組織には様々なボトルネックが存在します。徹底排除うするのは難しいにしろ、このタスクの待ち時間を極限まで少なくすることで、開発者は時間を重要な作業に当てることができ、フロー効率も向上します。結果的にベロシティが向上するなども十分にありえます。ベロシティが上がっていけば、プロダクトバックログアイテムは開発者から見て絶対的に小さいと捉える事もできます。

現実的最適手段とは？

上記の問題は一時的には解決が難しいものが多いです。短期的な解決策が見つからない場合には、現実的な最適手段を選択することが重要です。私の経験から、以下の優先順位で目指すのが良いと考えています。

INVESTに優先順位をつける

繰り返しますが、INVESTが良質なプロダクトバックログアイテムを表現するための条件としては理想的なものであるという考えは変わりません。しかしながら、これを意識するあまり、上記のような致命的な問題につながるケースがよくあります。これらをなるべく避けながら、理想状態を目指すためにスクラムを組み続けることも非常に重要です。現実的最適手段を選択することにより、スクラムチームそのものをインクリメンタルに改善していくのが良いと考えます。

個人的な考えとして下記の優先順位で目指し続けるのが良いと考えています。

1. Small
2. Estimable
3. Negotiable
4. Testable
5. Valuable
6. Independent

Small（小さい、最適なサイズ）
小さいとはいえ、小さすぎることも非常に危険です。小さすぎることで、上記のような「プロダクトバックログアイテムがタスクリストになってしまい、スクラムチーム全員がプロダクトバックログアイテムの内容を知らないどころか興味を持てない」という問題が新たに発生します。
では最適なサイズとはどういうことか。下記のプロセスでできたプロダクトバックログアイテムであると考えます。

1. まずはValuable, Independent, Testableを満たした状態のプロダクトバックログアイテムを作る
2. サイズが大きすぎてEstimableではない、Estimableではあるが1スプリントで到底終わらない場合、ValuableとIndependentを妥協し、Estimableで1スプリントで終わらられる程度までアイテムを分割する

こうすることで現実的に分割可能になるはずです。繰り返しますが、あまり分割しすぎると上記のような「プロダクトバックログアイテムがタスクリストになってしまい、スクラムチーム全員がプロダクトバックログアイテムの内容を知らないどころか興味を持てない」という問題が新たに発生しますので、上記プロセスでやることが重要です。
それで、INVEST状態ではないと自覚し、それがどうすれば改善できるかを真剣に考え、レトロスペクティブなどの場で話合いましょう。この漸進的なマインドセットは決して忘れてはいけません。
このINVESTの優先順位における妥協が、現実的最適手段となるパターンをよく見かけます。これを選択することによって、

• 1スプリントで完成させることができます
• これにより、「経験主義的な見積もりと生産性の可視化」が可能になります
• これにより、POが中期的なプロダクト戦略を考えやすくなります。また、スプリントプランニング第一に相当するWhatを決める際に最適な選択をできるようになります。そして、スプリントプランニング第二に相当するHowを決める際に、より具体的に時間軸の概念を含めて考えることができます。