-
Yoshiba Ryutaro
- 2026/01/06 11:02
- Scrum
- 2805
- 2627
- Show Slide Vertically
- Show Embedded Code
Tidy First? ―個人で実践する経験主義的ソフトウェア設計
- 著者/訳者:Kent Beck、 吉羽 龍太郎、 永瀬 美穂、 細澤 あゆみ
- 出版社:オライリー・ジャパン
- 発売日:2024-12-25
- 単行本(ソフトカバー):164ページ
- ISBN-13:9784814400911
- ASIN:4814400918
脳に収まるコードの書き方 ―複雑さを避け持続可能にするための経験則とテクニック
- 著者/訳者:Mark Seemann、 吉羽 龍太郎、 原田 騎郎、 Robert C. Martin
- 出版社:オライリー・ジャパン
- 発売日:2024-06-18
- 単行本(ソフトカバー):312ページ
- ISBN-13:9784814400799
- ASIN:4814400799
Transcript
1.
デイリースクラム Deep Dive 2026/1/7 Regional Scrum Gathering Tokyo 2026 fi 株式会社アトラクタ / Certi ed Scrum Trainer (CST) 吉羽 龍太郎 (@ryuzee)
2.
自己紹介 吉羽龍太郎 / Ryutaro YOSHIBA / ryuzee ▸ 株式会社アトラクタCTO /アジャイルコーチ / 翻訳者 ▸ Scrum Alliance 認定スクラムトレーナー (CST) 認定チームコーチ (CTC) ▸ Microsoft MVP (DevOps) ▸ X(Twitter): @ryuzee ブログ: https://www.ryuzee.com/ 2
3.
自己紹介 最新書籍紹介(買ってください!!) 3
4.
自己紹介 過去のDeep Diveシリーズ ▸ スプリントレトロスペクティブ Deep Dive ▸ ベロシティ Deep Dive ▸ スプリントレビュー Deep Dive ▸ スプリントプランニング Deep Dive ▸ プロダクトバックログ Deep Dive ▸ https://www.ryuzee.com/scrum-deep-dive/ 4
5.
デイリースクラム Deep Dive 今日のテーマ ▸ 今日のテーマは「デイリースクラム」 ▸ 「朝会」ではない ▸ 用語は正しく使う ▸ 「名前を付けることが知識の始まり」(アリストテレス『範疇論』) ▸ 物事を正しく理解し、知識として整理するには、それぞれの対象に適切な名前を与えることが必要 ▸ 既存の概念と区別するために、スクラムは意図的に既存の用語とは違う用語を用いている ▸ 既存の別の単語で置き換えてしまうと、目的への集中が薄まり、余計なコンテキストが増える 5
6.
デイリースクラム Deep Dive 2020年版のスクラムガイドは473文字(2017年版は973文字。当社調べ) 6
7.
デイリースクラム Deep Dive 2020年版の変更による影響 ▸ 全体的に分量が削減された ▸ 指示的な要素が減った ▸ つまり、実践者自身で考えることを強く求めるようになった ▸ たとえば3本柱、価値基準、アジャイルマニフェストと12の原則などをベースに考える ▸ 過去のスクラムガイドは考えるときに非常に参考になる 7
8.
デイリースクラム Deep Dive 8 デイリースクラムとは? デイリースクラムの目的は、計画された今後の作業を調整しながら、スプリントゴールに対 する進捗を検査し、必要に応じてスプリントバックログを適応させることである。 デイリースクラムは、スクラムチームの開発者のための15分のイベントである。複雑さを低 減するために、スプリント期間中は毎日、同じ時間・場所で開催する。 プロダクトオーナーま たはスクラムマスターがスプリントバックログのアイテムに積極的に取り組んでいる場合 は、開発者として参加する。 -- スクラムガイド2020
9.
デイリースクラム Deep Dive 9 デイリースクラムとは? ▸ 検査と適応のための正式なイベントの1つ ▸ スクラムガイド2020の原文を読むともっとよくわかる ▸ The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. ▸ 目的は2つ ▸ スプリントゴールに向けた進捗を検査する ▸ 必要に応じてスプリントバックログを適応する(今後予定している作業を調整する) ▸ 2017 「スプリントゴールとスプリントバックログの進捗を検査する」とあるが、スプリントゴールを検査 するにはスプリントバックログを見るので、記述が簡素化された
10.
デイリースクラム Deep Dive 10 なぜスプリントゴールへの進捗の検査なのか? ▸ スクラムガイド2020 「スプリントゴールはスプリントの唯一の目的である」 ▸ 選択したプロダクトバックログアイテムをすべて終わらせることは目的ではない ▸ 洗い出したタスクをすべて終わらせることも目的ではない ▸ 作業に柔軟性を持たせることで、スプリントゴール達成の可能性を向上させる ▸ スクラムガイド2020 「スプリントゴールは開発者が確約する」 ▸ 「スクラムチーム全体が、スプリントごとに価値のある有用なインクリメントを作成する責任を持つ」 ので、スプリントでインクリメントを作成し、スプリントゴールを達成するように全力を尽くす ▸ 確約するからには、スプリントゴールを達成できるかどうかは最大の関心事なので、検査する
11.
デイリースクラム Deep Dive 必要に応じてスプリントバックログを適応する ▸ 作業の追加や削除 11 これらは必要に応じて行う。 またデイリースクラムのときしかできな いわけではない ▸ スプリントゴール達成に必要な作業を追加し、不要になった作業を削除する ▸ 作業内容の見直し ▸ 新しい学びや状況の変化に基づいて、作業のスコープややり方を調整する ▸ 作業の順番の見直し ▸ スプリントゴール達成の可能性を高めるために、どの作業に先に取り組むべきかを再計画する ▸ 進め方やこれから1日の実行計画の見直し ▸ 次のデイリースクラムまでの進め方を合意する(分担、協力方法、タスク分割など) スプリントバックログは静的な計画ではない。スプリント中にずっと変わり続ける
12.
デイリースクラム Deep Dive デイリースクラムの参加者 ▸ デイリースクラムは開発者のためのイベント ▸ すなわち開発者全員 ▸ プロダクトオーナーやスクラムマスターが開発者の仕事をしている場合は開発者として参加する ▸ プロダクトオーナーやスクラムマスターは参加するのかしないのか? 12
13.
デイリースクラム Deep Dive 13 デイリースクラムにプロダクトオーナーは参加するのか? ▸ スクラムガイドの記述には変遷がある ▸ 2016 「スクラムマスターは、デイリースクラムには開発チームのメンバーしか参加できないという ルールを遵守する」 ▸ 2017 「デイリースクラムは開発チームのためのミーティングである。 それ以外の人たちが参加す る場合、開発チームの邪魔にならないようにスクラムマスターが配慮する」 ▸ 2020 「開発者は、(中略)必要な構造とやり方を選択できる」 ▸ 「遵守」→「配慮」→「選択」と推移していて、自己管理の一環になった ▸ すなわち開発者自身の意志でプロダクトオーナーの参加を決定すればよいとするのが妥当
14.
デイリースクラム Deep Dive 14 デイリースクラムにスクラムマスターは参加するのか? ▸ プロダクトオーナーの参加のときの原則はそのまま有効だが、スクラムマスターには責任がある ▸ スクラムガイド2020 ▸ 「スクラムマスターは、スクラムガイドで定義されたスクラムを確立させることの結果に責任を持つ (略)スクラムの理論とプラクティスを全員に理解してもらえるよう支援することで、その責任を果た す」 ▸ 「すべてのスクラムイベントが開催され、ポジティブで生産的であり、タイムボックスの制限が守ら れるようにする」 ▸ その責任を果たすために参加することはある(とくに初期)が、必須ではない ▸ スクラムマスターが常に参加していることによって別の問題(自己管理の阻害等)を生むこともある
15.
デイリースクラム Deep Dive 15 デイリースクラムのタイムボックス ▸ スクラムガイド2020 「デイリースクラムは、スクラムチームの開発者のための15分のイベントである。複 雑さを低減するために、スプリント期間中は毎日、同じ時間・場所で開催する」 ▸ タイムボックスなので上限が15分 (スクラムの基本はタイムボックス) ▸ 15分以内を厳守。15分に収まらないのはやり方が悪い ▸ 割れ窓理論にあるように、延長グセはすべてに伝搬し、スクラムチームの有効性に著しい悪影響 ▸ デイリースクラム終了後に必要なら別の場を設定してよい ▸ 毎日同じ時間に同じ場所で開催する ▸ 別に朝でなければいけないわけではない (ある会社では昼前に実施。参加しやすい時間がよい) ▸ 他のスクラムイベントも複雑さを避けるために同じ時間・同じ場所が推奨
16.
デイリースクラム Deep Dive タイムボックスを守るためには? ▸ 軽微な問題はデイリースクラムで解決しても構わない ▸ だが、詳細まで踏み込んで議論を始めてしまうと、あっというまに時間がなくなってしまう ▸ 通常は問題の存在の確認と進め方の方針を決めるまでにとどめる ▸ 「デイリースクラム後にAさんとBさんで会話する」 ▸ 「今日の午後全員でモブプログラミングして対処する」 ▸ 参加者全員がタイムボックスを守る責任を共有する ▸ 誰でも途中で話を止めるように提案してよい ▸ 2人挙手ルール(同時に2人が手を挙げたら、その話題を終了する)などのテクニックもある 16
17.
デイリースクラム Deep Dive 17 デイリースクラム以外でも必要に応じて頻繁に話して再計画せよ デイリースクラムは、コミュニケーションを改善し、障害物を特定し、迅速な意思決定を促進 する。 その結果、他の会議を不要にする。 開発者が計画を調整できるのは、デイリースクラムのときだけではない。 スプリントの残り の作業を適応または再計画することについて、より詳細な議論をするために、開発者は一日 を通じて頻繁に話し合う。 -- スクラムガイド2020 うまくいっていないチームの多くが、イベント以外の時間でのインタ ラクション不足。デイリースクラムでしか話をしていないのは危険信号
18.
デイリースクラム Deep Dive 18 デイリースクラムの進め方は開発者が決める(ただしタイムボックスは守る) 開発者は、デイリースクラムがスプリントゴールの進捗に焦点をあて、これからの1日の作 業の実行可能な計画を作成する限り、必要な構造とやり方を選択できる。 これは集中を生 み出し、自己管理を促進する。 -- スクラムガイド2020 やり方はいろいろある!
19.
デイリースクラム Deep Dive 古典的なやり方(スクラムガイド2017まで) ▸ 3つの質問(2016までは「以下のことを説明する」。2017は例としての扱い) ▸ 「開発チームがスプリントゴールを達成するために、私が昨日やったことは何か?」 ▸ 「開発チームがスプリントゴールを達成するために、私が今日やることは何か?」 ▸ 「私や開発チームがスプリントゴールを達成する上で、障害となる物を目撃したか?」 ▸ これには構造上の問題がある ▸ そもそもスプリントゴールを達成できそうかどうかに言及していない ▸ 質問が個人へのフォーカスを誘発しやすい (無関心が起こりやすい) ▸ 開発者が増えるほど時間がかかりやすい 19
20.
デイリースクラム Deep Dive 別のやり方: PBI by PBI ▸ スプリントバックログに含めているプロダクトバックログアイテム(PBI)を1つずつ順に取り上げる ▸ 各PBIについて「現在の状態」「進捗」「障害」「次にやること」を全員で確認する ▸ PBIが「完成」に近づいているか、スプリントゴールにどう貢献するかを話し合う ▸ 進捗が思わしくないPBI は、原因や必要な支援を明確にする ▸ 必要であれば、タスクの追加・削除・分割・順番変更など、スプリントバックログを適応する ▸ 新しく判明した仕事やリスクがあれば、その場でスプリントバックログに反映する ▸ PBIごとに確認するため、状況が可視化され、スプリントゴールとの整合性を常に検査できる ▸ 最終的に、次の24時間の作業計画をPBI単位で決定する 20
21.
デイリースクラム Deep Dive 別のやり方: スプリントゴールチェックイン ▸ 最初に誰かが「このままいけばスプリントゴールを達成できそうか?」と開発者全体に問いかける ▸ 「はい」「いいえ」「微妙」の3種類のサインで挙手する ▸ 「いいえ」や「微妙」がいる場合は、「何が懸念か?」「何を変えれば達成できるか?」を話す ▸ それを踏まえて、必要に応じてプロダクトバックログアイテムや作業計画を変更する ▸ 次の24時間の動きを決めて終了する 21
22.
デイリースクラム Deep Dive モブプログラミングとデイリースクラム ▸ 生成AIの利用が増えるにつれて、以下のような変化が起こる ▸ チームサイズが小さくなる ▸ 並列作業の必要性が下がりモブプログラミングを多く行う ▸ この場合、常にコミュニケーションして、検査と適応を繰り返している ▸ すなわちデイリースクラム相当のことを頻繁に行っていると言える ▸ 正式なイベントとしてのデイリースクラムはすぐに終わる ▸ タイムボックスなので早く終わって構わない ▸ (イベントによって定点チェックのリズムを作り忘れないようにする) 22
23.
デイリースクラム Deep Dive デイリースクラムの事前準備 ▸ 準備もせずに臨むと15分はあっというまに終わる ▸ 「えーっと何してたっけ」みたいな時間は全員にとってムダな時間 ▸ 開始前に短時間で構わないので個人で準備をしておく (準備の内容も検査と適応) ▸ このままいくとスプリントゴールを達成できそうか? ▸ スプリントゴールの達成を脅かすようなリスクや懸念があるか? ▸ 自分が着手している作業はどのような状況か? ▸ 他の人の助けが必要なことがないか? ▸ スクラムボードなどの状況を最新にしておく 23
24.
デイリースクラム Deep Dive デイリースクラムのよくあるアンチパターン ▸ 毎日、同じ時間に、同じ場所で開催していない ▸ 時間を延長する ▸ 準備をせずに参加する ▸ 会話せずメールやチャットで代用する ▸ Jiraなどのツールに頼りすぎる ▸ スプリントゴール達成の可能性に触れない ▸ 詳細を話しすぎる ▸ 問題をその場で解決しようとする ▸ スクラムマスターへの報告会になっている 24
Comment
No comments...
Related Slides
本資料は、2021年1月7日に行われたRegional Scrum Gathering Tokyo 2021のセッション 『スクラムにおける「完成」とはな...
2025/12/14 | 39 pages | 323 views
2025/1/8のRegional Scrum Gathering Tokyo 2025の登壇資料です
2025/01/08 | 44 pages | 19029 views
2024/1/10に行われたRegional Scrum Gathering Tokyoでの登壇資料です
2024/01/10 | 40 pages | 34351 views
6/20に技術顧問先で話したときの資料です
2023/06/21 | 31 pages | 18904 views
2023年1月11-13日に行われたRegional Scrum Gathering Tokyo 2023の登壇資料です。再配布や複製等はご遠慮ください。...
2023/01/11 | 51 pages | 44469 views
2022年8月26-27日に行われたScrum Fest Sendai 2022の登壇資料です。再配布や複製等はご遠慮ください。共有したい場合は本ページの...
2022/08/27 | 46 pages | 32552 views
2022年1月5-7日に行われたRegional Scrum Gathering Tokyo 2022の登壇資料です。再配布や複製等はご遠慮ください。共有...
2022/01/07 | 64 pages | 70863 views
2021/1/7にRegional Scrum Gathering Tokyoで発表したときの資料です
2021/01/07 | 40 pages | 21860 views
とあるプライベート講演で、SI案件でアジャイルを適用する際に重要になってくるポイントについて話をしました。
2020/12/18 | 66 pages | 30790 views
2020/1/20にプライベート講演で、マネジメント層向けにアジャイル開発の概要を説明した際の資料です。
2020/01/20 | 53 pages | 50954 views
2020/1/8のRegional Scrum Gathering Tokyo 2020での登壇資料です
2020/01/07 | 29 pages | 25354 views
2019/2/23にScrum Fest Osakaで登壇した際の資料です #scrumosaka
2019/02/21 | 53 pages | 29725 views
Embedded Code





