It dependsから脱却するスクラム #scrumsapporo / Scrum to break away from It depends

by TAKAKING22

Slide 1

Slide 1 text

It depends から脱却するスクラム及部敬雄 (@TAKAKING22) Photo by Pablo Heimplatz on Unsplash

Slide 2

Slide 2 text

スクラムが難しいと感じるのはどんなところですか？

Slide 3

Slide 3 text

スクラムガイドから複雑で変化の激しい問題に対応するためのフレームワークスクラムフレームワークは、スクラムチームとその役割・  イベント・作成物・ルールで構成されている。それぞれに目的があり、スクラムの成功や利用に欠かせない。スクラムフレームワークを使用する具体的な方法にはさまざまな  ものがあり、それらについては本稿では触れない。

Slide 4

Slide 4 text

スクラムを難しいと感じる理由を聞いてみたわかるようでわからない具体的なのか抽象的なのかわからないどこからはじめればよいのかわからないどうやって自分たちの状況にあてはめればよいのかわからない

Slide 5

Slide 5 text

再びスクラムガイドからスクラムとは、以下のようなものである。・軽量・理解が容易・習得は困難マジ！？

Slide 6

Slide 6 text

いざ詳しい人に聞いてみると… It depends 状況に依るね

Slide 7

Slide 7 text

は!?

Slide 8

Slide 8 text

It depends から脱却するスクラム及部敬雄 (@TAKAKING22) Photo by Pablo Heimplatz on Unsplash

Slide 9

Slide 9 text

!5",",*/( גࣜձࣾσϯιʔσδλϧΠϊϕʔγϣϯࣨ "(*-&.0/45&3$0.ʢݸਓࣄۀओʣ 4*-7&3#6--&5$-6#ʢνʔϜෳۀʣ ٴ෦ܟ༤ ੍ޚෆೳͳΞδϟΠϧϞϯελʔ

Slide 10

Slide 10 text

It depends マインドセット心理的安全性

Slide 11

Slide 11 text

それっぽい言葉どんなことでもだいたい It depends どんなときでも心理的安全性もマインドセットは大切確かにそのとおりでも一切情報量が増えていない

Slide 12

Slide 12 text

で、どうしたらいいの？

Slide 13

Slide 13 text

ここからのお話実際の現場で自分がどうしているのか大事にしていること特に気をつけていることなぜそれをやっているのか It depends で片付けずに実装の話をする

Slide 14

Slide 14 text

仕事をとりまく状況どうなるのかわからないビジネスどうすればよいのかわからないプロダクト何を考えているのかわからない人たちなぜそうなっているのかわからない組織やルール

Slide 15

Slide 15 text

わかるうまくいくわからないうまくいかない

Slide 16

Slide 16 text

わかるうまくいくわからないうまくいかない未知のわからない

Slide 17

Slide 17 text

わからないなんてふつうだ！わからないことだらけわからないことが多いと不安なので解消したくなるなにかがわかるとまた新しいわからないことが見つかる常にわからないはそこにある

Slide 18

Slide 18 text

こうやって考えてるわからないことをどうやって解消するかわからないこととどうやって付き合っていくか

Slide 19

Slide 19 text

プロジェクト序盤プロジェクト中盤プロジェクト終盤

Slide 20

Slide 20 text

プロジェクトプロジェクト人生チームプロダクトシステム

Slide 21

Slide 21 text

プロジェクトプロジェクトは終わらせるために行うプロジェクトは続いていくなにかのための活動内製開発でも受託開発でも同じ

Slide 22

Slide 22 text

プロジェクト中盤プロジェクト序盤プロジェクト終盤

Slide 23

Slide 23 text

プロジェクト序盤一番情報を持っていない（＝わからないことが多い）最初からすべてを計画することをあきらめる目指す先がないとスタートできないので必要な計画はする全体の方向性と直近の見通しが立つ適度な計画どうすれば最速でスタートすることができるか

Slide 24

Slide 24 text

No content

Slide 25

Slide 25 text

インセプションデッキプロジェクトを始める前に明らかにしておくべき  大切なことを知るための活動 10個の質問に答えていく形式チーム全員で話し合って合意したものをアウトプットする

Slide 26

Slide 26 text

大事にしているスライドチーム名・ロゴ（オリジナル）我々はなぜここにいるのかエレベーターピッチやらないことリスト・あとで決めることリスト夜も眠れなくなるような問題トレードオフスライダー OKR（オリジナル）個人としての目標（オリジナル）

Slide 27

Slide 27 text

No content

Slide 28

Slide 28 text

好きなインセプションデッキの進め方 1. 個人ワークでそれぞれ書く 2. お互いに共有し合う 3. チームで1つにまとめてアウトプットする https://takaking22.com/2019/how-to-use-inceptiondeck/

Slide 29

Slide 29 text

インセプションデッキのポイント成果物よりもつくる過程を大切にする完成させることに固執せずにできる範囲でつくるチームやプロダクトのことを自分で考えて自分で話す練習をするズレていることを見つけるチームで合意して1つのアウトプットにまとめる体験をする

Slide 30

Slide 30 text

共通の言葉がチームのコンパスになる Photo by Jordan Madrid on Unsplash

Slide 31

Slide 31 text

仕事のリズムを設計する ೔ εϓϦϯτ ೔ εϓϦϯτ ೔ εϓϦϯτ ೔ εϓϦϯτ ೔ εϓϦϯτ ೔ εϓϦϯτ ೔ εϓϦϯτ ೔ εϓϦϯτ ೔ εϓϦϯτ ೔ εϓϦϯτ プロジェクト 1週間スプリント 1週間スプリント

Slide 32

Slide 32 text

タイムボックス時間の箱をつくって繰り返していく定期的にフィードバックを得る機会をつくる比較して計測できるように箱の大きさは基本変えないコンテキストに合わせて階層構造をとってもよい

Slide 33

Slide 33 text

チームの構造プロダクトオーナー開発チームスクラムマスタープロジェクトマネージャー顧客

Slide 34

Slide 34 text

チームは階層構造であることが多い密疎理想は目指しつつも現実を受け入れる（ex. 兼務、雇用形態…）心地よいリズムや距離感が人によって違う型にはめようとせずに柔軟に設計をするスムーズ・シンプルであることを目指す

Slide 35

Slide 35 text

誰をプロダクトオーナーにするのか顧客、発注者、事業部自社、部署、チーム開発チーム自分

Slide 36

Slide 36 text

誰をプロダクトオーナーにするのか顧客、発注者、事業部自社、部署、チーム開発チーム自分ほんとはプロダクトオーナーになってほしいやりづらいので近くに仮プロダクオーナーを置く

Slide 37

Slide 37 text

役割と責任を人に当てはめてもうまくいかないことが多いはやく走れる人たちが走り回ればよい誰かに依存していること（最終決定）を明確にして、  それ以外は全体として役割を包含できればよいプロダクトオーナーやスクラムに限った話ではない誰をプロダクトオーナーにするのか

Slide 38

Slide 38 text

自分だったらこうするかなー顧客、発注者、事業部自社、部署、チーム開発チーム自分最終決定やそのために必要な準備はお願いする判断するために必要な情報を集めたり、優先順位をおすすめしたり、こまめにプロダクトを見せて確認してもらう仮プロダクトオーナーをおいてコミュニケーションを  階層構造にしない

Slide 39

Slide 39 text

全体像を一枚絵にする

Slide 40

Slide 40 text

余白をつくる最初に決めて終わりではなくここから始まる決め過ぎずに余白をもたせておくプロダクトやチームと一緒にみんなで育てていく

Slide 41

Slide 41 text

未完成をつくる Photo by Sung Shin on Unsplash

Slide 42

Slide 42 text

プロジェクト序盤プロジェクト中盤プロジェクト終盤

Slide 43

Slide 43 text

プロジェクト中盤それまでに決めたこと＝過去に縛られない目の前で起きていることにフォーカスする経験を積み重ねて解像度を上げていく取り返しのつかない失敗だけはしないようにするどうやって変わらないようにするかではなくどうやって変えていくか

Slide 44

Slide 44 text

起こった事象（Fact）動いているプロダクトフィードバック計画プロダクトバックログ開発プロセス左よりも右をより大切にする

Slide 45

Slide 45 text

動いているプロダクト実際につくること、動いているプロダクトをさわることで  はじめてわかることが多い最初に計画したものにこだわらずどんどん変える

Slide 46

Slide 46 text

プロダクトバックログ ˌ ϓϩμΫτόοΫϩάΞΠςϜ ׬੒ͷఆٛ ݟੵ΋Γ ཉ͍͠ॱ൪ʹฒΜͰ͍Δ ͜ͷॱ൪ʹ͍ͭͬͯ͘͘ ॱ൪͸ఆظతʹݟ௚͢ ༧ଌ౸ୡ఺ʢϕϩγςΟʣ աڈͷ࣮੷͔Β༧ଌ ༧૝Ͱ͸ͳ͘༧ଌ શ෦΍Βͳ͍ͷͰ ඞཁҎ্ʹઌ·Ͱ ৄࡉʹܭը͠ͳ͍

Slide 47

Slide 47 text

活き活きしたプロダクトバックログやることのリストアップではなくて仮説のリストアップ最初は解像度が荒くて質も低いが、  プロジェクトが進むにつれてどんどん育っていくプロダクトバックログへのCRUD処理が多い

Slide 48

Slide 48 text

見積もり優先順位をつけるときの判断基準としてのボリュームや、  ビジネス判断をする際に見通しを知りたいことはある上記が満たされていれば、  数字どころか見積もりそのものもいらないかもしれない数字当てゲームに時間を使い過ぎない

Slide 49

Slide 49 text

障害リストリスクだと思っていることを貯めておく箱を作る書き溜めたら忘れる定期的にチェックするタイミングをつくる（スプリント毎など）

Slide 50

Slide 50 text

決定を遅延する適切なタイミングで決定ができるようにする今決めなくていいことは先送りにする今やるべきことにフォーカスする

Slide 51

Slide 51 text

フィードバック適切なフィードバックをどうやってもらうか「それユーザーではなくてあなたの意見ですよね？」問題ユーザーの声をただ鵜呑みにするのではなく、  自分たちの仮説を検証するためにフィードバックを活用する

Slide 52

Slide 52 text

肩越しの視線実ユーザーがプロダクトを使っているところを見せてもらうこちらの想定通りに問題解決までたどりつけるか問題解決までがスムーズだったか

Slide 53

Slide 53 text

書いたコードを捨てる捨てることを厭わない捨てる＝ムダになったのではなくより洗練されたと考える Be Simple

Slide 54

Slide 54 text

モブプログラミングチーム全員で同じ時間に同じ画面を見ながら同じ仕事をするリソース効率ではなくフロー効率を重視するリモートワークにおいても有効である https://speakerdeck.com/takaking22/remote-mobprogramming-stay-home-with-team

Slide 55

Slide 55 text

No content

Slide 56

Slide 56 text

私たちのモブプログラミング ϞϒʹνʔϜ

Slide 57

Slide 57 text

一緒に作業をする会議に向けてそれぞれ準備や作業をして、  集まった時に報告・議論・判断をすることが効率がよいのか集まった時に一緒に作業を進めた方が、  スムーズに進むことは自分たちが考えている以上に多い作業の結果だけでなく過程もチームの合意となる

Slide 58

Slide 58 text

ボトルネックは移動するボトルネックは移動していくボトルネックを停滞させないボトルネックを素早く発見して移動させる

Slide 59

Slide 59 text

Photo by Grillot edouard on Unsplash

Slide 60

Slide 60 text

螺旋を登っていくイメージ似たような問題が再発しているように感じるときがある前回よりも経験を積んでいる分、解像度は上がっている解像度が上がると問題の見え方や見える範囲も変わる経験から学習してうまくなっていく

Slide 61

Slide 61 text

プロジェクト序盤プロジェクト中盤プロジェクト終盤

Slide 62

Slide 62 text

プロジェクト終盤終盤だからという理由で頑張らない特別にやることはない終わらせるのではなく次につなげる

Slide 63

Slide 63 text

最後に頑張るのをやめる終盤戦になって一気にやることが増えてしまいがち開発チームはペースを変えずに冷静に判断をするプロジェクト内でやる必要があれば計画を変えるプロジェクト内でやる必要がなければ先送りをする質を下げることだけは絶対にしてはいけない

Slide 64

Slide 64 text

次への準備に時間を割くプロダクトバックログを精査する障害リストを精査するドキュメントや環境を整える勉強をする

Slide 65

Slide 65 text

まとめ必要なことを必要なときに必要な分だけ実施する変わらないようにするのではなく、積極的に変えていく失敗しても受け身で魅せる終わらせるではなく、次につなげる

Slide 66

Slide 66 text

わからないことをどうやって解消するかわからないこととどうやって付き合っていくか経験主義計画駆動

Slide 67

Slide 67 text

こういうことを言うと… それはスクラムではない

Slide 68

Slide 68 text

フィードバックありがとうございます実装するとはこういうこといまの自分たちの頭で考えて一番よいと思うものを実装する他人にとってスクラムかどうかはあまり気にしていないこれがベストだとは思っていないので、  建設的なフィードバックはありがたく受け取る

Slide 69

Slide 69 text

で、どうしたらいいの？

Slide 70

Slide 70 text

A. 知らんわ！

Slide 71

Slide 71 text

It depends の正体抽象具体スクラム事例A 事例B 事例C

Slide 72

Slide 72 text

抽象具体スクラム事例A 事例B 事例C 自分 It depends の正体自分たちへ適応させて実装する

Slide 73

Slide 73 text

抽象具体スクラム事例A 事例B 事例C 自分 It depends の正体他者の事例を抽象化して理解し、そこから自分たちへ適応させて実装する

Slide 74

Slide 74 text

スクラムはフレームワークよいフレームワークを使ったからといって、  よいプロダクトにはなるとは限らないよいプロダクトと同じフレームワークの使い方をしたとして、  よいプロダクトになるとは限らないフレームワークを使ってどう実装するのかは  実装者の腕の見せどころ

Slide 75

Slide 75 text

It depends の正体実装力が問われているシステムを実装するときに、  他人のコードをそのままコピペして動かそうとはしないはず実装に必要な情報を一番多く持っているのは自分自身 It depends を脱却して先へ行くのは自分自身

Slide 76

Slide 76 text

自問自答してみよう行動せずに難しいかどうかを批評してしまっていないか答えクレクレ君、事例クレクレ君になっていないか

Slide 77

Slide 77 text

実装力 Photo by Thao Le Hoang on Unsplash

Slide 78

Slide 78 text

どうやって実装力を上げるか知識をインプットする人に聞きやすい部分書籍、論文、勉強会、研修経験を積み重ねる

Slide 79

Slide 79 text

どうやって経験を積み重ねるか現場で実験をする思考実験をする

Slide 80

Slide 80 text

思考実験現場の制約に関係なく、実験し放題である一人ではなくて誰かとやるとよい相手や自分の具体的な事象について話す自分の頭で考えてフィードバックをもらう Open Space Technology やオンラインの場を使う

Slide 81

Slide 81 text

自分のことが話せるオンラインの場分散アジャイルチームについて考える会製造業アジャイル勉強会アジャイル・ディスカッション Scrum Masters Night! スクラム道関西 …

Slide 82

Slide 82 text

自分の頭で考えるなるほど！勉強になりました刺激を受けましたなぜそうしたんだろう自分だったらこうする

Slide 83

Slide 83 text

論理感覚実装力

Slide 84

Slide 84 text

スクラムは難しいのかスクラムが難しいかどうかを気にしたことがないなぜならプロダクト開発が難しいことを知っているわからないことだらけだって知っているわからないことをどうやって解消するかだけではなくて、  わからないこととどうやって付き合っていくかを考えるスクラムの習得もスクラムと同じ経験主義

Slide 85

Slide 85 text

It depends から実装の世界へ Photo by Grant Ritchie on Unsplash