スクラムにおける技術的スパイクの進め方

みなさんこんにちは。@ryuzeeです。

スクラムでは、スプリントに投入するプロダクトバックログアイテムはReady（準備ができている）である必要があります（Readyとはどんな状態なのかについては以前に詳しく説明したので、そちらを参照してください）。 Readyにしておくことによって、成果の量が安定しプロダクトオーナーやステークホルダーにとっては予測精度が向上していきます。

Readyにする活動は単に受け入れ基準を用意したり、プロダクトバックログの内容を精緻化したり、並べ替えたりするだけではありません。スプリント内でプロダクトバックログアイテムが完成する可能性を上げるために必要な活動すべてが含まれます。そしてその中の1つが技術的な調査です。スプリントでプロダクトバックログアイテムに着手してから実現方法を調べたり、技術的な制約によって大幅な方針転換したりするのでは遅い上に予測性が低いので、先に技術調査をするわけです。このことをスパイクと呼びます。

今回はスプリントを実際に開始したあとで、スプリントを回しながらどのようにスパイクをしていけばよいか見ていきましょう（スプリント0の立ち上げ期間中に��スパイクを実施しますが、今回はスプリントでの活動にフォーカスします）。

1. スパイクの定義

まずは、AgileDictionaryというアジャイル用語解説サイトの定義でスパイクの定義を確認しましょう。そこでは以下のようになっています（拙訳。一部改変）。

スパイク

リリース可能なプロダクトを作るのではなく、質問に答えたり情報を収集したりすることを目的とした作業。開発チームが技術的な質問や設計上の問題を解決するための実際の作業を行うまで、見積りができないようなプロダクトバックログアイテムが出てくることがあります。解決策は、「スパイク」を行うことです。目的は、質問に対する回答やソリューションを見つけることです。

語源

スパイクという用語は、エクストリームプログラミング（XP）に由来します。そこでは、「スパイクとは、非常に簡素なプログラムのことで、ソリューション候補を探求するのに使われる」とされています。ウォード・カニンガムは、c2.comというwikiでこの用語がどのようにできたかを述べています。「ベック、自分たちが正しい方向に進んでいると確信できる、もっとも簡単なことは何だろう？」手に余りそうなものを小さくして進めることで、単純で説得力のある解決策につながりました。ケント・ベックはこれをスパイクと名づけました。私は大きなフレームワークの保守をしているときでも、このプラクティスが特に役立つことを発見しました。

2. スパイクの目的

つまり、スパイクの目的は以下のように整理できます。

質問や疑問に答えるた��の情報を集める
より良い実現方法を探索する
見積り精度を上げる
リスクを明らかにする

3. スパイクの進め方

スクラムではスプリントごとに「リリース判断可能なインクリメント」を作ると決められています。それぞれのスプリントで、スプリントゴールを満たすように進めていかないといけません。したがって、スプリントの時間をスパイクで埋め尽くしてはいけません。以下の手順で進めていくとよいでしょう。

基本の流れ

まずはプロダクトバックログリファインメントなどを活用して、直近数スプリント内に着手する可能性のあるプロダクトバックログアイテムをウォークスルーして、技術的な課題がないかどうかを確認する
例えば技術的な観点で以下のように分類してみます
環境や前提条件などを決めて測定してみないと分からないもの
誰もやったことがなく、ノウハウや情報の入手も難しいもの
誰もやったことはないが、ネット上などにさまざまな情報がありそうなもの
開発チーム内のごく少数だけは経験があるもの
開発チーム内の多くの人が分かるもの
分類した上で、特に上記の1点目〜3点目に該当するような技術的な課題があった場合は、それらがどの程度大きな問題になりそうなのかを開発チームで判断する
開発チームとして大きな問題にならないと自信をもてる場合は特にアクションは必要ない
そうでない場合は、開発チームとして、それらの課題がどのような状態になったら解決となるかを合意する
複数のスパイク項目がある場合は、通常のプロダクトバックログと同じように並べ替える
その上で、スパイクに使う時間の上限を設定する（終わるまでやろうとすると時間が延びるので、タイムボックスを定める）
状況に応じて、プロダクトバックログアイテム化するか、開発チームのバッファの中で行うか判断する
スパイクを実施する。必要なことが判明したり、タイムボックスの上限に達したりしたら、スパイクの結果を共有する
その上でさらに追加でスパイクが必要かどうかの判断をする

4. スパイクを進める上での注意点

スパイクを進める上ではいくつか注意点があります。例を挙げておきましょう。

目的や課題の認識抜きでやらない
スプリント1を開始する前の初期フェーズで、全てを検証しようとしない
直近数スプリント程度を対象とし、重要な箇所にフォーカスする
プロダクトバックログアイテムの着手の仕方と同じように、なるべく開発チーム内で1つづつ終わらせる。すなわちスパイクの担当者を固定しすぎない
やりすぎない。目的はプロダクトバックログアイテムの精度をあげることなので、それができる最低限で構わない。全てを網羅しようとしない
スパイクはあくまでスパイクなので、スパイクの成果のコードをいきなりプロダクトコードに統合しない
タイムボックスを設定し、その枠で収まらない場合は状況を確認した上で再計画する。時には諦める判断をすることもある
タイムボックスをどの程度にするかの決まりはないが、スプリントの長さの20%程度までの時間が現実的。もちろん開発チームの能力に強く依存する
スパイクの結果はプロダクトバックログアイテムの中身（見積りや受け入れ条件など）に反映する

5. スパイクをプロダクトバックログに入れるか、それともバッファのなかで行うか

スパイクをプロダクトバックログに入れるか、スプリントのバッファで行うかは悩ましいポイントです。考え方としては、以下のようにしておくと良いと思います。

バッファで対応する

スパイクの所要時間の見込みが短い場合
万一ほかのプロダクトバックログアイテムの実装に時間がかかってバッファが減り十分なスパイクができなくても、即時大きな問題にはならない場合

プロダクトバックログアイテムに入れる

次以降のスプリントで進捗を阻害する重大な問題になると考えられる場合
スパイクが必要なプロダクトバックログアイテムが、他のプロダクトバックログアイテムと依存関係を形成している場合
検証に時間がかかる場合（開発チームのバッファを超える時間が必要な場合）

なお、プロダクトバックログの並び順の最終決定権限はプロダクトオーナーにあります。したがって、スパイクのプロダクトバックログアイテムの重要性を開発チームとしてプロダクトオーナーに伝えて、スプリントへの投入を決定してもらう必要があります。

6. まとめ

繰り返しになりますが、準備のできていない（Readyでない）プロダクトバックログアイテム、完成できる自信のないプロダクトバックログアイテムをスプリントに投入するのは避けるようにするべきです。そして、プロダクトバックログアイテムは着手前に、要求の観点だけでなく技術の観点なども含めて完成できそうかを確認しておく必要があります。そして、技術の観点ではスパイクは有効な手立てになります。どの程度のスパイクが必要なのかは、開発チームの扱っている技術や経験に大きく左右されますが、重要な問題にフォーカスしタイムボックスを設定して取り組むと良いでしょう。

それでは。