スパイク

スパイクとは

スパイク (Spike) は、技術的な不確実性を解消するために、あらかじめ決めた時間だけを調査・検証に充てるタイムボックス付きのタスクである。エクストリームプログラミング (XP) のルール集では「スパイクソリューション」として、検証したい問題だけを扱う可能な限り単純なプログラムを書き、それ以外の関心事は無視すると整理されている (1999 年公開の XP ルール集)。目的は技術的リスクを下げることと、ストーリーの見積もりの確かさを上げることの 2 点で、「この技術は使えるか？」「この設計で性能は出るか？」を実装前に確かめる。

期間の相場は一つに決まらない。XP のルール集では、技術的な難所が開発を止めそうなときに開発者 2 人を 1〜2 週間充てる例が挙げられている。スプリントの中に収める運用では 1〜2 日で切ることも多い。長さの相場より、着手前に長さを決めて延長しないことが本質である。

スパイクが必要なケース

スパイクを立てるかどうかの判断基準は「見積もれない理由が知識の欠落にあるか」である。設計の好みが分かれているだけなら、調査ではなく議論と決定で片付く。知らないから見積もれないときだけスパイクにする。

ケース	例
未知の技術	「Bedrock の応答速度は要件を満たすか？」
設計の検証	「DynamoDB のシングルテーブル設計でこのクエリは可能か？」
見積もりの不確実性	「この機能は 1 週間で実装できるか？」
サードパーティ連携	「この API のレート制限は問題にならないか？」

スパイクの進め方

手順の要は 1 番目にある。答えるべき質問を一文で書けないスパイクは、期限が来ても終わらない。

1. 質問を明確にする
   「DynamoDB で全文検索は実現可能か？」

2. タイムボックスを設定
   「2 日間で調査する」

3. 最小限のプロトタイプを作成
   → DynamoDB + OpenSearch の連携を検証

4. 結果を報告
   「DynamoDB 単体では不可。OpenSearch との連携が必要。
    実装に追加で 3 日かかる見込み」

5. 本実装の見積もりを更新

スパイクの成果物

成果物は「動くコード」ではなく「判断できる情報」である。

成果物	内容
調査結果	技術的な可否、制約、パフォーマンス
プロトタイプ	検証対象だけを扱う最小限のコード。XP のルール集も「大半のスパイクは残す価値がないので捨てるつもりで作る」としている
見積もりの更新	不確実性が解消された見積もり
代替案	不可の場合の代替アプローチ

捨てる前提を崩すと、エラー処理も設定の外部化も省いた検証用コードがそのまま本番へ流れ込む。スパイクで手に入れるのは知識であり、コードはその手段にすぎない。本実装では、判明した制約を踏まえて改めて設計から書き直す。

スパイク vs ストーリー

スパイクはストーリーの代わりではない。ストーリーを見積もれる状態にするための前工程であり、スパイク自体はユーザーに価値を届けない。したがってスパイクの完了をもって進捗とは呼べない。

観点	スパイク	ストーリー
目的	不確実性の解消	機能の実装
成果物	知識、プロトタイプ	動作するソフトウェア
見積もり	タイムボックス (固定時間)	ストーリーポイント
完了条件	質問に回答できた	Acceptance Criteria を満たした

タイムボックスの重要性

スパイクにはタイムボックスを必ず設定する。期限がないと調査が際限なく続く。

❌ 「DynamoDB の設計を調査する」(期限なし)
✅ 「2 日間で DynamoDB のシングルテーブル設計を検証し、
    アクセスパターン 5 つが実現可能か報告する」

スパイクの結果が「不可」の場合

不可という結果も価値がある。間違った技術選択を本実装前に防げる。代替案を提示し、チームで方針を決定する。

よくある失敗は 2 つある。1 つは結論を書き残さないことである。口頭共有だけで終えると、数週間後に別の担当が同じ調査をやり直す。もう 1 つはスパイクを積み続けることである。着手前の不安を全部スパイクで潰そうとすると実装が始まらない。不確実性が見積もりを揺らすほど大きい項目に絞り、残りは実装しながら判断する。