ブログ

ryuzeeによるブログ記事。不定期更新

スクラムにおける技術的スパイクの進め方

みなさんこんにちは。@ryuzeeです。

スクラムでは、スプリントに投入するプロダクトバックログアイテムはReady(準備ができている)である必要があります (Readyとはどんな状態なのかについては以前に詳しく説明したので、そちらを参照してください)。 Readyにしておくことによって、成果の量が安定しプロダクトオーナーやステークホルダーにとっては予測精度が向上していきます。

Readyにする活動は単に受け入れ基準を用意したり、プロダクトバックログの内容を精緻化したり、並べ替えたりするだけではありません。 スプリント内でプロダクトバックログアイテムが完成する可能性を上げるために必要な活動すべてが含まれます。 そしてその中の1つが技術的な調査です。 スプリントでプロダクトバックログアイテムに着手してから実現方法を調べたり、技術的な制約によって大幅な方針転換したりするのでは遅い上に予測性が低いので、先に技術調査をするわけです。 このことをスパイクと呼びます。

今回はスプリントを実際に開始したあとで、スプリントを回しながらどのようにスパイクをしていけばよいか見ていきましょう(スプリント0の立ち上げ期間中にもスパイクを実施しますが、今回はスプリントでの活動にフォーカスします)。

1. スパイクの定義

まずは、AgileDictionaryというアジャイル用語解説サイトの定義でスパイクの定義を確認しましょう。 そこでは以下のようになっています(拙訳。一部改変)。

スパイク

リリース可能なプロダクトを作るのではなく、質問に答えたり情報を収集したりすることを目的とした作業。 開発チームが技術的な質問や設計上の問題を解決するための実際の作業を行うまで、見積りができないようなプロダクトバックログアイテムが出てくることがあります。 解決策は、「スパイク」を行うことです。 目的は、質問に対する回答やソリューションを見つけることです。

語源

スパイクという用語は、エクストリームプログラミング(XP)に由来します。 そこでは、「スパイクとは、非常に簡素なプログラムのことで、ソリューション候補を探求するのに使われる」とされています。 ウォード・カニンガムは、c2.comというwikiでこの用語がどのようにできたかを述べています。 「ベック、自分たちが正しい方向に進んでいると確信できる、もっとも簡単なことは何だろう?」 手に余りそうなものを小さくして進めることで、単純で説得力のある解決策につながりました。 ケント・ベックはこれをスパイクと名づけました。 私は大きなフレームワークの保守をしているときでも、このプラクティスが特に役立つことを発見しました。

2. スパイクの目的

つまり、スパイクの目的は以下のように整理できます。

  • 質問や疑問に答えるための情報を集める
  • より良い実現方法を探索する
  • 見積り精度を上げる
  • リスクを明らかにする

3. スパイクの進め方

スクラムではスプリントごとに「リリース判断可能なインクリメント」を作ると決められています。 それぞれのスプリントで、スプリントゴールを満たすように進めていかないといけません。 したがって、スプリントの時間をスパイクで埋め尽くしてはいけません。 以下の手順で進めていくとよいでしょう。

基本の流れ

  • まずはプロダクトバックログリファインメントなどを活用して、直近数スプリント内に着手する可能性のあるプロダクトバックログアイテムをウォークスルーして、技術的な課題がないかどうかを確認する
  • 例えば技術的な観点で以下のように分類してみます
  • 環境や前提条件などを決めて測定してみないと分からないもの
  • 誰もやったことがなく、ノウハウや情報の入手も難しいもの
  • 誰もやったことはないが、ネット上などにさまざまな情報がありそうなもの
  • 開発チーム内のごく少数だけは経験があるもの
  • 開発チーム内の多くの人が分かるもの
  • 分類した上で、特に上記の1点目〜3点目に該当するような技術的な課題があった場合は、それらがどの程度大きな問題になりそうなのかを開発チームで判断する
  • 開発チームとして大きな問題にならないと自信をもてる場合は特にアクションは必要ない
  • そうでない場合は、開発チームとして、それらの課題がどのような状態になったら解決となるかを合意する
  • 複数のスパイク項目がある場合は、通常のプロダクトバックログと同じように並べ替える
  • その上で、スパイクに使う時間の上限を設定する(終わるまでやろうとすると時間が延びるので、タイムボックスを定める)
  • 状況に応じて、プロダクトバックログアイテム化するか、開発チームのバッファの中で行うか判断する
  • スパイクを実施する。必要なことが判明したり、タイムボックスの上限に達したりしたら、スパイクの結果を共有する
  • その上でさらに追加でスパイクが必要かどうかの判断をする

4. スパイクを進める上での注意点

スパイクを進める上ではいくつか注意点があります。例を挙げておきましょう。

  • 目的や課題の認識抜きでやらない
  • スプリント1を開始する前の初期フェーズで、全てを検証しようとしない
  • 直近数スプリント程度を対象とし、重要な箇所にフォーカスする
  • プロダクトバックログアイテムの着手の仕方と同じように、なるべく開発チーム内で1つづつ終わらせる。すなわちスパイクの担当者を固定しすぎない
  • やりすぎない。目的はプロダクトバックログアイテムの精度をあげることなので、それができる最低限で構わない。全てを網羅しようとしない
  • スパイクはあくまでスパイクなので、スパイクの成果のコードをいきなりプロダクトコードに統合しない
  • タイムボックスを設定し、その枠で収まらない場合は状況を確認した上で再計画する。時には諦める判断をすることもある
  • タイムボックスをどの程度にするかの決まりはないが、スプリントの長さの20%程度までの時間が現実的。もちろん開発チームの能力に強く依存する
  • スパイクの結果はプロダクトバックログアイテムの中身(見積りや受け入れ条件など)に反映する

5. スパイクをプロダクトバックログに入れるか、それともバッファのなかで行うか

スパイクをプロダクトバックログに入れるか、スプリントのバッファで行うかは悩ましいポイントです。 考え方としては、以下のようにしておくと良いと思います。

バッファで対応する

  • スパイクの所要時間の見込みが短い場合
  • 万一ほかのプロダクトバックログアイテムの実装に時間がかかってバッファが減り十分なスパイクができなくても、即時大きな問題にはならない場合

プロダクトバックログアイテムに入れる

  • 次以降のスプリントで進捗を阻害する重大な問題になると考えられる場合
  • スパイクが必要なプロダクトバックログアイテムが、他のプロダクトバックログアイテムと依存関係を形成している場合
  • 検証に時間がかかる場合(開発チームのバッファを超える時間が必要な場合)

なお、プロダクトバックログの並び順の最終決定権限はプロダクトオーナーにあります。 したがって、スパイクのプロダクトバックログアイテムの重要性を開発チームとしてプロダクトオーナーに伝えて、スプリントへの投入を決定してもらう必要があります。

6. まとめ

繰り返しになりますが、準備のできていない(Readyでない)プロダクトバックログアイテム、完成できる自信のないプロダクトバックログアイテムをスプリントに投入するのは避けるようにするべきです。 そして、プロダクトバックログアイテムは着手前に、要求の観点だけでなく技術の観点なども含めて完成できそうかを確認しておく必要があります。 そして、技術の観点ではスパイクは有効な手立てになります。 どの程度のスパイクが必要なのかは、開発チームの扱っている技術や経験に大きく左右されますが、重要な問題にフォーカスしタイムボックスを設定して取り組むと良いでしょう。

それでは。

アジャイルコーチングやトレーニングを提供しています

株式会社アトラクタでは、アジャイル開発に取り組むチーム向けのコーチングや、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください。

詳細はこちら
  • スクラム実践者が知るべき97のこと
  • 著者/訳者:Gunther Verheyen / 吉羽龍太郎 原田騎郎 永瀬美穂
  • 出版社:オライリージャパン(2021-03-23)
  • 定価:¥ 2,640
  • スクラムはアジャイル開発のフレームワークですが、その実装は組織やチームのレベルに応じてさまざまです。本書はスクラムの実践において、さまざまな課題に対処してきた実践者が自らの経験や考え方を語るエッセイ集です。日本語書き下ろしコラムを追加で10本収録
  • プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
  • 著者/訳者:Melissa Perri / 吉羽龍太郎
  • 出版社:オライリージャパン(2020-10-26)
  • 定価:¥ 2,640
  • プロダクト開発を作った機能の数やベロシティなどのアウトプットで計測すると、ビルドトラップと呼ばれる失敗に繋がります。本書ではいかにしてビルドトラップを避けて顧客に価値を届けるかを解説しています。
  • SCRUM BOOT CAMP THE BOOK 【増補改訂版】
  • 著者/訳者:西村直人 永瀬美穂 吉羽龍太郎
  • 出版社:翔泳社(2020-05-20)
  • 定価:¥ 2,640
  • スクラム初心者に向けて基本的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。
  • みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた
  • 著者/訳者:Matt LeMay / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン(2020-3-19)
  • 定価:¥ 2,640
  • アジャイルで本当の意味での成果を出すには、開発チームだけでアジャイルに取り組むのではなく、組織全体がアジャイルになる必要があります。本書にはどうやってそれを実現するかのヒントが満載です
  • レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
  • 著者/訳者:David Scott Bernstein / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン( 2019-9-18 )
  • 定価:¥ 3,132
  • レガシーコードになってから慌てるのではなく、日々レガシーコードを作らないようにするにはどうするか。その観点で、主にエクストリームプログラミングに由来する9つのプラクティスとその背後にある原則をわかりやすく説明しています。
  • Effective DevOps ―4本柱による持続可能な組織文化の育て方
  • 著者/訳者:Jennifer Davis、Ryn Daniels / 吉羽 龍太郎、長尾高弘
  • 出版社:オライリージャパン( 2018-3-24 )
  • 定価:¥ 3,888
  • 主にDevOpsの文化的な事柄に着目し、異なるゴールを持つチームが親和性を高め、矛盾する目標のバランスを取りながら最大限の力を発揮する方法を解説します
  • ジョイ・インク 役職も部署もない全員主役のマネジメント
  • 著者/訳者:リチャード・シェリダン / 原田騎郎, 安井力, 吉羽龍太郎, 永瀬美穂, 川口恭伸
  • 出版社:翔泳社( 2016-12-20 )
  • 定価:¥ 1,944
  • 米国で何度も働きやすい職場として表彰を受けているメンローの創業者かつCEOであるリチャード・シェリダン氏が、職場に喜びをもたらす知恵や経営手法、より良い製品の作り方などを惜しみなく紹介しています
  • アジャイルコーチの道具箱 – 見える化の実例集
  • 著者/訳者:Jimmy Janlén / 原田騎郎, 吉羽龍太郎, 川口恭伸, 高江洲睦, 佐藤竜也
  • 出版社:Leanpub( 2016-04-12 )
  • 定価:$14.99
  • この本は、チームの協調とコミュニケーションを改善したり、行動を変えるための見える化の実例を集めたものです。96個(+2)の見える化の方法をそれぞれ1ページでイラストとともに解説しています。アジャイル開発かどうかに関係なくすぐに使えるカタログ集です
  • カンバン仕事術 ―チームではじめる見える化と改善
  • 著者/訳者:原田騎郎 安井力 吉羽龍太郎 角征典 高木正弘
  • 出版社:オライリージャパン( 2016-03-25 )
  • 定価:¥ 2,138
  • チームの仕事や課題を見える化する手法「カンバン」について、その導入から実践までを図とともにわかりやすく解説した書籍。カンバンの原則などの入門的な事柄から、サービスクラス、プロセスの改善など、一歩進んだ応用的な話題までを網羅的に解説します。
  • 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』の著者がコンパクトにまとめた変化のためのガイドブック