

短期間の目標を定め、効果的なデイリースクラムを!
こんにちは。ソリューション開発部 認定スクラムマスターの羽澤です。
最近はスクラムマスターとして仕事をしており、チームがより気持ちよく作業できたり、より効率よく作業するためのお手伝いをしています。このような立場なので、スクラムやアジャイルというキーワードで勉強会を探して参加したり、Webで記事を読んだりしていますが、いつも思うことがあります。
なんか「ふりかえり」関係の話題多くない・・?
気のせいではないと思うのですが、ふりかえりに関する記事は良く目にします。しかしそれ以外のスクラムイベントについての記事はあまり見ないのです。(私の観測範囲が偏っているだけかもしれませんが。。。)
私もふりかえりの大切さは良く理解しています。しかし!効率よく作業をしたりチームを強くするため、私はデイリースクラム(朝会)を大切にしています。今回はそんなデイリースクラムに焦点を当てようと思います。
デイリースクラムについて
デイリースクラムとは
今更説明は不要かもしれませんが一応。
1日1回開発チームが集合し、状況の共有を行う場です。先ほど「デイリースクラム(朝会)」と書いた通り、朝に行うチームが多いように思いますが、朝夕に分けて1日2回実施するチームもありますし、夕方に1回だけ行うチームもあります。私はどのやり方でも構わないと考えておりまして、チームにフィットする時間帯に行うのがベストだと思います。
デイリースクラムの目的
デイリースクラムの目的はなんでしょうか。スクラムガイドの説明の中で、私が最も重要だと感じているのは以下の一文です。
デイリースクラムは、開発チームがスプリントゴールを達成する可能性を最適化する。
そうです。スプリントゴールを達成する可能性を少しでも上げることが目的なのです。チームはその意識を持ってデイリースクラムを行うべきと考えています。そしてそれはチーム自身が行うのが、スクラムをはじめとするアジャイル開発です。後述しますが、私がSIerとして受託開発を行う上でも目指している形です。
よくある課題
今までいくつかのチームを見てきましたが、陥りやすい状況をいくつか取り上げてみます。
報告の場になってしまう
主に「メンバーから」「リーダーへの」「報告の場」となってしまうことです。チームの立ち上がり初期にありがちというか、必ず通る道です。
アジャイルを経験したことのあるエンジニアは、まだ多くないのが実情だと私は感じています。そのようなメンバーは、リーダーに状況を報告しながら作業しますし、それは間違っていません。ただ、アジャイル開発にリーダーはいません。開発チームは全員平等であり、チームで進んでいきます。アジャイルではリーダーはおらず、自分たちで開発の方針を決めながら進んでいくことが大切です。
リーダーへの報告の場ではないという意識を育てることが大切ですし、それはスクラムマスターの重要な仕事です。
状況の共有”だけ”で終わってしまう
デイリースクラムで何をするかはチームによると思いますが、よくあるのが以下の3つを共有することだと思います。
- 昨日やったこと
- 今日やったこと
- 問題点
この3つを共有するのはとても良いことです。しかし共有して終わりなのであればそれは意味がありません。大切なのは、共有された状況をどう活かすかです。
「こんな問題があります。」
「そうですか。じゃあ遅れそうですね。」
「そうですね。以上です。」
こんな会話していませんか?せっかく共有された情報を活していないなと感じます。
先ほど、「メンバーから」「リーダーへの」「報告の場」になっていることがあると書きましたが、こちらは「メンバーから」「チームへの」「報告の場」になっているパターンです。先ほどより一歩進んではいますが、まだまだデイリースクラムを有効活用しているとは言えません。
どうすべきか
さて、陥りやすい状況を挙げてみましたが、どうやればより良いデイリースクラムになるでしょうか。
「報告の場」になってはいけないと書きましたが、私は「再計画の場」になるのが理想だと考えています。
私はデイリースクラムを説明する際、「日々の再計画ですよ」と説明しています。最近読んだ本にも、そのようなことが書かれていて嬉しくなりました。そのために私が実践しているのはただ一つだけ、「目標をインプットする」ということです。
目標を決めよう
スクラムを始めとするアジャイル開発では、短期間のスプリント単位で進めていくはずです。スプリントの最初に、そのスプリントの計画を立てます。スクラムであればスプリントプランニングとなります。ここで決めたことが目標となるのですが、慣れるまでは一工夫することが多いです。
ざっくりマイルストーンを置く
スプリントプランニングでは、今スプリントで対応するプロダクトバックログアイテムを、細かいタスクに分解するチームがほとんどだと思います。これは王道ですしとても良いアプローチなのですが、計画通り進んでいるかわかりにくいなと感じています。
タスクを元にバーンダウンチャートを作ってはいるのですが、特に最初のうちはタスクの大きさがバラバラになりがちです。そのため大きなタスクをこなしているとバーンダウンが下がらず、遅れてるように見え、小さなタスクが最初に消化された場合は進んでいるように見えてしまいます。
全タスクを同じくらいの大きさにするのが理想ですが、簡単ではありません。また成熟したチームであれば、阿吽の呼吸で進捗がわかってくるものですが、そこに到達するまでをどうにかしなければなりません。
私はまず最初に、プロダクトバックログアイテムごとに、いつ終われば順調かを明確にしてもらうことが多いです。こんな感じです。


ストーリーに振られている番号ごとに、ざっくりとしたガントチャートで表現しています。細かく作りすぎると手間がかかりますのでこのくらいの粒度で十分です。
デイリースクラムで毎回確認する
デイリースクラムでは各メンバーの状況を共有した後、先ほどのチャートを見ながら、計画通りに進行しているか?という確認をします。
チャート通りであればそのまま進めますし、ちょっと怪しいなと思えば、チャート通りに進めるためのアクションを決めることで、できる限りスプリントの目標を達成できるように進めていきます。
メンバーがフォローしあったり、プロダクトオーナーに協力を仰いだり、タスクの実施順を工夫したりなど、やり方はいくらでもあります。
無理はしない
このようなチャートを作ると、計画を守ろうとするあまり厳しい残業をしてしまう方もいらっしゃいます。
ですが、それは良くありません。残業が必要なことも当然ありますが、それを継続するとチームが疲弊しますし、無理に進捗を上げてしまいがちです。無理に上げた進捗を元にそれ以降の見通しを立てると・・・それは破綻してしまいますよね。
目的は無理をすることではなく、計画を参考にして臨機応変に対応することです。その上で達成できないことも勿論あります。達成できないとしても、より良い着地点を見つけましょう。
「全アイテムが80%出来てますが、完成したものは一つもありません。」
よりも、
「1つだけ未着手ですが、他は全部完成しています。」
の方が、スクラムにおいてはより良いはずです。
受託開発でも活用したい!
私、次のお仕事がウォーターフォール型の開発となる見込みです。そこでも今書いたことは活用できるんじゃないかと思っています。
スプリント単位で動くことはありませんが、毎週定例会があります。そこで次の定例までの目標を決め、朝会で計画との乖離を確認する。それだけのことです。
アジャイル開発のエッセンスは、ウォーターフォール開発にだって活かせます。
終わりに
デイリースクラムはその名の通り、毎日行うイベントです。
だからこそ、毎日の活動に直結する大事なイベントです。チームのベロシティを向上させたり、チームとして成熟していくために、とても重要なイベントだと考えています。
今後もより工夫を行い、より良い場になるよう努力を続けていこうと思います。