わたしたちがスクラムのスプリント期間を 1 週間にし、タスクを 1 時間以下の単位に分割するのはなぜか
こんにちは、開発部の野口です。
最近メイン DAW を Cakewalk SONAR から PreSonus Studio One に移行しようかどうか検討中です。(ニッチな話)
本記事は、Appresso Advent Calendar の 3 日目の記事です。
昨日の記事の最後に、スクラムマスターの土岐からバトンを受け取ったので、今日は「1 週間スプリントのプランニング」について書きます。
目次
はじめに
私は DataSpider Servista の次期バージョン開発チームで、開発者をやっています。
昨日の記事で紹介したように、3 ヶ月前からスクラムによる開発を行っていて、スプリント期間は 1 週間に設定しています。
スクラムによる開発を始めた経緯や、スクラムによる開発の様子については、ぜひ昨日の記事をご一読ください。
この記事では、「わたしたちがスクラムのスプリント期間を 1 週間にし、タスクを 1 時間以下の単位に分割するのはなぜか」について、その始まりから、実践、メリット、今後の課題についてお話ししていきます。
やる前に ― 与えられた状況と不安
「スプリント(イテレーション)期間を 1 週間にする!」という話を聞いて、「なるほど 1 週間か、いいね、それでいこう」とただちに思える開発者は、まだそれほど多くないと思います。
始めた頃の私たちもそうでした。
なにしろ、ほんの半年ほどまではこのようなプロセスで開発していたので、
「1 週間? いいネ、毎週デリバリーしてこ!」といきなり思えるほうがおかしい。
与えられた状況
本物のスクラムでプロジェクトを運用すると決めたとき、私たちが受け入れることにしたのは以下のような条件でした。
- スプリント(計画に始まり、機能を開発して、ふりかえりに終わる)期間を 1 週間にする
- スプリント計画では、すべてのタスクを 0.5h or 1.0h まで分解する
根拠は、昨日の記事でも何度か登場した、認定スクラムマスター研修講師の江端さんのおすすめです。
私も研修に参加したのですが、この話が出たときあまりのショックに思わず「マジでやるんですか」と聞いたら「やるんです」と言うので、「やるか」と思いました。
「でも、やるんだよ!―それが君のなすべきことなんだとしたらね」
――― Jonathan Rasmusson(『アジャイルサムライ』pp.287)
「1 週間だ。私を信じろ」
――― Ron Jeffries(『スクラム現場ガイド』pp.178)
「やるんです」
――― Kazumasa Ebata(某日某所 認定スクラムマスター研修会場にて)
そもそも、スプリント計画とは何か?
ところで、スプリント計画(Sprint Planning)とは何でしょうか。
Sprint Planning はスクラムフレームワークで定められたセレモニーの一つで、簡単にまとめると、以下のようなものです。
- 参加者はスクラムチーム全体(開発チーム、スクラムマスター、プロダクトオーナー)
- 優先順位付けされたプロダクトバックログから、今スプリントで開発する PBI(Product Backlog Item)を選び出す
- チームはタスクレベルでの計画を行い、最終的にスクラムチーム全体として計画へのコミットメントを行う
Sprint Planning によって、短期(スプリントレベル)の ROI を最適化します。
プロダクトオーナーによって最も必要とされている PBI が選び出され、チームは最大限の PBI を完成させられるように計画を行います。
成果物は、コミットメントです。
「完成できそう」「完成できるかもしれない」ではなく「完成させます」という「約束」です。当然ながら、「すみません、一日遅れます」もありえません。
予想ではなくコミットメントであるということは、スクラムの透明性を確保するために重要な部分だと思います。
できるのか
とは言ってみたものの、不安です。
1 週間以内の完成を約束する? そのためにタスクを 1 時間以下の単位に分割する?
どちらも、できそうなイメージが湧きません。
以下のような不安がいくらでも湧いてきます。
- 2 週間のイテレーションによる開発を既に始めてはいた……ものの、タスクの見積もり単位は 4h とか 8h とかだった。それをさらに 4 つ、8 つに分ける? 細かすぎませんか? 数が多すぎませんか?
- 計画した機能を期間内にすべて完了できたこともほとんどなかった。2 週間でも! なのに、さらにその半分の期間だって?
- 1 週間で「完了」させ続けるなんて、オーバーヘッドが大きすぎて何もできないのでは?
- 1h 以下に分割するには、メソッド単位の設計が必要になりそう。BDUF(事前の過剰な設計)を助長するのでは?
とにかく、やってみるしかありませんでした。
やっていく ― それから 3 ヶ月後のわたしたち
9 月前半にスクラムによる 1 週間単位の開発を始め、それから 3 ヶ月あまりが経ちました。
それがとてもうまくいっていることは、昨日の記事で紹介された通りです。
では、「1 週間のスプリント計画、タスクは 1 時間以下」という制約を、どのように克服したのでしょうか。
どうやっているのか
はじめに言っておくと、さまざまな紆余曲折を経ました。
スクラムでは毎スプリントの終わりに必ずふりかえり(Sprint Retrospective)を行い、開発チームとして、必ず何か一つ(以上)の改善アクションに合意します。
そうやって少しずつ改善してきました。
その経緯をくだくだしく説明することはしません。現在のやり方を、かいつまんで紹介します。
1. PBI ごとにチーム分け
1 時間未満に分割しようとすると、タスクの数は膨大になります。(たとえば、今スプリント = 今週のタスク数は付箋の数で 82 枚でした)
もちろん、そのために設計上の調査や議論も必要になります。
だから、私たちは、PBI をある程度(ストーリーポイント数から判断して、ほぼ確実にコミットできるだろうという数だけ)選択したあと、まずチームをいくつかに分けて、並列で見積を始めます。
最近は、1 スプリントでだいたい 4 つ~ 6 つ程度の PBI に取り組むという傾向です。
ただ、並列度を最大化するのではなく、だいたい 2 ~ 3 チームに分かれて見積もります。1 チームが平均 2 つの PBI を見積る計算になります。
2. DEV メンバと QA メンバでそれぞれ計画
これは課題でもあるのですが、チームには開発部のメンバー(DEV メンバ)と品質管理部のメンバー(QA メンバ)が混在しており、スキルセットがかなり異なります。
この図を見れば、その背景をわかっていただけるかと思います。
▲前バージョンまでの開発体制。「開発チーム」と「QA チーム」は部レベルで異なる(開発部と品質管理部。もちろん上司も違う)
そのため、(残念ながら)計画においても、実行においても、DEV タスクか QA タスクかによって担当者が限られます。
よって、DEV メンバと QA メンバはそれぞれでタスクの見積りを行っています。
前項の「PBI ごとに分かれる」ことと組み合わせると、結局、スプリント計画中に最大で 4~ 5 グループ程度に分かれて調査・見積を行っています。
3. 「チェックポイント」を設ける
DEV / QA のスキルセットが大きく異なるという背景もあり、「プログラマが実装してから、テスターが手動テストをする」というモデルが残っています。*1
しかし、「すべての開発が終わってからテストを始める」のでは、とても 1 週間では完了できません。
だから、「チェックポイント」を設けて、計画中に「ここまでできたら、ここまでテストできる」ということを取り決めます。
この取り決めは、分かれたグループごとに DEV / QA で集まって行っておき、のちにチーム全体でレビューします。
4. タスクに分ける
さて、いよいよタスク分割です。
当然ですが、計画では、実際のコードを見ます。
ときには少しだけコードを書いてみて、動作を確かめたりもします。
設計上の議論もしますが、UML のような成果物は原則として残しません。議論したことを覚えていれば十分だからです。一週間なら、覚えていられます。
量が多く、覚えていられなそうなときには、試しに書いたコード辺のスクリーンショットを撮ったり、クラス名をメモしたりします。
どれくらいメモするかということは経験による感覚なので、一概には説明できません。
ある程度設計が見えてきたら、タスクを作っていきます。
基本的には作業の順に上からタスク化していき、1 時間以内におさまるものはそのままタスクに、1 時間でできなそうな作業は、どうすれば分割できるか考え、分割して、1 時間以下のタスクの集まりにします。
私は DEV メンバなので、残念ながら QA メンバのタスク分割に参加したことはありません。(本当に残念です……)
現在は、テスト項目の大まかなリストを作っていて、1 時間以内の単位で区切ってタスクとしているようです。
5. QA 観点チェックとフィードバック
前述のように、QA メンバはテスト項目の大まかなリストを作ります。
テスト専門家のリストなので、DEV メンバが想定するものよりも、より広範で緻密な観点になっていることが往々にしてあります。
だから、そのテスト項目リスト(「QA 観点」と呼ばれています)を DEV メンバはレビューし、設計上の考慮漏れや自動化テストの不足を補います。
また、時には実装上リスクの高い箇所のテストが案外手薄なこともあり、その場合は QA メンバにフィードバックします。
6. チーム混ざってレビュー
計画もいよいよ大詰めです!
チェックポイントを定め、すべての作業を 0.5h または 1h のタスクに分割し、DEV / QA 間のフィードバックも行いました。
はじめにグループを分けて計画を始めましたが、1 週間で確実に機能を届けるために、すべてのメンバが、任意のタイミングで、任意のタスクを実行できることが目標です。
だから、できあがったタスクリストを、皆で集まってレビューします。そして、タスクに不明瞭な点(「このタスクは何だ? 私はこのタスクを正しく実行できそうにない」)があれば、質問します。
結果として、計画がより洗練され、実際のところ、誰でも任意のタスクを実行できる状態になります。
わかりやすい指標を上げると、1 つの PBI(→1 件の Pull Request になる)には、だいたい 2 ~ 3 名のコミットが含まれます。
もちろん、2 ~ 3 名を予めアサインしているのではなく、日々の状況に応じて各自が最適なタスクを取った結果、2 ~ 3 名が 1 つの PBI に関わることになります。
ただし残念なのは、このプロセスも基本的には DEV と QA で分かれて行っていることです。
7. 調整&コミットメント!
こうやって、1 週間で実行する、数十(今スプリントでは、82)のタスクができあがります。
タスクの見積を合計し、今スプリントの稼働時間と比較します。この際は、これまでの実測データに基づくバッファ率を掛けてから比較します。
見積が稼働時間を下回っていたら、PO に新しい PBI を選んでもらいます。(もちろん、収まりそうなサイズのものにします)
あまりありませんが、見積が稼働時間を上回っていたら、泣く泣く PBI を一つ諦めます。*2
開発チームとプロダクトオーナーが共に計画に満足したら、スクラムチーム全体としてコミットメントします。
閑話 : 紆余曲折について
私たちは、さまざまな紆余曲折を経て、今このプロセスで計画を行っています。
そして、これからもプロセスを変えていくでしょう。
スクラムにおいて、いやスクラムではなくても、チーム活動において、難しい課題に際して、チームとして紆余曲折を経ることは、おそらく必要です。
「うまいやり方」はあるでしょう。
しかし、それを読んだり聞いたりして、そのまま真似しても、うまくいかないと思います。「そのチームのやり方」になっていないからです。
結論が同じだとしても、チームとして紆余曲折を経て得た解決策は機能し、ただ輸入しただけの解決策は不完全にしか機能しません。
不思議ですが、それが人間の集まりというものなのだと思います。
こんなに苦労して、なにが嬉しいのか
▲スプリント中のスプリントバックログの様子。真ん中の「P O」は「この PBI の開発完了したのでプロダクトオーナーは動作を確認してね」という意味です
閑話休題。
ようやく「なぜか」の話にたどり着きました。
わたしたちがスクラムのスプリント期間を 1 週間にし、タスクを 1 時間以下の単位に分割するのはなぜか。
実際にそのやり方で 3 ヶ月やってみて、以下のようなメリットを感じています。
非常に正確に予測し、コミットメントができるようになった
計画した機能を期間内にすべて完了できたこともほとんどなかった。2 週間でも! なのに、さらにその半分の期間だって?
1 週間スプリントを始める前に感じていた不安の一つです。
結果はどうだったでしょうか?
スプリント期間を 1 週間にして最初のスプリントでは、完了できた PBI は 1 件でした。
わはは。
誰だって、始めたばかりの頃は下手クソでした。開発チームも、プロダクトオーナーも、(結果が直接見えないのでわかりませんが、たぶん)スクラムマスターも。
でも 3 ヶ月たった今、コミットメントした PBI をほぼ確実に届けることができています。*3
なぜかベロシティも上がった
1 週間で「完了」させ続けるなんて、オーバーヘッドが大きすぎて何もできないのでは?
これもまた、不安の一つでした。
結果はというと、以下の通りです。
- 2 週間スプリント期の平均ベロシティ : 5.4(※1 スプリントあたりに換算)
- 1 週間スプリント期の平均ベロシティ : 8.65
ベロシティ = スループットが、60% 向上しました。
不思議ですが、これが結果です。
でも、まだまだ、まだまだです。
これからもっと上げていきます。
より集中できるようになった
ベロシティが上がった理由の一つとして、「より集中できるようになった」ことが挙げられると思います。
開発者として、かつては、「仕様・設計・実装を同時に(並行で)考える」ことを日常的にしていました。
しかし、1 週間スプリント・1 時間以下のタスク分割を実践するようになった今、それが大きなストレスだったことがよくわかります。
美しい仕様と美しい実装は、しばしば対立します。そのため、実装中に(不確定な)仕様のことを考えるのは大きなストレスになります。(「ユーザにとってはこちらの方がいいはずだ。しかし、実装は難しい。設計レベルの変更が必要だ。待てよ、本当にユーザにとってはこちらのほうがいいのだろうか? いや、しかし……PO に相談しようか? でも、実現可能性がわかってからの方がいいよな……」)
スプリント計画でタスクを 1 時間以下に分割すると、仕様上の懸念点は計画中にほぼ一掃されます。
そのため、軽快に実装を進めることができます。
たのしい!
軽快に実装を進めることは、たのしいです。
悩むのが好きな人もいるでしょう。私もそうです。
人口上位 5% には入る自信があります。
しかし、1 時間以内のタスクを軽快に消化していくたのしさには、なかなか代えがたいものがあります。
毎日会社に行くのが楽しみになります。
苦しくない
魔法はありません。
軽快に実装を進めるのがたのしいということは、そのための準備が決して楽なものではないということです。
タスクを 1 時間以下に分割する作業は、楽ではありません。
しかし、ここがスクラムのいいところで、それを一人で行う必要はありません。
スプリント計画は、セレモニーです。チーム全体で行います。
苦しいのは自分だけではない。そのことが、計画の苦しみを軽減させます。
実際のところ、苦しいというほどのものではなくて、課題の厳しさを感じることもありますが、それもまた楽しいものです。
BDUF ではない
1h 以下に分割するには、メソッド単位の設計が必要になりそう。BDUF(事前の過剰な設計)を助長するのでは?
最後に、この不安について。
まず、メソッド単位の設計は、時には必要です。
○○クラスに○○メソッドを追加する、みたいなタスク、ちょいちょい出てきます。
でも、ものによってはそれほどでもありません。
たとえば、「プロジェクト名、スクリプト名、○○、○○を保持するモデルクラスを作る」みたいな書き方になっていたりもします。これで十分小さく、またチーム全員に通じるからです。
そして何より、Big ではありません。
たかだか 1 週間分の計画です。1 週間分の作業を 1 時間以下の単位で設計しても、BDUF(Big Design UpFront)とは言えない、というのが率直な実感です。
BDUF の問題点は、のちの要求変更などによって、多くの事前設計、事前作業が無駄になることです。
1 週間分の PBI、それも優秀なプロダクトオーナーによってよく書かれた PBI であれば、そのために行った作業が無駄になることはまずありません。
もちろん、「モデルクラスを作る」の例に見られるように、不要な詳細までは設計しません。
「ここは実装者におまかせでいいよね」というのが計画中の頻出フレーズとなっています。
課題
1 週間スプリントの計画について、その端緒から、実践、メリットについて書いてきました。
現状の課題についても、簡単に記しておきます。
計画に時間がかかる
現状、計画にはだいたい 6 ~ 7 時間くらいを費やしています。
ほぼまる 1 日です。
スプリントが 1 週間なので、実に全体の 20% です。
それでもやる価値は(間違いなく)あると感じていますが、一方で、(生み出す計画の価値を落とさずに)これを短縮できたら、確実にベロシティが向上します。(開発に使える時間が増えるわけなので)
だから、計画をより素早く終えることが一つの大きな課題となっています。*4
DEV と QA が分かれている
これまでに何度も言及したように、私たちのチームには、DEV と QA という 2 つの役割があります。
QA メンバは、「DEV のタスク」を決して実行しません。(DEV メンバは、稀に「QA のタスク」を実行することがあります)
本物の職能横断型チームを目指して、少しずつ、徐々にであっても、これをならしていく必要があります。
個人的には、飛躍的なベロシティ向上の鍵がここにあるのではと踏んでいます。
おわりに
書かなかったこと
この記事では、書かなかったこと(字数の都合上、書けなかったこと)がいくつかあります。
- 予め計画するタスクと、計画できない(計画時点では特定できない)追加タスクについて
- スプリントバックログの運用について
- ペアプログラミングの活用とその効果について
- チーム内でのスキルのバラツキについて
- 稼働時間の算出について
- そもそも、プロダクトオーナーは 1 週間に収まる PBI をどうやって書くのか
こういったことについては、今後書いていけたらと思います。
反論がないはずがない
「わたしたちがスクラムのスプリント期間を 1 週間にし、タスクを 1 時間以下の単位に分割するのはなぜか」について書いてきましたが、「いやいや、その理屈はおかしい」「馬鹿げている」という反論はきっとあるものと思います。
実践する前の私なら、間違いなく反論しています。
その反論の多くは単なる思い込みの可能性が高いと思いますが、中には、たぶん当たっているものもあります。
実際、世の中には向いていない人はいるでしょう。その中にはスーパーエンジニアもいるかもしれません。向いていないプロダクトというのもあるのかもしれません。
しかし、試してみる価値はあります。
このやり方に向いていないスーパーエンジニアを抱えて開発していくほうが、すぐれたプロダクトができるかもしれません。
このやり方に向いていないスーパーエンジニアと(残念ながら)別れ、このやり方に舵を切ったほうが、すぐれたプロダクトができるかもしれません。
どちらの可能性もあります。
プロダクトの性質、市場の性質、規模、メンバの性質、さまざまなものが要因として考えられます。
もちろん、組織内で方法論を併用し、共存していく方法もあるでしょう。
これが一番いいかもしれません。
スクラム実践上のおすすめ
もしこれをやってみようと思ったら、この記事や本だけを読んで試してみるよりは、決して安くはありませんが、Odd-e Japan の認定スクラムマスター研修を受講されることをおすすめします。
スクラムは人の問題を扱っていて、人の問題を文字情報だけから理解するのはなかなか難しいからです。
Jim Coplien や Joe Justice といった外タレが来日して行う研修も行われているようですが、個人的には江端さんの研修をおすすめします。
*1:もちろん自動テストは書いていますし、CI も行っていますが、アプリケーションレベルのテストの多くを手動でも行っています
*2:なお、1 時間や 2 時間程度の超過なら、多少の残業を覚悟してコミットすることもなくはないです
*3:ほぼです。まだ、たまに失敗します……
*4:なお、Scrum Guide には、スプリント計画は 1 ヶ月スプリントの場合で最大 8 時間、と書いています。これを演繹すると、1 週間スプリントであれば 2 時間で計画を終えなければならないことになります。よって、私たちは(この点に関しては)スクラムフレームワークにのっとっていないことになるのかもしれません。しかし、「それでもやるべし」と言ってくれた江端さんの言葉を信じて実践し、今のところこの方向は正しいと感じています。もしかしたら遠くない将来、この「2 時間」を意識する日が来るのかもしれません。