Slide 1
Slide 1 text
10分でスクラム
Slide 2
Slide 2 text
川口 恭伸
かわぐち やすのぶ
Twitter: @kawaguti
アギレルゴコンサルティング株式会社 シニアアジャイルコーチ
株式会社ホロラボシニアアジャイルコーチ
一般社団法人スクラムギャザリング東京実行委員会 代表理事
一般社団法人 DevOpsDays Tokyo 代表理事
Slide 3
Slide 3 text
アギレルゴコンサルティング株式会社
株式会社ホロラボ
所属企業両方で、
スポンサーさせて
いただいております
Slide 4
Slide 4 text
10分でスクラムとは
https://www.slideshare.net/kawaguti/
20110118-scrum-10-mins
2011年1月にスクラムの共
同開発者のJeff Sutherland
博士とGabriele Benefield
さんによる日本初の認定スク
ラムプロダクトオーナー研修
(CSPO)の後に、カッとなっ
て作った資料。
Slide 5
Slide 5 text
10分でスクラムとは
https://www.publickey1.jp/blog/11/10_5.html
Innovation Sprint2011で
の野中先生、Jeffさん、東証
宇治さんなどの発表を記事に
していただいた、PublicKey
新野さんにご紹介いただき、
結構読まれました。
Slide 6
Slide 6 text
Innovation Sprint
http://innovationsprint.com
平鍋さんと、ピークワン前田
さんとで企画した、初めての
スクラム大きなイベント。よ
しおかさん仲介で品川シーサ
イド楽天タワーの朝会会場を
お借りして開催。野中先生と
ジェフを会わせるイベント。
Slide 7
Slide 7 text
当時のスクラム事情
日本国内での通訳付きの認定スクラ
ムマスター研修(CSM)の開催数はま
だ数回(私の観測範囲では４回とか)。
私はXP祭り、オブジェクト倶楽部に
参加してました。
2009年から始まったすくすくスク
ラムには常時30人以上集まったりし
てました。
Slide 8
Slide 8 text
私のスクラム事情
2008年のXP祭りでScrumを
知り、懇親会でCSM取得した
林栄一さんと知り合い、
2009年から予算が取れて社
内試行。スクラムマスターは
同じ部署にいた、江端一将さ
ん。一緒にすくすくスクラム
を立ち上げて、会社の会議室
で開催しました。
Bas Voddeさん Jim Coplienさん
2009年にBasさんのCSMを受
講し、2010年末にJim
Coplien さんのCSMをオーガ
ナイズしました。
Slide 9
Slide 9 text
先行者の言葉
2008年のデブサミで栃木の
関将俊さんのセッションに参
加。すでに８年アジャイル開
発をやっている関さんから、
社内でなにかを始めるときに
大事なのは「信頼貯金」だと
いうアイデアを聞く。あれ、
しまった、やれてないのは自
分のせいじゃん。
Slide 10
Slide 10 text
私のプロダクト
自分が絡む二つのチームでス
クラムをやってみました。一
つは新規開発・新しいチーム。
ニュース配信の仕組みに画像
を追加するというもの。ス
テークホルダが3,4 部署に絡
まっていて、実現していな
かったのを簡易な仕組みで実
現。運用負担も軽減。
Slide 11
Slide 11 text
私のプロダクト2
もう一つは既存のインフラ運
用者を引き継いだもので、デ
プロイの自動化を実現するだ
けでなく、定期的なスケ
ジュール(=スプリント)と緊
急リリースのフローを作り、
チームメンバーが自律的に要
望を受けられる仕組みにしま
した。
Slide 12
Slide 12 text
私はどうしたかった？
それまで難しかった「引継
ぎ」をやらなくていい仕組み
を手に入れ、メンバーは育っ
ている感じ。作っているもの
も安定稼働して会社の収益を
支えている。これを続けるた
めには、正当化も必要。みん
ながスクラムやれば、もっと
やりやすくなるに違いない。
Slide 13
Slide 13 text
すくすくスクラム
社外にもスクラムを普及させ
たい江端さんが立ち上げたい
ということに協力。会議室を
とるとかビデオ撮るとか、そ
ういう作業をだいたい手伝い
ました。MS長沢さんにサイ
ト作っていただいたり、日経
ソフトウェアさんにも取材し
ていただきました。
Slide 14
Slide 14 text
勉強会カンファレンス
2009年に勉強会カンファレ
ンスのスタッフをやりました。
どうやったら企業の場所を借
りて勉強会やるのかとか。
よしおかさん、岩切さんとは
ここで出会っています。
https://gihyo.jp/news/report/
2009/06/0802
Slide 15
Slide 15 text
ＸP祭り
2009年まで実行委員長だっ
た倉貫さんが、実行委員の公
募制を提案したことを受けて、
2010年1月の実行委員会の
募集を立候補して、引き受け
ました。すくすくスクラムを
やっている会社の会議室で第
一回ミーティング。
https://enterprisezine.jp/iti/
detail/2676
Slide 16
Slide 16 text
AgileUCD 研究会
2009年にAgile
Conference に初めて参加す
るにあたって、興味のあった
人間中心設計(UCD)とAgile
の関係について樽本徹也さん
に教えを請うところから始
まった勉強会。Jeff Patton
について注目したのもここか
ら。
https://enterprisezine.jp/iti/
detail/2676
※樽本さんは古田一義さんに紹介していただき
ました。次のセッションは古田さんとやります。
Slide 17
Slide 17 text
スクラムギャザリング東京
2011年10月に第一回のスク
ラムギャザリング東京を開催。
キーノートは Henrik
Knibergさんと Jeff Patton
さん。今、考えてもベストメ
ンバーだったと思います。熱
気あふれたカンファレンスに
なりました。今年のセッショ
ン公募は10/15まで！ https://confengine.com/conferences/
regional-scrum-gathering-tokyo-2022
Slide 18
Slide 18 text
できることの積み重ね
「おそらく確実にできるこ
と」の要素を思い浮かべて、
その組み合わせだけで、いま
やりたいなーと思っているこ
とをうまいこと実現できない
だろうか。ほかの人が見過ご
していそうな新しい結合がな
いだろうか？社会に貢献でき
るところはないか？
Slide 19
Slide 19 text
ハイキュー!! 14巻より
• 烏野高校の精神的支柱であり、
守備の要(かなめ)である主将の
負傷退場の穴を埋める、
二年生のリーダー。
• スキルも経験も統率力も主将には
遠く及ばない、レギュラーでもない
ことを自認しながら、チームのために
尽くした。
• 基本を思い出すこと。練習の通りに
やること。全員がベストを尽くすこと。
自分で考えること。
「バタバタしない。
良いジャンプは、良い助走から。」
Slide 20
Slide 20 text
イノベーターにならない
一方で、Fearless Change
にあるとおり、新しいことを
追いかける人、イノベーター
にはなってしまうと、「また
新しいことをやっている」と
いうレッテルをもらって、
放っておかれることになるの
で、とにかく継続できること
を低燃費でやり続けたい。
Slide 21
Slide 21 text
10分でスクラム
https://www.slideshare.net/kawaguti/
20110118-scrum-10-mins
2011年のCSPO研修は会社
からも5人受けてもらうこと
ができました。社内の予算や
私の働き分で枠作って。受講
後、一人が「うちではできな
いと思います」と打ち明けた
ので、カッとなって一晩で
作ったのがこのまとめ資料。
Slide 22
Slide 22 text
ということで
初代の10分でスクラム
Slide 23
Slide 23 text
No content
Slide 24
Slide 24 text
No content
Slide 25
Slide 25 text
No content
Slide 26
Slide 26 text
No content
Slide 27
Slide 27 text
No content
Slide 28
Slide 28 text
No content
Slide 29
Slide 29 text
No content
Slide 30
Slide 30 text
No content
Slide 31
Slide 31 text
No content
Slide 32
Slide 32 text
No content
Slide 33
Slide 33 text
No content
Slide 34
Slide 34 text
No content
Slide 35
Slide 35 text
No content
Slide 36
Slide 36 text
No content
Slide 37
Slide 37 text
No content
Slide 38
Slide 38 text
No content
Slide 39
Slide 39 text
No content
Slide 40
Slide 40 text
No content
Slide 41
Slide 41 text
No content
Slide 42
Slide 42 text
No content
Slide 43
Slide 43 text
No content
Slide 44
Slide 44 text
No content
Slide 45
Slide 45 text
No content
Slide 46
Slide 46 text
No content
Slide 47
Slide 47 text
No content
Slide 48
Slide 48 text
No content
Slide 49
Slide 49 text
No content
Slide 50
Slide 50 text
No content
Slide 51
Slide 51 text
No content
Slide 52
Slide 52 text
No content
Slide 53
Slide 53 text
No content
Slide 54
Slide 54 text
No content
Slide 55
Slide 55 text
No content
Slide 56
Slide 56 text
No content
Slide 57
Slide 57 text
No content
Slide 58
Slide 58 text
No content
Slide 59
Slide 59 text
No content
Slide 60
Slide 60 text
No content
Slide 61
Slide 61 text
No content
Slide 62
Slide 62 text
No content
Slide 63
Slide 63 text
No content
Slide 64
Slide 64 text
No content
Slide 65
Slide 65 text
No content
Slide 66
Slide 66 text
No content
Slide 67
Slide 67 text
No content
Slide 68
Slide 68 text
No content
Slide 69
Slide 69 text
No content
Slide 70
Slide 70 text
No content
Slide 71
Slide 71 text
めざしたこと
https://www.slideshare.net/kawaguti/
20110118-scrum-10-mins
相手に説明するときに、自分
なりのまとめ資料を作ってみ
る。特定の相手に向けて資料
を作れば、どんな内容が響き
そうか、一歩一歩検討ができ
る。説得ではなく、情報を提
示する。相手を動かすのでは
なく、理解を高めてもらう。
Slide 72
Slide 72 text
スクラムが見直しをせまっていること
1. とりあえず期限決めましょう
2. 相手に約束させて履行を迫る
3. 一人でやった方が早い
4. まだ見せられません
5. まだ時間あるからもうちょっと
6. なんのためにやってるんだっけ？
7. 誰のせいかを明確にする
8. 管理だけを仕事にする
9. 現物を見ないで進める
Slide 73
Slide 73 text
竹内野中論文(1986)が示した
マネジメントスタイル
• Type A NASAのウォーターフォール型
• 要求、分析、設計、実装、試験と、
順に次の工程の部署に引き渡される
• Type B 富士ゼロックスのサシミ型
• 前工程と後工程が同席する
• Type C ホンダのスクラム型
• 一時は全工程が同席する
Jeff SutherlandはこのType Cから、
自らのフレームワークの名前を
とった。
https://www.infoq.com/presentations/The-Roots-of-Scrum/
Slide 74
Slide 74 text
コマンド＆コントロールを打ち破る
• 旧来の企業では、戦略は中央で作られる
• それぞれの現場で、創発的な戦略が自己
組織される
• 分散化された認知とアクション
• スクラムチームは、
自己組織化を許されなければならない
• 自働的 Autonomous
• 卓越的 Transcendent
• 他家受粉 Cross-fertilization
• チームは自らの仕事を選択する
• それぞれの個人は自らの仕事を管理する
• マネジメントを排除する
竹内野中
https://www.infoq.com/presentations/The-Roots-of-Scrum/
Slide 75
Slide 75 text
https://www.infoq.com/presentations/The-Roots-of-Scrum/
多様な観点
• 職能横断チーム (クロスファンクショナル)
• スクラムチームは(すべての職能を)持つ。
プロダクトの知識、業務分析、UIデザイ
ン、ソフトウェアエンジニア、品質保証
• さらに進んだスクラムではもっとステー
クホルダーを巻き込む ー 経営陣、顧客、
インストール担当、サポート担当
Slide 76
Slide 76 text
プロダクト
バックログ
顧客が求める機能の
優先順位付きリスト
スプリントバックログ
スプリント内で完成させる機能
機能をより小さなタスクに分解する
新しい機能
スプリントの
終わりにデモする
毎日15分のミーティン
グを行う。
スクラムマスターは３
つの質問をする
1)昨日なにを達成しま
したか？
2)ゴールを満たすため
に障害になっているの
は？
3)明日までになにをた
達成しますか？
https://www.infoq.com/presentations/The-Roots-of-Scrum/
スクラムスプリントサイクル
Slide 77
Slide 77 text
不確実性が要求する
経験主義的プロセスコントロール
• 入力
• 要件
• 技術
• チーム
• 制御
• プロセス
• 出力
• 漸進的にプロダクトが変化
https://www.infoq.com/presentations/The-Roots-of-Scrum/
Slide 78
Slide 78 text
https://www.infoq.com/presentations/The-Roots-of-Scrum/
トヨタウェイ : Learn by Doing
張富士夫 : 代表取締役社長 2002
• 私たちが一番重視するのは、実際に実践し、
行動すること アジャイル原則#1
• わかっていないことはたくさんある。だから
「とにかくまずやってみよう」アジャイル原則#3, #11
• 自分の知識の少なさに気づき、自分の失敗に
直面して、もう一度やり直し、2回目の試行で
また別の失敗に気づく。そしてもう一度やり
直す。アジャイル原則#11, #12
• 絶え間ない改善によって、より高いレベルの
実践と知識に至る。アジャイル原則#3
Slide 79
Slide 79 text
トヨタウェイは
冗長性と失敗を許容する
• 生物の進化のような創発的プロセスでは、
失敗が生まれる
• 早めに失敗し、頻繁に失敗して、
素早く学習し、急速に進化する
• 創発的なソリューションに向けた、
合理的で効果的なアプローチは、
大事故を引き起こす
https://www.infoq.com/presentations/The-Roots-of-Scrum/
Slide 80
Slide 80 text
https://www.infoq.com/presentations/The-Roots-of-Scrum/
スクラムを進化させる
Type A, B, Cのスプリント
• Type A スプリントで部分的なものしか
作れないかもしれない
• Type B 徐々にオーバーラップさせる
• Type C すべてを一つのチームで
自分たちのやり方を現地現物で見つめ、
自分たちで進化させていくのがスクラム。
自分で考えるメンバーを作り、守り、鍛えていく。
Slide 81
Slide 81 text
https://scrumguides.org/
スクラムの定義のアップデート
『スクラムガイド』
• コミュニティの意見を採り入れて
わかりにくい表現をなくしたり、
必須のルールのみを残して、
ベストプラクティスは外し、
ルールブックとして再定義
• 2020年版で主要なワードが大きく
変わったので、認定を受ける方や
最新の動向を確認したい人は
読んでみてください。
Slide 82
Slide 82 text
ということで
今日の10分でスクラム
Slide 83
Slide 83 text
スクラムマスター
プロダクトオーナー
開発者(たち)
Slide 84
Slide 84 text
プロダクトオーナー
• プロダクトのビジョンを持ち、育てる。
• ビジョンを達成するためのロードマッ
プを考え、提示する。
• 開発チームと協力して、着手可能な仕
様としてプロダクトバックログを作成
する。
• ステークホルダーやエンドユーザーと
話す。
• 予算を確保する。
• ROIが高くなるようプロダクトバック
ログの優先順位をつける。
Slide 85
Slide 85 text
• 自己組織化して仕事を進める。
• 全員がプロダクトに貢献する。
• 必要な能力をチーム全体でカバーする。
• プロダクトバックログを理解し、
優先順位に従って出荷判断可能な
プロダクトインクリメントを仕上げる。
• プロダクトバックログの各項目に
サイズの見積もりをつける。
開発者(たち)
Slide 86
Slide 86 text
スクラムマスター
• スクラムのプロセスがうまく機能する
ように、あらゆる手を尽くす。
• チームの集中を妨げる妨害を排除する。
• チームの行く手を阻む障害を取り除く。
• チームに改善をそそのかす。
• チームの自己組織化を尊重する。
• プロダクトオーナーが機能していない
ときは、指導する。
• 指示しないサーバントリーダー。
Slide 87
Slide 87 text
プランニング スプリント
(作業時間)
レビュー レトロスペ
クティブ
スプリント
Slide 88
Slide 88 text
プランニング
スプリント
(作業時間)
レビュー
レトロスペ
クティブ
スプリント
Slide 89
Slide 89 text
プランニング
• プロダクトバックログを理解する。
• バックログ項目はチームが見積もる。
• チームの実力(ベロシティ)からみて、
どこまで行けそうかを測る。
• 行けそうなところまでのバックログアイ
テムを完成させるために、チームがどう
動くかを考える。
• よく考えたらダメっぽいなら、もう
ちょっと減らす。
Slide 90
Slide 90 text
スプリント
(作業時間)
• 集中して仕事をする。
• プロダクトバックログの順番通りに
完成させる。
• やり方はチームが考え、自律して進める。
• なるべく多くのバックログアイテムを
出荷判断可能にする。
• どうやると終わるか(完成の定義)は
だんだん拡張する。
• 毎日同期し、再計画する
= デイリースクラム
Slide 91
Slide 91 text
レビュー
• 動くソフトウェアを利害関係者に
デモする。
• 利害関係者に意見をもらう。
• できなかったことがあれば報告する。
• 技術的負債について話す。
• ロードマップを俯瞰する。
• マーケットの状況を共有する。
• 追加バックログ項目があれば足す。
• この方向で進めることを合意する。
Slide 92
Slide 92 text
レトロスペ
クティブ
• なにをやったか話す。
• レビューでどんな意見が
返ってきたか話す。
• 技術的負債について話す。
• よかったことや反省点を話す。
• どうしたらもっとよくなるか話す。
• 困ったことがないか聞く。
• アイデアがあれば出す。
Slide 93
Slide 93 text
デイリー
スクラム
• 毎日15分以内、立って話す
• ３つの質問、昨日やったこと、今日
やること、足を止めているもの
• 同じ時間、同じ場所。自動的に。
• リーダーへの報告ではない。全員が
自己マネジメントする。
• 問題解決より、見える化優先。
• 残りのスプリントの作業を再プログ
ラミングする。
Slide 94
Slide 94 text
ToDo WIP Done
プロダクト
バックログ
スプリント
バックログ
障害リスト
Slide 95
Slide 95 text
プロダクト
バックログ
• 優先順位付けされた機能や対応項目のリスト。
何を提供するか(What)。
• ROIが最も高まるように優先順位付けされ、
開発チームは上から順に届ける。
• 各項目の規模は開発チームが見積もる。
• スプリントで完成した項目の規模の合計が
ベロシティ。次も同じくらいいけると考える。
• 開発チームはスプリントごとに、
どうやって実現するか(How)を考え、
スプリントバックログに落とし込む。
Slide 96
Slide 96 text
ToDo WIP Done
スプリント
バックログ
• スプリントごとに、チームが作成し
たタスクリスト。
• プロダクトバックログの上位の項目
を優先順位に従って届けるための、
開発チームの作業リスト。
• 完成の定義を守る。
技術的負債を溜めない。解消する。
• チームはタスクに群がって作業し、
アグレッシブに終わらせていく。
Slide 97
Slide 97 text
障害リスト
• チームの進行を妨げる障害をリストにする。
スクラムマスターにとってのバックログ。
• デイリースクラム、レトロスペクティブ
などで発見され、まずチームが解決する。
• だれにとってもオープン・正直に。
• 障害は誰のせいでもない。解決できそうな
課題だけを出すような忖度はしない。
• 障害を一歩一歩取り除いていく。 = 改善
• 解決できないときは組織の問題として
助けを求める必要があるかもしれない。
Slide 98
Slide 98 text
バックログ
リファインメント
• 定期的に時間をとって、次回以降の
スプリント向けのプロダクトバック
ログを見直しておく
• 見積もりをアップデートする
• 細かくなってないものを分割
• 直近３スプリント分は十分に細かく
• 先のことは書いておくが細かくしな
い
• スプリント中にやるが、スプリント
の集中を乱さない
Slide 99
Slide 99 text
アジャイルな見積りと計画づくり
スクラム普及の立役者の一人、
マイク・コーンのプランニングに
関する名著。
なぜ時間ではなくポイントで見積も
るのか？なぜ私たちは計画に失敗す
るのか？プロダクトバックログや、
プランニングポーカーに関して最も
詳しく論じられている。
スクラム
ジェフ・サザーランド博士がいかに
してスクラムにたどり着いたのか、
詳細に語られた一冊。ジャーナリス
ト出身の息子、ＪＪサザーランドが
大きく貢献をしている。ビジネス書
としてスクラムを押さえるために重
要な一冊。野中・竹内論文にどのよ
うに出会ったのかも、細かく書かれ
ている。
スクラム現場ガイド
スクラムアライアンスの初期の
マネージングディレクターであ
るケン・ルービンの包括的な
スクラム解説書。分厚く、詳細
に書かれている。
エッセンシャルスクラム
スクラム適用を長年行ってきた
ミッチ・レイシーによる
現場で起こる問題に対応する
実戦的なガイドブック。
ScrumMaster the Book
薄い本だが、スクラムマスター
の長い道のりを論じている。ま
ずチームのコーチングやメンタ
リングを行うこと。チーム運営
の罠はどこにあるか。チームを
越えた組織開発の必要性。