スクラム導入して変わったチーム、組織のありかた

by yumechi(Motoki Hirao)

Slide 1

Slide 1 text

https://www.dip-net.co.jp/ ディップ株式会社平尾元紀（ひらおもとき）スクラム導入して変わったチーム、組織のありかた

Slide 2

Slide 2 text

https://www.dip-net.co.jp/ 自己紹介 • 2021年7月に開発者としてディップにジョイン • 機能開発を行うスクラムチームのスクラムマスターを担当 • ゲームが好き（最近はポケモン） 2 会社ではこんなアイコンでやってます！

Slide 3

Slide 3 text

https://www.dip-net.co.jp/ 自分が担当しているプロダクト 3 引用: https://www.hatarako.net/kanto/

Slide 4

Slide 4 text

https://www.dip-net.co.jp/ 簡易アーキテクチャ図 4

Slide 5

Slide 5 text

https://www.dip-net.co.jp/ 今日のアジェンダ • これまでの開発体制と、求める仕事の変化 • スクラム始めてみた！ • 今の状況とこれから 5

Slide 6

Slide 6 text

https://www.dip-net.co.jp/ 今日のアジェンダ • これまでの開発体制と、求める仕事の変化 • スクラム始めてみた！ • 今の状況とこれから 6

Slide 7

Slide 7 text

https://www.dip-net.co.jp/ これまでの開発体制 7 • タスクの依頼関係だった • 企画部門でアイデア出す、PM が整理、見積もりや実装をパートナーさんの開発者に依頼するフロー

Slide 8

Slide 8 text

https://www.dip-net.co.jp/ PHPカンファレンス2022で発表しました裏でやっていたプロジェクト終了 https://fortee.jp/phpcon- 2022/proposal/ab138440-5240-43be-99ed- 3680bad17085

Slide 9

Slide 9 text

https://www.dip-net.co.jp/ 9 ディップのエンジニアもパートナーさんと一緒に開発するフローになった

Slide 10

Slide 10 text

https://www.dip-net.co.jp/ 現在の進め方のふりかえり 10 • タスクの依頼関係だった • 企画部門でアイデア出す、PM が整理、見積もりや実装をパートナーさんの開発者に依頼するフロー

Slide 11

Slide 11 text

https://www.dip-net.co.jp/ 私が考える社員エンジニアの思考 • プロダクトの成長にコミットしたい • プロダクトの機能面の企画から入りたい、ユーザー体験を改善したい、納品型の開発ではなく継続的に開発したい • 多様なメンバーとサービスを成功に導きたい • 開発者だけのやりとりに閉じず、企画職とも会話するなど 11

Slide 12

Slide 12 text

https://www.dip-net.co.jp/ 現在の進め方のギャップ • 依頼されたものを作るフローであると、プロダクトの成長に寄与しずらい • 本当に必要なものを考えて実装する体験がしづらい • 言われたものを高速に、その場しのぎで行う人が必要とされてしまう • 企画・開発者の距離が遠く、問題の大小を問わずプロダクトのために対話できていない 12

Slide 13

Slide 13 text

https://www.dip-net.co.jp/ 今日のアジェンダ • これまでの開発体制と、求める仕事の変化 • スクラム始めてみた！ • 今の状況とこれから 13

Slide 14

Slide 14 text

https://www.dip-net.co.jp/ トップダウンでスクラムやりませんかという声が…

Slide 15

Slide 15 text

https://www.dip-net.co.jp/ だが、現実は簡単ではなく

Slide 16

Slide 16 text

https://www.dip-net.co.jp/ どういう形で始めた？ • 人：PO1名、スクラムマスター1名、開発者3名 • スクラムイベント：2週間1スプリントで、デイリースクラム30分、レビュー、レトロスペクティブ、プランニングは1時間ずつ • ※プロダクトではなくプロジェクトへの適用 16

Slide 17

Slide 17 text

https://www.dip-net.co.jp/ スクラムの導入… • アジャイルソフトウェア開発宣言とスクラムガイドを読んでいく • https://agilemanifesto.org/iso/ja/manifesto.html • https://agilemanifesto.org/iso/ja/principles.html • https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum- Guide-Japanese.pdf 17

Slide 18

Slide 18 text

https://www.dip-net.co.jp/ 曖昧すぎてわからんねーとなる

Slide 19

Slide 19 text

https://www.dip-net.co.jp/ スクラムマスターとしてスクラムについて教えなければ… • スクラムガイドで説明されているスクラムチーム、スクラムイベント、スクラムの制作物とこのチームでのマッピングを共通理解に落とした • だれがどんな役割か • このチームでのスクラムイベントはどう進めて行くか • インクリメント、バックログアイテムをどう考えるか 19

Slide 20

Slide 20 text

https://www.dip-net.co.jp/ デイリースクラムの議事録やレトロスペクティブボードを整える • テンプレにして時間短縮＆流れを明確に • レトロスペクティブはKPTを採用せず、FLAPを採用 • https://speakerdeck.com/viva_tweet_x/retrospective-catalog- 59bd3a29-314c-45dd-911b-f8e5f1308333?slide=65 20

Slide 21

Slide 21 text

https://www.dip-net.co.jp/

Slide 22

Slide 22 text

https://www.dip-net.co.jp/ 個人的なことも話しやすいようにフリースペースを用意

Slide 23

Slide 23 text

https://www.dip-net.co.jp/ 確実な改善を意識しアクション欄を追加している

Slide 24

Slide 24 text

https://www.dip-net.co.jp/ スクラムがようやく理解され始めた • あえてフレームしか書いていないスクラムガイドから、具体的に自分たちが何をするべきなのか、というのがチーム内に浸透した • ここまで2週間〜1ヶ月くらいかかった（やることやバックログの整理なども並行してやっていたため） 24

Slide 25

Slide 25 text

https://www.dip-net.co.jp/ 今日のアジェンダ • これまでの開発体制と、求める仕事の変化 • スクラム始めてみた！ • 今の状況とこれから 25

Slide 26

Slide 26 text

https://www.dip-net.co.jp/ 最近の様子 • 半年くらいチームで進めてきた • メンバーの人数的な構成に変化はないが、メンバー自体の入れ替わりは案件都合などで多少あった • 自分がいなくてもスクラムイベントが進むようになりつつある 26

Slide 27

Slide 27 text

https://www.dip-net.co.jp/ コミュニケーションパスの変化の図 27

Slide 28

Slide 28 text

https://www.dip-net.co.jp/ とてもよかったこととして • 開発者・企画部門間の関係性の変化を実感している • これまで：言われたものを作る • 今：サービスがどうあるべきか、の視点で話せる • この動きにしたほうがいいの？とかユーザーにとってわかりやすいのは？とかそういう話が生まれている • POもデイリースクラムに参加している • 寄り添っていただけており大変ありがたい 28

Slide 29

Slide 29 text

https://www.dip-net.co.jp/ よかったこととして • 開発者間もコミュニケーションが強化 • 細部の実装、テスト観点の認識を合わせられるようになった • スプリントごとに検査しながら、今後の予定を見据えて小さくふりかえりをし動き始めた • スクラムイベントが有効に働いている • みんなで相談し、考えながら計画できている 29

Slide 30

Slide 30 text

https://www.dip-net.co.jp/

Slide 31

Slide 31 text

https://www.dip-net.co.jp/ 本当にこれでいいのか？ 31

Slide 32

Slide 32 text

https://www.dip-net.co.jp/ ゾンビスクラムサバイバルガイド健全なスクラムへの道 https://www.maruzen- publishing.co.jp/item/b304740. html 先人の知恵を借りる

Slide 33

Slide 33 text

https://www.dip-net.co.jp/ ゾンビスクラムの特徴 • 第3章ゾンビスクラム入門より • 症状1：ゾンビスクラムチームはステークホルダーのニーズを知らない • 症状2：ゾンビスクラムチームは速く出荷しない • 症状3：ゾンビスクラムチームは（継続的に）改善しない • 症状4：ゾンビスクラムチームは障害を克服するための自己組織化をしない 33

Slide 34

Slide 34 text

https://www.dip-net.co.jp/ あっ… • 第3章ゾンビスクラム入門より • 症状1：ゾンビスクラムチームはステークホルダーのニーズを知らない • 症状2：ゾンビスクラムチームは速く出荷しない • 症状3：ゾンビスクラムチームは（継続的に）改善しない • 症状4：ゾンビスクラムチームは障害を克服するための自己組織化をしない 34

Slide 35

Slide 35 text

https://www.dip-net.co.jp/ 思い当たることたち • 少し中長期の機能開発をやっているとは言え… • スプリント内に決めたところまで終わっている？ • 着手してからの感覚というものもあるが… • 努力目標でとりあえず積む、スプリント内に終わらないため、持ち越しといった状況が日常 35

Slide 36

Slide 36 text

https://www.dip-net.co.jp/ 続々と思うことが… • レビューで動くものを見せれていますか？ • 見せれてない… • 他システムとの連動が多いとか、そのための影響調査が… • チケットベースで全体の進捗を見ることが多い感じに 36

Slide 37

Slide 37 text

https://www.dip-net.co.jp/ 向き直りプラン • タスク分解をタスクとして定義する • ついでの作業とせずにスプリント内で追われるタスクサイズにする • 見積り、技術的な調査などもチケット発行する • レビューで動くものを見せる • 弊社ではデザインや要求仕様でかなり固めてしまう傾向がある • それらをWeb上で動作させているだけのデモになってしまうが、動いているものを見てユーザー価値を再検討はできるはず • スクラムの原義を理解し直す 37

Slide 38

Slide 38 text

https://www.dip-net.co.jp/ これからも良くしていきたい • チームでスクラムを始めて半年くらいなので、まだまだ経験を貯めていくところ • スクラムを始めたいチームに良い知見を残し、より良い関係性で開発を高速に、ユーザー価値を提供したい 38

Slide 39

Slide 39 text

https://www.dip-net.co.jp/ まとめ • スクラムにして見たら関係者とのやりとりが大きく変わった、実装するだけでなくサービスを作るということに取り組めている • 慣れによっておかしくなっている部分もあるので、改めてアジャイル・スクラムの認識をチーム内で合わせたい • この経験を横に展開していきたい…！ 39

Slide 40

Slide 40 text

https://www.dip-net.co.jp/ • ディップ株式会社ではエンジニア積極採用チュー！ • 大きなプロダクトに挑戦して見たい方は是非一度カジュアル面談でお話しさせてください積極採用チュー！

Slide 41

Slide 41 text

https://www.dip-net.co.jp/ Appendix • 商用可・フリーイラスト素材｜ソコスト https://soco- st.com/ • Loose Drawing | 無料で商用利用可なフリーイラスト https://loosedrawing.com/ • diagrams.net https://app.diagrams.net/ • Miro https://miro.com/ 41