スクラムで作る頼もしく生き生きとしたチーム / The lively trustworthy team by scrum

Transcript

1. スクラムで作る頼もしく
   生き生きとしたチーム
   YAPC::Japan::Online 2022 DAY2
   

   View Slide

2. 自己紹介
   ● 名前
   ○ 五十嵐 雄（いがらし ゆう）id:yigarashi
   ○ https://twitter.com/yigarashi_9
   ● 所属
   ○ 株式会社はてな はてなブックマークチーム Webアプリケーションエンジニア
   ■ テックリード
   ■ デリバリーリードエンジニア
   ■ シニアエンジニア
   ● ソフトウェア、プロセス、ヒトの観点でプロダクト開発をリード
   ● Perlはほぼ毎日読み書きしています
   

   View Slide

3. 今日のトーク
   見積もりとスプリントゴールでスクラムを学び直した話
   ● スクラム高速ハイライト
   ● チームの課題と変革
   ● 急加速する改善とスクラムのパワー
   

   View Slide

4. スクラム
   高速ハイライト
   

   View Slide

5. スクラムとは
   ● スクラムガイドで定義されたアジャイル開発の代表的なフレームワーク
   ● 反復的な開発で不確実性に対処する
   ● 経験主義で経験から学び素早く変化するための3つの特徴を持つ
   ○ 「透明性」問題を常に可視化する
   ○ 「検査」　プロセスや成果物が適切か検査する
   ○ 「適応」　発見した問題に対処する
   

   View Slide

6. スクラムが目指す開発
   こんな感じですがど
   うですか？
   適応
   透明性、検査
   なるほど！
   ちょっと方向性を
   修正します
   反復的な開発
   効率の良いやり方を思い
   ついたので試そう！
   プロセスも常に進化
   

   View Slide

7. スクラムの概念 - スクラムイベント
   ● スプリント
   ○ あらゆる作業と他のイベントを含む固定の期間
   ● スプリント計画
   ○ スプリントのゴールを設定し達成するための作業を計画する
   ● デイリースクラム
   ○ 毎日スプリントのゴール達成のために検査と適応を行う
   ● スプリントレトロスペクティブ（ふりかえり）
   ○ 組織やプロセスに対する検査と適応を行う
   ● スプリントレビュー
   ○ 成果物の検査を行う
   

   View Slide

8. スクラムの概念 - 成果物
   ● プロダクトバックログ
   ○ プロダクトを改善するためにやることが優先度順に並んだリスト
   ● スプリントバックログ
   ○ スプリントゴール
   ■ 例: ユーザー機能を作る
   ○ ゴール達成に必要なプロダクトバックログアイテム
   ■ 例: 登録機能、ログイン機能、プロフィール機能
   ○ 作業計画
   ■ 例: 登録APIの実装、登録ページの実装 ……
   ● インクリメント
   

   View Slide

9. チームの課題と変革
   

   View Slide

10. チームの課題
    ● 大半を実践しているが形式的で効果が低い
    ○ デイリースクラムが大人数（ 15人ほど）でステータスミーティングになっている
    ○ ふりかえりで何を議論したら良いかわからない ……etc.
    ● 欠けているピースがあった
    ○ 見積もり
    ■ チームに日常的な見積もり経験がなかった
    ■ チームにとって全てのタスクを見積もるのは大袈裟で高い障壁があった
    ○ スプリントゴール
    ■ 見積もりをしていないので何が完了するか設定のしようがない
    

    View Slide

11. 見積もりとスプリントゴールこそが鍵だった
    ● 透明性、検査、適応がスクラムの特徴
    ● 見積もりは透明性の土台
    ○ 自分達のパフォーマンスや進捗を定量化できる
    ● スプリントゴールは検査と適応の主題
    ○ ゴールに対して自分達がどれくらい進んでいるか
    ○ ゴールを達成できているか
    ○ ゴールは適切だったか、もっと上手く達成する方法はないのか
    ● これら無くしてスクラムが形式的になるのは必然だった
    ○ どうにか理解してもらって変化しないといけない
    

    View Slide

12. スクラム実践リブート
    知識を入れ直すことで実のあるスクラムを目指す
    ● チーム全員で勉強会を開催
    ○ 毎週1時間
    ○ 集まって決めた範囲を読む
    ● 読んだ範囲とチームの差分を議論する
    ○ チームの欠けている部分を共通認識とする
    ○ 理想の姿を再確認する
    

    View Slide

13. 勉強会の成果
    ● およそ3ヶ月で教科書を完走
    ● 全てのタスクをチームで見積もるようになった
    ○ 全員でやってみようと合意することができた
    ● スプリントゴールを設定するようになった
    ○ 見積もりに基づいて完了できる量を予測できるようになった
    ○ まずはプロダクトバックログアイテムの束をゴールとした
    ● 鍵となるピースが埋まり劇的な改善が起こり始める
    

    View Slide

14. 急加速する改善と
    スクラムのパワー
    

    View Slide

15. 急加速するチームの改善
    ● 見積もりとスプリントゴールというピースが埋まった
    ○ これらがチームのスクラムの鍵だった
    ○ 透明性、検査、適応のための基礎
    ● ゴール達成のために透明化、検査、適応をすればよいとわかった
    ○ スクラムイベントを意味のあるものに作り替える方法がわかった
    ○ それを積み重ねて、頼もしく生き生きとしたチームに
    

    View Slide

16. スプリント計画
    適切なゴールを設定しゴール達成の確度を高めるための場になった
    ● ベロシティに基づいて適切なゴールを設定する
    ● 達成の確度を高めるための工夫
    ○ PBIをさらに細かい作業に分解・見積もりする
    ■ 不確実性を下げ、透明性を高める
    ■ 分担しやすくする
    ○ 取り組む順序を細かく計画する
    ■ 不確実性やブロッカーを先に排除する
    ○ 達成の自信度をポーカーする（ 0%、25%、50%、75%、100%）
    ■ 平均が75%を下回ったら不安な要因を話して排除する
    

    View Slide

17. デイリースクラム
    ゴール達成のために検査と適応を行う場になった
    ● ゴール達成に責任を持つ開発メンバーのみで実施するようにした
    ○ ゴールの具体的な障害物を排除しやすくなった
    ● 徹底した透明化を実施
    ○ バーンダウンを引いてゴールに近づいているか可視化
    ○ カンバンで以下をわかるようにする
    ■ PBIの達成状況
    ■ タスクの未着手、着手、待ち、完了
    ○ 毎日異常を発見して適応できるようになった
    ■ 例: 「チャートは下がってないけど、待ちがやたら多くないですか？」
    

    View Slide

18. スプリントレトロスペクティブ（ふりかえり）
    ゴール達成の過程を検査し改善する場になった
    ● ゴール達成に責任を持つ開発メンバーのみで実施するようにした
    ○ 話題のズレなど気にせず深い分析ができるようになった
    ○ スプリントゴールを中心に密度の濃い会話ができるようになった
    ■ 「ゴール達成に役立ったことは？」
    ■ 「ゴール達成の障害になったことは？」
    ● Findy Teamsを用いた活動の透明化でふりかえりを強化
    ○ GitHub上のアクティビティの量や各種リードタイム
    ○ レビューの件数や偏り
    

    View Slide

19. 頼もしいチームへと進化
    ● ゴールの達成に全力を尽くし、実際に確度高く達成する
    ○ ベロシティやバーンダウンチャートといった透明化
    ○ 綿密なスプリント計画
    ○ デイリースクラムやふりかえりによる不断の検査と適応
    ● 先の計画についても指針を提供できる
    ○ 「この施策は全体で80ポイント、単純計算では 4スプリントほどで終わります」
    ■ 確度の高いスプリントを繰り返すことで安定した中長期計画を提供する
    ○ 「ここ3ヶ月、技術基盤に10％程度しか時間を使えていません」
    ■ 透明化のバリエーション
    

    View Slide

20. 生き生きとしたチームへと進化
    ● 短期のゴールがチームをモチベートする
    ○ 毎日バーンダウンチャートを見て一喜一憂
    ○ ゴール達成でお互いを讃えあう
    ○ 未達でも検査と適応で再チャレンジする
    ● 共通のゴールがチームワークを育てる
    ○ 自分のタスクが終わっても、チームでゴールを達成しなければ意味がない
    ■ レビュー依頼がきたら積極的に見る
    ■ 困っている人がいたらペアプロしにいく
    ○ 議論が活発になり信頼関係が深まる
    

    View Slide

21. まとめ
    ● スクラムの大きな特徴として透明性、検査、適応がある
    ● チームの課題
    ○ 検査と適応が機能せず、形式的な実践に止まっていた
    ○ ハードルがあった見積もりとスプリントゴールこそが欠けていた鍵だった
    ● スクラム勉強会で変化のハードルを乗り越えた
    ● ゴール達成のために透明化、検査、適応をすればよいとわかった
    ○ スクラムイベントを意味のあるものに作り変える方法がわかった
    ○ それを積み重ねて、頼もしく生き生きとしたチームに
    

    View Slide