定期的な価値提供だけじゃない、スクラムが導くチームの共創化 / 20251004 Naoki Takahashi

by SHIFT EVOLVE

Slide 1

Slide 1 text

定期的な価値提供だけじゃない、スクラムが導くチームの共創化 2025.10.04 スクラム祭り2025 髙橋直規 #scrummatsuri #scrumat 株式会社SHIFT

Slide 2

Slide 2 text

自己紹介髙橋直規 / 幡ヶ谷亭直吉 x:@asagayanaoki 出身：神奈川 / 居住：東京エンジニア歴：18年7か月今の役割：PjM、PdE 好きな言語：Java 好きな主義：経験主義好きな思考：プロダクト思考趣味：アナログレコード、映画鑑賞、マンガ、アニメ土日の過ごし方：6歳の娘ととにかく遊ぶ（10/2誕）

Slide 3

Slide 3 text

本日お話すること https://confengine.com/conferences/scrummatsuri/proposal/22743

Slide 4

Slide 4 text

■背景・要約 • ウォーターフォールプロジェクトの管理で進める考えが染みついていた。 • スクラムでも成果に注目し、チーム開発という文脈を意識できていなかった。 • スクラムは“機能”だけでなく、 “チーム“という有機体を育てる仕組みだった。本日お話すること

Slide 5

Slide 5 text

アジェンダ • 定期的なプロダクト機能のリリースというスクラムに対する理解 • チームでの共創に対する意識の転換 • チーム開発での実践 • まとめ

Slide 6

Slide 6 text

定期的なプロダクト機能のリリースというスクラムに対する理解

Slide 7

Slide 7 text

1.定期的なプロダクト機能のリリースというスクラムに対する理解 VUCAの時代。プロダクトに求められるものは時間とともに移ろいやすい。 VUCA のマーク（ Volatility ） VUCA のマーク（ Uncertainty ） VUCA のマーク（ Complexity ） VUCA のマーク（ Ambiguity ）変動性不確実性複雑性曖昧性

Slide 8

Slide 8 text

1.定期的なプロダクト機能のリリースというスクラムに対する理解ウォーターフォールのように長期計画が必要となる開発プロセスでは、計画時に欲しかったものがリリースタイミングには不要になる可能性が高い。計画時リリース時 VUCA のマーク（ Volatility ） VUCA のマーク（ Uncertainty ） VUCA のマーク（ Complexity ） VUCA のマーク（ Ambiguity ）

Slide 9

Slide 9 text

1.定期的なプロダクト機能のリリースというスクラムに対する理解計画からリリースまでを小さく刻むスクラムでは、そうしたプロダクトに対する変動する要求に柔軟に対応ができる。計画時リリース時 VUCA のマーク（ Volatility ） VUCA のマーク（ Uncertainty ） VUCA のマーク（ Complexity ） VUCA のマーク（ Ambiguity ）計画時リリース時計画時リリース時計画時リリース時

Slide 10

Slide 10 text

1.定期的なプロダクト機能のリリースというスクラムに対する理解結果、スクラムの価値とは、定期的にプロダクト機能をリリースするサイクルを設けることで、不確実性の高い時代の要求にプロダクトを追随させることができることにある。

Slide 11

Slide 11 text

ということは… 1.定期的なプロダクト機能のリリースというスクラムに対する理解

Slide 12

Slide 12 text

1.定期的なプロダクト機能のリリースというスクラムに対する理解欲しいものが固定化されており、時代の要求に大きく変動しないプロダクトは従来のウォーターフォール開発でも十分に効果的であると考えることができる。計画時リリース時 VUCA のマーク（ Volatility ） VUCA のマーク（ Uncertainty ） VUCA のマーク（ Complexity ） VUCA のマーク（ Ambiguity ）

Slide 13

Slide 13 text

1.定期的なプロダクト機能のリリースというスクラムに対する理解私のスクラムに対する理解要求の変動性が高い：スクラムが効果的要求の変動性が低い：ミニウォーターフォールのような開発でもよい気がするプロダクトに求められる要求の属性によって、開発プロセスは適切に選択すべきだと考えていた。

Slide 14

Slide 14 text

チームでの共創に対する意識の転換

Slide 15

Slide 15 text

2.チームでの共創に対する意識の転換ある日のSlack上でのアジャイルコーチとのやり取りアジャイルコーチ

Slide 16

Slide 16 text

2.チームでの共創に対する意識の転換アジャイルコーチ参考：実は相性が悪い「開発生産性」と「アジャイル」。うまくいかない開発を好転させるためにPMがやるべきこととは【ryuzee|吉羽龍太郎】 https://levtech.jp/media/article/interview/detail_406/ ある日のSlack上でのアジャイルコーチとのやり取り

Slide 17

Slide 17 text

2.チームでの共創に対する意識の転換ある日のSlack上でのアジャイルコーチとのやり取り参考：実は相性が悪い「開発生産性」と「アジャイル」。うまくいかない開発を好転させるためにPMがやるべきこととは【ryuzee|吉羽龍太郎】 https://levtech.jp/media/article/interview/detail_406/ 吉羽龍太郎さん「物的生産性を高めたいなら、ウォーターフォール方式で決まった機能を決まったように開発すればよくて、アジャイルを取り入れる必要はないと思います。」

Slide 18

Slide 18 text

2.チームでの共創に対する意識の転換私我々のプロダクトのバックログは、事業計画によってほぼ固まっている。機能実現が優先されており、アウトカム測定には重きが置かれていない。ある日のSlack上でのアジャイルコーチとのやり取り

Slide 19

Slide 19 text

2.チームでの共創に対する意識の転換私スクラムの目的を、不確実性が高い機能の実現に対する定期健診が主目的だとした場合、やるべきことが明瞭であり、ぶれが少ない場合はウォーターフォールが良いのではある日のSlack上でのアジャイルコーチとのやり取り我々のプロダクトのバックログは、事業計画によってほぼ固まっている。機能実現が優先されており、アウトカム測定には重きが置かれていない。

Slide 20

Slide 20 text

2.チームでの共創に対する意識の転換スクラムの目的を、不確実性が高い機能の実現に対する定期健診が主目的だとした場合、やるべきことが明瞭であり、ぶれが少ない場合はウォーターフォールが良いのでは最近は、「プロダクト」もしくは「アウトカム/価値/成果」に、作っているサービスだけじゃなくて、スクラムチームも含めて考えると頭の整理がしやすいなと思っています。私アジャイルコーチある日のSlack上でのアジャイルコーチとのやり取り

Slide 21

Slide 21 text

2.チームでの共創に対する意識の転換

Slide 22

Slide 22 text

2.チームでの共創に対する意識の転換スクラムスクラムを、入力・プロセス・出力の構造で捉えた場合、スクラムはプロセスであると考えることができる。

Slide 23

Slide 23 text

2.チームでの共創に対する意識の転換スクラムスクラムによって実現するプロダクト機能は、スクラムにとっての出力であると考えることができる。プロダクト

Slide 24

Slide 24 text

2.チームでの共創に対する意識の転換スクラム今までの私の理解では、プロセスと出力に対して意識はできていたが、入力を意識できていなかった。プロダクト

Slide 25

Slide 25 text

2.チームでの共創に対する意識の転換私のスクラムに対する理解要求の変動性が高い：スクラムが効果的要求の変動性が低い：ミニウォーターフォールのような開発でもよい気がするプロダクトに求められる要求の属性によって開発プロセスは適切に選択すべきだと思っていた。 →何がプロダクト機能を実現するかの考えが抜けていた

Slide 26

Slide 26 text

2.チームでの共創に対する意識の転換スクラムスクラムにとっての入力はスクラムチームであると考えることができる。スクラムチームが、スクラムというプロセスに入力され、プロダクト機能のリリースを実現する。プロダクトチーム

Slide 27

Slide 27 text

2.チームでの共創に対する意識の転換スクラム定期的なプロダクト機能のリリースサイクルを設けることで、スクラムチームはリリースによるフィードバックを効果的に得ることができる。それによりスクラムチームは持続的なプロダクト開発のための成長を続けることができる。プロダクトチーム

Slide 28

Slide 28 text

2.チームでの共創に対する意識の転換結果、スクラムの価値とは、不確実性の高い時代の要求にプロダクトを追随させることだけでなく、そのプロダクトを成長させることを実現するチームの醸成にある。

Slide 29

Slide 29 text

2.チームでの共創に対する意識の転換たとえ欲しいものが固定化されていて、プロダクトに求められる機能が大きく変動しないとしても、何度もプロダクトを成長させていくためには、チームの成長は必須。チームが成長できないと、プロダクトの成長を持続することができない。計画時リリース時

Slide 30

Slide 30 text

2.チームでの共創に対する意識の転換計画からリリースまでを小さく刻むスクラムでは、プロダクトリリースまでの経験のフィードバックを繰り返すことで、スクラムチームの成長を実現することができる。そのことにより、持続的なプロダクト開発を実現することができる。計画時リリース時 VUCA のマーク（ Volatility ） VUCA のマーク（ Uncertainty ） VUCA のマーク（ Complexity ） VUCA のマーク（ Ambiguity ）計画時リリース時計画時リリース時計画時リリース時

Slide 31

Slide 31 text

チーム開発での実践

Slide 32

Slide 32 text

3.チーム開発での実践チームに向けた視点でスクラムガイドを読み直す。・スクラムの5つの価値基準・スクラムの3本柱出典：スクラムガイド https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

Slide 33

Slide 33 text

3.チーム開発での実践確約：共通のゴールに対するお互いのサポートを確約集中：個人個人ではなくチームとしてスプリント作業に集中公開：心理的安全性をもとに作業や課題の公開を実現尊敬：お互いに能力のある独立した個人として尊敬（原文まま）勇気：立場や役割を越えて正しいこと、困難な問題に取り組む勇気スクラムの5つの価値基準

Slide 34

Slide 34 text

3.チーム開発での実践 ■それまでの理解プロダクトを作るプロセス、作業に対する透明性の重要性 ■改めての理解「作業を実行する人とその作業を受け取る人」の関係性の透明性の重要性スクラムの3つの柱出典：スクラムガイド https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

Slide 35

Slide 35 text

3.チーム開発での実践 ■それまでの理解作成物や進捗状況の健全性に対する検査の重要性 ■改めての理解作成物、進捗状況の主体となるスクラムチームの健全性に対する検査の重要性スクラムの3つの柱出典：スクラムガイド https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

Slide 36

Slide 36 text

3.チーム開発での実践スクラムの3つの柱出典：スクラムガイド https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf ■それまでの理解プロセスやプロダクトの要求に対する適応の重要性 ■改めての理解プロセスやプロダクトに求められる要求にスクラムチームを適応させていく重要性

Slide 37

Slide 37 text

これらの考えをもとに 3.チーム開発での実践

Slide 38

Slide 38 text

3.チーム開発での実践 ■常時ハドル施策：Slack上での常時ハドルを開設価値：公開、集中／柱：透明性、検査、適応結果：困りごとや作業の詰まりを随時相談できる状態を実現 ■バグバッシュ（PO・他関係者巻き込み）施策：スプリントレビュー時に実現された機能を触る会を実施価値：尊敬、勇気、確約／柱：検査結果：リリース前に全員で品質に対する合意できる状態を確立役割に閉じない機能の使われ方に対する学習を実現

Slide 39

Slide 39 text

3.チーム開発での実践 ■仕様共有施策：仕様策定した結果や新規でのDB設計内容などチーム知見の随時共有価値：集中、公開／柱：透明性、適応結果：個人個人に埋もれないチームとしてのシステム理解を醸成。 5つの価値基準３本柱 × ＝価値基準がスクラムチームや⼀緒に働く⼈たちによって具現化されるとき、経験主義のスクラムの三本柱「透明性」「検査」「適応」に息が吹き込まれ、信頼が構築される。出典：スクラムガイド https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

Slide 40

Slide 40 text

3.チーム開発での実践 ■ふりかえりの目的見直し施策：スクラムチームでなぜふりかえりを実施するかの議論価値：確約、公開、尊敬、勇気／柱：透明性、検査、適応結果：それまでふりかえりでは個々人の課題感の解像度が十分ではないまま解決策を考えることに集中していた。チームでふりかえりの目的を議論した結果、個々人が抱える課題感をチームのものとして共有できることが重要と合意できた。

Slide 41

Slide 41 text

Slide 42

Slide 42 text

3.チーム開発での実践スクラムスクラムの価値基準と3本柱に根差した実践を繰り返すことで、持続的なプロダクト成長とともに、それを実現するスクラムチーム自身も成長させることができることに気付いた。プロダクトチーム 5つの価値基準３本柱 ×

Slide 43

Slide 43 text

まとめ

Slide 44

Slide 44 text

4. まとめスクラムの価値とは、不確実性の高い時代の要求にプロダクトを追随させることにあると考えていました。ただ、そこにはそれを実現するチームに対する理解が抜けていました。

Slide 45

Slide 45 text

4. まとめプロダクトを持続的に成長させていくためには、プロダクト成長を実現するチームの成長が必要だと気が付きました。

Slide 46

Slide 46 text

4. まとめスクラムスクラムはプロダクト成長を実現するだけではなく、スクラムチームの成長も実現できることに気付きました。プロダクトチーム

Slide 47

Slide 47 text

スクラムは“機能”だけでなく、 “チーム“を成長させる仕組み 4. まとめ