Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
スクラムガイドを踏まえた実践についての考え方
Search
Hiroyuki Kusu
October 03, 2026
Business
23
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
スクラムガイドを踏まえた実践についての考え方
Hiroyuki Kusu
October 03, 2026
More Decks by Hiroyuki Kusu
See All by Hiroyuki Kusu
モノレポのプルリクエストに最近、導入したもの
hkusu
2
600
GitHub composite actions
hkusu
2
470
Android の静的解析における SARIF ファイルの活用
hkusu
0
5.7k
CI_でライブラリのバージョンの変化をレポートする.pdf
hkusu
0
430
Maestro を GitHub Actions で動かす 〜Android編〜
hkusu
1
1.8k
Android の CI(GitHub Actions)の改善で、最近やったこと
hkusu
0
750
Tauri Mobile で生成される Android のコードを見てみる
hkusu
0
1.6k
Custom GitHub Actions を作って Organization 内で共有する
hkusu
1
620
GitHub Actions でユニットテストの結果をレポートする
hkusu
0
4k
Other Decks in Business
See All in Business
FY2026.6 Impact Report EN
mercari_inc
0
6.3k
会社紹介資料/Idein株式会社
ideininc
0
1.2k
Hubble Company Deck
hubbleinc
0
140
reiwatravel ai era
reiwatravel_0405
0
1.2k
採用広報資料_2026年9月.pdf
gw_recruit
0
2.6k
丸石グループ会社紹介
maruishi
0
190
20260806financial-results-presentation
sios3744
0
230
PLAID ALPHA概要資料_202608
plaid
PRO
0
630
LW_brochure_engineer
lincwellhr
1
45k
kintone-ai-first-steps.pdf
kintonepapers
0
170
AIがなくてもつよいPM/PdM/ディレクターになるには?
iflection
0
1k
malna-recruiting-pitch
malna
0
27k
Featured
See All Featured
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
10k
Why You Should Never Use an ORM
jnunemaker
PRO
61
10k
Reality Check: Gamification 10 Years Later
codingconduct
0
2.3k
Joys of Absence: A Defence of Solitary Play
codingconduct
1
530
Heart Work Chapter 1 - Part 1
lfama
PRO
10
36k
SEO for Brand Visibility & Recognition
aleyda
0
4.8k
How Fast Is Fast Enough? [PerfNow 2025]
tammyeverts
3
910
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.8k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
Highjacked: Video Game Concept Design
rkendrick25
PRO
1
470
Bash Introduction
62gerente
615
220k
How GitHub (no longer) Works
holman
316
150k
Transcript
スクラムガイドを踏まえた、実践についての考え方 スクラムは、複雑な課題にチームで取り組み、価値を生み出すための「型」です。その基本は、短い文書であるスクラムガイ ドにまとめられており、仕組み自体はシンプルです。ただし、理解することと、実践して成果につなげることには違いがあり ます。 各要素には意味があり、その目的を理解して型に沿って実践することは大切です。ただし、型を守ること自体が目的にならな いようにすることも重要です。その実践が、問題の発見や学習、改善につながっているかを確認する必要があります。 目指すのは、実際の成果や利用者・関係者の反応から学び、よりよい価値を届けることです。そのために、作るものや日々の 仕事の進め方を見直し、個人とチームの能力を高め、連携を深めていきます。スクラムは、こうした学習と改善を継続するた めの枠組みです。
スプリントゴールと継続的な改善 スクラムでは、スプリントゴールの達成に向けて、チームで真剣に取り組むことが大切です。一方、不確実な開発では、実際 に取り組んで初めて分かることもあり、当初の見通しどおりに進まない場合があります。 スプリントレビューでは、ゴールの達成状況や実際の成果、未達成の場合の背景と影響を事実に基づいて共有し、関係者と次 の対応や優先順位を話し合います。原因の確認も、その判断に必要な範囲で行います。 レトロスペクティブでは、計画や連携、仕事の進め方を詳しく振り返り、具体的な改善につなげます。改善の対象には、技術 やチームの連携だけでなく、ゴールの大きさ、作業範囲、不確実性の確かめ方も含まれます。挑戦的な計画であれば、その前 提や実現可能性も見直します。 ゴールの達成を目指すことと、安心して問題を共有し、粛々と改善を重ねることは両立します。実際に分かったことを次の行 動に反映し、より確実に価値を届けられるようになることが、スクラムを実践するうえで大切な姿勢です。
学習と裁量について 学習について 開発に必要な言語や技術の学習は、仕事を進めるための活動として考えるのが自然です。習得に必要な時間や支援を計画に含 め、調査、試作、ペア作業、レビューなどを通じて理解を深めます。 個人が学ぶ姿勢と、チームが学習を支えることは両立します。必要な学習を個人の私生活だけに委ねず、業務の中で能力を高 められるようにすることが大切です。 学習目標は、必ずしもスプリントゴールにする必要はありません。チームとして実現したい成果をゴールに据え、そのために 必要な学習時間や支援を作業計画に組み込みます。 裁量について チームや個人が状況に応じて仕事を進めるには、方法や順序を判断できる裁量が必要です。細かな作業指示で動きを固定し、
時間を隙間なく割り当てると、調査や相談、新しく分かったことへの対応が難しくなります。 目的、優先順位、品質、必要な制約を共有したうえで、具体的な進め方は担当者やチームが調整できるようにします。裁量は 任せきりにすることではなく、進捗や問題を共有しながら判断できることです。また、裁量を実際に使うには、考えたり相談 したりできる時間的な余裕も必要です。
コード改善とリファクタリング スプリントゴールに直接関係しないコード改善やリファクタリングも、行うことができます。ゴールはチームが集中する目的 を示すものであり、品質の維持や今後の開発に必要なすべての作業を列挙するものではありません。 改善に取り組む際は、保守性の向上、不具合リスクの低減、今後の変更を容易にすることなど、プロダクトにとっての意味を 明確にします。必要な時間を作業計画に織り込み、チームで共有することが大切です。 実装に伴う小さなリファクタリングは、開発作業の一部として開発者が必要性を判断します。独立した大規模な改善は、目的・ 効果・リスク・作業量を明らかにし、プロダクトバックログでプロダクトオーナーと優先順位を相談します。 ゴールへの集中を保ち、達成を危うくするほど変更を広げないことも重要です。影響が大きくなりそうな場合は、早めに共有 し、作業範囲や実施時期を調整します。ゴールに書かれているかだけで可否を決めず、必要性と優先順位を共有して取り組み ます。