スプリントプランニングをやっていると、たまに誰もポイントを付けられないストーリーが出てきます。見積もりは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の技術的負債について - スパイクが技術的負債の予防にどう役立つか

• SSHでは、ログイン試行があったタイミングで任意のコマンドを実行できます。この記事では、Slackと連携させつつPAMの実行順序を制御する方法を紹介します。

Slack APIのWebhook

#

• アプリの作り方はこちらにまとまっています。

• Slackアプリを作成してWebhookを有効にし、SSHからの通知を受け取るためのIncoming Webhookを用意してください。

ログイン失敗時の通知スクリプト

#

• スクリプトはどこに置いても構いません。私は /var/opt/notify-attempt.sh に置きました。

#!/bin/bash
if [ "$PAM_TYPE" != "close_session" ]; then
        url="<YOUR SLACK WEBHOOK>"
        channel="#channel"
        host="$(hostname)"
        content="\"attachments\": [ { \"mrkdwn_in\": [\"text\", \"fallback\"], \"fallback\": \"SSH login: $PAM_USER connected to \`$host\`\", \"text\": \"SSH login to \`$host\`\", \"fields\": [ { \"title\": \"User\", \"value\": \"$PAM_USER\", \"short\": true }, { \"title\": \"IP Address\", \"value\": \"$PAM_RHOST\", \"short\": true } ], \"color\": \"#F35A00\" } ]"
        curl -X POST --data-urlencode "payload={\"channel\": \"$channel\", \"mrkdwn\": true, \"username\": \"SSH Notifications\", $content, \"icon_emoji\": \":inbox-tray:\"}" "$url" &
fi
exit

他のSSHイベントについて

#

• ログイン成功など、他のイベントも通知したい場合はファイルを2つ作るのがおすすめです。
• それぞれのファイルに、Slackへ送るJSONを書いておきます。
• fallback\": \"SSH login: $PAM_USER connected to \$host`"` の行はイベントに合わせて書き換えてください。
• OpenSSHがこれらのスクリプトをどう使うかは、下の設定を見れば分かります。

sshの設定

#

ログイン成功時の通知はコメントアウトしてあります。使いたい場合はコメントを外せば、成功時にもSlackへ通知が飛びます。 該当行：# auth optional pam_exec.so /var/opt/notify-login.sh

[success=2] は「ログインに成功したら2行スキップする」という意味で、これで失敗時の通知を飛ばしています。

ファイル：/etc/pam.d/common-auth

# /etc/pam.d/common-auth - authentication settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the
# traditional Unix authentication mechanisms.
#
# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules. See
# pam-auth-update(8) for details.
# here are the per-package modules (the "Primary" block)
auth  [success=2 default=ignore]   pam_unix.so nullok
auth  optional            pam_exec.so /var/opt/notify-attempt.sh
# here's the fallback if no module succeeds
auth  requisite            pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
# For successful login, uncomment the below line, ensure the file exists.
# auth  optional            pam_exec.so /var/opt/notify-login.sh
# auth  required            pam_permit.so
# and here are more per-package modules (the "Additional" block)
auth  optional            pam_cap.so
# end of pam-auth-update config

ありがとうございました！

#

• 質問やコメントがあれば、気軽に直接連絡してください