スプリントプランニングをやっていると、たまに誰もポイントを付けられないストーリーが出てきます。見積もりは2から13までバラバラ、誰かが「まあ、場合によりますね」と言い、議論は堂々巡り。GraphQLとREST、どちらにするか？　システムは同時接続1万ユーザーに耐えられるのか？　このサードパーティライブラリは本番で使い物になるのか？　こういう問いは、見積もりでは解決できません。実際に調べるしかない。そのためにあるのがスパイクです。

スパイクの出どころ

#

この言葉はエクストリームプログラミング（XP）から来ていて、元々は「解決策の候補を探るためのごく単純なプログラム」を指していました。問題にスパイク（杭）を打ち込むイメージです。今の形で言えば、タイムボックスを切った短い調査タスクで、成果物は動くソフトウェアではなく「知識」。スパイクはユーザーストーリーではなく、それ自体は顧客価値を生みません。それでいいのです。役割は特定の問いにひとつ答えを出し、本来の作業をまともに見積もって計画できるようにすることです。

実務では2種類に分かれます。テクニカルスパイクは「どう作るか」を探るもの。フレームワークやライブラリの評価、アーキテクチャパターンのプロトタイピング、現実的な条件でのパフォーマンステスト、外部システムとの連携がどれだけ厄介かの調査などです。ファンクショナルスパイクは「何を作るか」を探るもの。曖昧なストーリーの明確化、使い捨てプロトタイプでのUI検証、ドメインの複雑さの解きほぐしなどが該当します。

時間を割く価値がある理由

#

大きな未知数を抱えたまま見積もると、結果は2つに1つです。水増しされた見積もりか、破られる締め切りか。スパイクは「わからない」を実データに変えてくれるので、チームは胸を張ってコミットできます。意見のぶつけ合いも証拠ベースになります。どのデータベースが良いかを議論で決める代わりに、2日かけて測定する。その結果はそのまま意思決定文書に流し込めます。

そして何より、安い保険です。ライブラリの限界を明らかにする2日間のスパイクは、開発が3スプリント進んでから同じ限界に気づくより、はるかに安上がりです。

スパイクを使うべきとき、使うべきでないとき

#

スパイクの出番は、技術的な未知数のせいでチームが自信を持って見積もれないとき、有力な選択肢が複数あって選ぶためのデータが要るとき、新しい技術や連携を検討しているとき、パフォーマンスが不確実かつ重要なとき、そして何度ステークホルダーと話しても要件が曖昧なままのときです。

逆に、チームがすでにやり方を知っている作業や、手元の情報で決められる判断の先延ばしには使わないこと。また、まっとうな要件収集やユーザー受け入れテストの代わりにもなりません。スパイクは問いに答えるものであって、プロダクトを検証するものではないからです。

私の進め方

#

まず問いを書き出します。「キャッシングを調査する」ではなく「Redisクラスターは50msのレイテンシ要件を満たせるか？」。対象と対象外をはっきりさせ、タイムボックスは1〜3日（それ以上必要なら問いが広すぎます）、達成をどう判定するかの成功基準も決めておきます。

あとは調べるだけです。ドキュメントや事例を読み、最小限の概念実証を作り、経験者に話を聞き、実際のコードで測る。スパイクのコードは最初から捨てる前提です。

タイムボックスが終わったら、調査結果、理由付きの推奨、見つかったリスクを書き上げ、プロトタイプには「スパイクの成果物であって本番コードではない」と明記してリンクします。チームに共有して質問を受け、学んだことに基づいてバックログを調整する。ストーリーを作る、磨く、消す、どれもありです。スパイクの進め方そのものを次のレトロスペクティブで振り返るのもおすすめです。スパイクは回数を重ねると目に見えて上手くなります。

使っているテンプレート

#

## スパイク：[タイトル]

**タイムボックス**：[X日]
**オーナー**：[名前]
**スプリント**：[スプリント番号/名前]

### 答えるべき質問
[このスパイクが答える単一の焦点を当てた質問]

### 背景
[このスパイクが必要な理由；不確実性のきっかけ]

### 仮定
- [仮定1]
- [仮定2]

### 範囲
**対象範囲**：
- [項目1]
- [項目2]

**対象外**：
- [項目1]

### 成功基準
- [ ] [基準1]
- [ ] [基準2]

### 調査結果
[スパイク中に完了予定]

### 推奨事項
[スパイク後に完了予定]

### フォローアップストーリー
- [ ] [ストーリー1]
- [ ] [ストーリー2]

「仮定」の欄はちゃんと役に立ちます。「データモデルは基本的にリレーショナル」「読み取りは書き込みの10倍」と着手前に書いておくと、タイムボックスを使い切る前に前提そのものへ突っ込んでもらえますし、調査の途中で仮定が崩れたら、それは2日の無駄ではなく立派な発見になります。

スパイクがこじれるパターン

#

定番の失敗はスコープクリープです。気づけばスパイクが終わりのない研究プロジェクトになっている。新しい疑問が出てきたら（必ず出てきます）、今のスパイクを広げるのではなく、次のスパイク候補としてメモしておきます。2つ目の失敗は作り込みすぎ。スパイクのコードにエラーハンドリングやテストを足し始めた瞬間、探索から実装に足を踏み入れています。3つ目は記録を残さないこと。半年後に誰かが同じ問いにぶつかったとき、せっかくの2日分の学びが消えてしまいます。最後は、スパイクを既定の答えの追認として扱うこと。「このアプローチは無理」と判明したスパイクは、完璧に仕事をしています。

スプリント計画への組み込み方

#

スプリントを計画するときに効いた習慣をいくつか。本当に未知数のあるストーリーは、今のスプリントでスパイクを回し、実作業は後のスプリントに置く。スパイクはスプリントあたり1〜2本まで。それ以上は集中力が霧散します。スパイクにストーリーポイントは付けません。生み出すのは知識であってソフトウェアではないので、タイムボックスで管理します。そしてスパイクの結果は、関連ストーリーの見積もりの後ではなく前、つまりリファインメントの場で共有します。

次に「答えより疑問のほうが多いストーリー」に出くわしたら、そのスプリントで一番価値ある作業はスパイクかもしれない、と考えてみてください。立ち止まって学ぶのが、結局いちばん速いこともあります。

ざっくり言うと

#

スパイクは、見積もりだけでは答えの出ない問いひとつに絞って、1〜3日のタイムボックスで調べる作業です。使いどころは、未知数が見積もりを阻んでいるとき。有力な選択肢が複数あるのに選ぶためのデータがない、新しい技術や連携を検討している、パフォーマンスが不確実なうえに重要、何度話しても要件が曖昧なまま、といった場面です。逆に、チームがすでにやり方を知っている作業や、手元の情報で決められる判断の先延ばしには使いません。

成果物は動くソフトウェアではなく知識です。調査結果、理由付きの推奨、見つかったリスク、使い捨てのプロトタイプが残り、それをもとにバックログを調整します。スパイクにはストーリーポイントを付けずにタイムボックスで管理し、結果は関連ストーリーを見積もる前のリファインメントで共有します。

さらに読む

#

このサイトの関連記事：

• レトロスペクティブ：スパイクの成果を振り返る - スパイクの学びを継続的改善につなげる
• ユーザー受け入れテスト - スパイクに基づく決定がユーザーニーズを満たすか検証する
• 意思決定文書 - スパイクの結果から生まれる決定を構造化する
• API計画 - スパイクがAPI設計の判断にどう効くか

外部リソース：

• スパイク - Scaled Agile Framework (SAFe) - 大規模開発でのスパイク運用ガイド
• スパイクソリューション - エクストリームプログラミング - スパイクの発祥であるXPの原典
• スクラムガイド - スプリント計画におけるスパイクの位置づけ
• Martin Fowlerの技術的負債について - スパイクが技術的負債の予防にどう役立つか