スパイクしなければ開発計画が不確実なものになる、しかしそのスパイクがいつ完了するのかわからない、そのような経験はないでしょうか。スクラムでは、ソフトウェア開発の不確実性を乗り越えるためにスパイクを実施しますが、スパイクそのものの不確実性は残ったままです。スパイクとは不確実なものを早期に確実なものに変えるための手法であり、不確実性をはじめからなかったことにできる魔法のアイテムではないからです。
私は HRMOSプロダクト本部で人財活用システム「HRMOSタレントマネジメント」のプロダクト開発をしているエンジニアの Suzaking です。私たちのチームでは、未経験の技術要素を使用し、1スプリントで完結せず完成までに数ヶ月を要する機能を開発した際に、スパイクの不確実性という課題に直面しました。
この記事では、私たちのチームがスパイクそのものの不確実性にどのように向き合い、どうやって乗り越えたのかを紹介します。
スパイクの不確実性
スクラムにおけるスパイクは、開発に潜む「未知」を「既知」に変えるためのひとつの手法です。「未知」には常に不確実性が付き纏うことになります。
調べてみたら思っていたのと違っていた、使ってみたら使えなかった、作ってみたら想定以上に複雑だった、そもそもどうやって実現したらいいのだろうか、等々。これらの調査や試行にどれくらいのコストがかかるのでしょうか？
スクラムのバックログアイテムは、一般的なプラクティスに従えばストーリーポイントによってコストを見積もります。しかしスパイクには多くの未知が詰まっているため、ストーリーポイントによる見積もりは行わず、タイムボックスを設定して DONE すると良いと言われています。しかし、そのタイムボックスはどのように設定すればいいのでしょうか。
不確実性を解決するためのスパイク自体が不確実なのです。
私たちのスパイクの定義
私たちのチームでは、スパイクをざっくり「技術的な実現可能性を検討する」ものというように定義しています。
スパイクするかどうかはチーム内での会話によって決まるため、この定義自体はあまり明確なものではありません。あくまでも「だいたいこういうもの」程度の定義です。
以下に私たちがスパイクを実施している例を挙げます。
- 要求にある挙動が技術的に実現可能か仮実装して調べる
- 外部ライブラリや外部サービスが要求通りに利用できるか調べる
- 新規の AWS インフラ構成を考える
AWS インフラ構成の設計については、チーム全員が AWS に精通しているわけではないため、いくつかの構成案を出して Pros / Cons を比較検討するというプロセスを実施しています。ここには多くの未知が含まれているため、私たちはこれをスパイクとして扱うことにしています。
スプリントの流れ
私たちのスプリントサイクルは1週間です。また基本的なスクラムイベントは概ねスクラムガイドに沿って実施しています。
デイリースクラムについては1日に2回、午前中のメンバーが揃う時間帯と、夕方まだメンバーが揃っている時間帯に行っています。（デイリースクラムを1日に2回実施するようになったのは、1週間というスプリントサイクルにおいて個人タスク進捗が24時間滞ると致命的な遅れになるという理由からです。）
本記事で扱うスパイクを確実に DONE する試みはこの2回のデイリースクラムを利用して行いました。
「未知」だらけの開発に挑む
私たちがスパイクをうまく扱えるようになりたいと思ったのは、「未知」だらけの新機能開発という大きな壁が目の前に立ちふさがったためでした。その新機能とは、全ての社員データを高速に検索できる「社員検索」機能です。
要求の検討当初から、全文検索エンジンを利用した機能となることが想定されていました。しかし、私たちのチームには全文検索エンジンを利用した開発経験があるメンバーはいなかったので、ほとんどすべてが未知であることが最初からわかっていました。
結果から見ると、社員検索機能の開発開始から完了までに34個ものスパイクを実施しました。
未知で不確実なものは時間を食い潰す
終わらないスパイク
開発を開始した当初は、スパイクに着手すると一般的なプラクティスに従ってタイムボックスを設定しているにも関わらず、2〜3日に渡って IN PROGRESS のままチケットステータスが動かないことが頻発していました。スパイクがスプリントを跨いでしまったことすらありました。
未知であるために、設定したタイムボックスの中で完了しないことが日常的に起こっていたのです。そもそも設定したタイムボックスの妥当性もわかりませんでした。こんな不確実なものをどうやってスプリントの計画に組み込めばいいのか、チームでは何度も議論しながら悩みました。
手放せないスパイク
私たちのスプリントにはスパイクだけでなくいくつかのストーリーやタスク、バグの修正なども計画されていることがほとんどでした。そのため、スパイクだけをやっていればいいわけではありません。メンバーは各々そのことは理解していましたし、デイリースクラムでもそういった会話はしていました。しかし、完了したと言い切れないスパイクをそのままにして別のタスクに移るという判断をすることはとても難しいものでした。
責任感ある開発者であれば、着手したからには中途半端にせず DONE したいと思うのが自然です。私たちのチームも例外ではありませんでした。「調査し終えなければ新機能開発の進捗が滞る」「もっとこんなことを調べておけば安心できる」「より良い方法が他にもあるかもしれない」「検討漏れしていないだろうか」そんな思いを抱えながら未完了とも思えるチケットを手放すことは自分たちの首を絞めるに等しい行為だと考えてしまい、スパイクを継続してしまうのです。
このようにスパイクの完了目処がわからなくなって多くの時間を食い潰し、先行きが見通せなくなっていきました。
スパイクを確実に DONE したい
「兎にも角にも、まずは DONE しよう。」が出発点でした。
スプリントを跨ぐスパイクは計画を台無しにします。
どうすれば不確実なものを確実に DONE できるのか、私たちが考えて実践したのは本質的にはとてもシンプルな方法でした。
簡単に言えば、
- 明確で具体的なゴールを設定する
- ゴールはできる限り1つだけにする
- タイムボックスの開始・終了をチームで同期する
という、たった3つのことです。
1 明確で具体的なゴールを設定する
バックログアイテム全般に言えることですが、明確で具体的なゴールの設定はとても大切なことです。
ストーリーアイテムなどでは、不明確なゴールは実装不足等のバグを引き起こす原因になります。しかしスパイクでは、多くの場合 時間を使いすぎる という問題を引き起こしました。理由は単純で、未知の塊であるスパイクでは、これも調べておいた方が良い、それも検討した方がいい、あれも試しておくべきだ、と際限なく調査検討を続けてしまうためです。
この問題への対処としては、開発者の責任でスパイクチケットを作成し、チームメンバーが話し合って明確かつ具体的なゴールを設定するようにしました。
重要なことは、誰かひとりに任せずに複数のメンバー（基本的には全員）で確認するということです。「明確」とか「具体的」という表現は、おおよそ主観に基づいています。全員が明確かつ具体的であると認識できるかどうかは、全員で確認するしかありません。
私たちが明確で具体的だと考えて決めたゴールには、例えば以下のようなものがあります。
- 社員検索でXXXの表示をする実装方針の案ができている（私たちは何らかの案を出すとき、概ね「松・竹・梅」の3つ作成するという共通認識を持っています）
- 社員検索でXXXを実現する仮実装ができている（マージはしないが Pull Request を作成する）
- 社員検索でYYYの表示速度がわかっている
- ZZZの Design Doc が完成している
- ZZZのインフラ構成案ができている
ゴールの設定と同時に、やらないことの認識を合わせるのも大切なことです。やらないことはチケットにメモとして追記するようにしていました。
2 ゴールはできる限り1つだけにする
複数のゴールがあると、いくつかのゴールは達成したのに他のいくつかのゴールを達成していなくてスパイク全体がDONEできない、ということが起きます。これは一見、それぞれのゴール単位で見るとうまく進捗しているように見えます。
プロダクトオーナーから見てもそれは同じでしょうか？多くの場合その答えはノーです。チケットステータスが IN PROGRESS ならば、そのスパイクはまだ完了していないのです。あとどれくらいで終わるのか、毎回尋ねられることになるでしょう。
また、ひとつのゴールを達成してみると、後続のゴールが変更になるかもしれません。スパイクでは未知だったものを調査・検討しているので、後続作業は容易に変化します。ゴールが増えてしまうかもしれません。そのスパイクはいつになったら完了するのでしょうか。
この問題への対処として、1つのスパイクにゴールは1つだけというルールを決め、できる限りスパイクを早期に DONE できるようにしました。調査・検討の途中で追加の調査・検討が必要であることに気づいても、一緒にやってしまいたい気持ちをぐっと堪えて別のスパイクとしてチケット化するのです。最近では、調べる、案を出す、実現性を検証する、というステップそれぞれを別のスパイクとしてチケット化するようになっています。
3 タイムボックスの開始・終了をチームで同期する
明確かつ具体的なただ1つのゴールがあったとしても、それそのものが未知で不確実なことには変わりありません。
知らないことを調べたり試したり、新たな知識や技術を得るということが大好きな私たちエンジニアは、そういったものに時間を使いすぎる傾向にあります。そのため、スパイクのタイムマネジメントを個人に委ねてしまうと、結局チーム全体から見れば不確実なままなのです。
この問題への対処には頭を悩ませました。X時間で完了しよう、という決め事だけではあまり効果がありませんでした。
そこで私たちは、1日2回実施していたデイリースクラムを利用することにしました。デイリースクラムにはチームメンバー全員が参加しています。スプリントの残り時間をどう過ごすかを調整しています。この場で、スパイクの成果も確認すればいいのではないか、というアイディアでした。
私たちが実施している朝のデイリースクラムから夕方のデイリースクラムまで、概ね4時間あります。この4時間をスパイクのためのタイムボックスとして固定したのです。そして、まだ調査・検討が終わっていなくても、夕方のデイリーで報告した成果をもって、そのスパイクは DONE します。残っている課題は新たなチケットを作成します。小さなスパイクかもしれないし、単純作業のタスクになるかもしれません。いずれにせよ、残ったものがチケットとして可視化されます。すぐには対応不要なものの選別もできるようになります。
こうすることで、いちいちこのスパイクの見積もりはX時間だからHH時mm分までに終わらせよう、などと考える必要がなくなりました。朝のデイリースクラムで「このスパイクに着手します」と宣言をし、夕方のデイリースクラムで成果を報告すれば良いのです。開発者個人としてもチームとしても、とても簡単にタイムマネジメントができるようになりました。
私たちはたまたまデイリースクラムを2回実施していたのでこれを利用しましたが、そうでないチームでも成果を全員で同期的に確認する時間をあらかじめ設定しておくと同じような効果を得られると思います。
どうなったのか
私たちのチームでは、紹介した3つの試みを記事執筆現在も継続しています。
これらの試みは私たちのチームにさまざまな好影響を与えてくれました。
スパイクがスプリント内で確実に DONE するようになった
まず最も大きく、直接的な効果としてはこれです。
「兎にも角にも、まずは DONE しよう。」を出発点としていたので当たり前ではあるのですが、これには多少の副作用もありました。
DONE するためにスパイクを分割することがあるため、スパイクをひとつ DONE したらスパイクが増えたということが発生します。これはスパイクという特性上どうしても避けようのない問題です。しかしその問題が可視化されるかされないか、という差はとても大きなものであると私たちは考えています。これは終わった、これは終わっていない、という情報がチケットとして可視化されることで、先の見通しを立てやすくなったと実感しています。
また、増えたスパイクは、ある未知を取り除いた上で発見した新たな未知であるためほとんどの場合その規模は小さくなっています。規模が小さくなればなるほど、未知であるとはいえ大雑把な見積もりができるようになり、スパイクの規模感をなんとなく把握できるようになっていきます。
確実に（半ば強引とも言える方法で）DONE させるという方法は、かなり効果的であったと言えます。
スパイクに限らずタスクを完了・分割するための会話が普段から活発になった
これは狙っていた効果ではないのですが、スパイクを DONE させる試みはチームに間接的な好影響も与えてくれました。
デイリースクラムでスパイクを DONE させるための会話をするということを継続した結果、スパイク以外のタスクもどのように DONE させるかという会話が自然と起きるようになったのです。あとどの作業が残っているか、新たに発見した問題はないか。別のチケットとして切り出したり、設計を再検討して仕切り直した方がいいのではないか。
ともすれば単なる個人進捗確認の場となりがちなデイリースクラムで、仕掛中のタスクを DONE させるためにどうするかを考え会話して計画するという、チームとして本来果たすべきことを果たしているように感じています。
また、デイリースクラムだけでなく、普段の会話や Slack 上でのやりとりでも、スパイクのゴールをより具体的にする案や分割の提案などが発生するようになりました。
スプリント中のさまざまなリスクを早期に発見するためのコミュニケーションがあらゆるシーンで活性化したというのは、私たちが今回の試みで獲得した非常に大きな力だと思っています。
最後に
私たちのチームは、これまでも多くの課題と向き合い、日々小さな改善を積み重ね、少しずつチームとして成長してきました。この記事ではその改善のひとつをご紹介しました。同じような課題を抱えている方々の一助となれば幸いです。
察しの良い方であればお気づきかもしれませんが、私たちは「チームではたらく」ということを大事にしています。私ひとりでは成し得ないこともチームであれば成し遂げることができます。あなたひとりでは成し得ないことも、チームであれば成し遂げられるでしょう。それと同時に、ひとりでは発生しないかもしれない問題が、チームに発生することもあります。これからも私たちはチームで多くのことを成し遂げ、多くの問題を解決していきます。ぜひ、あなたの力も貸してください。
