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