2020年11月5〜7日に開催された「SCRUM FEST SAPPORO 2020 」にて。
It depends から脱却するスクラム及部敬雄 (@TAKAKING22)Photo by Pablo Heimplatz on Unsplash
View Slide
スクラムが難しいと感じるのはどんなところですか？
スクラムガイドから複雑で変化の激しい問題に対応するためのフレームワークスクラムフレームワークは、スクラムチームとその役割・ イベント・作成物・ルールで構成されている。それぞれに目的があり、スクラムの成功や利用に欠かせない。スクラムフレームワークを使用する具体的な方法にはさまざまな ものがあり、それらについては本稿では触れない。
スクラムを難しいと感じる理由を聞いてみたわかるようでわからない具体的なのか抽象的なのかわからないどこからはじめればよいのかわからないどうやって自分たちの状況にあてはめればよいのかわからない
再びスクラムガイドからスクラムとは、以下のようなものである。・軽量・理解が容易・習得は困難マジ！？
いざ詳しい人に聞いてみると…It depends状況に依るね
は!?
!5",",*/(גࣜձࣾσϯιʔσδλϧΠϊϕʔγϣϯࣨ"(*-&.0/45&3$0.ʢݸਓࣄۀओʣ4*-7&3#6--&5$-6#ʢνʔϜෳۀʣٴ෦ܟ༤੍ޚෆೳͳΞδϟΠϧϞϯελʔ
It dependsマインドセット心理的安全性
それっぽい言葉どんなことでもだいたい It dependsどんなときでも心理的安全性もマインドセットは大切確かにそのとおりでも一切情報量が増えていない
で、どうしたらいいの？
ここからのお話実際の現場で自分がどうしているのか大事にしていること特に気をつけていることなぜそれをやっているのかIt depends で片付けずに実装の話をする
仕事をとりまく状況どうなるのかわからないビジネスどうすればよいのかわからないプロダクト何を考えているのかわからない人たちなぜそうなっているのかわからない組織やルール
わかるうまくいくわからないうまくいかない
わかるうまくいくわからないうまくいかない未知のわからない
わからないなんてふつうだ！わからないことだらけわからないことが多いと不安なので解消したくなるなにかがわかるとまた新しいわからないことが見つかる常にわからないはそこにある
こうやって考えてるわからないことをどうやって解消するかわからないこととどうやって付き合っていくか
プロジェクト序盤 プロジェクト中盤 プロジェクト終盤
プロジェクトプロジェクト人生チームプロダクトシステム
プロジェクトプロジェクトは終わらせるために行うプロジェクトは続いていくなにかのための活動内製開発でも受託開発でも同じ
プロジェクト中盤プロジェクト序盤 プロジェクト終盤
プロジェクト序盤一番情報を持っていない（＝わからないことが多い）最初からすべてを計画することをあきらめる目指す先がないとスタートできないので必要な計画はする全体の方向性と直近の見通しが立つ適度な計画どうすれば最速でスタートすることができるか
インセプションデッキプロジェクトを始める前に明らかにしておくべき 大切なことを知るための活動10個の質問に答えていく形式チーム全員で話し合って合意したものをアウトプットする
大事にしているスライドチーム名・ロゴ（オリジナル）我々はなぜここにいるのかエレベーターピッチやらないことリスト・あとで決めることリスト夜も眠れなくなるような問題トレードオフスライダーOKR（オリジナル）個人としての目標（オリジナル）
好きなインセプションデッキの進め方1. 個人ワークでそれぞれ書く2. お互いに共有し合う3. チームで1つにまとめてアウトプットするhttps://takaking22.com/2019/how-to-use-inceptiondeck/
インセプションデッキのポイント成果物よりもつくる過程を大切にする完成させることに固執せずにできる範囲でつくるチームやプロダクトのことを自分で考えて自分で話す練習をするズレていることを見つけるチームで合意して1つのアウトプットにまとめる体験をする
共通の言葉がチームのコンパスになるPhoto by Jordan Madrid on Unsplash
仕事のリズムを設計するεϓϦϯτεϓϦϯτεϓϦϯτεϓϦϯτεϓϦϯτεϓϦϯτεϓϦϯτεϓϦϯτεϓϦϯτεϓϦϯτプロジェクト1週間スプリント 1週間スプリント
タイムボックス時間の箱をつくって繰り返していく定期的にフィードバックを得る機会をつくる比較して計測できるように箱の大きさは基本変えないコンテキストに合わせて階層構造をとってもよい
チームの構造プロダクトオーナー開発チームスクラムマスタープロジェクトマネージャー顧客
チームは階層構造であることが多い密 疎理想は目指しつつも現実を受け入れる（ex. 兼務、雇用形態…）心地よいリズムや距離感が人によって違う型にはめようとせずに柔軟に設計をするスムーズ・シンプルであることを目指す
誰をプロダクトオーナーにするのか顧客、発注者、事業部自社、部署、チーム開発チーム自分
誰をプロダクトオーナーにするのか顧客、発注者、事業部自社、部署、チーム開発チーム自分ほんとはプロダクトオーナーになってほしいやりづらいので近くに仮プロダクオーナーを置く
役割と責任を人に当てはめてもうまくいかないことが多いはやく走れる人たちが走り回ればよい誰かに依存していること（最終決定）を明確にして、 それ以外は全体として役割を包含できればよいプロダクトオーナーやスクラムに限った話ではない誰をプロダクトオーナーにするのか
自分だったらこうするかなー顧客、発注者、事業部自社、部署、チーム開発チーム自分最終決定やそのために必要な準備はお願いする判断するために必要な情報を集めたり、優先順位をおすすめしたり、こまめにプロダクトを見せて確認してもらう仮プロダクトオーナーをおいてコミュニケーションを 階層構造にしない
全体像を一枚絵にする
余白をつくる最初に決めて終わりではなくここから始まる決め過ぎずに余白をもたせておくプロダクトやチームと一緒にみんなで育てていく
未完成をつくるPhoto by Sung Shin on Unsplash
プロジェクト中盤それまでに決めたこと＝過去に縛られない目の前で起きていることにフォーカスする経験を積み重ねて解像度を上げていく取り返しのつかない失敗だけはしないようにするどうやって変わらないようにするかではなくどうやって変えていくか
起こった事象（Fact）動いているプロダクトフィードバック計画プロダクトバックログ開発プロセス左よりも右をより大切にする
動いているプロダクト実際につくること、動いているプロダクトをさわることで はじめてわかることが多い最初に計画したものにこだわらずどんどん変える
プロダクトバックログˌ ϓϩμΫτόοΫϩάΞΠςϜ ͷఆٛ ݟੵΓ ཉ͍͠ॱ൪ʹฒΜͰ͍Δ͜ͷॱ൪ʹ͍ͭͬͯ͘͘ॱ൪ఆظతʹݟ͢༧ଌ౸ୡʢϕϩγςΟʣաڈͷ࣮͔Β༧ଌ༧Ͱͳ͘༧ଌશ෦Βͳ͍ͷͰඞཁҎ্ʹઌ·Ͱৄࡉʹܭը͠ͳ͍
活き活きしたプロダクトバックログやることのリストアップではなくて仮説のリストアップ最初は解像度が荒くて質も低いが、 プロジェクトが進むにつれてどんどん育っていくプロダクトバックログへのCRUD処理が多い
見積もり優先順位をつけるときの判断基準としてのボリュームや、 ビジネス判断をする際に見通しを知りたいことはある上記が満たされていれば、 数字どころか見積もりそのものもいらないかもしれない数字当てゲームに時間を使い過ぎない
障害リストリスクだと思っていることを貯めておく箱を作る書き溜めたら忘れる定期的にチェックするタイミングをつくる（スプリント毎など）
決定を遅延する適切なタイミングで決定ができるようにする今決めなくていいことは先送りにする今やるべきことにフォーカスする
フィードバック適切なフィードバックをどうやってもらうか「それユーザーではなくてあなたの意見ですよね？」問題ユーザーの声をただ鵜呑みにするのではなく、 自分たちの仮説を検証するためにフィードバックを活用する
肩越しの視線実ユーザーがプロダクトを使っているところを見せてもらうこちらの想定通りに問題解決までたどりつけるか問題解決までがスムーズだったか
書いたコードを捨てる捨てることを厭わない捨てる＝ムダになったのではなくより洗練されたと考えるBe Simple
モブプログラミングチーム全員で同じ時間に同じ画面を見ながら同じ仕事をするリソース効率ではなくフロー効率を重視するリモートワークにおいても有効であるhttps://speakerdeck.com/takaking22/remote-mobprogramming-stay-home-with-team
私たちのモブプログラミングϞϒʹνʔϜ
一緒に作業をする会議に向けてそれぞれ準備や作業をして、 集まった時に報告・議論・判断をすることが効率がよいのか集まった時に一緒に作業を進めた方が、 スムーズに進むことは自分たちが考えている以上に多い作業の結果だけでなく過程もチームの合意となる
ボトルネックは移動するボトルネックは移動していくボトルネックを停滞させないボトルネックを素早く発見して移動させる
Photo by Grillot edouard on Unsplash
螺旋を登っていくイメージ似たような問題が再発しているように感じるときがある前回よりも経験を積んでいる分、解像度は上がっている解像度が上がると問題の見え方や見える範囲も変わる経験から学習してうまくなっていく
プロジェクト終盤終盤だからという理由で頑張らない特別にやることはない終わらせるのではなく次につなげる
最後に頑張るのをやめる終盤戦になって一気にやることが増えてしまいがち開発チームはペースを変えずに冷静に判断をするプロジェクト内でやる必要があれば計画を変えるプロジェクト内でやる必要がなければ先送りをする質を下げることだけは絶対にしてはいけない
次への準備に時間を割くプロダクトバックログを精査する障害リストを精査するドキュメントや環境を整える勉強をする
まとめ必要なことを必要なときに必要な分だけ実施する変わらないようにするのではなく、積極的に変えていく失敗しても受け身で魅せる終わらせるではなく、次につなげる
わからないことをどうやって解消するかわからないこととどうやって付き合っていくか経験主義計画駆動
こういうことを言うと…それはスクラムではない
フィードバックありがとうございます実装するとはこういうこといまの自分たちの頭で考えて一番よいと思うものを実装する他人にとってスクラムかどうかはあまり気にしていないこれがベストだとは思っていないので、 建設的なフィードバックはありがたく受け取る
A. 知らんわ！
It depends の正体抽象具体スクラム事例A 事例B 事例C
抽象具体スクラム事例A 事例B 事例C 自分It depends の正体自分たちへ適応させて実装する
抽象具体スクラム事例A 事例B 事例C 自分It depends の正体他者の事例を抽象化して理解し、そこから自分たちへ適応させて実装する
スクラムはフレームワークよいフレームワークを使ったからといって、 よいプロダクトにはなるとは限らないよいプロダクトと同じフレームワークの使い方をしたとして、 よいプロダクトになるとは限らないフレームワークを使ってどう実装するのかは 実装者の腕の見せどころ
It depends の正体実装力が問われているシステムを実装するときに、 他人のコードをそのままコピペして動かそうとはしないはず実装に必要な情報を一番多く持っているのは自分自身It depends を脱却して先へ行くのは自分自身
自問自答してみよう行動せずに難しいかどうかを批評してしまっていないか答えクレクレ君、事例クレクレ君になっていないか
実装力Photo by Thao Le Hoang on Unsplash
どうやって実装力を上げるか知識をインプットする人に聞きやすい部分書籍、論文、勉強会、研修経験を積み重ねる
どうやって経験を積み重ねるか現場で実験をする思考実験をする
思考実験現場の制約に関係なく、実験し放題である一人ではなくて誰かとやるとよい相手や自分の具体的な事象について話す自分の頭で考えてフィードバックをもらうOpen Space Technology やオンラインの場を使う
自分のことが話せるオンラインの場分散アジャイルチームについて考える会製造業アジャイル勉強会アジャイル・ディスカッションScrum Masters Night!スクラム道関西…
自分の頭で考えるなるほど！勉強になりました刺激を受けましたなぜそうしたんだろう自分だったらこうする
論理 感覚実装力
スクラムは難しいのかスクラムが難しいかどうかを気にしたことがないなぜならプロダクト開発が難しいことを知っているわからないことだらけだって知っているわからないことをどうやって解消するかだけではなくて、 わからないこととどうやって付き合っていくかを考えるスクラムの習得もスクラムと同じ経験主義
It depends から実装の世界へPhoto by Grant Ritchie on Unsplash
takaking22
sat
lmi
oldbigbuddha
coconala_engineer
shibuiwilliam
nishiuma
bengo4com
yoshidashingo
poteboy
tomoaki25
chiroito
mongodb
brad_frost
addyosmani
hatefulcrawdad
chriscoyier
lemiorhan
geeforr
wjessup
jensimmons
dotmariusz
reverentgeek
davidbonilla