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
19
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
610
GitHub Actions でユニットテストの結果をレポートする
hkusu
0
4k
Other Decks in Business
See All in Business
なぜデベロッパーアドボカシーが必要なのか?
taiponrock
PRO
0
190
株式会社レボルト採用deck
takemura_yuto
0
210
スピーチ公開:続けることが、いちばんの機会になる(プログリット感謝祭2026)
forest8810
0
470
【株式会社VISIONARY JAPAN】エンジニアチーム採用ピッチ資料_202609
visionaryjapan1
0
130
アッテル会社紹介資料/culture deck
attelu
11
17k
freeeの福利厚生と働き方
freee
PRO
1
110k
20260828_15minLT_データ分析10倍時代を考える
doradora09
PRO
0
990
AI時代の開発体制論 — 人から人へのプルリクはもう要らない
noritaka88tax
0
160
カンパニーデック_260910.pdf
kojima1
0
350
AI × 型|FDE的な働き方を再現可能にする「判断の軸」
aictokamiya
0
160
「仕訳」から「取引」へ(fAD2026)
shunsuke_takeuchi
PRO
0
1.4k
AIがなくてもつよいPM/PdM/ディレクターになるには?
iflection
0
1k
Featured
See All Featured
コードの90%をAIが書く世界で何が待っているのか / What awaits us in a world where 90% of the code is written by AI
rkaga
63
46k
Mozcon NYC 2025: Stop Losing SEO Traffic
samtorres
1
570
[RailsConf 2023] Rails as a piece of cake
palkan
59
7k
Mobile First: as difficult as doing things right
swwweet
225
10k
Efficient Content Optimization with Google Search Console & Apps Script
katarinadahlin
PRO
1
890
Paper Plane
katiecoart
PRO
4
53k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
287
14k
Organizational Design Perspectives: An Ontology of Organizational Design Elements
kimpetersen
PRO
1
840
HDC tutorial
michielstock
2
930
Deep Space Network (abreviated)
tonyrice
0
350
Faster Mobile Websites
deanohume
310
32k
Digital Ethics as a Driver of Design Innovation
axbom
PRO
1
440
Transcript
スクラムガイドを踏まえた、実践についての考え方 スクラムは、複雑な課題にチームで取り組み、価値を生み出すための「型」です。その基本は、短い文書であるスクラムガイ ドにまとめられており、仕組み自体はシンプルです。ただし、理解することと、実践して成果につなげることには違いがあり ます。 各要素には意味があり、その目的を理解して型に沿って実践することは大切です。ただし、型を守ること自体が目的にならな いようにすることも重要です。その実践が、問題の発見や学習、改善につながっているかを確認する必要があります。 目指すのは、実際の成果や利用者・関係者の反応から学び、よりよい価値を届けることです。そのために、作るものや日々の 仕事の進め方を見直し、個人とチームの能力を高め、連携を深めていきます。スクラムは、こうした学習と改善を継続するた めの枠組みです。
スプリントゴールと継続的な改善 スクラムでは、スプリントゴールの達成に向けて、チームで真剣に取り組むことが大切です。一方、不確実な開発では、実際 に取り組んで初めて分かることもあり、当初の見通しどおりに進まない場合があります。 未達成になったときは、その事実と影響を率直に共有し、何が想定と違ったのかを確認します。具体的な行動や判断、それを 取り巻く条件を振り返り、次に必要な改善や支援を考えます。 改善の対象には、技術やチームの連携だけでなく、ゴールの大きさ、作業範囲、不確実性の確かめ方、計画の立て方も含まれ ます。挑戦的な計画を立てたのであれば、その前提や実現可能性も含めて見直すことが重要です。 ゴールの達成を目指すことと、安心して問題を共有し、粛々と改善を重ねることは両立します。型どおりに活動するだけで満 足せず、実際に分かったことを次の行動に反映し、より確実に価値を届けられるようになることが、スクラムを実践するうえ で大切な姿勢です。
学習と裁量について 学習について 開発に必要な言語や技術の学習は、仕事を進めるための活動として考えるのが自然です。習得に必要な時間や支援を計画に含 め、調査、試作、ペア作業、レビューなどを通じて理解を深めます。 個人が学ぶ姿勢と、チームが学習を支えることは両立します。必要な学習を個人の私生活だけに委ねず、業務の中で能力を高 められるようにすることが大切です。 学習目標は、必ずしもスプリントゴールにする必要はありません。チームとして実現したい成果をゴールに据え、そのために 必要な学習時間や支援を作業計画に組み込みます。 裁量について チームや個人が状況に応じて仕事を進めるには、方法や順序を判断できる裁量が必要です。細かな作業指示で動きを固定し、
時間を隙間なく割り当てると、調査や相談、新しく分かったことへの対応が難しくなります。 目的、優先順位、品質、必要な制約を共有したうえで、具体的な進め方は担当者やチームが調整できるようにします。裁量は 任せきりにすることではなく、進捗や問題を共有しながら判断できることです。また、裁量を実際に使うには、考えたり相談 したりできる時間的な余裕も必要です。
コード改善とリファクタリング スプリントゴールに直接関係しないコード改善やリファクタリングも、行うことができます。ゴールはチームが集中する目的 を示すものであり、品質の維持や今後の開発に必要なすべての作業を列挙するものではありません。 改善に取り組む際は、保守性の向上、不具合リスクの低減、今後の変更を容易にすることなど、プロダクトにとっての意味を 明確にします。必要な時間を作業計画に織り込み、チームで共有することが大切です。 実装に伴う小さなリファクタリングは、開発作業の一部として開発者が必要性を判断します。独立した大規模な改善は、目的・ 効果・リスク・作業量を明らかにし、プロダクトバックログでプロダクトオーナーと優先順位を相談します。 ゴールへの集中を保ち、達成を危うくするほど変更を広げないことも重要です。影響が大きくなりそうな場合は、早めに共有 し、作業範囲や実施時期を調整します。ゴールに書かれているかだけで可否を決めず、必要性と優先順位を共有して取り組み ます。