スプリントの失敗は「まったく予見ができなかった問題」が原因になるとは限りません。認識できたはずの問題を認識できなかった、存在は認識していたのに注目しなかった、問題に注目はしたが対策を検討していなかったなど、後から振り返ると「なぜそこでつまづいてしまったんだろう…」と思えるようなことが、スプリントの失敗の原因となることもあります。
この記事ではそのような問題を「予見できたはずの問題」と呼び、それらに「Emoji」で立ち向かうプラクティスを紹介します。
予見できたはずの問題へ対処するための「RPMプロセス」
私たちのチームでは、例えば「着手をしてみたら設計が生煮えだったことが分かり、予定通りにタスクの実装が進められなかったこと」や、「タスク間の依存関係が認識できておらず、不要な待ちが発生してしまったこと」などといった、本来ならプランニングの時点で予見できたはずの問題を適切に扱えなかったことによる失敗が多くありました。
とはいえ、このような「予見できたはずの問題」に対するプロセスの改善は一筋縄ではいきません。
なぜならこの「予見できたはず」という性質のために、どうしても「もっと気をつけよう」以外の具体的なアプローチになかなか繋がりづらい傾向があるためです。
そこで、私たちがヒントになると考えているのが、マイケル・ワトキンズとマックス・ベイザーマンによる「ビジネス危機は予見できる（Predictable Surprises: The Disasters You Should Have Seen Comming）」というレビューです。
このレビューでは、予見できたはずの問題を適切に扱うために必要な3つのステップが挙げられています。
- 認識（Recognition）：迫りくる危機や問題に気づく
- 注目（Prioritization）：認識した危機や問題を分析し、注意を払うべきものに注意を払う
- 対応（Mobilization）：可能性の高い危機や問題に対して、程度に見合った対策を講じる
ワトキンズとベイザーマンは、この3ステップを認識（Recognition）、注目（Prioritization）、対応（Mobilization）の頭文字をとって、「RPMプロセス」と呼んでいます。
スクラムチームの目線でRPMプロセスを捉える
上記のRPMプロセスをスクラムチームに応用し、よりロバストな計画づくりを行うためには、具体的に活動のどのような側面に注目するのがよいでしょうか？
スクラムチームにとって一番身近な「計画」である、スプリントプランニングをお題に考えてみましょう。
認識
スプリントプランニングでは、複数の観点からタスクに分析を加える必要があります。しかし、特定の観点（このタスクはどのように細分化できるか、など）に注意を払うあまりに、別の観点（このタスクは別のタスクと依存関係があるのか、など）への注意が損なわれて、問題の認識がうまく行えないこともあります。
この例を示すのが、クリストファー・チャブリスとダニエル・シモンズによる「バスケットボールのパスの数を数える」という有名な実験です（映像のネタバレになってしまうため、実験の内容はここでは伏せます。初めて知った方は、ぜひリンク先の映像をご覧になってみてください）。
一般に、問題の認識がうまく行えなかったとなると、私たちは「当人/チームがぼんやりしていたから」という理由を思い浮かべがちです。しかしこの実験は、ある対象を認識することへの集中が、別の対象への認識を妨げることがあるということを示しています。スプリントプランニングにおいては、このような偏った集中の悪影響を取り除き、複数の角度からタスクを分析できる仕組みをつくる必要があります。
注目
認識されたすべての問題に100%の注意を払える訳ではありません。そのため、「どの問題に注目すべきか」をピックアップする必要があります。
厳密なリスク分析によって注目の対象を定める手もありますが、1~2週間のスプリントという時間軸を考慮すると、コストに対しての恩恵が薄いでしょう。
スプリントプランニングへの応用にあたっては、よりスピーディーで効率の良いプロセスを用いる必要があります。
対応
注目の対象となった問題に対して、一つ一つ対応策を設けていきます。問題に対して対応策が機能するかが不安であれば、次善策をセットで設けることになります。
スプリントプランニングでは、問題に対する対応策や次善策が用意されているかを確認する必要があります。
EmojiでRMPプロセスを「実装」する
お待たせしました。ここからがEmojiの話です。
私たちのチームがRPMプロセスをスプリントプランニングに適用する上でキーとなっているのが、Emojiによる不確実なタスクのマーキングです。スプリントプランニングでのEmojiの利用方法を、RPMプロセスの視点から整理してみます。
大まかな流れは以下のようなイメージです。
- 認識: 不確実なタスクに「😇」や「🏃」、「🧠」などのEmojiを付けていく
- 注目: 付けたEmojiから「注目すべきタスク」を特定する
- 対応: 注目すべきタスクの「有事の際の対応」にチームとして合意する
1. 認識: 不確実なタスクに「😇」や「🏃」、「🧠」などのEmojiを付けていく
RPMプロセスのR、「認識」のためのフェーズです。
スプリントプランニングの最後に、分割したタスク一覧を眺めながら、「不確実性を持つタスク」に特定のEmojiのセット、通称 :innocent:s を付与していきます。
下記は架空のTodo管理アプリの実装タスクにEmojiを付与したイメージです。
付与するEmojiは、タスクの不確実性の性質に応じて使い分けます。
たとえば、ちょっとした設計を伴う実装タスクなどがこの分類にあたります。この性質を持ったタスクの着手やレビューが遅れるほど、スプリントのリスクが増えていきます。
たとえば「ツリーのデータ構造の実装や、それを走査するロジックの実装」などがこれに分類されます。この性質を持ったタスクを効率的に実行するためには、担当者がまとまった時間で集中してプログラミングに取り組めるようにスケジューリングを行う必要があります。また、ペア/モブプログラミングの実施も有効です。
1つ目を完了させれば、その他を横展開的に処理していくことが可能ではありますが、1つめの対応にミスがあると、間違った対応を量産してしまう性質を持っており、注意が必要です。そのため、難易度によっては1つ目を完了したあとに部分的なレビューを設けるなどを行うこともあります。
一方で、1つ目のものに対して正しい対応が行えれば分業は比較的楽であり、新メンバーのオンボーディングタスクとして適切なものとなりうる性質も持っています。
たとえば、コッテリとしたバグの調査・改修などがこの分類にあたります。
私たちのチームでは上記を含め計8種類のEmojiを使い分け、不確実なタスクを分類しています。
このEmojiの使い分けを考える工程が認識のミソです。「🏃にあたるタスク、つまり解決策が生煮えのタスクはないだろうか」や、「🧠のタスク、つまりまとまった集中作業が必要なタスクはないだろうか」などといった思考が働くことによって、複数の観点からタスクを再検討することができ、問題の認識の見逃しを防ぐ効果があります。
2. 注目: 付けたEmojiから「注目すべきタスク」を特定する
RPMプロセスのP、「注目」のためのフェーズです。
Emojiのついたタスクの全てが注目すべき問題とは限りません。たとえば「🧠」であれば、まとまった集中作業の時間が確保さえできれば、大きな不確実性とはならないかもしれません。「🌊」は、たとえばメンバーが入れ替わりで休暇を取るようなスプリントにおいては、作業の引き継ぎ時の情報ロスが起き得ないかという観点で注目すべきタスクになります。課題にも解決策にも不明点がある「😇」の付いたタスクは特に不確実であり、常に注目すべき対象です。
また、Emojiという強烈に視覚に訴える表現方法を用いることは、「スプリントの全体」におけるリスクへの注目のしやすさにも繋がります。
たとえば、Emojiがスプリントの後半に集まっているようであれば、そのスプリントは「いざというときのリカバリ対応が間に合わない」というリスクを抱えていることを示します。スプリントのリスクが視覚的に現れるので、POやステークホルダーといった非開発メンバーにとっても把握がしやすいという効果もあります。
3. 対応: 注目すべきタスクの「有事の際の対応」にチームとして合意する
最後に、RPMプロセスのM、「対応」のためのフェーズです。注目の対象となるタスクの対応策をチームで検討し、合意します。
Emojiによる不確実性の分類は、この「有事の際の対応をどうするか」をより効果的に検討するためでもあります。
タスクが持つ不確実性の性質に応じて、適切な対応は異なります。しかし、それらの不確実性をどう見立てるか、どう対応するかの議論は、骨の折れるワークとなることがしばしばです。
私たちのチームでは、Emojiをチームの「パターン」として用いることで、不確実性の分析と有事の対応についての議論をよりスムースに行えるようになりました。
「このタスクは🧠だからペアプロしたいね」や、「このタスクは🏃だから、このタスクの後に設計の中間レビューを挟もう」、「この😇のタスクがコケるとまずいので、リカバリが容易なようにスプリントの前半に持ってこよう」といった対応についての会話が、スプリントプランニングにて行われています。
また次善策をセットで設けた場合、次善策はしかるべきタイミングで速やかに実行される必要があります。そのためには「if-then プランニング」のフォーマットに則って、タスクを記載することも効果的でしょう。
どうしても具体的な対応策が設けられない場合は、問題が観測されたあとの「再計画」のタスクを計画に事前に盛り込むとよいでしょう。
単なるバッファと再計画タスクを明示的に分けることで、他のタスクによるバッファの消費から再計画の時間枠を保護し、スプリント中の混乱を防ぐ効果が期待できます。
発展的課題: 過去のタスクについたEmojiを計画づくりと能力開発に用いる
ここまで、Emojiを使ってスプリントの不確実性を分析し、有事に備えるプラクティスをご紹介してきました。
今後の発展的課題として、「過去のスプリントにおける、Emojiがついたタスクごとの見積もりの予実を把握できるようにしたい」ということを考えています。見積もりの予実を、次のスプリントの計画づくりに役立てる（「どうやら自分たちは🧠のタスクを低く見積もりがちのようだ」など）ことや、チームや個人としての能力開発（「今期は🏃のタイプのタスクをスムースにできるようになりたい」など）に役立てられると、さらにおいしいプラクティスになりそうです。
まだ進化途上のプラクティスではありますが、不確実性に立ち向かうみなさまの一助となれば幸いです。
本記事では書ききれなかった細かいプラクティス、伝えきれなかったニュアンスも多くありますので、より突っ込んだ話が気になる方は、お気軽にご連絡をください！ぜひカジュアルにお話ししましょう！👌
