スクラムのスプリントプランニングでは、スプリント中にやる作業(タスク)を出して、スプリントの計画づくりをします。ここでのタスクの出し方が、スプリントが順調に進むか左右します。こんな問題が起きたことはないでしょうか。

タスクがいつまでも終わらない
途中でタスクが大量に発生してスプリントに収まらなくなる
書いてあるタスクが何のことかわからなくなる

スプリントがうまくいくタスクの出し方のヒントを「設計しよう」「さくせん」「1つの頭脳」という切り口で紹介します。

設計しよう

タスク出しとは、やることを漫然とリストアップする作業ではありません。「設計する」「実装する」「テストする」などのタスクを出しても、あまり役に立ちません。タスクに着手する人にとってクリアになっていなければ、意味がない。何をすればいいのか、どこまでやればいいのか、いつ完了するのか。

そうしたタスクを出すには、スプリントで実現するものをプランニングで設計します。ページの構成や要素、変更するAPI、モジュールやクラス、メソッド、あるいは設定やスクリプトといったレベルで「何を作る・直す」のか考えましょう。プロダクトは小さなブロックの積み重ねです。タスクは、小さなブロックを積む小さな計画です。どこにどんなブロックを積むのか、見通しがたってはじめて、計画も考えられます。

タスクの達成条件を決めよう
- あるタスクは、別のタスクの前提となります。どこまでできていれば完了とみなすのか、考えましょう。
タスクは具体的に「何をどうする」と書こう
- 設計をすると、作ったり直したりするものに名前を付けられます。タスクの対象の名前がわかるようにしましょう。
なにをどうデモするかというゴールから、タスクを逆算しよう
- 実現方法の設計から始めると、リリースに必要なものを見落としやすくなります。スプリントレビューでどんなデモをするか考え、必要になるものはすべてタスクで網羅しましょう。

さくせん

短い期間を全速力で駆け抜ける、これがスプリント(sprint = 短距離走)です。全力でダッシュしているときに、角を曲がったり、立ち止まって考えたりする余裕はありません。スプリントプランニングとは、スプリントでやることを洗い出すだけではなく、どんな順序、タイミング、役割分担でこなすか作戦を立てる場です。立てた作戦、イコール計画です。

タスクの並列性と依存関係を確認しよう
- チームの人数が増えると、タスクの依存関係や前後関係のせいで待ちが発生しやすくなります。並行して進められるもの、先にやっておかないといけないものを確認ましょう。
タスクは小さく、見積もらず、全体がスプリントに収まるか検討しよう
- タスクが大きいと曖昧になりやすく、問題があっても発見が遅れがちになります。個々のタスクは小さくしておきます。十分に小さくなっていれば、個別の見積もりをしなくても、全体がスプリントに収まりそうか「腹具合」で判断できるようになります。
途中で予想外のタスクが発生すると予想する
- タスク出しをいくら綿密にやっても、スプリントをはじめれば予想外のことが起きます。計画には調整の余地を含みましょう(ただしバッファを積んではいけません)。計画を綿密にやりすぎると、ちょっとでも想定が外れたら破綻してしまいます。
ボトルネックに気をつける
- タスクの中には、特定のメンバーしかできないものや、チーム外に依頼するもの、一定の時間がかかるものなどがあります。そうしたボトルネックは先に見つけておいて、問題にならないように計画しましょう。

1つの頭脳

ソフトウェア開発はチームスポーツです¹。とりわけ頭脳が、チーム全体の能力を決定づけます。チーム全体が1つの頭脳として考えられるよう、情報や認識や理解を一致させておきたくなります。プランニングとタスク出しはチーム全体で知識を共有し、判断を一致させる素晴らしい機会です。

みんなで設計し、作戦を立てる
- 設計の議論や判断はチーム全体の作業です。ここで知識の差を埋め、判断基準をそろえておけば、スプリント中の行き違いや不要な議論を避けやすくなります。作戦も同様で、進め方のイメージを全員が持っていれば、ムダを減らせます。
開発だけでなく、暗黙のこと、あたりまえの作業もぜんぶ出そう
- チームメンバーにはそれぞれ得意分野や経験があります。ある人があたりまえと思っている作業も、わかっていない人がいるかもしれません。作業や進め方について対話しながら、すべてタスクとして出しておきましょう。出したタスクをお互いにレビューするのもいいです。
事前アサインはしない。でも誰がやるとよいか見当はつける
- 誰がどのタスクをやるとベストか考えると、よりよい作戦が立てられます。ただし、実際に担当を決めるのは、スプリント中の着手する時点にしましょう。予想外のことが起きたら、ベストの担当も変わります(たとえばインフルエンザ)。そなえとして、全員がタスクの概要をつかんでおきます。

ふりかえり (レトロスペクティブ)

スクラムかどうかを問わず、多くのチームがふりかえり(レトロスペクティブ)を定期的にやっています。タスク出しのやり方そのものも、ふりかえりで扱うべき大事なテーマになります。見落としを防ぐには？プランニングの時間を短縮できないか？タスクの書き方のいいアイデアは？タスクボード(スプリントバックログ)は改善できる？もっと上手くやるには？

タスクの出し方、粒度、内容、書きぶり、整理の仕方などはすべて、チームで洗練させていき、チームの能力を向上させるポイントのひとつです。チームごとの特色が出るところでもあります。ふりかえりを積み重ねて、チーム独自の優れたやり方を編み出してください。

まとめ

設計しよう
- タスクの達成条件を決めよう
- タスクは具体的に「何をどうする」と書こう
- なにをどうデモするかというゴールから、タスクを逆算しよう
さくせん
- タスクの並列性と依存関係を確認しよう
- タスクは小さく、見積もらず、全体がスプリントに収まるか検討しよう
- 途中で予想外のタスクが発生すると予想する
- ボトルネックに気をつける
1つの頭脳
- みんなで設計し、作戦を立てる
- 開発だけでなく、暗黙のこと、あたりまえの作業もぜんぶ出そう
- 事前アサインはしない。でも誰がやるとよいか見当はつける
ふりかえりで改善しよう

『Team Geek』Brian W. Fitzpatrick、Ben Collins-Sussman、角征典 ↩