Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
チームが自己組織化してから敢えて専任スクラムマスターを置いてみたらめちゃめちゃワークした話 ...
Search
HirokiChida
August 26, 2024
Technology
2
2.4k
チームが自己組織化してから敢えて専任スクラムマスターを置いてみたらめちゃめちゃワークした話 / How bringing in a Scrum Master to an already self-organized team totally worked out
HirokiChida
August 26, 2024
Tweet
Share
More Decks by HirokiChida
See All by HirokiChida
Loglassのバックエンドアーキテクチャについて
hc0208
0
110
Other Decks in Technology
See All in Technology
エンジニアが一生困らない ドキュメント作成の基本
naohiro_nakata
2
130
Microsoft Intune アプリのトラブルシューティング
sophiakunii
1
390
透過型SMTPプロキシによる送信メールの可観測性向上: Update Edition / Improved observability of outgoing emails with transparent smtp proxy: Update edition
linyows
2
180
신뢰할 수 있는 AI 검색 엔진을 만들기 위한 Liner의 여정
huffon
0
540
国土交通省 データコンペ参加者向け勉強会
takehikohashimoto
0
380
GraphRAGを用いたLLMによるパーソナライズド推薦の生成
naveed92
0
190
Railsで4GBのデカ動画ファイルのアップロードと配信、どう実現する?
asflash8
1
190
10分でわかるfreee エンジニア向け会社説明資料
freee
18
520k
ZOZOTOWNでの推薦システム活用事例の紹介
f6wbl6
1
480
TinyGoを使ったVSCode拡張機能実装
askua
2
200
「 SharePoint 難しい」ってよく聞くけど、そんなに言うなら8歳の息子に試してもらった
taichinakamura
2
790
いろんなものと両立する Kaggleの向き合い方
go5paopao
2
960
Featured
See All Featured
Keith and Marios Guide to Fast Websites
keithpitt
409
22k
Optimising Largest Contentful Paint
csswizardry
33
2.9k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.4k
Fireside Chat
paigeccino
33
3k
Git: the NoSQL Database
bkeepers
PRO
427
64k
10 Git Anti Patterns You Should be Aware of
lemiorhan
654
59k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
31
2.7k
Typedesign – Prime Four
hannesfritz
40
2.4k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
27
4.2k
Side Projects
sachag
452
42k
A Tale of Four Properties
chriscoyier
156
23k
Designing for humans not robots
tammielis
249
25k
Transcript
1 ©2024 Loglass Inc. チームが自己組織化してから敢えて 専任スクラムマスターを置いてみたら めちゃめちゃワークした話 2024/08/24 千田浩輝 佐藤悠 今井健男(ぼのたけ)
2 ©2024 Loglass Inc. Profile 千田浩輝 (@hc0208) 株式会社ログラス エンジニアリングマネージャー 大学時代にベンチャー企業の立ち上げから参画し、テックリードと
してSaaSの開発に従事。 その後、大手SIerにジョインし金融システムの開発からマネジメン トまで幅広く携わり、2022年6月からエンジニアとして株式会社 ログラスにジョイン。 2023年10月〜エンジニアリングマネージャー。
3 ©2024 Loglass Inc. Profile 佐藤悠 (@yusato___) 株式会社ログラス プロダクトマネージャー 精密機器メーカー子会社や料理動画ベンチャーにてエンジニアとして
開発に従事。料理動画アプリ事業では開発マネージャーを務める。 株式会社ログラスではエンジニアとして経営管理システムの開発に従 事した後にプロダクトマネージャーへ転向。
今井健男(ぼのたけ) @bonotake フリーランスアジャイルコーチ • スクラム / アジャイル導入支援、プロダクト マネジメント支援、開発組織づくり支援 • 現在は主にログラスで、スクラムマスター
からのアジャイルスケーリング支援など • チーム焼肉 ソフトウェア工学研究者 • 以前、某電機メーカーの研究所にて企業研究 • 現在、国立情報学研究所にてスクラム / アジャイルの研究 Profile
5 5 ©2024 Loglass Inc. 企業価値を向上する 経営管理クラウド
6 ©2024 Loglass Inc. ログラス公式Xがんばっています!フォローしてください! https://x.com/LoglassPrdTeam
7 ©2024 Loglass Inc. わざわざ専任SMを置こうとした経緯
8 ©2024 Loglass Inc. プラトー わざわざ専任SMを置こうとした経緯 専任SMを採用したいと思った理由はいくつかあったが、 その理由の一つとして、チームがプラトー(停滞期)に入っ ており、そこから脱却したいという想いがあった チームメンバーとしては当時、
「課題らしい課題は全部片付けた気がする。開発もうまく いっている感覚はあるしこのままこの状態をキープすれ ばいいのかな?これ以上の成長ってあるのだろうか。」 という感覚だった 成長曲線 プラトー
9 ©2024 Loglass Inc. プラトーに入る前 わざわざ専任SMを置こうとした経緯 レトロでは、「チームがどれだけプロダクトに向き合えている のか」という重めのテーマを扱ったり、「スクラムをやめてみて どうだったか」(※中盤に紹介)というような振り返りを行うな どすることで、チームとして成長している感覚があった
自分たちのやり方でプロダクトにとっても価値のある重要な 機能の開発を提供できたという成功体験もあった (実際にどういうことをやっていたかは資料中盤で紹介)
10 ©2024 Loglass Inc. プラトーに気づいた時 わざわざ専任SMを置こうとした経緯 • 事前に話したいテーマをあげてそれについて深掘りするという形でレトロを行っていた が、これまで活発にあがっていたテーマが徐々にあがらなくなった •
当時のEMからは「プラトーに入っているのでは」という言葉があった
11 ©2024 Loglass Inc. スクラムマスターの採用 わざわざ専任SMを置こうとした経緯 • プラトーを脱却したいという想いから、2023年11月にスクラムマスターとして 今井さんが参画することに •
大なり小なり改善を行ったが、今回は特に「スプリントゴールを復活させた話」に 特化して話をしていきます 2023/04 2023/11 2023/12 プラトーに 気づく SM ジョイン スプリント ゴール復活
12 ©2024 Loglass Inc. 参考資料 わざわざ専任SMを置こうとした経緯 参考資料: スクラムマスターを採用しようと思った他の 理由は記事にもまとめてあるので、もし興味 がある方がいたらご覧ください
https://zenn.dev/loglass/articles/95f367d2a6ced7
13 ©2024 Loglass Inc. スプリントゴールを復活させた話 〜 チーム視点 〜
14 ©2024 Loglass Inc. チームの変遷 スプリントゴールを復活させた話 2023/04 2023/11 2023/12 プラトーに
気づく SM ジョイン スプリント ゴール復活 2023/01 2022/12 通常 スクラム期 スクラム やめた期 スプリントゴールを撤廃 スプリントゴールの撤廃から復活までの経緯を 時系列に沿ってチーム視点で紹介させていただきます
15 ©2024 Loglass Inc. 通常スクラム期
16 ©2024 Loglass Inc. 通常スクラム期(〜2022/12末) スクラムチームの概要 • チーム人数 ◦ PO(0.5人),
開発者(3人) • スプリント期間:1週間 • スプリントゴールはタスクを全てやり切ること ◦ 明示的にスプリントゴールをおくことはしていない ◦ 毎スプリントプランニングしたものを消化することはできていた
17 ©2024 Loglass Inc. スクラムやめた期
18 ©2024 Loglass Inc. スクラムやめた期(2023/1) チーム環境の変化 • 全く知見のない開発を担当 ◦ 社内に全く知見がなく、ネット上にもほとんど情報がない領域の開発をし始めた
◦ フィジビリティスタディとしてプロトタイプを作成して、うまく行かなければ実現方法を調査 する日々 ➡ 課題の顕在化 ◦ 検証の結果で後続の予定作業が全く変わってしまうため1週間のプランニングができない ◦ ゴールが達成できない、スプリント中にタスクがなくなる
19 ©2024 Loglass Inc. スクラムやめた期(2023/1) チームに訪れた転機 • RSGT2023への参加 ◦ アジャイルコーチに相談できるコーチーズクリニックで課題について相談
不確実性が高すぎる開発をしていて1週間スプリントがう まく回りません。どうするのがいいでしょうか? 私
20 ©2024 Loglass Inc. スクラムやめた期(2023/1) チームに訪れた転機 • RSGT2023への参加 ◦ アジャイルコーチに相談できるコーチーズクリニックで課題について相談
スクラムやめたらよろしいやん 私 アジャイル コーチ 不確実性が高すぎる開発をしていて1週間スプリントがう まく回りません。どうするのがいいでしょうか?
21 ©2024 Loglass Inc. スクラムやめた期(2023/1) スクラムをやめる決断 • RSGT2023で得た気づき ◦ スクラムは「やめてもいい」
◦ 安定的に価値を届けるのと不確実なものを探索する開発はやり方が違う ➡ チームでカッチリしたスクラムをやめる意思決定をした
22 ©2024 Loglass Inc. • やめたこと ◦ 1週間スプリントの枠組みを撤廃した ◦ それに伴ってスプリントゴールの設定とプランニングをやめた
• 取り入れたこと ◦ カンバン方式による開発を採用 ◦ デイリーで1日の行動計画をチームで行い何をするのか決める ▪ 何か発見があったら/困ったら随時相談する スクラムやめた期(2023/1) 新しいやり方に変えてみた
23 ©2024 Loglass Inc. • 良かったこと ◦ どうせ変わってしまうプランニング・見積もりにかける時間がなくなった ◦ 新たな発見があったら次のスプリントを待たずに、すぐにアクションを変えられるように
なった • 良くなかったこと ◦ スプリントのリズムがなくなってしまい常に走り続けている感覚に陥った ◦ スプリントゴールの達成感がなくなってしまった • 所感 ◦ 当時の状況にあっており、チームの満足度は高かった スクラムやめた期(2023/1) 変えてみた結果
24 ©2024 Loglass Inc. プラトーに気づく
25 ©2024 Loglass Inc. スクラムやめた期のタスクの進め方紹介 プラトーに気づく(2023/4) OKR作成 (3ヶ月ごと) デイリースクラム レトロスペクティブ
スプリントレビュー • 3ヶ月ごとの目標がOKRとして決まる • OKRを達成するために必要なタスクをバックログ (わからないことリスト)として積んでいく • デイリーではバックログで取り組んでいる開発アイ テムの進捗を確認する • 週に1度OKRのトラッキングを行う OKRトラッキング
26 ©2024 Loglass Inc. スクラムマスターを採用するまでに至った経緯を改めて プラトーに気づく(2023/4) スクラムをやめた状態での開発はチームの状況にあってい るやり方に感じていたが、進めていく中で徐々にチームが プラトー(停滞期)に入っている感覚が生まれてきた。 チームメンバーとしては当時、
「課題らしい課題は全部片付けた気がする。開発もうまく いっている感覚はあるしこのままこの状態をキープすれば いいのかな?これ以上の成長ってあるのだろうか。」 という感覚だった そこでSMを採用してみるという決断に至った 成長曲線 プラトー
27 ©2024 Loglass Inc. スクラムマスタージョイン
28 ©2024 Loglass Inc. ゴールとタスクが遠い スクラムマスタージョイン(2023/11) • 今井さんがチームに参画した後のレトロで「ゴールとタス クが遠くないか?」という課題を提起してくれた •
OKRが3ヶ月ごとに決まり、バックログに開発アイテム を必要に応じて積んでいく、デイリーではバックログに積 まれたアイテムの進捗がどうか確認をする流れだった • OKRトラッキングの場でOKRを意識するタイミングは あったが、個々のタスクと紐づいてはいない状態だった
29 ©2024 Loglass Inc. チームとして抱えていた課題 スクラムマスタージョイン(2023/11) • 今井さんからの提起以外に、自分たちとしても課題があった • 具体的には以下のような課題
◦ 「次タスク選択時の優先度が認識できていない」 ◦ 「タスク着手時に事前にどこまで認識を揃えるべきなのか」 ◦ 「何をすべきか、何に向かうべきか合意できていない」
30 ©2024 Loglass Inc. スプリントゴール復活 スクラムマスタージョイン(2023/11) • これらの課題を解決するには、OKRとバックログの繋 がりが確認できるなんらかの仕組みが必要というのが チームで話した結論だった
• 「デイリーでOKRを意識できると良いのでは」という意 見も出たが、タスクが完了することで上位のゴールに どう影響があるかわかりにくいという課題があった • その課題を解消しつつOKRとバックログの繋がりを確 認できるようにするために、スプリントゴールを設定す るのがいいのではとなった
31 ©2024 Loglass Inc. タスクの進め方紹介 スクラムマスタージョイン(2023/11) OKR作成 (3ヶ月ごと) OKRトラッキング デイリースクラム
レトロスペクティブ スプリントゴール作成 スプリントレビュー • 週に1度OKRトラッキング&スプリントゴールの作 成を行う時間を設けることにした • OKRトラッキング&スプリントゴール作成ではこの ままでOKRが達成されそうかというのを考慮し、ス プリントゴールの作成を行うようにした • 結果的にゴールとタスクがより近くに感じられるよ うになった
32 ©2024 Loglass Inc. レトロであがったよかった点の紹介 スクラムマスタージョイン(2023/11)
33 ©2024 Loglass Inc. スプリントゴールを復活させた話 〜 スクラムマスター視点 〜
34 ©2024 Loglass Inc. チームに参画して感じたことと 自分の立ち位置 スクラムマスター視点①
35 ©2024 Loglass Inc. 恐ろしいほどいいチームだった その1 初日、スクラムイベントを見学して
36 ©2024 Loglass Inc. 恐ろしいほどいいチームだった その2 PBIに締切日を記入した方がよくないですか? 以前は記入してたんですけど、そうすると不必要なものまで リリースしてしまうことに気づいたので、記入をやめました
37 37 ©2024 Loglass Inc. とはいえ 課題がないわけではないな、とも 感じた • 自己解決能力はとても高い割に、
改善の施策があまり精度良くない • おそらく、行動力と比較して知識 が相対的に足りていない そこで、自分の役割を2つに絞った (9 Coaching Roles から) Reflective Observer … 観察して 得た事実をただ伝える Teacher … 今ある課題に対し、 もしかしたら使えるかもしれない一 般的知識を教える https://www.growingagile.co/the-9-coaching-roles/ より
38 ©2024 Loglass Inc. チームが「スクラムをやめた」ことと 観察して得た課題感 スクラムマスター視点②
39 ©2024 Loglass Inc. 「スクラムをやめたこと」に対して • 大まかなところは、チーム参画前にあらかじめ聞いていたし、そ れ自体がダメだとは思わなかった • ただ、実際にチームを観察してみると課題があると感じた
40 40 ©2024 Loglass Inc. なぜチームは「スクラムをやめた」のか (1/4) クネビンフレームワークを使って 考察してみる ここでのポイントは
煩雑 … 過去の経験から今後の計 画が立てられる 複雑 … 過去の経験から、今後の計 画や見通しが立たない 単純 煩雑 複雑 混沌 無秩序
41 41 ©2024 Loglass Inc. ウォーターフォール … 「煩雑」領域で使える開発モデル 事前に計画が立てられることが前提 スクラム
… 「複雑」と「煩雑」の境界 とよく言われる • 中長期では「複雑」 • スプリントに区切ることで「煩雑」な 問題として扱えることが多い 単純 煩雑 複雑 混沌 無秩序 ウォーター フォール スクラム なぜチームは「スクラムをやめた」のか (2/4)
42 42 ©2024 Loglass Inc. つまり、世間でよく行われるスクラムは 数か月以上のスパンでは「複雑」だが 1スプリント内は「煩雑」 とみなしていることが多い •
見積もりができる (ストーリーポイント、ベロシティ) • プランニングで積んだSBIを 消化すればスプリントが終わる 単純 煩雑 複雑 混沌 無秩序 数ヶ月以上 スプリント なぜチームは「スクラムをやめた」のか (3/4)
43 43 ©2024 Loglass Inc. ところが、1スプリントに区切っても 「複雑」な領域から落ちないケースが 世の中には存在する - 完全な新規ドメインが対象で、チームに
経験者が一人もいないような状態での開発 - ユーザーにとって真の価値は何か、と いった価値提案を1から探索するレベルの ディスカバリー - 実現方法が見えていないような機能の R&D - etc. 単純 煩雑 複雑 混沌 無秩序 数ヶ月以上 スプリント スプリント なぜチームは「スクラムをやめた」のか (4/4)
44 44 ©2024 Loglass Inc. これこそ 「チームがスクラムをやめた」理由 2022年頃は「煩雑」な領域でスプリ ントを扱うスクラムを組んでいたが、 2023年1月頃から、「複雑」な問題を
スプリントでこなさないといけなくな り、詰んだ それゆえ、スプリントのタイムボックス を破壊しカンバンに寄せた (=「スクラムをやめた」) 単純 煩雑 複雑 混沌 無秩序 数ヶ月以上 2022年頃の スプリント 2023年1月以降の スプリント
45 ©2024 Loglass Inc. ただ、こうした変更には メリットだけでなくデメリットも必ず伴う
46 ©2024 Loglass Inc. チームに入って感じた課題 課題1: プロダクトゴール(OKR)と、日々の開発との接続が切れてし まっている • 開発者は目の前のタスクのことだけを気にしていて、チームとしてどこに向かおうとし
ているのか意識するタイミングが普段の開発の中にない ◦ OKRトラッキングの場で「このスプリントで開発した内容はOKRのどこに紐づく んですか?」という質問が飛んでいた 課題2: 全体で何をやっているのか見通しが悪く、チームとしてのガバ ナンスが効きづらくなっている • 開発者ごとにやっていることがバラバラ、隣の開発者が何をやってるのかもあまり共 有されない(DSで共有されてもわからない) • カンバンに寄せたはずが、WIP制限といったプラクティスも実施されていなかった
47 ©2024 Loglass Inc. それで
48 ©2024 Loglass Inc. その結果
49 ©2024 Loglass Inc. びっくりするほどチームが変わった 観察していると、明らかに • OKRと日々の開発が連動するようになった • チーム全員で同じ方向を見ながら開発するようになった
• OKR達成をモチベーションに、リードタイム短縮への強い意識が生まれた (フロー効率重視な開発スタイルに変わった) 以前との最も大きな違いは、OKR達成のマイルストーンとしてスプリントゴールを 再定義したこと • それを、チームがすぐに理解した • 一度スプリントゴールという概念を捨てたからこそ、「なぜ今スプリントゴールを置くのか」の意義が チーム内で明確に意識できた
50 50 ©2024 Loglass Inc. すごかった話 復活1回目のゴールは、OKRを意識して かなりストレッチなものになってしまった すると、チームがスプリントバックログ作成 中に突然線表を引き始めた
目的は、彼らなりのフロー効率の追求 • ゴール達成のためのタスクをどれだ け並列にこなせるか の可視化 • フルタイムじゃないメンバーといつ・ 何を協働するか、それまで何をする か の調整 ⇒ 当初は2スプリント分と見積もっていた 作業を1スプリントで実現してしまった
51 ©2024 Loglass Inc. まとめ
52 ©2024 Loglass Inc. まとめ 自己組織化したチームに敢えて専任SMを置いてみた話 チーム視点で感じたメリット: ◦ チームだけでは気づけなかったプラトー脱却のきっかけを与えられた ◦
チームがSMと共同で取り組むことで成果を出すまでに遠回りせずに進む ことができた SM視点で感じたメリット: ◦ 自己組織化したチームの方が、嚙み合ったときの価値はむしろ大きい ▪ 「なぜそれをやるのか」について、より深い理解に到達できる ▪ 理解した後の適応が速く、効果の大きい改善を素早く実行できる 特に「成長が落ち着いてきているチーム」は専任SMを置いてみると、新たな成長の 機会に気づけるかもしれない
53