スクラム開発をボトムアップで始める (2) 〜 Sprint Planningで計測可能な計画を作る〜

こんにちは「むらたん」です。不定期連載「スクラム開発をボトムアップで始める」の2回目の記事です。

前回までのあらすじと今回のテーマについて

このシリーズは私が所属するチーム（まだ立ち上げ段階）の取り組みを紹介しており、前回の記事では、スクラムで定義されたルールを用いながら、チームやメンバーの不透明な部分を管理し、理解を深めていく話をしました。また、その過程の中でスクラムのルールを段階的に適用しつつ、テーラリングしながらスクラム開発ができる状態に近づけていくためのアプローチについても触れました。以降、スクラムの用語を使いますので、詳細についてはスクラムガイドをご参照ください。

現時点で適用しているスクラムのルールは一部で、紹介している活動はスクラム開発ではないですが、すべてがととのう頃にはチームに最適化された形のプロセスになるはずだと信じています。今回は活動サイクルの計画立案時、つまり、スクラムのルールで言うところの、スプリントプランニングの取り組みについて紹介したいと思います。

よくある計画立案と陥りがちな光景

スクラム開発では、スプリントの最初にスプリントプランニング（以降、プランニング）を行い、最後にスプリントレビューとスプリントレトロスペクティブ（以降、レトロスペクティブ）を行うという流れがルール化されています。他のアジャイル開発手法においても、同様のプラクティスが提唱されています。チーム形成期のレトロスペクティブは改善すべき事柄が多いことから、回数を重ねるごとに活動が改善します。そして、目立つ課題が片づくと、チームの生産性を向上させたくなりますが、チームの生産性が数ヶ月経っても安定しないなんてときは、計画の立て方に問題があるかもしれません。

プロダクトバックログアイテム（以降、PBI）に対してプランニングポーカー的なことを行うが、メンバーは自身の経験からの相対見積もりで工数感をポイント化してしまう
そのポイントをチームに持ち寄って議論をしても各自の尺度が異なるため、合意したポイントはチームメンバーの誰のものでもないポイントとなってしまう
誰のものでもないポイントの総和をチームの生産性で割り返し、活動期間中に取り組むことを決めてしまう
実現したいことに対して、作業イメージを持っている人がやることを洗い出し、気づける限りの抜け漏れが無ければプランニング完了としてしまう

上記のプランニングの形はそれっぽいのですが、本質的な計画ができていないように見えます。順調に進んでいるときは良いのですが、計画どおりに進まなくなると、課題が分からなかったり、見誤ったりします。

メンバーがポイント化している見積もり対象は何か？

プランニングポーカーで見積もるのは「規模」なので、本来、人による差が生じないものですが、知識や経験の有無、楽観的・悲観的といった個人の考え方に基づいて「工数」を見積もることで差が生じます。

マラソンで例えると、規模の見積りは「何キロ走る競技か？」を問われていて、過去の経験から「42.195km」と正確に答える人もいれば、「だいたい40km」と答える人もいます。これらはどちらも正解で「10km」だと不正解になります。一方、工数の見積もりは「完走するのにどれくらい掛かるか？」を問われていて、「2時間程度」で走る人もいれば、「6時間程度」で走る人もいます。誰も"自分の足で"という制約を設けていないので、乗り物を利用して「1時間を切る」人がいるかも知れません。これらはすべて正解です。工数の差異は実現手段（誰がどのようにやるか）で大きく変化します。

「人日」や「時間」は工数の単位で、それとは異なる規模を算出するために「ポイント」を用いるのですが、上述の通り、ポイントという単位に置き換えただけの工数で見積もるメンバーも出てきてしまいます。そこで、私のチームではポイントを用いた見積もりを行っておらず、5段階の規模の目安を設けて見積もりを行っています（Tシャツサイズ見積もりというらしいです）。現在試みている規模の目安は、クネビンフレームワークで提唱されている問題の特性を参考にしています。Tシャツサイズだと計算しづらいので、フィボナッチ数列のポイントも仮置しています。こうすると規模の目安とポイントが工数のように比例しないので、ポイントをラベルとして扱えるようになり、工数の呪縛から抜けられます。

規模 (仮置ポイント）	規模の目安
XS(1)	【単純】実現したいことに対して最適解があり、着手すれば終えられるもの
S(2)	【繁雑】実現したいことに対して課題が複数あり、手間や時間を要することが見込まれるもの
M(3)	【煩雑】実現したいことに対する課題の解法が複数あり、頭を使って解法を選択した後に着手すれば終えられるもの
L(5)	【複雑】実現したいことに対して複数の課題が絡み合っている状況のため、それぞれの課題を解決可能な状態に分離すべきもの
XL(8)	【混沌】何をすべきかを特定できていない状態なので、取り組むべき課題に落とし込む必要があるもの

この見積もり方法の精度を上げるには、取り組むべき事柄をXSサイズやSサイズに細かく分解してから消化することです。スプリントプランニングでここまですれば規模に対する生産性（ベロシティ）が計測できるようになるはずで、生産性の安定や向上といった打ち手を講じやすくなります。ただ、これだけでは実際のスプリントで実現したいことが達成できるかが不安になるので、次項では実現可能なタスクに落としこみます。

メンバーのタイムボックスには何が入っている？

スプリント内での活動をタスク化する、スプリントバックログの作成は有識者が行えば効率の良い段取りが組めますが、それは有識者にとってのものであり、タスクを担当する人が期待通りに対応できるとは限りません。担当者がタスクを完遂するイメージを持てていない、調査が必要でタスク完了までの所要時間が読めない、実は外出予定があるなど、さまざまな理由が考えられます。

これを明確にするための取り組みとして、私のチームではメンバーに対し、担当するタスクを個人のタイムボックスで管理するようにお願いしています。

タイムボックスとは

一定の制限時間を設けた箱を稼働時間にあわせて複数用意し、箱の中に実行可能なタスクを入れて管理をします。たとえば、2時間のタイムボックスを運用する場合、以下のようになります。

所要時間が1時間のタスクであれば、1つのタイムボックスに2つタスクを入れられます。
所要時間が3時間のタスクであれば、1つ目のタイムボックス埋まり、2つ目のタイムボックスが半分埋まります。

アスクルは1日の勤務時間が基本的には7.5時間なので、私のチームでの運用は、フルタイムの稼働者には2時間のタイムボックスを3つ用意してもらい、残りの1.5時間はスクラムの会議や事務作業などの管理業務のための時間としています。また、タイムボックス完了時には何らかの（中間）成果を出すようにお願いしています。こうすることで、大きなタスクが2時間以内のタスクに分割され、タスクの段取りや途中過程、完了時の状態を他のメンバーが理解しやすくなります。タイムボックスを2時間×3箱にしている理由は、オレオレ科学的根拠に基づいています。

人間の集中力を保てる限界
- 人間が集中力を保ちながら1つの作業に取り掛かれる時間と言われている時間が90分で、メールやSlackなどの外的要因で集中力が途切れてしまった際に頭を元に戻すため時間として30分を加味している。
人間の脳が並行処理できる限界
- 脳が一度に記憶したり処理できる量が3〜4つまでと言われており、それ以上のことを同時にしようとすると取りこぼしが発生する。
日々の活動リズムとの親和性
- 午前中にやること、昼過ぎにやること、夕方にやること、として、1日の活動をイメージを持ちやすくすることで、効率の良い時間の使い方ができるようになる。

メンバー同士でタイムボックスを見ると、タイムボックスの中間成果物がゴールイメージに近づいていなかったり、タスク消化のための調査タスクを組み込んだりするので、メンバーやチーム全体のスキルと抱える課題の理解が進みます。プランニングの段階でレトロスペクティブのテーマになりそうな点が把握できるので、スクラムマスターとしては、スプリントの中で定量的な計測を行うことができます。

生産性を向上させたくなったら…

2時間のタイムボックスを90分に凝縮してみます。一日で消化できるタイムボックスが4つに増えるので、生産性が1.3倍になります。上記の例でも、頭の切替時間なる時間を加味しているので、そのムダを生じさせないことが「はじめの一歩」かもしれません。

赤裸々告白：OPAのエンジニアチームについて

タイムボックス管理の導入時は私自身も含め、なかなか上手くいきませんでした。課題は以下のとおりです。

最終ゴールイメージを持っていない人は、タスク2時間以内のタスクに分割することができない
最終ゴールイメージを持っている人は、タイムボックスによる中間チェックポイントを用意する分だけ足枷となる
担当者がタイムボックスを管理しているので、「タスクが終わらない＝見積もりの甘さ」以上の気付きを得られない

タスク分割ができない課題はプランニングに時間を掛けることで解消でき、作業の見通しが立てられるようになりました。プランニングを短くしていくことが今後の課題です。タイムボックスが足枷になる課題は、作業を進めながら決めたゴールを達成できる見通せるなら、中間成果物を省略しても良いということを施行中です。見積もりの甘さ以外の気付きが得られない課題は、レトロスペクティブを行い、原因の掘り下げを施行しようとしているところです。