develop-spike-summary

スパイクの概要

スパイクの概要では、時間を区切って行った調査の結果を記録します。これは、実装に着手する前に不確実性を減らすための、焦点を絞った調査です。スパイクでは、「この API と統合できるか」「この技術はユースケースに適しているか」といった具体的な問いに答えます。概要に調査結果をまとめることで、スパイクの参加者が説明を繰り返さなくても、チームが十分な情報に基づいて判断できるようになります。

使用する場合

• 時間を区切った技術調査を完了した後
• 技術の選択肢やベンダーの選択肢を評価する場合
• チームの判断材料となる概念実証を終えた後
• 提案されたソリューションの実現可能性を調査する場合
• 新しいアプローチにエンジニアリングリソースを投入する前

使用しない場合

• 結果として得られたアーキテクチャ上の判断自体を記録する場合 → develop-adr を使用します。スパイクは情報を提供し、ADR は判断を下します。
• ユーザー調査を行ったのであり、技術的または設計上の実現可能性を調査したのではない場合 → discover-interview-synthesis を使用します。
• スパイクで示されたソリューションを提案したい場合 → develop-solution-brief を使用します。
• スパイクをまだ実施していない場合。このスキルでは結果を記録します。まず時間を区切って調査を実施してください。

手順

スパイクの記録を依頼された場合は、次の手順に従います。

1. 問いを明確に示す スパイクで答えることを目的とした具体的な問いを明確にします。適切なスパイクの問いは焦点が絞られており、割り当てられた時間内に回答できます。スパイクの途中で問いが変わった場合は、当初の問いと最終的な問いの両方を記録します。

2. 時間枠を定める 割り当てた時間（例：3 日間）と実際に費やした時間を記録します。スパイクが時間枠を超えた場合は、その理由を説明し、残っている作業も記載します。

3. アプローチを説明する 何を、どのような順序で、なぜ試したのかを説明します。これにより、今後の読者が方法論や、他のアプローチを検討したかどうかを理解できます。

4. 根拠を示して調査結果を提示する コードサンプル、パフォーマンスベンチマーク、スクリーンショット、API のレスポンスなど、具体的な根拠に基づいて学んだことを記録します。検証済みの調査結果と、追加のテストが必要な仮説を区別します。

5. 明確な推奨事項を示す 当初の問いに直接答えます。進める、進めない、条件付きで進める、のいずれかを示します。曖昧な表現は避けてください。チームには実行に移せる指針が必要です。

6. 成果物を記録する スパイクの実施中に作成したコード、プロトタイプ、図、ドキュメントへのリンクを記載します。こうした成果物は、概要の作成後も役立つことがよくあります。

7. 未解決の問いを記録する スパイクで答えられなかったことや、追加調査が必要なことを記載します。

出力形式

出力の構成には references/TEMPLATE.md のテンプレートを使用します。完全なスパイクの概要では、テンプレートのすべてのセクション（概要、背景、アプローチ、調査結果、推奨事項、成果物、未解決の問い、フォローアップ項目）を埋めます。

品質チェックリスト

最終化する前に、次の点を確認します。

• 当初の問いが明確に示されている
• 時間枠が記録されている（割り当てた時間と実際に費やした時間）
• 調査結果が意見だけでなく、根拠に裏付けられている
• 推奨事項が問いに直接答えている
• 成果物（コード、図）にリンクがあるか、添付されている
• 未解決の問いで、残っている不明点が明らかになっている

例

完成例については references/EXAMPLE.md を参照してください。