はじめに

こんにちは！QAエンジニアの中嶋です。

2023年もあと少し。残るイベントはクリスマスと年越しくらいでしょうか。

1年を通していろんなことがありましたが、私の一番大きなイベントは転職です。（2023年3月にSHIFT入社）

前職は美容室の受付をしておりIT業界とは無縁も無縁だったため、入社してから勉強の日々が続いておりますが、

その中でも私の中で大きな要素がアジャイル開発とスクラムです。

アジャイルやスクラムの知識を得るにあたって、研修を受けたり、本を読んだり、インターネットの海を泳いだり……

いろいろありますが、今回は社内で行われた勉強会に参加して学んだスクラムイベントのカイゼンについて書いていこうと思います！

参加した勉強会『シン・スクラムマスター虎の穴-3rd season-』について

【概要】

• スクラムマスターとしての立ち振る舞いをケーススタディなどのワークを通して学ぶ勉強会

• 毎週火曜日、全10回

【こんな人におすすめ】

• 知識のインプットはしているけど、アウトプットの機会がない

• アジャイル・スクラムの知見を広げていきたい

【実際に取り組んだ内容】

• 自己紹介&勉強会での目標設定

• プロダクトバックログを作成してみる

• バックログのカイゼン

• 各スプリントイベントのカイゼンに向けたなぜなぜ分析（⇐今回はここで学んだ内容をまとめています）

• 業務アジャイルについての講義受講

• miroの活用についての講義受講

• 全10回を通してのふりかえり

スクラムイベントとは

かの有名なスクラムガイド
（ https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf ）にはこのように記載されています。

勉強会のワークは「検査と適応」「規定通りにイベントを運用」を意識しながら進めていきました。

ワークに登場したスクラムイベント↓↓

• スプリントプランニング

• デイリースクラム

• スプリントレビュー

• スプリントレトロスペクティブ

上記の各スプリントイベントについて【問題】が提示され、それについてチームで改善策を考えるというワークに取り組みました！

①スプリントプランニングのカイゼン

【問題】プランニング中の見積もりやタスク分解など主に1人が進め他メンバーは同意しているだけになっている

この問題に対してチームで話し合い、分析をすすめながら、

• 各メンバーに当事者意識が無い

• リーダー層の意思決定権が強い

などの意見が出ていましたが、属人的な方向に進んでいないか？ということで、改めてスプリングプランニングの目的を確認。

私たちのチームでは、「話し合う準備ができているか」という部分に着目し、

スプリントプランニングに対する話し合う準備＝バックログリファインメントすなわち、『リファインメントが十分に行われていない』という原因を見つけることができました。

ここから改善策を考えるのですが、残念ながら時間切れ…なかなか難しい……！！

②デイリースクラムのカイゼン

【問題】デイリーで開発メンバーが今日やったこと、困りごとを共有しているが、スプリントゴールが達成できない状況が起きている

①と同じく属人的な方向に進まないように意識して取り組みますが…

す、進まない…！！

一旦、目的を確認します。

『スプリントゴールに対する進捗を検査』の部分が重要そうだ！ということで、

スプリントゴールが達成できない
↓
スプリントゴールの進捗が見えていない
↓
チーム内で進捗の共有ができていない
↓
『デイリースクラムに進捗状況の確認が組み込まれていない』

と、またしてもここで改善策を考える前に時間切れ。①よりは進んだけどやっぱり難しい～～～！

③スプリントレビューのカイゼン

【問題】スプリントレビューがPO（プロダクトオーナー）に対しての受け入れレビューになってしまっている

問題の分析の仕方も少し慣れてきたので早速進めていきます。

POに対する受け入れレビューになってしまっている
↓
スプリント中に、スプリントバックログのPOレビューをできていない
↓
タスクの分解ができていない
↓
どういうプロセスを踏めば"完了"になるのか決まっていない

ここで、「う～ん」と手が止まってしまいました。

次の段階が「話せていない」になると対象が"スクラムイベント"ではなく"人"になってしまうなぁ…。

さぁ、困ったときの目的確認です。

スプリントレビューで"次"について話し合うには明確な「スプリントの成果」「作業の結果」「達成」を提示することが必要なのではないか、すなわち、

『スプリントバックログを完了にする（＝スプリントレビューに出せる）ルールやプロセスを決める』が最終的な改善策となりました。

③にしてやっと改善策にたどり着くことに成功！達成感！

また、「完了の定義(※) を決めること」と「完了までのプロセス（道のり） を決めること」は別物である！という大きな学びも得られました。

(※)完了の定義…何をもって成果物としてOK！完了した！とするかスクラムチームで決めたルール

④スプリントレトロスペクティブのカイゼン

【問題】レトロスペクティブで発見したTryが実行できていない

いつも途中で目的の確認をしていましたが、毎度のことなので事前に確認しました。

目的をチームで把握した状態で改善策を考えていきます。

Tryが実行できていない
↓
Tryの優先順位が低くなっている
↓
カイゼンバックログには詰んでいるがスプリントバックログに積んでいない
↓
カイゼンバックログの運用が決まっていない
↓
カイゼンしたときの結果に対する指標が無い
↓
『メトリクスをとりカイゼン前後の比較に活用する』

改善策の考え方に慣れてきたことと、目的を最初に確認したことでスムーズにたどり着くことができました！

また、運営の方から「メトリクスはチームメンバーに負荷をかけないことが大切だから管理ツールを使うのがおすすめだよ！」と実務に役立つアドバイスもいただきました◎

まとめ

～スクラムイベントのカイゼンに必要な考え方～

• 根本的な原因を見つける

• "人"ではなく"プロセス"に目をつける

• ○○していないではなく、○○できていないを考える

• スクラムイベントの原理原則に立ち返る

この考え方を通して改善策を出し、実行し、ふりかえる、これらを繰り返すことでスクラムを利用することの効果を高めていけるのだと感じました。

今回のワーク①～④で挙げられた問題と改善策はあくまで一例で、実際にスクラムを利用して開発を進めるにあたっていろんな問題に直面することがあると思います。そんな時に、この考え方を生かしてカイゼンへの道を切り開けるようなチームを実務でも作っていきたいです！

最後までお読みいただきありがとうございました！

★★SHIFT公式ブログでアドベントカレンダー★★
明日の記事は、
『Workflowsで詰将棋ランキングシステム作るで | SHIFT将棋部』
お楽しみに！

お問合せはお気軽に

SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/

SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/

SHIFTの導入事例
https://service.shiftinc.jp/case/

お役立ち資料はこちら
https://service.shiftinc.jp/resources/

SHIFTの採用情報はこちら