スプリントバックログを活用して強いチームを作ろう
スプリントバックログはアジャイル開発におけるToDoリストである、という説明を目にしたことがあります。
この「バックログ＝ToDoリスト」という説明、半分間違いで、半分正しいと思います。
確かに、スプリントバックログは、タスクリストの役割を持っています。が、スプリントバックログの目的は、タスク管理だけではありません。
というか、スプリントバックログを、タスク管理にしか使っていないとしたら、非常にもったいないです。なぜなら、スプリントバックログは、チームビルディングのツールとしても非常に有効なものだからです。
プランニングを変えれば、チームが変わる
これから開始するスプリントのために、バックログアイテム（タスク）が２０件あったとします。スプリントプランニングで、この２０件すべてに担当者をアサインしているチームを、ときおり見かけます。
もし、あなたのチームが該当するとしたら、可及的速やかに、その運用をやめることをお勧めします。代わりに、
- プランニングでは、各エンジニアが「最初にやるタスクだけ」を決める
- 最初のタスクが終わったエンジニアは、オープンなタスクの中から、次に担当するものを選ぶ
- デイリースクラムを活用するなどして、皆がいる場で、これをやる
これを試してみてください。
たったこれだけのことで、驚くほどの変化が現れます。
- 手が空いたエンジニアが「次、何やったら良いですか？」とお伺いを立てる頻度が減る
- メンバーのスキルレベルや、どんなスキルを身に付けたいと思っているか、が表面化しやすくなる
- 若手がちょっとチャレンジングなタスクを取ったら、他のメンバーがサポートする、といった相互扶助が自然に行われる
などなど。簡単に言うと、メンバーの自発性が増し、チーム内の相互作用が促進されます。
「全部アサイン」は、チームの力を奪う
「全タスクのアサインを最初に決める」方式の背後には、リーダーがメンバーにタスクを割り振る、中央集権型組織の規範が潜んでいることが、とても多いのです。
「全部アサイン」型チームのプランニングをオブザーブすると、スクラムマスターが中心となり「このタスクはAくんでいいよね」「これはBさんかな？」という感じでアサインを決めていることが多いようです。
形式の上では「全員で協議してタスクアサインを決める」体裁をとっているものの、実態としては、スクラムマスターが意思決定を主導しています。他のメンバーは、異論があれば発言するけど、だいたいは無言でうなずくだけ。
こうしたチームのスクラムマスターは、従来型のPM、PLに近い存在です。メンバーも、自然と、スクラムマスター（という名目の実質的なリーダー）の指示を待つようになります。そして、この規範意識は、タスクアサイン以外の判断や、行動全般に蔓延して行きます。
特に、エンタープライズスケールの開発では、注意が必要です。スクラムチームメンバーの雇用形態が、一様ではないケースが多いからです。 スクラムマスターは社員、Devチームメンバーはグループ会社からの出向者や派遣エンジニア、といった現場です。 こうした現場では「立場の違い」が見えない壁となり、チームの自己組織化を阻んでいることがあります。
一見、アジャイルな開発を実践しているように見えても、その実、従来型のタスク割り振りの結果を、バックログアイテムに記入しているだけだとしたら…？「仏作って魂入れず」というやつですね。
タスクアサインから始めよう
これ、ウチのことかな？と思った方へ。あなたのチームの「仏」に魂がこもらないのは、中央集権型組織の規範を反映した、仕事のやり方のせいなのかもしれません。
組織の規範を変えるのは、とても大変です。 でも、タスクアアサインのやり方を変える、くらいなら、どうでしょう？ 少しでも「やれそう」と感じたなら、ぜひ、次回のレトロスペクティブで、タスクアサイン方法の見直しを提案してみてください。
「オープンなタスクから、自分で取る」方式は、タスクを、「リーダーに割り振られるもの」から「自分で選択するもの」へと変容させます。
その結果、雇用形態や契約上の立場の違いは、ロールの違いに過ぎず、上下関係ではない、という当たり前の価値観が、しだいにチームに浸透して行きます。
「スクラムチームにリーダーはいない」とお題目を１００回唱えるより、ちょっとしたやり方の変更の方が、ずっと効果的に、チームの規範意識を変えてくれます。
こんな効果があるとしたら、スプリントバックログの役割を、ToDoリストに限定してしまうのは、もったいないことだと思いませんか？
さて、次回は、「オープンなタスクから、メンバーが選択する」タスクアサインを上手く運用するコツを説明したいと思います。2019年2月18日公開予定の次回エントリーも、ぜひチェックしてください！
