形式スクラムの功罪

by yumechi(Motoki Hirao)

Slide 1

Slide 1 text

形式スクラムの功罪  Motoki Hirao 

Slide 2

Slide 2 text

twitter: @__yumechi misskey: @[email protected]  発表者について  ● Motoki Hirao  ● twitter: @__yumechi misskey: @[email protected]  ● ４月から転職して開発者になりました（それまではスクラムマスターを１年ほど）  ● なぜかスクラムとかアジャイルを入れるぜ！ってタイミングで会社や組織に所属しています  ● 趣味はゲームやカンファレンス（主に関東）に参加すること 

Slide 3

Slide 3 text

twitter: @__yumechi misskey: @[email protected]  初めての大阪、どきどきわくわくしてます  ● 通過駅や乗り換えのタイミングでご飯食べに降りたことはありますが、それ以外では来たことがない  ● 日曜日は観光して帰る予定なので、おすすめスポット有ればおしえてください！  ● 特になければ大阪城行くつもりです 

Slide 4

Slide 4 text

twitter: @__yumechi misskey: @[email protected]  この発表に関しての注意事項  ● 私個人の経験による主観のため、N=1の内容でしかありません  ● 記憶ベースで書いているので事実が若干歪んでいる可能性もあります  ● 特定の所属組織の話ではなく、多くの場所でアジャイル・スクラムを実践するんだ！となって現実的に私・私たちが見てきた課題点を取り上げています 

Slide 5

Slide 5 text

twitter: @__yumechi misskey: @[email protected]  本発表の概要  ● ウォーターフォールライクな開発チームにスクラムを導入する難しさ  ● 形式的なスクラムで解決できた問題  ● 形式スクラムの問題  ● 今後うまくやれそうな導入を考えてみる 

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

ライクって  なんやねん！  https://soco-st.com/1722 より 

Slide 9

Slide 9 text

twitter: @__yumechi misskey: @[email protected]  なぜウォーターフォール「ライク」なのか  ● 厳密にウォーターフォールを実行するのは難しいし、体感100%そのプロジェクトやプロダクトルールの何かが運用されている  ○ 参考：だったら WF でやればいいぢゃない!   ○ https://www.docswell.com/s/tommy109/K2XRMZ-2023-01-12-231349  ● おそらく社会の共通認識的にこれくらいの概念のなにかだけが残っている（と、発表者は考えている）  ○ 要求分析、設計、実装、テスト、総合・受入テスト、リリース  

Slide 10

Slide 10 text

twitter: @__yumechi misskey: @[email protected]  そんな中でスクラム・アジャイルを学習する壁  ● 人はパターン認識的に学習しようとするので、ウォーターフォールライクな手法と対比して学習しようとする  ○ https://ja.wikipedia.org/wiki/パターン認識  ○ アジャイルソフトウェア開発宣言は対話・協調を大事にし、変化し続けるソフトウェア開発という点でイメージがしやすい（表面的には…） 

Slide 11

Slide 11 text

twitter: @__yumechi misskey: @[email protected]  マッピングできないスクラムの概念  ● スクラムイベントがそもそもマッピング不可能  ○ 朝会、夕会 → デイリースクラム  ○ プロトタイピングなもの？基本設計？ → スプリントレビュー  ○ 計画や要件定義？？ → スプリントプランニング  ○ 振り返り？（そもそもウォーターフォールライクにはない） → スプリントレトロスペクティブ  ● 役割についてもマネージャー → スクラムマスター？？  ● プロダクトオーナーとマネージャーの違いは？？ 

Slide 12

Slide 12 text

知識が共通認識  になっていない場合は  更に色々出てくる… 

Slide 13

Slide 13 text

はい、理解できません  終了です 

Slide 14

Slide 14 text

はい、理解できません  終了です  https://www.irasutoya.com/2014/03/blog-post_2687.html より 

Slide 15

Slide 15 text

うまく行った  ワークを紹介 

Slide 16

Slide 16 text

twitter: @__yumechi misskey: @[email protected]  頑張ってみんなで学びましょう  ● 実際やってみて良かったこと  ○ スクラムガイドをみんなで読んで理解を深める（定期的に）   ○ スクラムガイドをみんなで音読する  ○ このプロダクト・このプロジェクトでの役割やスクラムイベントで何をやるかの詳細をつめて可視化する  ■ ドキュメントの準備が大事、体制図は大事   ● 実際やってみてうまく行かなかったこと  ○ 各々でスクラムガイドを読んでもらう  

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

みんなで行け  的なやつ  https://loosedrawing.com/illust/1129/ より 

Slide 22

Slide 22 text

twitter: @__yumechi misskey: @[email protected]  ● 関係者に我々はスクラムをやります！ということを伝える  ○ コミュニケーションが増えて手戻りが減るとかのメリット   ○ MTGが多少増えて、リーダー・マネージャーを介さないコミュニケーション増えるデメリット   ● スプリントやイベントをいつ行うのか調整する  ○ 体感、なぜか２週間スプリントで始めるものの１週間にすることが多い   ○ （スプリントの経験数が増えるとその分うまくスプリントが回るようになるため）   ○ スクラムイベントの時間が長すぎても良くないので調整する   スクラムのメリットや進め方を浸透させる 

Slide 23

Slide 23 text

Slide 24

Slide 24 text

形式スクラムの定義…  スクラムイベントと  各種役割は決めて  動いていることとします 

Slide 25

Slide 25 text

twitter: @__yumechi misskey: @[email protected] 

Slide 26

Slide 26 text

まとめると、  納得感かなぁ  https://loosedrawing.com/illust/1378/ より 

Slide 27

Slide 27 text

twitter: @__yumechi misskey: @[email protected]  ウォーターフォールライクで起きがちな問題  ● これまでのコミュニケーション  ○ リーダー・マネージャーが決めてくる   ○ その決定に対して、開発者視点での問題は上がりづらい   ● これまでのスプリント・イテレーション  ○ 機能ごと・プロジェクトごとになるのでスパンが長い、リズムがない  ○ 毎回ふりかえることはない、というか忘れる 

Slide 28

Slide 28 text

twitter: @__yumechi misskey: @[email protected]  スクラムの持つ性質によるメリット  ● コミュニケーション  ○ スクラムイベントで必然的に増える   ○ いろいろな人の発言を通して、知見や考え方が共有される  ○ ふりかえりから課題や問題を共有し、より良いアイディアで解決できる   ● スプリント・イテレーション  ○ タイムボックスが明確に区切られているので、次までに何をするかが明確  ○ どこまで進められるのかの合意形成もできる   ○ イベントを通してプロセスの改善もできる 

Slide 29

Slide 29 text

ただし、これは  どちらかといえばこれまでの  コミュニケーション  に問題があり、それが顕在化  しただけに過ぎないのだ… 

Slide 30

Slide 30 text

開発者も言われたものを  作るのではなく、  より便利になるものを  作りたい（はず） 

Slide 31

Slide 31 text

twitter: @__yumechi misskey: @[email protected]  専門性を生かした仕事をする  ● コミュニケーションが改善されて専門性を生かし、色々任せながら進められるようになる  ○ コミュニケーション量が増え、タスクの取りこぼしが減り役割分担が明確に   ○ POはプロダクトのことを考えながら優先順位を考える   ○ SMは開発者を支援しつつ、プロダクト開発がうまく進むようにいろいろ動き回る   ○ 開発者は開発視点で意見しながらプロダクトに貢献する  

Slide 32

Slide 32 text

コミュニケーションを  密にすることで  私たちはプロダクトの  方向性を理解し、  ユーザーの行動変容をどう  起こしたいのかを理解する 

Slide 33

Slide 33 text

プロダクトが向かう  方向やユーザーから  考えたときの  納得感がある！  https://loosedrawing.com/illust/987/ より 

Slide 34

Slide 34 text

言われたものを作る  を超え始めた！ 

Slide 35

Slide 35 text

ただし、  デリバリ速度の改善  まではわからないなぁ  という感想…（これまでの計測が甘い問題も含む） 

Slide 36

Slide 36 text

＝スクラムは開発速度を  改善する銀の弾丸ではない 

Slide 37

Slide 37 text

ただ納得感があることは  もっと良いステップに  つながるはず  （うまく言葉にできない…）  https://loosedrawing.com/illust/1434/  より 

Slide 38

Slide 38 text

Slide 39

Slide 39 text

よし、順調にイベントが回っているな！ 

Slide 40

Slide 40 text

ただなんかうまくいってない気がするぞ？ 

Slide 41

Slide 41 text

アジャイルソフトウェア  宣言に立ち返ると 

Slide 42

Slide 42 text

「プロセスやツールよりも個人と対話を」  と一番上に書いてある    https://agilemanifesto.org/iso/ja /manifesto.html   

Slide 43

Slide 43 text

アジャイル宣言の背後にある原則  に立ち返ると 

Slide 44

Slide 44 text

「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。」  https://agilemanifesto.org/iso/ja/principles.html より 

Slide 45

Slide 45 text

「チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。」  https://agilemanifesto.org/iso/ja/principles.html より 

Slide 46

Slide 46 text

おやおや？？？ 

Slide 47

Slide 47 text

形式スクラム最大の  弱点、それは… 

Slide 48

Slide 48 text

顧客への価値提供より  プロセスに従う  選択をしてしまうこと  🙀

Slide 49

Slide 49 text

プロダクトを良くする  という本質から  離れてしまうこと  😇

Slide 50

Slide 50 text

twitter: @__yumechi misskey: @[email protected]  イベントが定義されていることによるデメリメ  ● スクラムイベントが明確に定義されていることが良い面も悪い面も包含している  ○ 良い面：開発を一定のリズムで行う、コミュニケーションを取れる、スプリントゴールを設定して明確な形で進められる  ○ 悪い面: スクラムイベントをやっていればスクラムという誤った認識や誤解を持ってしまう、スクラムイベントに参加することが仕事になってしまう（コミュニケーションを取ることはしなくてもよい）   

Slide 51

Slide 51 text

twitter: @__yumechi misskey: @[email protected]  ウォーターフォールライク概念の亡霊  ● ウォーターフォールライクな開発プロセスにマッピングされたアジャイル・スクラムから外れた概念のまま進行してしまう危険性  ○ リリースなのか、デプロイなのか、納品なのか   ○ ストーリーポイントなのか、工数なのか   ○ 設計？実装？テスト？  ● これまでの開発プロセス・関係性に引き戻される危険  ○ 今までのやり方でもなんとかうまくやれていたから戻そう   ○ 開発者はMTGに出ずに開発に集中したい etc…   

Slide 52

Slide 52 text

twitter: @__yumechi misskey: @[email protected]  これが進行していくとどうなるのか？  ● 必要なメンバーが揃わないままスクラムイベントスタート  ○ 他の会議をしょっちゅう優先してしまう、絶対イベントに来ないチームメンバー   ○ あとから議事録を眺めて個別の追加の MTGなどが色々組まれる  ● ファシリテーターだけが方向性を定める形になってしまう  ○ 気がついたらファシリテーターが１時間話して終わってしまった！   ○ ファシリテーターが毎回固定…  ● etc…etc…   

Slide 53

Slide 53 text

Slide 54

Slide 54 text

twitter: @__yumechi misskey: @[email protected]  疲れてくると負のループに陥る  ● これまで問題になってたことが戻ってくる  ○ リーダーだけMTGに出ましょう→コミュニケーション不足  ○ ふりかえりはしません！→ プロセスが改善されない  ○ スケジュールを決めたのでこの通りやりましょう →開発の課題が上がりにくくなり、大変になる  ● 単純な疲れから生産性のダウン、モチベーション低下、チーム離脱…  ○ 疲れて労働時間が長くなる、全くあまりいいことはない   ■ 軽く調べても「我が国における労働生産性をめぐる現状と課題」など出てくる   ■ https://www.sangiin.go.jp/japanese/annai/chousa/rippou_chousa/backnumber/2018p df/20180601041.pdf 

Slide 55

Slide 55 text

Slide 56

Slide 56 text

twitter: @__yumechi misskey: @[email protected]  正しいスクラムに向き直りをするために  ● すでにゾンビスクラムと言われている段階に来ていると思うので、ゾンビスクラムサバイバルガイドを読んで実践する  ○ https://www.maruzen-publishing.co.jp/item/b304740.html  ● アジャイルソフトウェア開発宣言やスクラムガイドの読み直し  ○ 概念をもう一度捉え直す  ○ 今なんとなくやっていることが原義からいい意味で外れているのか、悪い意味で外れているのかを考える  ● ファシリテーターを毎回変えてみる   

Slide 57

Slide 57 text

twitter: @__yumechi misskey: @[email protected]  正しいスクラムに向き直りをするために  ● すでにゾンビスクラムと言われている段階に来ていると思うので、ゾンビスクラムサバイバルガイドを読んで実践する  ○ https://www.maruzen-publishing.co.jp/item/b304740.html  ● アジャイルソフトウェア開発宣言やスクラムガイドの読み直し  ○ 概念をもう一度捉え直す  ○ 今なんとなくやっていることが原義からいい意味で外れているのか、悪い身で外れているのかを考える  ● ファシリテーターを毎回変えてみる    あんまりうまくいかなかった

Slide 58

Slide 58 text

twitter: @__yumechi misskey: @[email protected]  それぞれに対してうまく行かなかったポイント  ● すでにゾンビスクラムと言われている段階に来ていると思うので、ゾンビスクラムサバイバルガイドを読んで実践する  ○ https://www.maruzen-publishing.co.jp/item/b304740.html  ● アジャイルソフトウェア開発宣言やスクラムガイドの読み直し  ○ 概念をもう一度捉え直す  ○ 今なんとなくやっていることが原義からいい意味で外れているのか、悪い身で外れているのかを考える  ● ファシリテーターを毎回変えてみる    自分一人で理解してもついてこないなんとなく反応薄め… 個人のファシリテーション能力に強依存、イベントの再現性がなくなってしまう

Slide 59

Slide 59 text

twitter: @__yumechi misskey: @[email protected]  今ふりかえるとこうしたい  ● すでにゾンビスクラムと言われている段階に来ていると思うので、ゾンビスクラムサバイバルガイドを読んで実践する  ○ https://www.maruzen-publishing.co.jp/item/b304740.html  ● アジャイルソフトウェア開発宣言やスクラムガイドの読み直し  ○ 概念をもう一度捉え直す  ○ 今なんとなくやっていることが原義からいい意味で外れているのか、悪い身で外れているのかを考える  ● ファシリテーターを毎回変えてみる    みんなでスクラムに問題があることを理解し、改善に向けて活動する外部者やアジャイルコーチに入ってもらう何度か様子を見る、まずはデイリースクラムから。デイリースクラムは回数をこなしやすいので最適。

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

twitter: @__yumechi misskey: @[email protected]  チームの局所最適化は起きていた  ● 開発手法が同じプロダクト内でバラバラしていた  ● システム間で開発手法を分断すると…？  ○ POと話している量が違うので、エンジニア間でも視座の違いが生まれやすくなる   ○ プランナー・ディレクター間でもエンジニアの理解度が変わってしまう   ■ ただ開発を委託する人から、一緒にプロダクトを盛り上げていく人に代わっている人に代わっている  ■ 人によって扱いが…   

Slide 66

Slide 66 text

twitter: @__yumechi misskey: @[email protected]  開発手法は違ってもいいけれど  ● アジャイル・スクラムを採用していないチームにも文化的に浸透が必要かもしれない  ● ステークホルダーに対してアジャイル・スクラムは手法が変わるだけではなく、文化形成が変わり関係性も変わること、と認識を変えてもらう必要があったのかも  ● いろいろな手法がある状態が無視できないレベルになったら、組織自体が変わっていく決断も必要かもしれない（私に権限はないですがｗ）  

Slide 67

Slide 67 text

昨日のKeynote聞いた  感想では、このあたりの  突破力は身につけないと  あかんなとなりました😇😇 

Slide 68

Slide 68 text

Slide 69

Slide 69 text

これはもう、  スクラムという言葉も  概念も一回持ち込まない 

Slide 70

Slide 70 text

twitter: @__yumechi misskey: @[email protected]  スクラムを導入する前にアジャイルマインドをやる  ● 過去の経験からアジャイルの代表例としてスクラムを導入しようと試みてきたが、スクラムイベントというプロセスに飲み込まれた  ○ スクラムのプロセスに頭を固定するのは絶対に避けたい   ● なのでいきなりスクラムに変えよう、はなんとしても避けたい  ○ アジャイルソフトウェア開発宣言や、アジャイル宣言の背後にある原則を読む   ○ 現状の自分たちの開発においてコミュニケーション不足なところから変える  

Slide 71

Slide 71 text

twitter: @__yumechi misskey: @[email protected]  レトロスペクティブ（ふりかえり）から入れたい  ● 自分たちを知らないと手の打ちようがない、まずは自分たちを知ろう  ● 経験上、その結果やプロセスについてのふりかえりは十分でないことも多い  ○ うまくいかなかったプロジェクトとかでものど元過ぎれば … みたいな実感はある  ○ とりあえず今の方法でやれているのでやっている、とかは十分にある   ● コミュニケーションが少なめでもうまく行くのであれば問題ないので無理にやらない  ○ 場合によってはアジャイル・スクラムを導入しないのも選択肢に入れて良い  

Slide 72

Slide 72 text

twitter: @__yumechi misskey: @[email protected]  どうふりかえるか  ● ふりかえりカタログを見ながら選定する  ○ ふりかえりカタログ / Retrospective Catalog - Speaker Deck   ○ https://speakerdeck.com/viva_tweet_x/retrospective-catalog-59bd3a29-314c-45d d-911b-f8e5f1308333  ● テーマによってふりかえり手法を変えたり…  ○ 普段の開発プロセスのふりかえりは KPTA  ○ 前向きになりたいときは Fun, Done, Learnなど  ● ふりかえりの手法選定は自分もまだまだ経験不足なので試行錯誤中 

Slide 73

Slide 73 text

twitter: @__yumechi misskey: @[email protected]  次はデイリースクラムをやりたい  ● 普段から顔合わせしてコミュニケーションは増やしておきたい  ○ コミュニケーションしたことがない相手を減らしておくのは大事だと思う   ● 毎日話すことによって日々の動向を知りつつ、課題となっている点を共有し、問題解決や優先順位を相談したい  ● 可能ならモニタリングとかも一緒に見ながら話せるといいなーとか   

Slide 74

Slide 74 text

twitter: @__yumechi misskey: @[email protected]  以降のスクラムイベントは必要に応じて  ● 本質的にやりたいのは気持ちよく働いて、良いプロダクトを顧客・ユーザーに届けることであるので、スクラムを導入することではない  ○ スクラムを導入するという方法の目的化は避けなければいけない   ● 他のスクラムイベントはチームの様子を見ながら  ○ デイリーのところでコミュニケーションがいっぱいいっぱいな感じであれば、一旦デイリーに慣れてもらうまで待つ  ○ チームが成熟していないのにコミュニケーション頻度が高いスクラムを行うのは難しいので… 

Slide 75

Slide 75 text

対話しながら  そのチームにとって  必要で成長できる  方法を提案したい  https://loosedrawing.com/illust/1411/ より 

Slide 76

Slide 76 text

twitter: @__yumechi misskey: @[email protected]  自分はスクラムマスターが適切だったのか？  ● 技術に触れる時間が減ったことに違和感があった  ○ 元々、開発のリードとしてテックリード寄りの考え方だった   ■ 開発したいものを渡すことにやや抵抗があった   ○ アジャイルスクラムについて教えながら、技術的なインプットもアウトプットも行っていた   ● スクラムマスターになった経験自体はとてもよかった、一方で今の自分が貢献できることは開発のほうが大きいという感覚  ○ 開発者視点でアジャイルを支えられることもたくさんある、自動化など  

Slide 77

Slide 77 text

自分のキャリアの壁打ちを誰か… 懇親会で… 

Slide 78

Slide 78 text

twitter: @__yumechi misskey: @[email protected]  まとめ  ● 導入時にはみんなでアジャイル・スクラムを学習しよう  ● アジャイル・スクラムはコミュニケーションが増えるため、コミュニケーションフローの改善に繋がり、プロダクトの方向性に納得感が生まれる  ● スクラムのイベントをこなす流れになると、定期的にあるイベントをこなすだけになりプロダクトへの指向性が薄れ、本質から遠ざかってしまう  ● スクラム導入を目的とせず、アジャイルなマインドを身につける。発表者も試行錯誤中！まずはチームとの対話を行う「ふりかえり」が鍵 

Slide 79

Slide 79 text

twitter: @__yumechi misskey: @[email protected]  利用情報  ● スライド作成: Google Slide https://www.google.com/slides/about/  ● フォント: Noto Sans https://fonts.google.com/noto/specimen/Noto+Sans  ● 利用画像  ○ フリーイラスト素材集｜ちょうどいいイラスト https://tyoudoii-illust.com/  ○ Loose Drawing | 無料で商用利用可なフリーイラスト https://loosedrawing.com/  ○ shigureni free illust │ 素朴で可愛い、女の子のイラスト素材サイト https://www.shigureni.com/  ○ 商用可・フリーイラスト素材｜ソコスト https://soco-st.com/  ○ ドット絵ダウンロードサイト DOTOWN|無料の素材サイト https://dotown.maeda-design-room.net/  ○ かわいいフリー素材集いらすとや https://www.irasutoya.com/ 