Appresso Engineer Blog

アプレッソのエンジニアが書く技術ブログです。

「1週間ずつ製品を作る」のが最強である説 ~スプリントを「1週間」でガチでやってみた結果

アプレッソ開発部の土岐です。最近メインDAWをAbleton LiveからPresonus Studio Oneに移行中です(ニッチな話)。

というわけでAppresso Advent Calendarの2日目! ということで今回は「スプリント1週間」について書きます。

qiita.com

はじめに

DataSpider Servistaなどのデータ連携製品を開発する弊社アプレッソ。開発部では最近、スクラム・アジャイルを取り入れた開発にチャレンジしています。

特に今年夏以降は、ガチで「スクラム」というものをやってみようという、ということで現在DataSpiderの次バージョン開発は、完全にプロセスも体制も含めて「スクラム」でやっています。

その中でいろいろな気付きがありました。書きたいことは様々あるのですが、特に「スプリント/イテレーションを1週間でやる!」=「1週間ずつ製品を開発する」という試みは、チームに予想以上の良い衝撃を与えた模様です。

  • 自然なリズムの中で素早く開発できる
  • 問題が早く見つかって解決が速くできる
  • 集中すべきことに集中できて無駄な作業が無くなる
  • 短いサイクルで改善し続けることができる

チームからはこのような声が上がっています。

「イテレーション/スプリントを導入する」ことによるメリットは様々な形で語られていますが、「その期間はどのくらいが最適か?」というのはあまり情報が多くなく、チームにとって悩みどころです。

我々のチームはイテレーション/スプリントを「無し」→「2週間」→「1週間」という3段階で経験して、

スプリント1週間が最強である

ということを深く確信した次第であります。

ということで、今回の記事では、この「1週間スプリント」にフォーカスして書こうと思います!

(※) このタイムボックスを一般的なアジャイル開発では「イテレーション」、スクラムでは「スプリント」と呼びます。2週間で行っているときはスクラムではなかったので本当は「スプリント」では無いのですが、混在している分かりにくいので以下は便宜上このタイムボックスを「スプリント」と統一します。

スクラムを「1週間スプリント」をガチでやり始めた経緯

ということで、まず「1週間スプリント」に至った経緯について簡単に書こうと思います。

もともと開発部では、開発フェーズ・テストフェーズが完全に分かれていました。各個人が基本的に自分の裁量で仕様策定・開発を行い、開発フェーズが終わったらテストフェーズに入りテストを行うという形です。

f:id:tokita93:20161201165659p:plain ▲従来の開発イメージ図。開発フェーズ・テストフェーズが完全に分割されている

厳格なウォーターフォールほどフェーズが分割されているわけではありませんが、開発フェーズ・テストフェーズは完全に分かれていて「緩やかなウォーターフォール」といった趣でした。

これ自体はさまざまな経緯があってこの形になったんですが、製品規模が拡大するについてこのやり方での問題が明らかになり、「アジャイル開発」を模索し始めることに。この辺りの経緯は以前本ブログに書いたりしました。

appresso.hatenablog.com

で! 導入したのが「スプリントを2週間でやる」というもの。「必ずスプリントが終わったときにテストが完了したリリース可能な製品を作ること」というルールで、開発とテストが協働して製品を開発する「タイムボックス」での開発がスタートしました。

f:id:tokita93:20161201170736p:plain ▲スクラム導入後。QAと開発は同じチームとして協働で作業をし、スプリント中にリリース可能なプロダクトを作る

このタイムボックス内での開発は、これまでと異なり「チーム」として短期的にリリース可能な製品を作り上げていくということで、さまざまなメリットがありました。 例えば、

  • チームの生産性(ベロシティ)が判明するので、リリース時期までに対応可能な範囲(スコープ)が予測しやすくなる
  • 開発してすぐにテストされるため、早期に問題が発生されて修正が早くなる
  • リリース可能な製品が常にあるため、動きを見せてフィードバックを得る機会が早くなり製品に取り組める

などが挙げられます。

で! さらに「もっと良いやり方は無いか?」と模索する中で、自分がScrum Alliance認定スクラムマスター研修を受講。「スクラム」について刺激的に学ぶ中で、強烈だったのが講師の江端一将氏のこの言葉。

スプリントは「1週間」です! ルール上は1~4週間ですが、私は「1週間」以外無い、と思っています。 世界の生産性の高いチームは「1週間」でやっています。貴方のチームがそういうチームと闘いたいのならば、「1週間」を導入すべきです。

本来はプロジェクト中にスプリントの期間を変更することは厳禁なのですが、どうしても「スクラムをやりたい! しかも1週間スプリントで!」ということでスクラム開発を開始したのが2016年9月。それから3ヶ月だったのが現在、というわけです。

www.instagram.com ▲壁に貼られたスクラム概要。この1週間のループの中でさまざまなセレモニー(MTG)をしながら1週間を駆け抜ける

江端氏はこうも言っていました。

このやり方でとりあえず3ヶ月やってみてください。そうするとその良さが実感できますよ。

ということで、3ヶ月経過した現在。どうなったかと言うと・・・。

良いリズムができて「製品(プロダクト)と踊(ダンス)っちまったんだよ・・・」

↑という見出しは個人的に書きたかっただけだったりしますが(元ネタ)、実際にやってみた結果、一番大きなメリットとして痛感するのが

「良いリズムが出来る!」

ということです。

メンバーからもその感想は多く出て、それはスクラムマスターとしてやっている自分も凄く実感します。

もともと「2週間」でスプリントをやっていたときもある程度リズムは出来ていてそのメリットは理解できていたのですが、「1週間」でやってみるとさらにそのリズムが身体に馴染むような気がしています。

具体的に1週間のメリットとして、「常に良い緊張感を持って開発できる」「しっかりと計画して取り組める」「タスクの優先順位が把握しやすい」ということが上げられると思います。実際に2週間と1週間のイテレーションを比較すると。以下のような感じです。

項目 2週間 1週間
緊張感 終了までの期間が長いので1週目はゆるい。2週目に入って徐々に緊張感が出る 常に終了までの時間が見通せるので、緊張感を持って取り組める
計画性 2週間でやれることなどで「できそう」というイメージで粗めの計画を行う。結果、予想外のタスク増加が多く成果が予想よりもぶれやすい 1週間で出来ることを0.5時間~1時間単位に分割して「できる!」となるまで細かく計画する。そのため予想よりもぶれにくくなる
優先順位 営業日の「10日」の中で、今日どのタスクを消化すれば良いのか把握しにくい 営業日が「5日」しかないので(実際は計画の日を除くとほぼ4日)、今日やるべきタスクがより明確になる

f:id:tokita93:20161201172615p:plain ▲2週間スプリントと1週間スプリントの違いのイメージ図。1週間だと終了までの見通しがはっきりしているため、緊張感を常に保ちつつ優先度を明確にしてタスクに取り組める

 なぜ「1週間」だとより良いリズムが出来やすいのか?

なぜ「2週間」と「1週間」でこのような感覚の違いが出るのか? あくまで自分の考察なのですが、大きく以下の3つの理由ではないかと思っています。

  1. そもそも人は「1週間単位」で時間を考えるのに慣れ親しんでいる
  2. ワーキングメモリに保持できる「7±2」個の日数を単位にするので脳内で処理しやすい
  3. 「(1+ 2) + 2 + (2)」のリズムが生活に馴染みやすい

それぞれについて以下に説明します。

  1. そもそも人は「1週間単位」で時間を考えるのに慣れ親しんでいる

我々現代人は、小さい頃から「1週間単位」で生活を行っています。そして物事を考えるときもこの単位を基本セットとして考えていると思います。 今日が金曜日だとして、

「先週の金曜日」何やりましたか?

と聞かれると、だいたい思い出せると思いますが、

「先々週の金曜日」何やりましたか?

と聞かれるとどうでしょう。より昔なので曖昧になるのは当たり前とはいえ、その期間以上に数十倍記憶が曖昧になると思います。

逆に未来で言うと、

「来週の金曜日」に何をやりますか?

「再来週の金曜日」に何をやりますか?

というのは、来週の方が数十倍イメージしやすいと思います。この生活の単位と「製品を作る」という単位を一致させることで、「このスプリント中での働き方」というのがものすごく具体的なイメージで作ることができるのではないか、と思います。

  1. ワーキングメモリに保持できる「7±2」個の日数を単位にするので脳内で処理しやすい

「人間のワーキングメモリに保持できる情報は7±2個」ということが認知心理学の研究で実証されています。

ワーキングメモリ - Wikipedia

この「7±2」というマジカルナンバーは、スクラムでは「チームの基本人数のルール」として使われたりしています。

「2週間」は営業日数「10日」になりますが、この日数はこのワーキングメモリから溢れています。そのため、それぞれの日でどのような動きをするか、というのを脳内でイメージするのは人間の認知能力の限界を超えていることになります。「1週間」の「5日間」はワーキングメモリ内で収まる日数であり、この「5日間」をどのように働いていくか、というイメージが脳内でしやすい、ということがあるのでは、と思います。

  1. 「(1+ 2) + 2 + (2)」のリズムが生活に馴染みやすい

何のこっちゃ、って感じだと思いますが、このリズムは重要です!

我々は「水曜スプリントスタート、火曜スプリント終了」というようにスプリントを組んでます。 これに従ってスプリントをこなすと、スプリント以下のような流れになります。

計画 実行 実行 休み 休み 実行 実行・レビュー&振り返り

1日を計画の日とし、2日実行して週末休み、そして残りの2日を頑張って終了、というサイクルになります。ちょうど実行の半分のところで休みがあるので、一旦休んだ後に残りを頑張ろう、という気になります。

また、月曜の朝がちょうど半分のところになるので、この日の朝会(我々のチームは9:45からやっています。スクラムでは「デイリー・スクラム」と呼びます)は「作戦会議」と位置づけています。ここでは、

  • このスプリントはこのまま進んで完了できるか?
  • 今の作業を止めて注力すべきタスクは無いか?
  • 優先度の高いアイテムに注力すべきなのではないか?

などを検討します。これは週末にリフレッシュして頭をスッキリさせた後で話すのにちょうど良いタイミングで、休み明けに頭を起動させていくのと共に非常に良い機会になっています。

この流れはとてもスプリントのリズムに良い影響を与えているように思います。

ちなみに唐突ですが、上記のサイクルを太鼓にしてみましょう。

f:id:tokita93:20161201172950j:plain

ドン・ドン・ドン・<休>・ドン・ドドン

こ、これは・・・我々はよく似たリズムを知っている・・・・!

ドン・ドン・ドン・<休>・ドドン・ドドン

日本古来に伝わる音頭のリズムだ! このリズムがつまり、製品(プロダクト)を踊(ダンス)させちまうのでは・・・

なんてことは無いと思います。

こういう思い付きで胡散臭いことを言う人に惑わされないように注意していきたいですね。

改善の機会が倍増し、改善アクションが試行錯誤できる!

話を戻します! 他のメリットとして、「ふりかえり・改善が素早くできる!」ということがあります。

2週間スプリント期でも「ふりかえり」という形でKPTを行い、スプリントを振り返って改善を繰り返していました。これも「1週間スプリント」により効果的な改善ができるようになった感じます。

その理由として、まず「ふりかえりの機会が2倍になった」ということが大きくあります。1週間動いてみてはふりかえることで、短い単位で軌道修正してプロジェクトを進めることができます。

また、先ほどの考察にもあったように「ふりかえるときに記憶が鮮明」ということも大きなメリットです。「2週間前にあったこと」は既に記憶が薄れかけているのですが、「1週間前」だと鮮明です(実際やってみると「1週間前」であっても忘れていたりということがよく起きる!)。この記憶が鮮明な状態でふりかえることで、より良いアクションを導くことができるように思います。

スクラムを実施するにあたってふりかえりの形式を変えたことも、良い影響を及ぼしているように思います。スクラムにおける「ふりかえり」は「スプリント・レトロスペクティブ」という名前でのMTGになるのですが、これのルールとして「次スプリントで生産性を改善するための具体的なアクションを1つ以上必ず決める」ということがあります。

www.instagram.com

▲スプリント・レトロスペクティブで次のスプリントで取るアクションについて検討中

このアクションは多少大胆であっても「とりあえず1週間改善案を試してみようぜ!」という感じで臆することなく気軽にアクションを試すことができます。2週間だと失敗したときの影響が大きいのですが、1週間だったら「試してみてダメだったらやめよう!」という感じで気軽に人体実験感覚で試すことができます。このアクションの取りやすさも「1週間」だからこそ、と感じます。

「1週間で製品を作る」ためにやったこと

ということでいろいろメリットはあるんですが、実際のところ「1週間」というのはその決定的な「短さ」故の大変さがあります。事実、我々のスクラムチームでやろうとしたときも「本当に可能なのか?」という疑問も当初はありました。

認定スクラムマスター研修で江端さんが研修の最初に強調していたことがあります。

スクラムをやることによって「生産性を4倍にする」などと謳う本もありますが、絶対にそんなことはありません。 もし生産性が4倍になるとしたら、チームが頑張ることによってのみ可能です。スクラムはそれを支援するフレームワークです。

ということで、我々のチームもこの短いスパンで製品を作り上げるため、プロダクトオーナー・スクラムマスター・チームのそれぞれが知恵を工夫を持ち寄って頑張っています。

具体的には、我々のスクラムチームでは以下のようなことを行って1週間のスプリントを行っています。

  • プロダクトオーナーはプロダクトバックログのアイテムをできるだけ小さくしスプリントに収まるようにする。また受け入れ条件を明確にしてスプリント中の相談コストを低減させる
  • チームはスプリントプランニングでタスクを1時間か30分まで細分化し、計画をより正確にする
  • チームは開発・テストの流れをできるだけスムーズにするようにアイテムをテスト可能な単位にさらに分割して(「チェックポイント」と呼んでいます)、テスト開始までの時間を最低限にする
  • スクラムマスターはCIによるビルド自動化やSlack通知などのシステムをメンテし、フローの無駄を省く。またスプリントのデータを可能な限り収集・見える化し、改善のきっかけを探す

などさまざまな方策を行っています。 (上記の1つ1つの項目はいろいろ掘り下げがいのあるテーマなので、別途取り上げたいと思います)

www.instagram.com

▲スプリントプランニング中の1コマ。ストーリーのタスク分解を徹底的にやっています。

これらのことをやり遂げて1週間のスプリントをこなす我々のチームを私は誇りに思います。と同時にまだまだ満足はできません。プロダクトオーナー・チームとスクラムマスターで協力しあい「スクラム」を組んで、さらに向上を目指したいと考える所存です。

で、結局スプリントの期間は何週間が良いの?

いろいろ書いてきましたが、しかしこれは我々のチームの話。結局のところそのチームでの「最強」の方法はそのチームで探すしかないわけであります。

その探索の一助としてスプリント期間を決めることについて参考になる書籍があるので紹介します。『スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-』です。

https://www.amazon.co.jp/dp/B01D4JHITO/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

この第6章に「スプリントの長さを決める」というズバリな章があります。

どんなチームにもピッタリ合う魔法のようなスプリントの長さはない。

という言葉から始まるこの章では、具体的なスプリントの長さの検討例から始まって、長さを決定する際に考慮する要素について解説しているのでとても役に立ちます。

特に最後の章では「スプリントの長さ決めクイズ」として、以下のような質問をしています。

プロジェクトの期間は?

顧客やステークスホルダーはフィードバックやアドバイスをどの程度できるか?

スクラムチームの技術的なスキルはどれくらいか?

これらの答えによって、最適な長さが点数で分かる一覧表があります。悩んでる方は試してみると参考になると思います。(ただし著者も「賢く使うこと」と注釈を付けている通り、これも絶対ではありません。

また、第12章「ストーリーやタスクを分割する」は「なぜスプリントは短い方が良いのか?」ということを分かりやすく説明しています。

この中の具体例で、「4週間のスプリント」でストーリーを完了させることができないスクラムチームが出てきます。「スプリントを5週間にすれば終わるんだけど、そうすべきか?」と悩むスクラムマスターに対して、XP(Extream Programming」の提唱者の一人でもあるロン・ジェフリーズはこうアドバイスします。

「スプリントを短くした方がいいよ」ロンは素っ気なく言った。 チーム一堂ぽかんとなったのに、ロンも気づいたと思う。

「聞き間違えか」と戸惑うチームにロンは、「なぜ短い方がいいのか」を具体的に説明します。その結果

「1週間だ。私を信じろ」

と1週間のスプリントへのチャレンジを促します。この辺の理由の詳細は面白く、かつ納得がいく話なのでぜひ本著で読んでみてください。「やっぱり一週間スプリントが最強だ!」と合点いくと思います。その他、ストーリーの分割方法や分割の指標についても参考になる情報が書いています。

終わりに

ということで「スプリント1週間」についていろいろと書いてきました。この「1週間スプリント」をやり始めてチームから

楽しい!

という声が上がることが多く、それが「最強」である最大の理由だなぁと思うところです。

恐らくアジャイル・スクラム開発に取り組んでるチームはこの「スプリントの長さ」についてはいろいろ意見を持っていると思います。我々のチームでの経験から考察してきましたが、ぜひ機会あればご意見をぶつけさせていただければと思います。

実は今回はテーマがぶれてしまうので詳細は書かなかったのですが、「スプリント計画時、タスクを30分~1時間まで徹底的に分解して見積りを行う」ということはこの「1週間スプリント」を構成する最重要要素だったりします。このスプリント計画(スプリント・プランニング)については、「チーム」の立場から開発部の野口が明日のAdvent Calendarで書いてくれるはず・・・! ですので、バトンを渡してこの記事を終わります。

楽しくより良い製品を素早く作っていきましょう!