スクラムにおける技術的スパイクの進め方
みなさんこんにちは。@ryuzeeです。
スクラムでは、スプリントに投入するプロダクトバックログ項目はReady（準備ができている）である必要があります （Readyとはどんな状態なのかについては以前に詳しく説明したので、そちらを参照してください）。 Readyにしておくことによって、成果の量が安定しプロダクトオーナーやステークホルダーにとっては予測精度が向上していきます。
Readyにする活動は単に受け入れ基準を用意したり、プロダクトバックログの内容を精緻化したり、並べ替えたりするだけではありません。 スプリント内でプロダクトバックログ項目が完成する可能性を上げるために必要な活動すべてが含まれます。 そしてその中の1つが技術的な調査です。 スプリントでプロダクトバックログ項目に着手してから実現方法を調べたり、技術的な制約によって大幅な方針転換したりするのでは遅い上に予測性が低いので、先に技術調査をするわけです。 このことをスパイクと呼びます。
今回はスプリントを実際に開始したあとで、スプリントを回しながらどのようにスパイクをしていけばよいか見ていきましょう（スプリント0の立ち上げ期間中にもスパイクを実施しますが、今回はスプリントでの活動にフォーカスします）。
1. スパイクの定義
まずは、AgileDictionaryというアジャイル用語解説サイトの定義でスパイクの定義を確認しましょう。 そこでは以下のようになっています（拙訳。一部改変）。
スパイク
リリース可能なプロダクトを作るのではなく、質問に答えたり情報を収集したりすることを目的とした作業。 開発チームが技術的な質問や設計上の問題を解決するための実際の作業を行うまで、見積りができないようなプロダクトバックログ項目が出てくることがあります。 解決策は、「スパイク」を行うことです。 目的は、質問に対する回答やソリューションを見つけることです。
語源
スパイクという用語は、エクストリームプログラミング（XP）に由来します。 そこでは、「スパイクとは、非常に簡素なプログラムのことで、ソリューション候補を探求するのに使われる」とされています。 ウォード・カニンガムは、c2.comというwikiでこの用語がどのようにできたかを述べています。 「ベック、自分たちが正しい方向に進んでいると確信できる、もっとも簡単なことは何だろう？」 手に余りそうなものを小さくして進めることで、単純で説得力のある解決策につながりました。 ケント・ベックはこれをスパイクと名づけました。 私は大きなフレームワークの保守をしているときでも、このプラクティスが特に役立つことを発見しました。
2. スパイクの目的
つまり、スパイクの目的は以下のように整理できます。
- 質問や疑問に答えるための情報を集める
- より良い実現方法を探索する
- 見積り精度を上げる
- リスクを明らかにする
3. スパイクの進め方
スクラムではスプリントごとに「リリース判断可能なインクリメント」を作ると決められています。 それぞれのスプリントで、スプリントゴールを満たすように進めていかないといけません。 したがって、スプリントの時間をスパイクで埋め尽くしてはいけません。 以下の手順で進めていくとよいでしょう。
基本の流れ
- まずはプロダクトバックログリファインメントなどを活用して、直近数スプリント内に着手する可能性のあるプロダクトバックログ項目をウォークスルーして、技術的な課題がないかどうかを確認する
- 例えば技術的な観点で以下のように分類してみます
- 環境や前提条件などを決めて測定してみないと分からないもの
- 誰もやったことがなく、ノウハウや情報の入手も難しいもの
- 誰もやったことはないが、ネット上などにさまざまな情報がありそうなもの
- 開発チーム内のごく少数だけは経験があるもの
- 開発チーム内の多くの人が分かるもの
- 分類した上で、特に上記の1点目〜3点目に該当するような技術的な課題があった場合は、それらがどの程度大きな問題になりそうなのかを開発チームで判断する
- 開発チームとして大きな問題にならないと自信をもてる場合は特にアクションは必要ない
- そうでない場合は、開発チームとして、それらの課題がどのような状態になったら解決となるかを合意する
- 複数のスパイク項目がある場合は、通常のプロダクトバックログと同じように並べ替える
- その上で、スパイクに使う時間の上限を設定する（終わるまでやろうとすると時間が延びるので、タイムボックスを定める）
- 状況に応じて、プロダクトバックログ化するか、開発チームのバッファの中で行うか判断する
- スパイクを実施する。必要なことが判明したり、タイムボックスの上限に達したりしたら、スパイクの結果を共有する
- その上でさらに追加でスパイクが必要かどうかの判断をする
4. スパイクを進める上での注意点
スパイクを進める上ではいくつか注意点があります。例を挙げておきましょう。
- 目的や課題の認識抜きでやらない
- スプリント1を開始する前の初期フェーズで、全てを検証しようとしない
- 直近数スプリント程度を対象とし、重要な箇所にフォーカスする
- プロダクトバックログ項目の着手の仕方と同じように、なるべく開発チーム内で1つづつ終わらせる。すなわちスパイクの担当者を固定しすぎない
- やりすぎない。目的はプロダクトバックログ項目の精度をあげることなので、それができる最低限で構わない。全てを網羅しようとしない
- スパイクはあくまでスパイクなので、スパイクの成果のコードをいきなりプロダクトコードに統合しない
- タイムボックスを設定し、その枠で収まらない場合は状況を確認した上で再計画する。時には諦める判断をすることもある
- タイムボックスをどの程度にするかの決まりはないが、スプリントの長さの20%程度までの時間が現実的。もちろん開発チームの能力に強く依存する
- スパイクの結果はプロダクトバックログ項目の中身（見積りや受け入れ条件など）に反映する
5. スパイクをプロダクトバックログに入れるか、それともバッファのなかで行うか
スパイクをプロダクトバックログに入れるか、スプリントのバッファで行うかは悩ましいポイントです。 考え方としては、以下のようにしておくと良いと思います。
バッファで対応する
- スパイクの所要時間の見込みが短い場合
- 万一ほかのプロダクトバックログ項目の実装に時間がかかってバッファが減り十分なスパイクができなくても、即時大きな問題にはならない場合
プロダクトバックログ項目に入れる
- 次以降のスプリントで進捗を阻害する重大な問題になると考えられる場合
- スパイクが必要なプロダクトバックログ項目が、他のプロダクトバックログ項目と依存関係を形成している場合
- 検証に時間がかかる場合（開発チームのバッファを超える時間が必要な場合）
なお、プロダクトバックログの並び順の最終決定権限はプロダクトオーナーにあります。 したがって、スパイクのプロダクトバックログ項目の重要性を開発チームとしてプロダクトオーナーに伝えて、スプリントへの投入を決定してもらう必要があります。
6. まとめ
繰り返しになりますが、準備のできていない（Readyでない）プロダクトバックログ項目、完成できる自信のないプロダクトバックログ項目をスプリントに投入するのは避けるようにするべきです。 そして、プロダクトバックログ項目は着手前に、要求の観点だけでなく技術の観点なども含めて完成できそうかを確認しておく必要があります。 そして、技術の観点ではスパイクは有効な手立てになります。 どの程度のスパイクが必要なのかは、開発チームの扱っている技術や経験に大きく左右されますが、重要な問題にフォーカスしタイムボックスを設定して取り組むと良いでしょう。
それでは。
サイト内検索
著作
変革の軌跡【世界で戦える会社に変わる"アジャイル・DevOps"導入の原則】
著者／訳者：Gary Gruver、Tommy Mouser / 吉羽 龍太郎、原田騎郎
出版社：技術評論社( 2017-1-25 )
定価：￥ 2,138
米ヒューレット・パッカードのLaserJet部門でいかにしてAgileやDevOpsの原則を適用しマーケットの変化に対応できるようになったかの事例を解説。巻末には日本の大手企業の事例も収録
著者／訳者：リチャード・シェリダン / 原田騎郎, 安井力, 吉羽龍太郎, 永瀬美穂, 川口恭伸
出版社：翔泳社( 2016-12-20 )
定価：￥ 1,944
米国で何度も働きやすい職場として表彰を受けているメンローの創業者かつCEOであるリチャード・シェリダン氏が、職場に喜びをもたらす知恵や経営手法、より良い製品の作り方などを惜しみなく紹介しています
著者／訳者：荒木靖宏, 大谷晋平, 小林正人, 酒徳知明, 高田智己, 瀧澤与一, 山本教仁, 吉羽龍太郎
出版社：マイナビ出版( 2016-06-10 )
定価：￥ 2,797
AWSを企業に導入する際に知っておくべきAWSサービスの全貌から、セキュリティ概要、システム設計、導入プロセス、運用までをまとめた書籍。操作の仕方ではなくどのように導入していくかの考え方や設計方法に焦点をあてています
著者／訳者：Jimmy Janlén / 原田騎郎, 吉羽龍太郎, 川口恭伸, 高江洲睦, 佐藤竜也
出版社：Leanpub( 2016-04-12 )
定価：$14.99
この本は、チームの協調とコミュニケーションを改善したり、行動を変えるための見える化の実例を集めたものです。96個(+2)の見える化の方法をそれぞれ1ページでイラストとともに解説しています。アジャイル開発かどうかに関係なくすぐに使えるカタログ集です
著者／訳者：原田騎郎 安井力 吉羽龍太郎 角征典 高木正弘
出版社：オライリージャパン( 2016-03-25 )
定価：￥ 2,138
チームの仕事や課題を見える化する手法「カンバン」について、その導入から実践までを図とともにわかりやすく解説した書籍です。カンバンの原則や流れの管理などの入門的な事柄から、サービスクラス、メトリクスの使用、プロセスの改善など、一歩進んだ応用的な話題までを網羅的に解説します。カンバンを一から学びたい、組織で使ってみたいと考える方に最適な実践的な入門書です。
サーバ/インフラエンジニア養成読本 DevOps編 [Infrastructure as Code を実践するノウハウが満載! ]
著者：吉羽龍太郎 新原雅司 前田章 馬場俊彰
出版社：技術評論社( 2016-02-26 )
定価：￥ 2,138
DevOpsの基本と主にツール面からの解説。Ansibleによるサーバ管理、CircleCIでの継続的インテグレーションフロー、Dockerの話まで幅広いトピックを扱っています
著者／訳者：西村直人 永瀬美穂 吉羽龍太郎
出版社：翔泳社( 2013-02-13 )
定価：￥ 2,520
スクラム初心者に向けて基本的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。
著者／訳者：渡辺 一宏 吉羽 龍太郎 岸田 健一郎 穴澤 康裕
出版社：インプレス( 2014-09-19 )
定価：￥ 4,320
Webアプリケーション開発における継続的インテグレーションについて、CakePHPのサンプルをベースにして、その概要から使用ツール解説、導入方法、メンテナンスまでを解説
Chef実践入門 ~コードによるインフラ構築の自動化 (WEB+DB PRESS plus)
著者／訳者：吉羽 龍太郎 安藤 祐介 伊藤 直也 菅井 祐太朗 並河 祐貴
出版社：技術評論社( 2014-05-22 )
定価：￥ 2,992
スタンドアロンでのChef Soloの利用から始めて、クックブックの書き方や注意すべきポイント、さらにはクックブックのテスト、継続的インテグレーションなど幅広いトピックを解説
Software in 30 Days スクラムによるアジャイルな組織変革“成功"ガイド
著者／訳者：Ken Schwaber、Jeff Sutherland著、角征典、吉羽龍太郎、原田騎郎、川口恭伸訳
出版社：アスキー・メディアワークス( 2013-03-08 )
定価：￥ 1,680
スクラムの父であるジェフ・サザーランドとケン・シュエイバーによる著者の日本語版。ビジネス層、マネジメント層向けにソフトウェア開発プロセス変革の必要性やアジャイル型開発プロセスの優位性について説明
How to Change the World 〜チェンジ・マネジメント3.0〜
著者／訳者：Jurgen Appelo, 前川哲次(翻訳), 川口恭伸(翻訳), 吉羽龍太郎(翻訳)
出版社：達人出版会
定価：500円
どうすれば自分たちの組織を変えられるだろう？それには、組織に変革を起こすチェンジ・マネジメントを学習することだ。アジャイルな組織でのマネージャーの役割を説いた『Management 3.0』の著者がコンパクトにまとめた変化のためのガイドブック
寄稿
著者／訳者：河原一哉, 白土慧, 菊田洸ほか
出版社：技術評論社( 2017-8-24 )
定価：￥ 1,598
100号記念選書、TOPエンジニアを支える一冊の企画に寄稿しました。紹介したのはアジャイル開発の原点の一つとも言える大野耐一著『トヨタ生産方式』です
著者／訳者：Roy Osherove著, 島田浩二翻訳
出版社：オライリージャパン( 2017-5-13 )
定価：￥ 3,024
本書は日本語版オリジナルとして巻末に日本人エンジニアによるエッセイが14本収録されています。そのうち、42章：採用プロセスについてもっと考えよう、を当方が寄稿しました。リーダーシップが必要なのであれば採用のときにも候補者にリーダーシップがあるのか確認すべきですよね
著者／訳者：原田騎郎, 吉羽龍太郎, 松浦隼人, 須藤涼介ほか
出版社：技術評論社( 2016-6-24 )
定価：￥ 1,598
特集の「実践見積り」を寄稿。見積りでは、スケジュールやスコープ、メンバーのスキルなどの要素が密接に絡み合っていて難しいと思う人が多いと思います。本特集では見積りの歴史的経緯、従来型とアジャイル開発における見積りのやり方、見積りの今後について解説しています
著者／訳者：原田騎郎, 吉羽龍太郎, 山口陽平ほか
出版社：技術評論社( 2014-10-24 )
定価：￥ 1,598
特集の「強いチームの作り方」を寄稿。刻々とニーズが変化する近年のソフトウェア開発では、既成観念にとらわれない新しいアイデアが不可欠ですが一方で意見の対立がメンバーの衝突を引き起こすことも多くあります。本特集では、意見の違いをメンバーどうしが受け入れ、新しいアイデアへつなげていけるチームの作り方を解説しています
著者／訳者：Mitchell Hashimoto
出版社：オライリージャパン( 2014-02-21 )
定価：￥ 2,808
Vagrantの概要やマシン設定から、プロビジョニング、ネットワーク、ボックス、さらにはプラグインによる拡張までを網羅した開発者自身による解説書。日本語版限定で「Vagrantプラグイン」と「Packer」について寄稿。また伊藤直也さんによる描きおろしも含まれている
100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊
出版社：翔泳社( 2012-02-22 )
定価：￥ 1,944
ソフトウェア技術者のための名著案内。国内最大級の開発者向けカンファレンス「DevelopersSummit」のベストスピーカーを中心とした、100名の執筆陣が書籍を選定・紹介。アジャイルプラクティスについて寄稿