英語でスパイクチケットを書くよう求められたとき、調査の目的・スコープ・成果物をどの形式で記述すればいいか迷った経験はないだろうか。
テクニカルスパイク（Technical Spike）は不確実性を調査・検証することで見積もりや設計の精度を上げるための時間制限付き作業だ。調査目的・スコープと制約・成果物・結果報告の4つの構成要素を押さえれば、英語でも問題なく書ける。
この記事では、英語テクニカルスパイクに必要な4つの構成要素と、そのまま使える日英テンプレートを紹介する。コピペして使えばすぐに次のバックログリファインメントで活用できる。
テクニカルスパイクに必要な4つの構成要素
テクニカルスパイク（Technical Spike）はXP（エクストリームプログラミング）が起源で、スクラムのスプリントバックログに組み込まれることが多い。「やってみないとわからない」状態を解消するための調査タイムボックスだ。以下の4つが実務で使いやすい構成要素になる。
- 調査目的（Spike Purpose）
- スコープと制約（Scope & Constraints）
- 成果物（Deliverables）
- 結果報告（Findings & Recommendations）
スパイクとユーザーストーリーの違い
ユーザーストーリーはユーザーへの価値を届けることを目的とする。スパイクは不確実性を除去して次のユーザーストーリーの精度を上げることを目的とする。スパイク自体はユーザーへの価値を直接届けないため、DoDの適用外とすることが多い。
なぜ英語で書くのか
グローバルチームでは、スパイクの調査結果をもとに設計判断や見積もりが行われる。英語で書いた調査結果報告書は、異なるタイムゾーンのエンジニアやPOが非同期で意思決定できる状態を作る。
バックログリファインメントとの連携は英語バックログリファインメントの書き方でも確認してほしい。
テンプレートをダウンロード（Word）
以下のWordファイルをダウンロードして、プロジェクトに合わせてカスタマイズして使ってほしい。表の列・行はそのまま追加・削除できる。
📥 日本語テンプレートをダウンロード（Word）
📥 Download English Template (Word)
日本語版テンプレート（コピペOK）
調査目的
| 項目 | 内容 |
|---|---|
| チケットID | （例：PAY-SPK-01） |
| スパイクタイトル | （例：Apple Pay JS SDK v4の認証フローを調査する） |
| 調査の背景 | （例：PAY-110（Apple Pay統合）の見積もりを行うにあたり、Apple Pay JS SDK v4の認証フローと既存の決済SDKとの互換性が不明なため） |
| 解決したい疑問 | （例：1. SDK v4の認証フローは既存の決済SDK v2.3と互換性があるか？ 2. ステージング環境での認証テストに必要な手順は何か？ 3. 想定されるリスクと回避策は何か？） |
| タイムボックス | （例：2日間（16時間）） |
| 担当者 | （例：田中） |
| スパイクの種別 | （例：技術調査 / PoC（概念実証） / パフォーマンス検証） |
スコープと制約
| 項目 | 内容 |
|---|---|
| スコープ内 | （例：Apple Pay JS SDK v4のドキュメント調査 / ステージング環境での認証フロー動作確認 / 既存決済SDKとの互換性確認） |
| スコープ外 | （例：本番環境への実装 / Google Pay対応の調査 / UIの実装） |
| 利用リソース | （例：Apple Developer ドキュメント / 社内ステージング環境 / テスト用Apple Payサンドボックスアカウント） |
| 前提条件 | （例：Apple Pay APIキーの取得が完了している（PAY-108が完了済み）） |
成果物
| No. | 成果物 | 形式 | 期限 |
|---|---|---|---|
| 1 | （例：調査レポート：SDK v4の認証フロー概要と互換性評価） | （例：Confluenceページ） | （例：スパイク終了日） |
| 2 | （例：PoC実装コード：ステージング環境での動作確認スクリプト） | （例：GitHubブランチ（spike/pay-spk-01）） | （例：スパイク終了日） |
| 3 | （例：PAY-110の見積もり更新（調査結果に基づき修正）） | （例：Jiraチケット更新） | （例：スパイク終了後1営業日以内） |
| 4 | （例：リスクと推奨アーキテクチャをまとめた意思決定メモ） | （例：Slack #dev-paymentチャンネルへの投稿） | （例：スパイク終了日） |
結果報告（スパイク終了後に記入）
| 項目 | 内容 |
|---|---|
| 調査実施日 | （例：2026年9月1日〜9月2日） |
| 担当者 | （例：田中） |
疑問への回答：
| 疑問 | 回答 | 詳細 |
|---|---|---|
| （例：SDK v4と既存SDK v2.3の互換性） | （例：互換性あり。ただし認証コールバックのインターフェースが変更されており、アダプターが必要） | （例：SDK v4ではonPaymentAuthorizedイベントが非同期になり、既存のコールバック処理を修正する必要がある） |
| （例：ステージング環境での認証テスト手順） | （例：確認済み。Apple PayサンドボックスアカウントとMerchant ID登録が必要） | （例：手順書をConfluenceに作成済み） |
| （例：主なリスクと回避策） | （例：認証コールバックの非同期対応が最大のリスク。アダプターパターンで対応可能） | （例：工数2〜3日の追加見積もりが必要） |
推奨事項：
（例：SDK v4の採用を推奨する。互換性の問題はアダプターで解決可能で、追加工数は2〜3日。PAY-110の見積もりを5ptから8ptに更新する。詳細設計はADRに記録する。）
次のアクション：
| アクション | 担当者 | 期限 |
|---|---|---|
| （例：PAY-110の見積もりを8ptに更新する） | （例：田中） | （例：9/3） |
| （例：ADRにアーキテクチャ決定を記録する） | （例：田中） | （例：9/3） |
| （例：次スプリントのバックログリファインメントでPAY-110の詳細を共有する） | （例：田中＋チーム全員） | （例：Sprint 45計画会議） |
英語版テンプレート（コピペOK）
Spike Purpose
| Item | Details |
|---|---|
| Ticket ID | (e.g., PAY-SPK-01) |
| Spike Title | (e.g., Investigate Apple Pay JS SDK v4 Authentication Flow) |
| Background | (e.g., Before estimating PAY-110 (Apple Pay integration), we need to understand whether Apple Pay JS SDK v4’s authentication flow is compatible with our existing payment SDK v2.3.) |
| Questions to Answer | (e.g., 1. Is SDK v4 compatible with our existing payment SDK v2.3? 2. What steps are needed to test authentication in our staging environment? 3. What are the key risks and mitigations?) |
| Timebox | (e.g., 2 days (16 hours)) |
| Owner | (e.g., Tanaka) |
| Spike Type | (e.g., Technical Research / Proof of Concept / Performance Validation) |
Scope & Constraints
| Item | Details |
|---|---|
| In Scope | (e.g., Apple Pay JS SDK v4 documentation review / Authentication flow verification in staging / Compatibility check with existing payment SDK.) |
| Out of Scope | (e.g., Production implementation / Google Pay investigation / UI implementation.) |
| Resources | (e.g., Apple Developer documentation / Internal staging environment / Apple Pay sandbox test account.) |
| Preconditions | (e.g., Apple Pay API key provisioning must be complete (PAY-108 done).) |
Deliverables
| No. | Deliverable | Format | Due |
|---|---|---|---|
| 1 | (e.g., Investigation report: SDK v4 auth flow overview and compatibility assessment.) | (e.g., Confluence page) | (e.g., End of spike) |
| 2 | (e.g., PoC implementation: staging verification script.) | (e.g., GitHub branch (spike/pay-spk-01)) | (e.g., End of spike) |
| 3 | (e.g., Updated estimate for PAY-110 based on findings.) | (e.g., Jira ticket update) | (e.g., 1 business day after spike) |
| 4 | (e.g., Decision memo with risks and recommended architecture.) | (e.g., Slack post to #dev-payment) | (e.g., End of spike) |
Findings & Recommendations (fill in after spike)
| Item | Details |
|---|---|
| Investigation Period | (e.g., September 1–2, 2026) |
| Owner | (e.g., Tanaka) |
Answers to Questions:
| Question | Answer | Details |
|---|---|---|
| (e.g., SDK v4 compatibility with existing SDK v2.3) | (e.g., Compatible. However, the authentication callback interface has changed and requires an adapter.) | (e.g., SDK v4 makes onPaymentAuthorized async; existing callback handling needs to be updated.) |
| (e.g., Staging environment auth test steps) | (e.g., Confirmed. Requires Apple Pay sandbox account and Merchant ID registration.) | (e.g., Step-by-step guide created in Confluence.) |
| (e.g., Key risks and mitigations) | (e.g., Async callback handling is the main risk. Addressable with the adapter pattern.) | (e.g., Requires 2–3 additional days of work.) |
Recommendation:
(e.g., Recommend adopting SDK v4. Compatibility issue is solvable via adapter pattern with 2–3 days of additional work. Update PAY-110 estimate from 5 pts to 8 pts. Record architecture decision in an ADR.)
Next Actions:
| Action | Owner | Due |
|---|---|---|
| (e.g., Update PAY-110 estimate to 8 pts.) | (e.g., Tanaka) | (e.g., Sep 3) |
| (e.g., Record architecture decision in an ADR.) | (e.g., Tanaka) | (e.g., Sep 3) |
| (e.g., Share PAY-110 details at next sprint’s backlog refinement.) | (e.g., Tanaka + team) | (e.g., Sprint 45 planning) |
各セクションの書き方と例文
テンプレートを埋めるときに悩みやすいポイントを解説する。
タイムボックスの設定
スパイクは必ずタイムボックス（時間制限）を設ける。「わかるまで調査する」では終わりが見えない。「2日間で調査できた範囲の結論を出す」と決めることで、不完全でも次の判断に進める。
| 日本語 | 英語 |
|---|---|
| 2日間（16時間）のタイムボックスを設ける | Set a timebox of 2 days (16 hours). |
| タイムボックス内で結論を出す | Deliver conclusions within the timebox. |
| タイムボックスが終わったら結果を共有する | Share findings when the timebox ends. |
| 未解決の場合は次のスパイクを計画する | If unresolved, plan a follow-up spike. |
「解決したい疑問」の書き方
スパイクの目的は「調査すること」ではなく「特定の疑問に答えること」だ。「〇〇を調査する」という動詞ではなく、「〇〇は△△と互換性があるか？」という疑問文で書くことで、タイムボックス終了時に「答えが出たか」を判断できる。
| 日本語 | 英語 |
|---|---|
| 〇〇は〇〇と互換性があるか？ | Is [X] compatible with [Y]? |
| 〇〇のパフォーマンスは要件を満たすか？ | Does [X] meet the performance requirements? |
| 〇〇を使って〇〇を実現できるか？ | Can [X] be used to achieve [Y]? |
| 〇〇の主なリスクと回避策は何か？ | What are the key risks of [X] and how can they be mitigated? |
ユーザーストーリーとの連携は英語ユーザーストーリーの書き方でも確認してほしい。
テクニカルスパイクでよく使う英語表現
実務でよく使う英語表現を場面別にまとめた。
スパイクの基本用語
| 日本語 | 英語 |
|---|---|
| テクニカルスパイク | Technical Spike / Spike |
| タイムボックス | Timebox |
| 不確実性 | Uncertainty |
| 概念実証 | Proof of Concept (PoC) |
| 調査結果 | Findings |
| 推奨事項 | Recommendation |
| 成果物 | Deliverable |
| スコープ外 | Out of Scope |
| 後続チケット | Follow-up Ticket |
| 見積もり更新 | Estimate Update |
スパイクの開始・終了時のフレーズ
| 日本語 | 英語 |
|---|---|
| このチケットは見積もり前にスパイクが必要です | This ticket requires a spike before we can estimate it. |
| 2日間のタイムボックスでお願いします | Please timebox this to 2 days. |
| スパイクの結果を共有してください | Please share the spike findings with the team. |
| 見積もりを更新しました | I’ve updated the estimate based on the spike findings. |
| 次スプリントで後続タスクを計画します | We’ll plan the follow-up ticket for the next sprint. |
スプリントゴールとの連携は英語スプリントゴールの書き方でも確認してほしい。
まとめ：英語テクニカルスパイクは4つのセクションで完成する
英語テクニカルスパイクに必要な構成要素を整理した。
- 調査目的は「解決したい疑問」を疑問文で書き、タイムボックスと担当者をセットで設定する
- スコープと制約はスコープ内・スコープ外・前提条件を明記し、調査が際限なく広がることを防ぐ
- 成果物は「何を・どの形式で・いつまでに」を明記し、スパイク終了時に成果が確認できる状態にする
- 結果報告は疑問への回答・推奨事項・次のアクションをセットで記録し、スパイクの学びを次の作業に確実につなげる
テンプレートをコピーして、まず「解決したい疑問」を疑問文で3つ書き始めてほしい。この3つが明確になれば、スコープと成果物の定義が自然と収束する。
コメント