実践から学ぶスクラム 〜新チームが直面した課題〜 （Scrum Fest Kanazawa 2024）

Transcript

1. 実践から学ぶスクラム 〜新チームが直面した課題〜 2024.07.20 Sat. スクラムフェス金沢2024 @金沢未来のまち創造館 川村 純志 SmartHR プロダクトエンジニア
2. 川村 純志（Atsushi Kawamura） 株式会社SmartHR プラットフォーム事業部 プロダクトエンジニア X : @a2c_dev 専門領域：フロントエンド開発 (Typescript/React.js/Next.js) 居住地：石川県金沢市（ 3年前に東京から移住） 出身地：奈良県
3. 1. 前提 ◦ SmartHR社とスクラム ◦ 弊チームの紹介 2. チームにおきた問題と改善策 ◦ 1~2ヶ月目：発生した問題・原因・改善策 ◦ 3ヶ月目：チームの変化 3. まとめ お品書き
4. • 全体開発チーム数：約20チーム • 開発手法：だいたいスクラム(一部はLeSSを採用) • スクラムの実装方法や運営方法：各チームの裁量 • スクラムマスター：チーム専任では設置しない SmartHR社のスクラムについて
5. 弊チーム -プロダクト- SmartHR Plus SmartHR API SmartHR Labs
6. 弊チーム -構成- 弊チーム PO 開発者 開発者 開発者 QA デザイナー UX ライター イネイブリングチーム 他チームの支援 必要に応じて参加
7. 弊チーム PO 開発者 開発者 開発者 QA デザイナー UX ライター イネイブリングチーム 他チームの支援 平均社歴 ２ヶ月 スクラム経験 個人差大 必要に応じて参加 弊チーム -構成-
8. 1ヶ月目
9. チーム組成時 新体制 旧体制 開発者 A 兼PO 開発者 B 開発者 私 人数変化 +3名 - 2名 離脱 開発者 A 兼PO 開発者 B 開発者 私 PO C NEW 開発者 D NEW 開発者 E NEW
10. 当時の状況 旧体制 新体制 スクラム なんちゃってスクラム 「ま、今までのままでいっか」 (当時の私)
11. 発生した問題 • 頻繁なデリバリー遅延 • 合意したはずの内容に手戻り • 各種スクラムイベント実施の目的の齟齬や認識の不一致 • その他諸々...
12. とあるレトロスペクティブにて 転換のきっかけ • スクラムの運用そのものに問題あるかも • 改善の意見が全然出ない チームで真剣に話し合うきっかけに Problem
13. 原因の深掘り
14. 理想状態を明文化、合意する会の実施 チームで出した改善策 原因1 チームの理想状態に 合意できていない 雑談会, 総当たり1on1, 出社推奨日の設定 原因2 価値基準を体現できる 人間関係の不足
15. チームの理想状態に合意する会 「チームの理想状態を言語化し合意する会」で出した理想状態： 「自己管理型チーム」 自分たちを取り巻く事柄に対して自分たちで考え、 自分たちで意思決定していく
16. 合意形成の会で工夫した点 スクラムガイドや自己管理型チームに関する社内外のドキュメントを 事前に用意し0から考え始める負担を軽減 ポイント1 事前インプット 全員が事前にインプット資料を読み、「共感したこと」「共感しなかった こと」「わからなかったこと」をアウトプット ポイント2 個人アウトプット 一人の意見に偏らないように、各メンバーの発言機会を設けながら、 理想状態についての共通理解を深め、合意形成を行う ポイント3 発言機会の均等化
17. 実際の議事録 ポイント1 事前インプット ポイント2 個人アウトプット
18. 理想状態に合意できたことによる変化 適切な課題設定が行えるようになった チームの意思決定が素早くになった
19. コミュニケーションの機会創出 価値基準の体現を促進するための人間関係の構築を目的に、コミュニケーションの機会を 企画・実施 • 雑談会 • 総当たり1on1 • 出社推奨日（任意）の設定
20. 週に1度、デイリースクラム終了後に15分程度、 業務とは関係のない話題でカジュアルな会話を行う 雑談会 各レポートラインにとらわれず、ヨコの関係やナナメの関係で 1on1 を30分実施 総当たり1on1 フルリモート勤務のため、月に一度出社推奨日（任意）を設けて、 出社するきっかけを設定 出社推奨日の設定 コミュニケーションの機会創出
21. 余談：雑談のネタに困ったので個人開発
22. 人間関係構築による変化 スクラムイベント内での発話や日々の開発活動の中で 「確約」「勇気」「尊敬」「公開」「集中」といった 価値基準の体現が観察できるようになった
23. 2ヶ月目
24. ２ヶ月目の状況 議論も活発になり、 なんとなくチームの成長や一体感を感じ始めた
25. ２ヶ月目の問題 しかし・・・ 理想 フィードバックループを高速に回したい 現実 デリバリーに想定よりも時間がかかってしまう
26. リソース効率を重視するあまり、価値を届けるためのリードタイムが遅延 各々が自分のチケットのみを担当し、透明性が低く個人への依存度が高い状態 スプリントゴールの設定 ペアプロやペア作業の 積極的な活用 リソース効率偏重ではなく、まずはフロー効率を向上させる
27. 当初、スプリントゴールを設定せずにスプリントを回していた。 スプリントゴールの設定 (「スプリントゴールを設定するのが良いかも知れない」という意見が出たときの Slackの反応)
28. 「スプリントゴールとは？何のために設定するのか？」を チームで学習。自分たちの課題を解決しうるのか判断 ポイント1 スプリントゴールの理解 決定に時間をかけすぎないように、プロダクトやビジネスの状況を踏まえ て、POの提案を基に開発者と協力してスプリントゴールを決定 SlackのhuddleやVS Code Live Shareを用いて同期的なコミュニケーショ ンを取り、小さなズレや開発上の障害点を確認 ポイント2 スプリントゴールを 提案してもらい、叩く！ ポイント3 ペア作業の積極活用 工夫した点
29. 3ヶ月目
30. 3ヶ月目の状況 ようやく開発が安定し、好循環が生まれるようになる。 スプリントゴールの設定 チームの集中を引き出す 顧客に価値を届ける 結果を振り返る
31. リードタイムの短縮 1成果物あたりのリードタイムが短縮 成果物のリリース数は約3倍 価値を素早く顧客に提供できるようになってきた。
32. 3ヶ月振り返って感じることは？
 - 「振り返ってみて3ヶ月の間に、これだけ色々なプロセスの改善に向き合い、実行されていることにシンプルに 驚きました。混乱と秩序を繰り返して、みんなで遠くに行けている最中という気持ちがあります。」 （エンジニア A）
 メンバーにも聞いてみた 自分自身またはチームとして、大きく変化したと感じることは？
 - 「チームとして、変化していくことに恐れがなくなりました。試した結果うまくいかなかったとしても、経験から得 ることが大事という共通認識があるので、色々なことが試せるようになりました。」（エンジニア B）
33. 1. 前提 ◦ SmartHR社とスクラム ◦ 弊チームの紹介 2. チームにおきた問題と改善策 ◦ 1~2ヶ月目：発生した問題・原因・改善策 ◦ 3ヶ月目：チームの変化 3. まとめ お品書き
34. 当時の状況 旧体制 新体制 スクラム なんちゃってスクラム 「ま、今までのままでいっか」 (当時の私)
35. まとめ 1ヶ月目 なんちゃって スクラム 目的の設定 人間関係構築 2ヶ月目 あとちょっと スクラム スプリントゴール 設定 ペア作業の実施 3ヶ月目 スクラム ﾁｮｯﾄﾃﾞｷﾙｶﾓ! リードタイムの短縮 リリースアイテム 増加
36. スクラムの価値観を体現できる人間関係を構築する チームの理想状態を話し合い、合意を得る。 その時のチームの状況や問題に対して「検査」と「適応」を繰り返す。 スクラムガイドを参照したり、周囲に意見を求めたり、皆で学習する。 人間関係構築 目的の設定 スクラムの実践 継続的な学習
37. スクラムを実践すると、うまくいかないこともある。 絶対の正解はなさそう。 学習しながら集合知で問題に向き合えば、 少しずつうまくいく(はず)。
38. おしまい