20260704_教科書にないスクラム風をしている人へ

https://shibuyagile.connpass.com/event/392971/

の登壇資料

Transcript

1. 教科書にないスクラム 風をしている人へ 2026-07-04 渋谷アジャイルカンファレンス @ryugen
2. whoami 山本竜玄 Yamamoto Tatsunori (@ryugen04) 経歴: 株式会社ヘンリーに2025年11月join 医療・ヘルスケア領域のWebエンジニア(ロール はEpic Owner)やっています。 趣味・領域 : Neovim好きです/スクラム好きです アクアリウム/カポエイラ/薬剤師 その他: ビールが好きです！
3. 5分で 最近ずっと考えている、 教科書通りでないスクラム風 味の、個人的な考えを話しま す (※スクラム原理主義者の方には厳密でない かもなのでごめんなさい) (Scrum Fest Mikawaにも似た話でプロポーザル出し てみたよ！)
4. 突然ですが皆さん、 ちゃんとスクラムをできていますか？？
5. スクラムガイドから考えるスクラム 大まかには以下のような特徴を持つものが スクラム、と解釈している • 基本的な単位としてScrum Teamがある • Scrum TeamにはDevelopers、Product Owner、Scrum Master、という三つのaccountabilityがある • Sprintという一定期間の反復があり、Sprint Planning、Daily Scrum、Sprint Review、Sprint Retrospectiveがその中で行わ れる • Product Backlog、Sprint Backlog、Incrementという三つの artifactがある • それぞれのartifactにはProduct Goal、Sprint Goal、Definition of Doneというcommitmentがある • 各イベントが、artifactとゴールへの進捗を検査し、適応する機 会として機能している • 毎Sprintで、価値があり有用で、利用可能なIncrementを作るこ とにScrum Team全体が責任を持つ • これらの構造が揃い、透明性、検査、適応にもとづく経験主義が 機能しているものがScrumである (引用: スクラムガイド 2020年11月 日本語版)
6. 現場でありがちなこと PJ特性、会社の事業計画・採用などに影響され以下のような逸脱が発生し やすい • Product Ownerはいるが、実際にはPdM、Tech Lead、CS、Bizが判断を分担している。 • Scrum Masterという肩書きはないが、誰かがイベント設計、停滞検知、関係者調整をして いる。 • Developersが実装だけでなく、要求の分解、受入条件、優先順位、リリース判断に踏み 込んでいる。 • Sprint Reviewがステークホルダーとの作業セッションではなく、社内向けの成果発表会 になっている。 • Daily ScrumがSprint Goalへの適応ではなく、進捗報告になっている。 • Product Backlogが価値順の単一情報源ではなく、要望、調査メモ、未練、保留事項の置 き場になっている。 • Definition of Doneはあるが品質基準や利用可能性の判定として機能していない。
7. 皆がスクラムに関心があるわけではない イベントを踏襲 したら、”スクラム”と表現す る会社も多いのでは？
8. 改変が許されるスクラム スクラムフレームワークは 意図的に不完全 実際の戦術やプロセス、技法は柔軟に扱う 前提となっている 教科書にないスクラムでも “スクラム”という共通言語を使っていれば 胸を張って話そう！ (引用: スクラムガイド 2020年11月 日本語版)
9. 本当に？
10. 進化したスクラムと形骸化した スクラムの 見分けはとても自覚しづらい
11. ScrumButとは？ スクラムガイド (引用: “What is ScrumBut?”, Scrum.org)
12. 完全なスクラムでないと 価値がない のか？
13. スクラムは目的でなく手段のひとつ • 本質的には、Agile Manifestoに基づいて開発をするということがやりた いこと • スクラムはそのとても強力なプロセス のひとつ (引用:アジャイルソフトウェア開発宣言 )
14. スクラムを保った拡張と、離れた実践 スクラムを保ったまま補完するもの • Scrum with Kanban • Nexus • LeSS • Scrum@Scale • SAFe • Disciplined Agile スクラムから離れた or ハイブリッド • Scrumban • Kanban • Extreme Programming • SDM Agile Project Framework • Feature Driven Development • FAST Agile フレームワークだけでも 多種多様。 適切なものを組織で活用でき る
15. ScrumBanとは？ ScrumとKanbanの特徴を組み合わせたハイブリッドなアジャイルフレーム ワーク 以下が特徴らしい。(※経験はないが今一番気になってる) • チームがスクラムからカンバンに移行する方法として開発された • ScrumのSprint、Planning、Daily、Review、Retrospectiveを残すことがある • Kanban boardで仕事の流れを可視化する • WIP制限で着手中の仕事を増やしすぎないようにする • 固定長Sprintを使うチームもあれば、必要に応じてpullするチームもある • Product Owner、Scrum Master、Developersの区別を残す場合も、責任を チームに分散する場合もある
16. スクラムの原則に従い、 教科書通りやること だけが価値ではない
17. 皆がスクラムに関心があるわけではない イベントを踏襲 したら、厳密にはスクラムで はないのに ”スクラム”と表現する会社も多 いのでは？
18. 教科書にないスクラム風をする価値 教科書にないスクラム風をすることにも価値はある ただし、スクラムを外れていることには自覚的である 必要がある • 固定長Sprintをやめて、Kanbanの継続フローで運用する • Product Ownerを一人に集約せず、チームで意思決定を分担する • Scrum Masterを専任で置かず、ファシリテーションや改善責任をチー ム内で分散する • Sprint Planningをなくし、随時で次の仕事を取る • Scrum Teamの固定メンバーアサインでなく、案件や専門性に応じて流 動的に人を組み替える • Daily Scrumを固定開催せず、非同期更新と必要時の同期に置き換え る
19. まとめ • スクラムガイド上では、厳密には一部だけのスクラム はスクラムではない • そもそもスクラムは不完全なフレームワーク であり、現場の工夫を足す余地が 意図的に残されている • スクラムガイドから外れた運用していること自体が悪いわけではない、外れた結 果として透明性・検査・適応などが有効になっているのか • ScrumButは、スクラムで発見できる問題をスクラム自体を変えて隠してしまう状 態 • スクラムから外れるなら、ScrumBan、Kanban、独自Agileとして自覚的に使え ばよい • 大事なのは、Agile Manifestoが重視した価値観を守れているのか • 教科書にないスクラム風をしているのであれば、何を守り・何を変え・何を捨て たのかをチームで説明 できる必要がある • (そもそも教科書なんてない) (言うは易く 行うは難C…)
20. ご静聴ありがとうございました