q
スパイクって何？アジャイル開発で使われる言葉っぽいけど。
a
アジャイル開発で言う スパイク（Spike） は、ざっくり言うと 「不確実なところを短時間で調べて、見積りや設計の判断材料を作るための調査タスク」 です。実装そのものを完了させるというより、学び（検証結果）を得るのが目的です。
何のためにやる？
- 技術的にできるか不明（例：新しいライブラリ、API連携、性能要件）
- 仕様が曖昧で見積りができない（例：要件の選択肢が多い）
- リスクが高い箇所を先に潰したい
→ スパイクで 「できる/できない」「だいたいどれくらい工数か」「どの案が良さそうか」 を早めに確かめます。
典型例
- 「この外部API、認証方式は何で、制限はどれくらい？簡単な疎通までやってみる」
- 「候補A/Bの実装方法で、性能比較の小さなプロトタイプを作って計測する」
- 「未知のバグの原因を切り分けるために最小再現コードを作る」
重要な特徴（アジャイルっぽい運用）
- タイムボックス（時間上限） を決める（例：2時間〜1日、長くても数日）
- 成果物は「動くコード」より 結論・メモ・推奨案・見積り更新 などでもOK
- 終わったら、結果を元に ユーザーストーリーを分割/見積り/方針決定 する
種類（よく言われる分類）
- 技術スパイク：技術検証（性能、互換性、構成、PoC）
- 調査スパイク：要件・仕様・業務理解、選択肢整理
必要なら、あなたの状況（何が不確実か、期限、技術スタック）を教えてください。スパイクの粒度（何を調べて何を成果にするか、時間上限）を一緒に切れます。
q
スパイクって原義は何？アジャイルではどんなニュアンスなの？
a
原義（一般の意味）
英語の spike は元々 「トゲ／釘／杭のような尖ったもの」、そこから転じて
- 急な突き上げ（例：price spike＝価格の急騰、traffic spike＝アクセス急増）
- スパイク（陸上のスパイク靴）のような「尖ったもの」
- （動詞で）突き刺す／急増させる
- 口語では （飲み物などに）混ぜ物をする（例：spike the punch）
みたいに「尖り」「急に立つ」「一気に増える」ニュアンスを持つ単語です。
アジャイルでのニュアンス（なぜ “Spike” と呼ぶのか）
アジャイル／XP文脈の Spike は、上の「尖り」の比喩で、
- Backlog上で そこだけ“尖って”深掘りする
- 大きく作り込むのではなく、狭く・短く・一点突破で調べる
- 目的は成果物（機能）より 不確実性を減らすこと（学びを得ること）
という意味合いで使われます。
イメージとしては「広く平らに進めたい開発の流れの中で、未知がある部分だけが“突起”になっているので、そこを短時間で刺して（掘って）確かめる」感じです。
もう少し実務っぽい言い方にすると
スパイク＝「この先の見積りや設計判断を可能にするための、タイムボックス付きの一点調査」。
その結果として「選ぶべき案」「やめるべき案」「だいたいの工数感」「リスク」「次に切るストーリー」などが手に入る、という位置づけです。
必要なら、あなたのチームで言っているスパイクが「技術検証寄り」か「要件調査寄り」かを聞いて、言葉の使い分け（PoC、プロトタイプ、調査タスクとの違い）も整理します。
q
スパイクにネガティブなニュアンスはあります？
たとえば「今回のスプリントはひたすらスパイクします」はアリ？
スパイク（Spike）自体に 強いネガティブな含みは基本的にありません。ただし、言い方や使い方によっては「計画できてない」「実装が進まない言い訳」に聞こえることがあり、そこがネガティブに受け取られるポイントです。
ネガティブに聞こえやすいケース（あるある）
- スパイクが長い／タイムボックスがない
調査がだらだら続くと「いつ終わるの？」になりがち。
- 成果（学び・判断材料）が明文化されない
結果が共有されず、バックログの意思決定に繋がらないと「やった感」だけ残る。
- スパイクの比率が高すぎる／毎スプリント続く
「見積り不能な状態が常態化している」「発見が遅い」印象になる。
- スパイクの目的が“実装の代替”になっている
本当は作るべきところを、ずっと検証で先送りしているように見える。
（※ちなみに “spike” は口語で「飲み物に混ぜ物をする」みたいな意味もありますが、アジャイル文脈でそれが連想されて悪い意味になることはほぼないです。）
「今回のスプリントはひたすらスパイクします」はアリ？
状況次第で アリ ですが、表現としては 注意が必要 です。
アリになりやすい状況
- 新規領域・未知が大きく、まず 技術/要件の不確実性を落とさないと前に進めない
- 近い将来の複数ストーリーの見積りや設計判断のために、先行してリスクを潰す必要がある
- チーム合意で「今スプリントは discovery（探索）比重」と割り切っている
そのままだと危険な理由
「ひたすら」が付くと、聞き手に “アウトカム不明の調査を延々やる” 印象を与えやすいからです。
こう言い換えると健全に伝わる
- 「今スプリントは 不確実性を潰すスパイクを3本やります（各1日でタイムボックス）。成果は 推奨案・リスク・概算見積り まで出します」
- 「次スプリント以降に実装を確実に進めるため、今スプリントは 調査スプリント（spike中心） にします。終了条件は 意思決定とバックログ分割 です」
“良いスパイク”の最低条件（これがあるとネガティブ化しにくい）
- 時間上限（タイムボックス）
- 問いが明確（何を確かめるのか）
- 終了条件（得たい判断材料）
- 成果の共有（メモでOK）＋ 次アクションに繋げる（ストーリー分割・見積り更新・方針決定）
もし「ひたすらスパイク」になりそうな背景が、技術不確実性なのか要件不確実性なのか、あるいは依存関係（外部チーム待ち等）なのかを教えてくれれば、スプリントの組み立て方（何本のスパイクに切るか、各スパイクの出口をどう置くか）まで一緒に整えられます。
q
製品開発よりも研究や実験の側面が大きいプロジェクトをスクラムで回してるんだけど、スパイクの要素が多いと感じている。スプリントの中で実装が一度も進まなかったことも多いし、その実装を丸々捨てたりもする。次何が起きるかはわからない（何が得られるかわからない）ので、スプリントごとに次何するかを決めている感じ。
こういうスタイルを spike driven development と呼びたくて、spike のニュアンスを調べていたんです。
a
その状況だと、「スパイクが多い」のは自然です。Scrumを“製品の増分を毎スプリント出す”前提で運用しようとすると違和感が出ますが、研究・実験（R&D）中心の探索フェーズは、そもそもアウトカムが不確実で、捨てる実装や行き止まりが織り込み済みだからです。
以下、あなたが言いたい spike driven development のニュアンス整理と、呼び方としての注意点／代替案です。
1) あなたのやっていることは「スパイク」っぽいのか？
かなりスパイク的です。特に
- 不確実性を減らすことが価値（学び・意思決定材料が成果）
- 捨てる前提のコード（プロトタイプ、検証コード）
- 次の一手が事前に確定しない（探索→結果で次を決める）
は、XP/アジャイルでいう spike の中心的な使い方と一致します。
一方で、一般に「スパイク」は “本実装に入る前の短い一点調査” というニュアンスが強いので、プロジェクト全体が常に探索で回っている状態を spike だけで表すと、聞き手によっては「ずっと前準備してるの？」と誤解される可能性があります。
2) “spike driven development” という言い方はアリ？
言葉としては通じなくはないですが、一般に定着した用語ではないので、初見の人には補足が必要になります。さらに “driven development” という型（TDD/BDDなど）に寄せた言い方なので、強いメッセージ性が出ます。
- ポジティブに伝わる可能性：
「探索（spike）を一次成果として回している」「学びで方向を駆動している」
- ネガティブに誤読される可能性：
「ずっとスパイク＝見積もれない／作れない状態を正当化してない？」
「スパイクの定義（短時間・一点突破）から外れてない？」
なので、使うなら 定義をセットで提示すると強いです。例：
- “We run Scrum in an R&D mode: each sprint is time-boxed experiments (spikes) to reduce uncertainty and decide next steps.”
3) そのスタイルを指す、より“通じやすい”言い回し候補
既存の語彙だと、次の方が誤解が少ないです（併記も可）。
- Discovery-driven development（探索駆動／学び駆動）
- Experiment-driven development（実験駆動）
- Hypothesis-driven development（仮説駆動：Lean Startup寄り）
- R&D Scrum / Research Scrum / Scrum for R&D
- Dual-track（Discovery/Deliveryの二本立て。Deliveryが薄い時期もある、と説明しやすい）
「スパイク」という単語を残したいなら、
“spike-heavy sprints”（スパイク多めのスプリント）とか “spike-first”（まずスパイクで不確実性を落とす）みたいな方が、原義の“短く尖る”イメージを保てます。
4) Scrumでやるなら、評価軸（Doneの定義）を「学び」に寄せると破綻しにくい
実装が進まない／捨てるのが多いこと自体は問題ではなく、問題になりやすいのは 「スプリントの成果が何かを説明できない」ことです。R&Dなら、増分の代わりに例えば：
- 検証した仮説と結果（数値・ログ・判断）
- 次にやるべき実験の優先順位
- “やらない”決定（棄却した案）と理由
- リスクの増減、未知の解消状況
をスプリント成果としてレビューできる形にすると、「実装がない＝進捗ゼロ」に見えにくくなります。
もしよければ、あなたの文脈に合わせて “spike driven development” の一文定義（英/日）と、スプリントレビューでの成果物テンプレ（何を出せば“進んだ”と見えるか）を一緒に作れます。プロジェクトのステークホルダーが「研究成果」を期待しているのか、「いつか製品化」を強く求めているのかで、言葉選びも変わります。
q
spike という言葉のニュアンスが一番わかりやすいと思うんですよね。
- タスクではなくスパイク
- 1スパイクは文脈とログと結果とレポートを持つ
- 文脈とはスパイクのタイトル、目的、なぜ何のためにやるか、制約や戦略や依存はなにかといったもの
- ログとは作業ログなど「やったこと」。また中間成果物や収集したファイルなども含めていい
- 結果とはスパイクの結果。仮説の検証結果、問いに対する答えなど。できてないならどこまでできたのかとか、なぜできなかったのかなど
- レポートは上記を端的に整理したもの。定義はないが、A4 一枚やカード 1 枚で整理した
- スパイクを終えるとそれは文脈、ログ、結果、レポートを持つはずだ
- なので「スパイク23により～～と言えるから」のような会話が可能となる。これを spike based communication と呼ぶ
こんな感じで、スパイクという「ラフな実験単位」を重ねていく感じです。プロダクトというほど重たいものは抱えずに、各自が自由に探索・議論しつつ、スパイクの形で知見を貯めていくんですよ。
少なくとも「タスク」は違う。タスクだと指示命令のニュアンスが強いから。スパイクが適切だと思うんですよ。
a
あなたの定義の「スパイク」は、XP/Scrumでよく言う “短い技術調査タスク” の狭い意味を超えて、R&Dにおける「知識生成の最小単位」として再定義していて、ニュアンスとしてかなり筋がいいです。特に「スパイク番号で参照できる」「捨てコードを許容しつつ知見が資産として残る」は、言葉の比喩（尖って刺して確かめる）とも相性が良いです。
その前提で、言い方（spike driven / spike based）を“通じる言語”にするための整理案だけ、実務的にまとめます。
1) 「タスクではなくスパイク」は成立する（ただし再定義を明示すると強い）
一般的に task は「やるべき作業」で、成果は“完了”になりがちです。一方あなたの spike は
- 不確実性の縮退（学び）が成果
- 結果が「できた」でも「できなかった」でも価値がある
- 捨てコードや途中経過が前提に入る
なので、命令・実行の単位というより 探索・意思決定の単位です。ここを宣言しておくと、「タスクと何が違うの？」に耐えます。
おすすめの一文定義（日本語）：
- Spike = タイムボックスされた探索で、不確実性を減らし、再利用可能な知見（文脈・ログ・結果・要約）を残す作業単位
2) あなたの4点セット（文脈・ログ・結果・レポート）はめちゃくちゃ良い。名前を付けるとさらに共有しやすい
いまのままでも強いですが、チーム用語としては「SpikeのDoD（完了の定義）」として固定すると一気に運用が安定します。
例：Spike DoD
- Context：目的、問い、成功条件/中止条件、制約、依存、タイムボックス
- Log：やったこと、試したパラメータ、参照リンク、作ったスクリプト/計測結果、失敗の記録
- Result：結論（Yes/No/Unknown）、分かったこと、分からなかったこと、残リスク
- Report：意思決定できる形に圧縮（1枚で良い）、次アクション提案（次のスパイク候補/やめる判断）
この形だと「スパイクが終わると、資産が増える」が担保できます。
3) “spike based communication” は通じる。さらに強くするなら「引用可能性」を前面に
あなたがやりたいのは実質これです：
- 「スパイク23によれば〜」と根拠を指せる
- 会話が“記憶”ではなく“参照”で進む
- 合意形成が「誰が強く言ったか」ではなく「どのスパイクが示したか」になる
この思想は、名前を少しだけ寄せると初見にも理解されやすいです。
候補：
- Spike-referenced communication（スパイク参照コミュニケーション）
- Evidence-by-spike / Spike as evidence
- Spike knowledge base（スパイクを知識ベース化している、という説明が一発で入る）
“based” でも悪くないですが、based だと「全部それだけ」感が出るので、社外/他チームにも説明するなら referenced / evidence が誤解されにくいです。
4) “spike driven development” はアリ。ただ “development” が「製品実装」を想起させる点だけ注意
あなたの実態は「開発(implementation)」というより 探索(Research/Discovery) なので、
- 対内（チーム内）では spike driven development で十分通る
- 対外（プロダクト開発を期待してる人）には
spike-driven discovery / spike-driven R&D の方が誤解が減る
という使い分けが安全です。
5) 最後に：この運用で一番効くガードレール（言葉の説得力が上がる）
スパイクを「タスクと違う」と言い切るなら、最低限これがあると盤石です。
- タイムボックス（スパイクが“尖る”ため）
- 問い（Question）がタイトルに入る（例：「XはY条件でZms以内か？」）
- 結論の型（Yes/No/Unknown＋根拠リンク）
- 次の行動（次スパイク/実装/やめる、のどれかに必ず着地）
必要なら、あなたの4点セットをそのまま使って「Spikeカード（テンプレ）」を日英で整形します。タイトルの付け方（問いベース）と、Resultの書式（Yes/No/Unknown）を揃えると、スパイク番号で会話する文化が一段と回りやすくなります。