ブログ

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

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

みなさんこんにちは、@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つに、スクラムチームとしてインクリメントを毎スプリント届けられていないことが挙げられます。これは不安を招き、マイクロマネジメントを誘発しやすいので注意が必要です。

それでは。

アジャイルコーチングやトレーニングを提供しています

株式会社アトラクタでは、アジャイル開発に取り組むチーム向けのコーチングや、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください。

詳細はこちら
  • スクラム実践者が知るべき97のこと
  • 著者/訳者:Gunther Verheyen / 吉羽龍太郎 原田騎郎 永瀬美穂
  • 出版社:オライリージャパン(2021-03-23)
  • 定価:¥ 2,640
  • スクラムはアジャイル開発のフレームワークですが、その実装は組織やチームのレベルに応じてさまざまです。本書はスクラムの実践において、さまざまな課題に対処してきた実践者が自らの経験や考え方を語るエッセイ集です。日本語書き下ろしコラムを追加で10本収録
  • プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
  • 著者/訳者:Melissa Perri / 吉羽龍太郎
  • 出版社:オライリージャパン(2020-10-26)
  • 定価:¥ 2,640
  • プロダクト開発を作った機能の数やベロシティなどのアウトプットで計測すると、ビルドトラップと呼ばれる失敗に繋がります。本書ではいかにしてビルドトラップを避けて顧客に価値を届けるかを解説しています。
  • SCRUM BOOT CAMP THE BOOK 【増補改訂版】
  • 著者/訳者:西村直人 永瀬美穂 吉羽龍太郎
  • 出版社:翔泳社(2020-05-20)
  • 定価:¥ 2,640
  • スクラム初心者に向けて基本的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。
  • みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた
  • 著者/訳者:Matt LeMay / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン(2020-3-19)
  • 定価:¥ 2,640
  • アジャイルで本当の意味での成果を出すには、開発チームだけでアジャイルに取り組むのではなく、組織全体がアジャイルになる必要があります。本書にはどうやってそれを実現するかのヒントが満載です
  • レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
  • 著者/訳者:David Scott Bernstein / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン( 2019-9-18 )
  • 定価:¥ 3,132
  • レガシーコードになってから慌てるのではなく、日々レガシーコードを作らないようにするにはどうするか。その観点で、主にエクストリームプログラミングに由来する9つのプラクティスとその背後にある原則をわかりやすく説明しています。
  • Effective DevOps ―4本柱による持続可能な組織文化の育て方
  • 著者/訳者:Jennifer Davis、Ryn Daniels / 吉羽 龍太郎、長尾高弘
  • 出版社:オライリージャパン( 2018-3-24 )
  • 定価:¥ 3,888
  • 主にDevOpsの文化的な事柄に着目し、異なるゴールを持つチームが親和性を高め、矛盾する目標のバランスを取りながら最大限の力を発揮する方法を解説します
  • ジョイ・インク 役職も部署もない全員主役のマネジメント
  • 著者/訳者:リチャード・シェリダン / 原田騎郎, 安井力, 吉羽龍太郎, 永瀬美穂, 川口恭伸
  • 出版社:翔泳社( 2016-12-20 )
  • 定価:¥ 1,944
  • 米国で何度も働きやすい職場として表彰を受けているメンローの創業者かつCEOであるリチャード・シェリダン氏が、職場に喜びをもたらす知恵や経営手法、より良い製品の作り方などを惜しみなく紹介しています
  • アジャイルコーチの道具箱 – 見える化の実例集
  • 著者/訳者:Jimmy Janlén / 原田騎郎, 吉羽龍太郎, 川口恭伸, 高江洲睦, 佐藤竜也
  • 出版社:Leanpub( 2016-04-12 )
  • 定価:$14.99
  • この本は、チームの協調とコミュニケーションを改善したり、行動を変えるための見える化の実例を集めたものです。96個(+2)の見える化の方法をそれぞれ1ページでイラストとともに解説しています。アジャイル開発かどうかに関係なくすぐに使えるカタログ集です
  • カンバン仕事術 ―チームではじめる見える化と改善
  • 著者/訳者:原田騎郎 安井力 吉羽龍太郎 角征典 高木正弘
  • 出版社:オライリージャパン( 2016-03-25 )
  • 定価:¥ 2,138
  • チームの仕事や課題を見える化する手法「カンバン」について、その導入から実践までを図とともにわかりやすく解説した書籍。カンバンの原則などの入門的な事柄から、サービスクラス、プロセスの改善など、一歩進んだ応用的な話題までを網羅的に解説します。
  • Software in 30 Days スクラムによるアジャイルな組織変革“成功"ガイド
  • 著者/訳者:Ken Schwaber、Jeff Sutherland著、角征典、吉羽龍太郎、原田騎郎、川口恭伸訳
  • 出版社:アスキー・メディアワークス( 2013-03-08 )
  • 定価:¥ 1,680
  • スクラムの父であるジェフ・サザーランドとケン・シュエイバーによる著者の日本語版。ビジネス層、マネジメント層向けにソフトウェア開発プロセス変革の必要性やアジャイル型開発プロセスの優位性について説明
  • How to Change the World 〜チェンジ・マネジメント3.0〜
  • 著者/訳者:Jurgen Appelo, 前川哲次(翻訳), 川口恭伸(翻訳), 吉羽龍太郎(翻訳)
  • 出版社:達人出版会
  • 定価:500円
  • どうすれば自分たちの組織を変えられるだろう?それには、組織に変革を起こすチェンジ・マネジメントを学習することだ。アジャイルな組織でのマネージャーの役割を説いた『Management 3.0』の著者がコンパクトにまとめた変化のためのガイドブック