はじめに
はじめまして、 テクノロジー本部システムアーキテクト部の高橋昭仁と申します。
昨年の7月から、社内のアジャイルトレーニングの受講の機会を頂き、 トレーニングに参加いたしました。
元々私は、以前の職場でもアジャイル開発を採用していたため、 プロセスやお作法、進め方や振り返りなどは、現場を通じ経験しておりました。 ただ、現場毎でアジャイル開発方法の違いがあったため、 改めてアジャイル開発とはどんなものなのかを基礎からトレーニングを通じ学ぶことが出来ました。
そこで今回は、トレーニングで学んだスパイクについて、お話させていただければと思います。
スパイクとは何か？また目的は？
まず、AgileDictionaryというアジャイル用語が 載っているサイトにスパイクの定義があります。 英文のため、翻訳します。
出荷可能な製品を作ることよりも、質問に答えたり情報を集めたりすることを目的としたタスク。 技術的な質問や設計上の問題を解決するために、開発チームが実際の作業を行うまで、 ユーザーストーリーをうまく見積もることができないことがある。 その解決策は「スパイク」を作ることである。 スパイクとは、答えや解決策を提供することを目的とした何らかの作業である。
上記を簡単にまとめますと、以下のようになります。
- 解決方法や実現方法を探索する
- 見積りの精度を高める
- 不明確な点を明らかにする
- 質問に対する回答やソリューションを見つける
例えば、インセプションデッキに、「夜も眠れない問題」という問いがあります。
この問いでは、不安要素をあげ、インセプションデッキ作成者全員で共有し、リスクに対して議論を行い、早期からコントロールできるリスクを管理していきます。 この管理したリスクは、スパイクを実施することで明確になり、対策や回答を準備することが出来るようになります。
また、上記のスパイクの定義では、「技術的な質問や問題を解決するため」として表現されていますが、 エムティーアイではSAFeにおける Enabler の定義も同じくスパイクとして扱います。
ビジネス、プロダクト検討サイド（顧客ニーズやアンケート、ヒアリングなど）がExplorationに含まれています。
つまり、ビジネス価値を高めていくための準備作業全般もスパイクと呼ぶことで、 プロジェクトの不確実性に備えられるようになり、実現したかったことが明確になります。
スパイクの由来
eXtreme Programing 由来の言葉
語源の由来についても、AgileDictionaryに記述されておりますので、こちらも翻訳しました。
スパイク・ソリューションは、潜在的な解決策を探るための非常にシンプルなプログラムです。 XPの第一人者であるWard Cunninghamは、C2.comのwikiでこの用語がどのように作られたかを説明しています。 私はよくKent（Beck）に、「我々が正しい道を進んでいると確信できるような、最も簡単なプログラムは何か」と尋ねたものです。 このように、目の前の困難から一歩踏み出すことで、よりシンプルで説得力のある解決策にたどり着くことがよくありました。 ケントはこれを「スパイク」と名付けました。大規模なフレームワークを保守しているときに、この練習が特に役に立ちました。
ここでは「試しにシンプルなプログラムを書いてみること 」とあり、まずは動くものを作り評価することが重要な要素だと分かります。
これはアジャイルソフトウェア開発宣言にもある、「包括的なドキュメントよりも動くソフトウェアを」でも表現されており、 早い段階で評価をしてもらうことでリスクを軽減し、見えなかった問題も対応しやすくなるということに繋がってくるのだと思います。
※ちなみにロッククライミングの時に打ち付ける スパイク（命綱を止めておくために岩に埋め込む金属）が由来だそうです
スパイクを進めるためのポイント
では、どのようにスパイクを取り入れていくか、また進めるうえで注意するポイントについても解説していきたいと思います。
技術検証あるあるになるのですが、技術検証は時間があればあるほど実施してしまうため、ゴールを定めた方が良いとされています。
簡単にまとめると、スパイクを進めるためのポイントは以下の通りです。
- やりすぎない（全て網羅しようとしない）
- タイムボックスを設定する
- タイムボックスの上限に収まらなければ追加するか、諦めるかを判断する
- スパイクもプロダクトバックログアイテムやNFR(非機能要求)と同様に取り扱い、完了条件も決めておく
仮に設定した時間に終わらなかった場合も、終わらなかったことがスパイクの結果となり、 必ずしも分かるまで終わらせることが重要ではありません。 スプリントに含める際は、スパイクだけでスプリントのアイテムを埋め尽くさないことも重要です。 ゴールを設定し、消化しきらなければ次のスプリント内で消化するようにします。
また、①何がわかったら完了か、②ストーリーポイントの見積もり、③時間の見積もり、の3つを定めておくのも重要です。 もし有識者がいた場合は、有識者の意見も取り入れタイムボックスを設定することがお勧めです。
スパイクの扱い
前述で少し触れましたが、プロジェクト開始前だけではなく、実際にスプリント開始した際にもスパイクをする必要があり、 そのスパイクを実施する際の扱いについても解説していきたいと思います。
実際にスパイクは以下2点で扱うことが多いです。
- プロダクトバックログアイテムとしても、タスクとしても扱うことはできる
- プロダクトバックログアイテムと同レベルのアイテムとして管理することを推奨する
上記2点以外に注意すべきは、プロダクトバックログの優先順位の責務は、プロダクトオーナーにあるため、 スパイクの重要性をプロダクトオーナーに説明・相談しスプリントに組み込んでもらう必要があります。
最後に
今回はスパイクについて解説させていただきました。
スパイクは、スパイクのゴールを定め、プロダクトバックログアイテムとして扱い、また技術検証のみならずプロダクトを作成する際に、 ビジネス側で調査・検証が必要になった場合もスパイクを実施することで、不安要素が見えるようになるためとても重要な作業だと思います。
私自身も、技術検証やPoCで不安要素を明確にしたことや、必要であろうコストを算出するなど、当時はスパイクと意識せずしておりました。
今回スパイクの定義を知り、目的や由来、チーム全体がスパイクを実施するものという観点を学べ、 今後は積極的に取り入れていきプロジェクトを円滑に進められるように取り組められればと思っております。
