スパイク

スパイクとは

スパイク (Spike) は、技術的な不確実性を解消するために、短期間 (通常 1〜2 日) で調査・検証を行うタイムボックス付きのタスクである。エクストリームプログラミング (XP) で定義された概念で、「この技術は使えるか？」「この設計で性能は出るか？」を実装前に検証する。

スパイクが必要なケース

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

スパイクの進め方

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

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

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

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

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

スパイクの成果物

成果物	内容
調査結果	技術的な可否、制約、パフォーマンス
プロトタイプ	動作する最小限のコード (本番品質は不要)
見積もりの更新	不確実性が解消された見積もり
代替案	不可の場合の代替アプローチ

スパイク vs ストーリー

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

タイムボックスの重要性

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

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

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

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

より深く学ぶには関連書籍が役立つ。