我々は自律的なスクラムチームになれたのか？〜柔軟性と可用性を求めて〜

スクラムフェス三河2026登壇応募プロポーザル資料です。

Transcript

1. 我々は自律的な スクラムチームに なれたのか？ 〜 柔軟性と可用性を求めて 〜
2. 自己紹介 杉山 大地 / Backend Engineer 新米スクラムマスターとして炎上案件からスクラム立ち上げまでを経験 本日は「柔軟性と可用性」を軸にその道のりを共有します
3. 本日の流れ 起 プロジェクト炎上 ── 二の舞を避けるには 承 スクラム開始 ── チームの成長 転 柔軟性と可用性 ── なぜスクラムなのか 結 自律的チームへ ── これからの課題と方針
4. 起 プロジェクト炎上 二の舞を避けるには
5. ウォーターフォール体制 縦割れ構造の弊害 縦割りのウォーターフォール的な開発体制 情報を束ね、判断をつなぐハブ人員が不在 エンジニア間の連携が滞り、認識のズレが蓄積 手戻りと遅延が重なり、プロジェクトが炎上 A B C HUB 不在 各エンジニアは 動くが、中心がいない
6. 炎上案件への参画 案件からの学び 参画直後の状況 エンジニア間の不信と情報の分断 優先順位が不明瞭で動きが止まる 求められた対応と得たもの 各エンジニア間のハブとなり対話を仲介する 障害を可視化し、一つずつ取り除く 障害排除がチームを前に進めるという実感
7. 承 スクラム開始 チームの成長
8. スクラム開始 全員がスクラムを理解できているとは言えない 手探りながらも、スクラムの柱「経験主義」に基づくスタートだった 経験者と初学者が混在するチーム 自分自身も新米スクラムマスター 共通理解のないままの船出
9. 新規プロジェクトの成功 チームとしての成長を確かに感じた プロジェクト概要 内容 AIエージェントチャットBot導入 期間 1か月程度 成果 依頼部署のCSにおける顧客対応負荷を6〜7割低減 小さく区切った反復で学習が回り始めた 役割を超えて互いに助け合えた ふりかえりで改善が習慣になった
10. 転 柔軟性と可用性 なぜスクラムなのか
11. モメンタムの喪失 差し込み対応に苦慮し、チームの士気が低下した 計画外の差し込みが頻発する スプリントの集中が削がれる 達成感が積み上がらず、士気が下がっていく スプリント開始時 差し込みの連続
12. “ 淡々とタスクをこなすだけのチームになっていた ── モメンタムも当事者意識も失われかけていた
13. 柔軟性と可用性 プロダクトオーナーからの示唆 ── スクラムが保つべきもの 柔軟性 可用性 変化や差し込みを受け止め、優先順位を組み替えられる チームが必要な時に動ける状態を保ち続ける 柔軟性と可用性を保つには、スクラムの三本柱（透明性・検査・適応）に息を吹き込む必要がある 5つの価値基準に基づいて 確約 集中 公開 尊敬 勇気
14. スクラムの三本柱の実現 障害 新機能で外部SDKが使えないと判明 ── ネイティブアプリでの完結が崩れた 透明性 「使えない」事実と各自の状況を、スク ラムマスター・開発チームでオープンに 共有 基盤となる価値基準 公開 勇気 約30 分で合意 検査 → 障害がスプリントゴール・進捗に与える 影響を見極め、取り得る選択肢を洗い出 す 基盤となる価値基準 集中 尊敬 適応 → 有効な案を選び、プロダクトオーナーと 優先順位・スコープを調整して合意に至 る 基盤となる価値基準 確約 5つの価値基準が三本柱に息を吹き込み、そのスピード感が自律的な調整力の証だった
15. 結 自律的チームへ これからの課題と方針
16. 我々は自律的になれたのか？ 自律性の確保 柔軟性と可用性を意識し続けたことで チームは差し込みも踏まえて動けるようになった！ → 一定レベルの自律性を確保できた
17. 残る課題 タスクをこなせているがコラボレーションが薄い 知識・判断が個人の中に閉じている 「コラボレーションできる = より多様性を持ったチーム」へは成長途上
18. 対応方針 コラボレーションを強くする具体の手法 1 モブ／ペア作業で判断を共有する 2 ふりかえりで「コラボレーション」にフォーカスする 3 スウォーミングで一つのことに集まる
19. 柔軟性と可用性が 自律的なチームへの第一歩だった そして次はその自律を「コラボレーション」へと広げていく ありがとうございました