Slide 1

Slide 1 text

実践から学ぶスクラム 〜新チームが直面した課題〜 2024.07.20 Sat. スクラムフェス金沢2024 @金沢未来のまち創造館 川村 純志 SmartHR プロダクトエンジニア

Slide 2

Slide 2 text

川村 純志(Atsushi Kawamura) 株式会社SmartHR プラットフォーム事業部 プロダクトエンジニア X : @a2c_dev 専門領域:フロントエンド開発 (Typescript/React.js/Next.js) 居住地:石川県金沢市( 3年前に東京から移住) 出身地:奈良県

Slide 3

Slide 3 text

1. 前提 ○ SmartHR社とスクラム ○ 弊チームの紹介 2. チームにおきた問題と改善策 ○ 1~2ヶ月目:発生した問題・原因・改善策 ○ 3ヶ月目:チームの変化 3. まとめ お品書き

Slide 4

Slide 4 text

● 全体開発チーム数:約20チーム ● 開発手法:だいたいスクラム(一部はLeSSを採用) ● スクラムの実装方法や運営方法:各チームの裁量 ● スクラムマスター:チーム専任では設置しない SmartHR社のスクラムについて

Slide 5

Slide 5 text

弊チーム -プロダクト- SmartHR Plus SmartHR API SmartHR Labs

Slide 6

Slide 6 text

弊チーム -構成- 弊チーム PO 開発者 開発者 開発者 QA デザイナー UX ライター イネイブリングチーム 他チームの支援 必要に応じて参加

Slide 7

Slide 7 text

弊チーム PO 開発者 開発者 開発者 QA デザイナー UX ライター イネイブリングチーム 他チームの支援 平均社歴 2ヶ月 スクラム経験 個人差大 必要に応じて参加 弊チーム -構成-

Slide 8

Slide 8 text

1ヶ月目

Slide 9

Slide 9 text

チーム組成時 新体制 旧体制 開発者 A 兼PO 開発者 B 開発者 私 人数変化 +3名 - 2名 離脱 開発者 A 兼PO 開発者 B 開発者 私 PO C NEW 開発者 D NEW 開発者 E NEW

Slide 10

Slide 10 text

当時の状況 旧体制 新体制 スクラム なんちゃってスクラム 「ま、今までのままでいっか」 (当時の私)

Slide 11

Slide 11 text

発生した問題 ● 頻繁なデリバリー遅延 ● 合意したはずの内容に手戻り ● 各種スクラムイベント実施の目的の齟齬や認識の不一致 ● その他諸々...

Slide 12

Slide 12 text

とあるレトロスペクティブにて 転換のきっかけ ● スクラムの運用そのものに問題あるかも ● 改善の意見が全然出ない チームで真剣に話し合うきっかけに Problem

Slide 13

Slide 13 text

原因の深掘り

Slide 14

Slide 14 text

理想状態を明文化、合意する会の実施 チームで出した改善策 原因1 チームの理想状態に 合意できていない 雑談会, 総当たり1on1, 出社推奨日の設定 原因2 価値基準を体現できる 人間関係の不足

Slide 15

Slide 15 text

チームの理想状態に合意する会 「チームの理想状態を言語化し合意する会」で出した理想状態: 「自己管理型チーム」 自分たちを取り巻く事柄に対して自分たちで考え、 自分たちで意思決定していく

Slide 16

Slide 16 text

合意形成の会で工夫した点 スクラムガイドや自己管理型チームに関する社内外のドキュメントを 事前に用意し0から考え始める負担を軽減 ポイント1 事前インプット 全員が事前にインプット資料を読み、「共感したこと」「共感しなかった こと」「わからなかったこと」をアウトプット ポイント2 個人アウトプット 一人の意見に偏らないように、各メンバーの発言機会を設けながら、 理想状態についての共通理解を深め、合意形成を行う ポイント3 発言機会の均等化

Slide 17

Slide 17 text

実際の議事録 ポイント1 事前インプット ポイント2 個人アウトプット

Slide 18

Slide 18 text

理想状態に合意できたことによる変化 適切な課題設定が行えるようになった チームの意思決定が素早くになった

Slide 19

Slide 19 text

コミュニケーションの機会創出 価値基準の体現を促進するための人間関係の構築を目的に、コミュニケーションの機会を 企画・実施 ● 雑談会 ● 総当たり1on1 ● 出社推奨日(任意)の設定

Slide 20

Slide 20 text

週に1度、デイリースクラム終了後に15分程度、 業務とは関係のない話題でカジュアルな会話を行う 雑談会 各レポートラインにとらわれず、ヨコの関係やナナメの関係で 1on1 を30分実施 総当たり1on1 フルリモート勤務のため、月に一度出社推奨日(任意)を設けて、 出社するきっかけを設定 出社推奨日の設定 コミュニケーションの機会創出

Slide 21

Slide 21 text

余談:雑談のネタに困ったので個人開発

Slide 22

Slide 22 text

人間関係構築による変化 スクラムイベント内での発話や日々の開発活動の中で 「確約」「勇気」「尊敬」「公開」「集中」といった 価値基準の体現が観察できるようになった

Slide 23

Slide 23 text

2ヶ月目

Slide 24

Slide 24 text

2ヶ月目の状況 議論も活発になり、 なんとなくチームの成長や一体感を感じ始めた

Slide 25

Slide 25 text

2ヶ月目の問題 しかし・・・ 理想 フィードバックループを高速に回したい 現実 デリバリーに想定よりも時間がかかってしまう

Slide 26

Slide 26 text

リソース効率を重視するあまり、価値を届けるためのリードタイムが遅延 各々が自分のチケットのみを担当し、透明性が低く個人への依存度が高い状態 スプリントゴールの設定 ペアプロやペア作業の 積極的な活用 リソース効率偏重ではなく、まずはフロー効率を向上させる

Slide 27

Slide 27 text

当初、スプリントゴールを設定せずにスプリントを回していた。 スプリントゴールの設定 (「スプリントゴールを設定するのが良いかも知れない」という意見が出たときの Slackの反応)

Slide 28

Slide 28 text

「スプリントゴールとは?何のために設定するのか?」を チームで学習。自分たちの課題を解決しうるのか判断 ポイント1 スプリントゴールの理解 決定に時間をかけすぎないように、プロダクトやビジネスの状況を踏まえ て、POの提案を基に開発者と協力してスプリントゴールを決定 SlackのhuddleやVS Code Live Shareを用いて同期的なコミュニケーショ ンを取り、小さなズレや開発上の障害点を確認 ポイント2 スプリントゴールを 提案してもらい、叩く! ポイント3 ペア作業の積極活用 工夫した点

Slide 29

Slide 29 text

3ヶ月目

Slide 30

Slide 30 text

3ヶ月目の状況 ようやく開発が安定し、好循環が生まれるようになる。 スプリントゴールの設定 チームの集中を引き出す 顧客に価値を届ける 結果を振り返る

Slide 31

Slide 31 text

リードタイムの短縮 1成果物あたりのリードタイムが短縮 成果物のリリース数は約3倍 価値を素早く顧客に提供できるようになってきた。

Slide 32

Slide 32 text

3ヶ月振り返って感じることは?
 - 「振り返ってみて3ヶ月の間に、これだけ色々なプロセスの改善に向き合い、実行されていることにシンプルに 驚きました。混乱と秩序を繰り返して、みんなで遠くに行けている最中という気持ちがあります。」 (エンジニア A)
 メンバーにも聞いてみた 自分自身またはチームとして、大きく変化したと感じることは?
 - 「チームとして、変化していくことに恐れがなくなりました。試した結果うまくいかなかったとしても、経験から得 ることが大事という共通認識があるので、色々なことが試せるようになりました。」(エンジニア B)

Slide 33

Slide 33 text

1. 前提 ○ SmartHR社とスクラム ○ 弊チームの紹介 2. チームにおきた問題と改善策 ○ 1~2ヶ月目:発生した問題・原因・改善策 ○ 3ヶ月目:チームの変化 3. まとめ お品書き

Slide 34

Slide 34 text

当時の状況 旧体制 新体制 スクラム なんちゃってスクラム 「ま、今までのままでいっか」 (当時の私)

Slide 35

Slide 35 text

まとめ 1ヶ月目 なんちゃって スクラム 目的の設定 人間関係構築 2ヶ月目 あとちょっと スクラム スプリントゴール 設定 ペア作業の実施 3ヶ月目 スクラム チョットデキルカモ! リードタイムの短縮 リリースアイテム 増加

Slide 36

Slide 36 text

スクラムの価値観を体現できる人間関係を構築する チームの理想状態を話し合い、合意を得る。 その時のチームの状況や問題に対して「検査」と「適応」を繰り返す。 スクラムガイドを参照したり、周囲に意見を求めたり、皆で学習する。 人間関係構築 目的の設定 スクラムの実践 継続的な学習

Slide 37

Slide 37 text

スクラムを実践すると、うまくいかないこともある。 絶対の正解はなさそう。 学習しながら集合知で問題に向き合えば、 少しずつうまくいく(はず)。

Slide 38

Slide 38 text

おしまい