ブログ

ryuzeeによるブログ記事。不定期更新

直近開催のScrum Alliance認定スクラムマスター研修のご案内

デイリースクラムの進め方

みなさんこんにちは、@ryuzeeです。

今日はデイリースクラムについて、概要や注意点を紹介します。 なお、あくまで一般論であることに注意してください。スクラムの基本は「透明性・検査・適応」です。自分たちで随時やり方を検査して、もっとうまくできるように適応していかなければ効果はあがりません。

1. デイリースクラムの目的

スクラムを利用するとき「フレームワークで決められているから」というだけの理解で進めてはいけません。これは全てのイベントに当てはまります。 スクラムのイベントはすべて、検査と適応が行われるように明確に設計されています。

デイリースクラムの最大の目的は、スプリントゴールの進捗を検査し、今後の作業計画を必要に応じて見直す(適応する)ことで、スプリントゴール達成の可能性を最適化することです。

毎日の検査と適応(高速なフィードバックループ)によって問題を早期に発見することでリスクを減らし、スプリントゴール達成の可能性を上げるとともに、ムダな待ち時間を減らします。

デイリースクラムはスクラムマスターへの報告イベントではありません(デイリースクラムの参加者で説明するとおり、スクラムマスターの参加は必須でもありません)。

2. デイリースクラムの参加者

スクラムガイド2016年版では、「スクラムマスターは、デイリースクラムには開発チームのメンバーしか参加できないというルールを遵守する」との記載がありました。 スクラムガイド2017年版では、「デイリースクラムは開発チームのためのミーティングである。 それ以外の人たちが参加する場合、開発チームの邪魔にならないようにスクラムマスターが配慮する」となりました。

スクラムガイド2020年版では、「デイリースクラムは、スクラムチームの開発者のための15分のイベントである。(略)プロダクトオーナーまたはスクラムマスターがスプリントバックログのアイテムに積極的に取り組んでいる場合は、開発者として参加する」に変わりました。

すなわち、デイリースクラムの参加者は「開発者」です。 なお、スクラムマスターは、すべてのイベントが確実に行われるようにすることに対して説明責任があるため、開発者だけでデイリースクラムが円滑に行えないような初期の段階では、スクラムのフレームワークを理解してもらうことを目的に参加することはあるでしょう。 ただし、開発者だけでデイリースクラムを実施できるようになれば、必ずしも参加する必要はありません。

3. デイリースクラムのタイムボックス

デイリースクラムのタイムボックスは15分です。厳密に15分のタイムボックスを守ります。 すなわち15分より短い時間で終わって構いませんが、15分を超えてはいけません。 開発者の人数に関係なく15分以内なので、人数が多くなればなるほどやり方に工夫が必要になります(たとえば個人単位で話すのではなく、PBI by PBI(プロダクトバックログアイテム単位で話をしていく)のようなやり方を使うのも1つの手です)。

実施時間と場所は常に同じにします。日によって時間や場所を変えてはいけません。また毎日開催する必要があり、隔日開催のようなものではいけません。 時間帯については決まりはありません。必ずしも朝やらなければいけないわけではなく、チームによって時間はさまざまです。ただし、開発者全員が参加できる妥当な時間帯にする必要はあります。 また、開始時間になれば、参加者が全員揃っているかどうかに関係なく開始するのがよいでしょう。遅れた人を待っている限り、その行動は繰り返されてしまいます。 場所については、オンサイトであればチームの作業エリアで行うのがよいでしょう。スクラムボードなどの見える化ツールを使っていればその情報がすぐ目に入りますし、移動の時間も減ります。

以上の内容については、開発者全員がはっきりと理解しているようにします。 そのために、たとえばデイリースクラムの時間や場所を貼りだしたり、チャットボットなどを使ってリマインドをしたりします。これはその他のイベントでも有効です。 派生形として、スクラムチームのイベントカレンダーを貼り出すチームもあります。

なお、デイリースクラムはあくまで、「最低でも1日に1回は同期して検査・適応せよ」と言っているに過ぎません。 他のメンバーとの会話をデイリースクラムまで待たなければいけないわけではないので、必要があれば随時集まって会話してください。 デイリースクラムは単なるチェックポイントであり、チームとして会話する唯一の場となるべきではありません。 すなわち、デイリースクラムで多くの話し合いが行われているようであれば(そして結果としてタイムボックスを守れないような状況であれば)、デイリースクラム以外での会話が不十分であることを示唆しています。

4. デイリースクラムの事前準備

デイリースクラムのタイムボックスは15分と短いため、効果を上げるには事前準備が必要です。

以前のスクラムガイドでは3つの質問に答えることでデイリースクラムを進行していましたが、スクラムガイド2020年版ではその記述はなくなっており、「開発者は、デイリースクラムがスプリントゴールの進捗に焦点をあて、これからの1日の作業の実行可能な計画を作成する限り、必要な構造とやり方を選択できる」となっています。

そのため、どのような準備をするかはチームごとに違ってきます。 とは言え、一般的には、以下のような点について事前に準備しておくとよいでしょう。 もちろん事前準備の内容も検査と適応の対象なので、有効性を見ながら自分たちの状況に合わせて改善します。 慣れないうちは、デイリースクラムで話す内容や、事前準備を見える場所に貼ったり、チャットボットに案内させたりしてもよいでしょう。

  • スプリントゴールを達成できると思うかどうかを表明できるようにしておく
  • 前回のデイリースクラムから変わった点(共有する価値がある情報は何なのかを考えること)
  • 解決した問題やいま抱えている問題と、それがスプリントゴールに与える影響を話せるようにしておく
  • 個々のプロダクトバックログアイテムやタスクの最新の状況。ツールを使っている場合はデータを更新しておく(これを可能にするために、作業は1日以内のサイズに収めておきます。そうすることで最新の状況が把握しやすくなります)
  • おやつ

なお、デイリースクラムには開発者全員が出席しますが、休暇などで出席できないこともあります。その場合は、事前に何らかの形で状況を伝えておくとよいでしょう。

5. デイリースクラムのファシリテーション・進行

デイリースクラムの進め方はチームによって違うので、進行にあたって重要な点について紹介します。

デイリースクラムを運営するのは開発者自身

デイリースクラムは開発者のためのイベントであり、開発者自身が運営しなければいけません。 ファシリテーターは誰がやっても構いません。開発者のなかで当番を決めて日替わりでやることもあります。

スクラムマスターは「すべてのイベントが開催され、ポジティブ・生産的であり、タイムボックスが守られるようにする」ことに対して説明責任を負います。 スクラムマスターには、デイリースクラムに出席して運営する責任はありません。スクラムマスターはデイリースクラムが確実かつ円滑に行われるように支援します。

すなわち、スクラムマスターがその場にいるかどうかに関係なく、開発者自身が日々デイリースクラムを行います。

集中する

15分のタイムボックスのなかで最大の成果を出すには、全員の集中が必要です。 携帯やPCをいじらずに、ほかの人の話を聞き、会話に参加できるように備えなければいけません。 同じ理由でプロジェクターの利用は避けるのがよいでしょう。画面を見るのに集中するのではなく、デイリースクラムでの会話に集中する必要があるからです。

問題解決はほとほどに

デイリースクラムは15分間で短いため、込み入った会話をしているとあっというまに時間がなくなってしまいます。 まずは、スプリントゴール達成の可能性を検査し、これから先の計画を適応することを最優先にしましょう。 もちろんごく軽微な問題であればその場で解決しても構いませんが、通常は進め方の方針を決めるまでにとどめます(例: 「デイリースクラム後にAさんとBさんで会話する」「今日の午後全員でモブプログラミングして対処する」などです)。 開発者だけで解決できない問題が判明した場合は、それをまとめておき、あとでスクラムマスターと共有しましょう。そうすることでスクラムマスターが組織に解決を働きかけられるようになります。

関係なさそうな話になったり深入りしすぎた話になったりしたら、開発者は誰でも話を止めるように提案します。たとえば2人挙手ルール(話を止めたほうがいいと思った人は黙って手を挙げる。それが2人以上の場合はそこでその話はおしまいにする)を使っているチームもあります。

6. デイリースクラムのアンチパターン

同じ時間に同じ場所で開催していない

同じ時間に開催しないと、検査の間隔が不安定になり、ペースの把握が難しくなります。 また場所の調整を毎回行うのもムダです。 スクラムのイベントは複雑性を避けるために、同じ時間、同じ場所で開催するようにします。

時間を延長する

15分のタイムボックスで終わらないからといって終わるまで時間を延長すると、本当の問題を隠してしまいます。 スクラムがさまざまなイベントでタイムボックスを設定しているのは、そのタイムボックスに収まらない状態を異常だと考えているからです。 終わるまで時間を延長するのではなく、時間内に終わらない原因を見つけて、それを解消してください。

準備不足

デイリースクラムの時間は15分と短いので、その場で思い出しながら進めようとしてもあっという間に時間が過ぎてしまうとともに、本当に必要な情報を共有できなくなってしまいます。 毎日同じ時間にやることがわかっているので、事前に準備をしたうえで時間通りに参加しましょう。 デイリースクラムの前に、スプリントゴールが達成できそうか、スプリントゴールを達成する上で問題となりそうなことがないか、現在作業中のものの状況など、他の人に共有したいことを準備しておきましょう。 また、スクラムボードやオンラインツールなどを使っているのであれば、そこに載っている情報を最新にしておきましょう。

会話せずメールやチャットで代用する

メールやチャットで代用すると、本当に重要な情報が何なのかを把握するのが難しくなります。 また、それを全員が読んで内容を把握しているかどうかもわかりません。 共通認識を手早く形成するには、対話した方が早くて確実です。

ツールに頼りすぎる

デイリースクラムの場で、Jiraなどのツールを見ながら進めると時間がかかりがちです。 バーンダウンのような全体感を把握するものを見るだけであればそれほどでもありませんが、プロダクトバックログアイテムや個々の作業の詳細まで見ているとすぐに時間がなくなります(そもそも、デイリースクラムは作業中のものを個々にレビューをする場ではありません)。 ツールの操作をしているところをみんなでただ眺めているときほどムダな時間はありません

意味ある情報が伝えられない

デイリースクラムでいちばんやりたいのは、スプリントゴール達成の可能性の検査です。スプリントゴールを達成する上でリスクがある状況であれば、必要に応じて対応策を考えたり、再計画したりします(15分に収まらなさそうな場合は別の場を設定して、速やかに行います)。 これができるような情報を伝えなければいけません。 単に各人が行っている作業の進捗状況だけを報告しても不十分です。 スプリントゴール達成の可能性、作業の開始、停止、完了、見積り超過、個人的な問題などに絞って話すようにし、個々の作業の詳細については必要なときに別途共有するようにしましょう。

詳細を話しすぎる

前項のとおり、スプリントゴール達成の可能性を最適化するのに必要な情報を中心にしましょう。 誰かが詳細を聞きたがったら、それはデイリースクラムの後で話すようにしましょう。 全員が詳細を話しているとデイリースクラムは15分では終わりません。 全員が詳細を話すような状況は、デイリースクラムの時間以外でのスクラムチーム内でのコミュニケーションが不足していることを示唆していますので、それを改善してください。

問題をその場で解決しようとする

デイリースクラムは15分と短いので、その場ですべての問題を解決することはできません。 その場で解決しようとするとタイムボックスを守れなくなってしまいます。 デイリースクラムでは、スプリントゴール達成の可能性を検査するとともに、問題が存在するかどうかを確認し、デイリースクラムのあとで問題に取り組むようにしましょう。 個人の作業に問題がある場合は、誰かから「あとで一緒に見るよ」と聞ければ充分です。 もちろん、ごくごく短時間で解決できる問題はその場で扱っても構いません。

スクラムマスターへの報告会になっている

とくにオンサイトでデイリースクラムをやるときに、開発者全員がスクラムマスターの方を向いて、説明しているのを見かけることがありますが、これは問題です。 デイリースクラムは開発者のためのイベントです。スクラムマスターはデイリースクラムが開催されることに対しては責任を持ちますが、スプリントゴールの達成や個々の進捗について責任を持つわけではありません。 進捗は開発者が自己管理すべきです。 開発者だけでデイリースクラムを実施できるようになれば、スクラムマスターはデイリースクラムに参加しなくて構いません。

スクラムチーム以外の人の割り込み

デイリースクラムは開発者のためのイベントです。 開発者の合意なしに他の人が割り込むのは、デイリースクラムの目的の達成を阻害する可能性があります。 たとえば、スクラムチーム外のステークホルダーがやってきて進捗を確認する、といったことがないようにしてください。なお、このような外部からの頻繁な進捗管理を誘発している理由の1つに、スクラムチームとしてインクリメントを毎スプリント届けられていないことが挙げられます。これは不安を招き、マイクロマネジメントを誘発しやすいので注意が必要です。

それでは。

アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください(初回相談無料)
前の記事 スプリントレビューの進め方
次の記事 【資料公開】ステークホルダーとの付き合い方を考える

プロダクト開発で、こんな課題を感じていませんか?

  • 何を作るべきか、順位の決め方が定まらない
  • プロダクトの方向性をチームで共有できていない
  • 開発組織の体制や役割がうまく機能していない
  • 開発プロセスが形骸化し、目的を見失っている
  • アジャイルを導入したが、組織に定着しない

プロダクトマネジメント、組織構造、開発プロセスの課題について、組織全体の視点から支援します。

お問い合わせ(初回相談無料)

契約を前提にした相談でなくて構いません。相談に際して事前の整理や準備は不要です。

Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方
ダイナミックリチーミング 第2版
Tidy First?
脳に収まるコードの書き方
プロダクトマネージャーのしごと 第2版
エンジニアリングマネージャーのしごと
チームトポロジー
スクラム実践者が知るべき97のこと
プロダクトマネジメント
SCRUM BOOT CAMP THE BOOK
みんなでアジャイル
レガシーコードからの脱却
Effective DevOps
変革の軌跡
ジョイ・インク
アジャイルコーチの道具箱
カンバン仕事術
Software in 30 Days
How to Change the World