Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
定期的な価値提供だけじゃない、スクラムが導くチームの共創化 / 20251004 Naoki ...
Search
SHIFT EVOLVE
PRO
October 03, 2025
Technology
0
4
定期的な価値提供だけじゃない、スクラムが導くチームの共創化 / 20251004 Naoki Takahashi
2025/10/4 スクラム祭り2025
https://www.scrummatsuri.org/
株式会社SHIFT
製造ソリューションサービス部
髙橋 直規
SHIFT EVOLVE
PRO
October 03, 2025
Tweet
Share
More Decks by SHIFT EVOLVE
See All by SHIFT EVOLVE
空間を設計する力を考える / 20251004 Naoki Takahashi
shift_evolve
PRO
0
3
トラウマ・コンプレックスを乗り越え、成長への道筋を見出す / 20250925 Ryo Tashiro
shift_evolve
PRO
2
76
一歩踏み出すだけで、世界は変わる / 20250925 Kazuki Mori
shift_evolve
PRO
3
340
ふりかえりVPCピアリング~実は奥深いサービス~ / 20250927 Masaki Okuda
shift_evolve
PRO
2
87
レトロスペクティブの改善のためにやってみたこと / 20250910 Nagisa Kabayama
shift_evolve
PRO
4
12
スクラムマスターの成果物はよいチーム ~人事とアジャイルの共通点~ / 20250916 Masato Mishina
shift_evolve
PRO
3
100
開発現場での実践的なUXの考え方・構築のアプローチと UXコンサルタントのアドバイス! / 20250912 Suguru Ishii
shift_evolve
PRO
2
34
AIでテストケースを作成するジレンマ / 20250912 Suguru Ishii
shift_evolve
PRO
2
45
開発・テストの経験って「UX評価」に役立つの? / 20250912 Mayumi Takahashi
shift_evolve
PRO
2
25
Other Decks in Technology
See All in Technology
バイブコーディングと継続的デプロイメント
nwiizo
2
340
業務でAIの力を最大限に発揮するために #弁護士ドットコム
bengo4com
0
290
履歴 on Rails: Bitemporal Data Modelで実現する履歴管理/history-on-rails-with-bitemporal-data-model
hypermkt
0
1.7k
AI×Data×SaaS×Operation
sansantech
PRO
0
100
GC25 Recap+: Advancing Go Garbage Collection with Green Tea
logica0419
1
300
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
11
77k
Deep Research と NotebookLM を使い倒す!レガシーリプレイスの技術選定と学習コスト削減術
tet0h
0
2.8k
pprof vs runtime/trace (FlightRecorder)
task4233
0
140
フルカイテン株式会社 エンジニア向け採用資料
fullkaiten
0
9k
GopherCon Tour 概略
logica0419
2
160
2重リクエスト完全攻略HANDBOOK / Double Request Handbook
shoheimitani
5
7k
Flaky Testへの現実解をGoのプロポーザルから考える | Go Conference 2025
upamune
1
280
Featured
See All Featured
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.1k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.5k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
1.6k
Thoughts on Productivity
jonyablonski
70
4.8k
Imperfection Machines: The Place of Print at Facebook
scottboms
269
13k
Typedesign – Prime Four
hannesfritz
42
2.8k
Raft: Consensus for Rubyists
vanstee
139
7.1k
Visualization
eitanlees
148
16k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.1k
Git: the NoSQL Database
bkeepers
PRO
431
66k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
How to Think Like a Performance Engineer
csswizardry
27
2k
Transcript
定期的な価値提供だけじゃない、 スクラムが導くチームの共創化 2025.10.04 スクラム祭り2025 髙橋直規 #scrummatsuri #scrumat 株式会社SHIFT
自己紹介 髙橋直規 / 幡ヶ谷亭直吉 x:@asagayanaoki 出身:神奈川 / 居住:東京 エンジニア歴:18年7か月 今の役割:PjM、PdE
好きな言語:Java 好きな主義:経験主義 好きな思考:プロダクト思考 趣味:アナログレコード、映画鑑賞、マンガ、アニメ 土日の過ごし方:6歳の娘ととにかく遊ぶ(10/2誕)
本日お話すること https://confengine.com/conferences/scrummatsuri/proposal/22743
▪背景・要約 • ウォーターフォールプロジェクトの管理で進める考えが染みついていた。 • スクラムでも成果に注目し、チーム開発という文脈を意識できていなかった。 • スクラムは“機能”だけでなく、 “チーム“という有機体を育てる仕組みだった。 本日お話すること
アジェンダ • 定期的なプロダクト機能のリリースというスクラムに対する理解 • チームでの共創に対する意識の転換 • チーム開発での実践 • まとめ
定期的なプロダクト機能の リリースという スクラムに対する理解
1.定期的なプロダクト機能のリリースというスクラムに対する理解 VUCAの時代。 プロダクトに求められるものは時間とともに移ろいやすい。 VUCA の マ ー ク ( Volatility
) VUCA の マ ー ク ( Uncertainty ) VUCA の マ ー ク ( Complexity ) VUCA の マ ー ク ( Ambiguity ) 変動性 不確実性 複雑性 曖昧性
1.定期的なプロダクト機能のリリースというスクラムに対する理解 ウォーターフォールのように長期計画が必要となる開発プロセスでは、 計画時に欲しかったものがリリースタイミングには不要になる可能性が高い。 計画時 リリース時 VUCA の マ ー ク
( Volatility ) VUCA の マ ー ク ( Uncertainty ) VUCA の マ ー ク ( Complexity ) VUCA の マ ー ク ( Ambiguity )
1.定期的なプロダクト機能のリリースというスクラムに対する理解 計画からリリースまでを小さく刻むスクラムでは、 そうしたプロダクトに対する変動する要求に柔軟に対応ができる。 計画時 リリース時 VUCA の マ ー ク
( Volatility ) VUCA の マ ー ク ( Uncertainty ) VUCA の マ ー ク ( Complexity ) VUCA の マ ー ク ( Ambiguity ) 計画時 リリース時 計画時 リリース時 計画時 リリース時
1.定期的なプロダクト機能のリリースというスクラムに対する理解 結果、スクラムの価値とは、 定期的にプロダクト機能をリリースするサイクルを設けることで、 不確実性の高い時代の要求にプロダクトを追随させることができることにある。
ということは… 1.定期的なプロダクト機能のリリースというスクラムに対する理解
1.定期的なプロダクト機能のリリースというスクラムに対する理解 欲しいものが固定化されており、時代の要求に大きく変動しないプロダクトは 従来のウォーターフォール開発でも十分に効果的であると考えることができる。 計画時 リリース時 VUCA の マ ー ク
( Volatility ) VUCA の マ ー ク ( Uncertainty ) VUCA の マ ー ク ( Complexity ) VUCA の マ ー ク ( Ambiguity )
1.定期的なプロダクト機能のリリースというスクラムに対する理解 私のスクラムに対する理解 要求の変動性が高い:スクラムが効果的 要求の変動性が低い:ミニウォーターフォールのような開発でもよい気がする プロダクトに求められる要求の属性によって、 開発プロセスは適切に選択すべきだと考えていた。
チームでの 共創に対する意識の転換
2.チームでの共創に対する意識の転換 ある日のSlack上でのアジャイルコーチとのやり取り アジャイルコーチ
2.チームでの共創に対する意識の転換 アジャイルコーチ 参考:実は相性が悪い「開発生産性」と「アジャイル」。うまくいかない開発を好転させるためにPMがやるべきこととは【ryuzee|吉羽龍太郎】 https://levtech.jp/media/article/interview/detail_406/ ある日のSlack上でのアジャイルコーチとのやり取り
2.チームでの共創に対する意識の転換 ある日のSlack上でのアジャイルコーチとのやり取り 参考:実は相性が悪い「開発生産性」と「アジャイル」。うまくいかない開発を好転させるためにPMがやるべきこととは【ryuzee|吉羽龍太郎】 https://levtech.jp/media/article/interview/detail_406/ 吉羽龍太郎さん 「物的生産性を高めたいなら、 ウォーターフォール方式で決まった機能を 決まったように開発すればよくて、 アジャイルを取り入れる必要はないと思います。 」
2.チームでの共創に対する意識の転換 私 我々のプロダクトのバックログは、 事業計画によってほぼ固まっている。 機能実現が優先されており、 アウトカム測定には重きが置かれていない。 ある日のSlack上でのアジャイルコーチとのやり取り
2.チームでの共創に対する意識の転換 私 スクラムの目的を、不確実性が高い機能の 実現に対する定期健診が主目的だとした場合、 やるべきことが明瞭であり、 ぶれが少ない場合はウォーターフォールが良いのでは ある日のSlack上でのアジャイルコーチとのやり取り 我々のプロダクトのバックログは、 事業計画によってほぼ固まっている。 機能実現が優先されており、
アウトカム測定には重きが置かれていない。
2.チームでの共創に対する意識の転換 スクラムの目的を、不確実性が高い機能の 実現に対する定期健診が主目的だとした場合、 やるべきことが明瞭であり、 ぶれが少ない場合はウォーターフォールが良いのでは 最近は、「プロダクト」もしくは 「アウトカム/価値/成果」に、 作っているサービスだけじゃなくて、 スクラムチームも含めて考えると頭の整理が しやすいなと思っています。
私 アジャイルコーチ ある日のSlack上でのアジャイルコーチとのやり取り
2.チームでの共創に対する意識の転換
2.チームでの共創に対する意識の転換 スクラム スクラムを、入力・プロセス・出力の構造で捉えた場合、 スクラムはプロセスであると考えることができる。
2.チームでの共創に対する意識の転換 スクラム スクラムによって実現するプロダクト機能は、 スクラムにとっての出力であると考えることができる。 プロダクト
2.チームでの共創に対する意識の転換 スクラム 今までの私の理解では、 プロセスと出力に対して意識はできていたが、入力を意識できていなかった。 プロダクト
2.チームでの共創に対する意識の転換 私のスクラムに対する理解 要求の変動性が高い:スクラムが効果的 要求の変動性が低い:ミニウォーターフォールのような開発でもよい気がする プロダクトに求められる要求の属性によって 開発プロセスは適切に選択すべきだと思っていた。 →何がプロダクト機能を実現するかの考えが抜けていた
2.チームでの共創に対する意識の転換 スクラム スクラムにとっての入力はスクラムチームであると考えることができる。 スクラムチームが、スクラムというプロセスに入力され、 プロダクト機能のリリースを実現する。 プロダクト チーム
2.チームでの共創に対する意識の転換 スクラム 定期的なプロダクト機能のリリースサイクルを設けることで、 スクラムチームはリリースによるフィードバックを効果的に得ることができる。 それによりスクラムチームは持続的なプロダクト開発のための 成長を続けることができる。 プロダクト チーム
2.チームでの共創に対する意識の転換 結果、スクラムの価値とは、 不確実性の高い時代の要求にプロダクトを追随させることだけでなく、 そのプロダクトを成長させることを実現するチームの醸成にある。
2.チームでの共創に対する意識の転換 たとえ欲しいものが固定化されていて、 プロダクトに求められる機能が大きく変動しないとしても、 何度もプロダクトを成長させていくためには、チームの成長は必須。 チームが成長できないと、プロダクトの成長を持続することができない。 計画時 リリース時
2.チームでの共創に対する意識の転換 計画からリリースまでを小さく刻むスクラムでは、 プロダクトリリースまでの経験のフィードバックを繰り返すことで、 スクラムチームの成長を実現することができる。 そのことにより、持続的なプロダクト開発を実現することができる。 計画時 リリース時 VUCA の マ
ー ク ( Volatility ) VUCA の マ ー ク ( Uncertainty ) VUCA の マ ー ク ( Complexity ) VUCA の マ ー ク ( Ambiguity ) 計画時 リリース時 計画時 リリース時 計画時 リリース時
チーム開発での実践
3.チーム開発での実践 チームに向けた視点でスクラムガイドを読み直す。 ・スクラムの5つの価値基準 ・スクラムの3本柱 出典:スクラムガイド https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
3.チーム開発での実践 確約:共通のゴールに対するお互いのサポートを確約 集中:個人個人ではなくチームとしてスプリント作業に集中 公開:心理的安全性をもとに作業や課題の公開を実現 尊敬:お互いに能力のある独立した個人として尊敬(原文まま) 勇気:立場や役割を越えて正しいこと、困難な問題に取り組む勇気 スクラムの5つの価値基準
3.チーム開発での実践 ▪それまでの理解 プロダクトを作るプロセス、作業に対する透明性の重要性 ▪改めての理解 「作業を実行する人とその作業を受け取る人」 の関係性の透明性の重要性 スクラムの3つの柱 出典:スクラムガイド https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
3.チーム開発での実践 ▪それまでの理解 作成物や進捗状況の健全性に対する検査の重要性 ▪改めての理解 作成物、進捗状況の主体となる スクラムチームの健全性に対する検査の重要性 スクラムの3つの柱 出典:スクラムガイド https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
3.チーム開発での実践 スクラムの3つの柱 出典:スクラムガイド https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf ▪それまでの理解 プロセスやプロダクトの要求に対する適応の重要性 ▪改めての理解 プロセスやプロダクトに求められる要求に スクラムチームを適応させていく重要性
これらの考えをもとに 3.チーム開発での実践
3.チーム開発での実践 ▪常時ハドル 施策:Slack上での常時ハドルを開設 価値:公開、集中/柱:透明性、検査、適応 結果:困りごとや作業の詰まりを随時相談できる状態を実現 ▪バグバッシュ(PO・他関係者巻き込み) 施策:スプリントレビュー時に実現された機能を触る会を実施 価値:尊敬、勇気、確約/柱:検査 結果:リリース前に全員で品質に対する合意できる状態を確立 役割に閉じない機能の使われ方に対する学習を実現
3.チーム開発での実践 ▪仕様共有 施策:仕様策定した結果や新規でのDB設計内容などチーム知見の随時共有 価値:集中、公開/柱:透明性、適応 結果:個人個人に埋もれないチームとしてのシステム理解を醸成。 5つの 価値基準 3本柱 × =
価値基準がスクラムチームや ⼀緒に働く⼈たちによって具現化されるとき、 経験主義のスクラムの三本柱 「透明性」「検査」「適応」に息が吹き込まれ、 信頼が構築される。 出典:スクラムガイド https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
3.チーム開発での実践 ▪ふりかえりの目的見直し 施策:スクラムチームでなぜふりかえりを実施するかの議論 価値:確約、公開、尊敬、勇気/柱:透明性、検査、適応 結果: それまでふりかえりでは個々人の課題感の解像度が十分ではないまま 解決策を考えることに集中していた。 チームでふりかえりの目的を議論した結果、 個々人が抱える課題感をチームのものとして共有できることが重要と合意できた。
3.チーム開発での実践 ▪ふりかえりの目的見直し 施策:スクラムチームでなぜふりかえりを実施するかの議論 価値:公開、尊敬、勇気/柱:透明性、検査、適応 結果: それまでふりかえりでは個々人の課題感の解像度が十分ではないまま 解決策を考えることに集中していた。 チームでふりかえりの目的を議論した結果、 個々人が抱える課題感をチームのものとして共有できることが重要と合意できた。 ふりかえりが解決策を考える場から、
チームで課題に対する認知を醸成できる場に変わった。 その場で解決策を考えつかなくても、継続的に課題に向き合える状態を作った。
3.チーム開発での実践 スクラム スクラムの価値基準と3本柱に根差した実践を繰り返すことで、 持続的なプロダクト成長とともに、 それを実現するスクラムチーム自身も成長させることができることに気付いた。 プロダクト チーム 5つの 価値 基準
3本柱 ×
まとめ
4. まとめ スクラムの価値とは、不確実性の高い時代の要求に プロダクトを追随させることにあると考えていました。 ただ、そこにはそれを実現するチームに対する理解が抜けていました。
4. まとめ プロダクトを持続的に成長させていくためには、 プロダクト成長を実現するチームの成長が必要だと気が付きました。
4. まとめ スクラム スクラムはプロダクト成長を実現するだけではなく、 スクラムチームの成長も実現できることに気付きました。 プロダクト チーム
スクラムは“機能”だけでなく、 “チーム“を成長させる仕組み 4. まとめ