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

定期的な価値提供だけじゃない、スクラムが導くチームの共創化 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つの価値基準３本柱 × ＝
価値基準がスクラムチームや⼀緒に働く⼈たちによって具現化されるとき、経験主義のスクラムの三本柱「透明性」「検査」「適応」に息が吹き込まれ、信頼が構築される。出典：スクラムガイド https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

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

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

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

まとめ

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

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

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

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

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