Photoruction Advent Calender 2022の18日目の記事です！
こんにちは！CREチームリーダーの田中です。
前回、スクラムマスターとしての半年間の経験の備忘録を書きました。
今回はその後半に当たる記事です。
突然ですが、「ゆるラム」という言葉はご存知でしょうか？
ま、知るわけはないですよね。僕が勝手に作った造語ですから。。
経緯としては、どうせスクラムの勉強をしたのだから、
スクラム開発を行わないチームに、スクラムのエッセンスを取り入れられないかな〜と思い立ちました。
そして、ガッツリしたスクラムのフレームワークの文脈には添えない状況で、いかに、
スクラムの良いとこどりをするか、「ゆるラム」を真剣に考えてみようと思います！
前提の違いを考える
まず、スクラム開発の基本的な考えをおさらいしてみましょう。
スクラムは、不確実性をヘッジしていくのが基本思想。
タスクの割り込みが発生する場合は、基本的には次回以降のスプリント(期間内に対応するタスク)に組み込まれます。
安定した進捗を出すためです。(ただ、勿論緊急度が高いタスクが発生した場合は、他のタスクを次回のスプリントに回す形で、スプリント内で対応するようにします。)
一方、弊社のCREチームだと、不具合の一時切り分けがメインタスクになります。
カスタマーサポートのチーム顧客から不具合の報告を受け、CREチームに原因究明を依頼します。
当然、顧客に対して不具合に関しての説明が求められますので、それまで取り組んでいるタスクよりも優先度を高めて、一時調査
をし→原因突き止めたら、報告。そして、対応の優先順位を決め、改修。
こんなフローになっています。
スクラム開発に比べたら、割り込みタスクを翌週翌々週に調整していくことが難しいのが現状かなと思います。
つまり差分は
- スクラムチーム：不確実性をいかに増やさず、減らすか
- CREチーム：不確実性が増えていく可能性がある中で、いかに減らすか
を考えていかねばなりません。
表現として、矛盾してるような気もしますが、それでも向き合っていかないといけません笑
スクラム開発から転用できそうな考え方
- こまめなコミュニケーションを取り合えるようにする
- 検査→適応できる(要するにPDCAを回せる)
- スコープを区切るのは大事
転用できるイベント
逆に転用できないこと
- プランニング(後述の通り、差し込み計画を立てても意味がない。だって予測できないから)
- リファインメント(仕様の検討をメインで行わないため)
具体的なアクション
- デイリースクラム
- 週一の定例→デイリーを毎日に変更
- 細かい改善ができるようにということと、コミュニケーション量増進が目的
- レトロスペクティブ
- 隔週でKPTを設ける
- 短期的なタスクの追われる中でも、中長期的な視野を持って日々の業務に取り組むことを忘れないために重要
- レビュー
- 日々対応した不具合隔週でレビュー
- それを題材に仕様理解、コード理解を深める
- レビューというより勉強会の意味合いが強い
- 日々対応した不具合隔週でレビュー
まとめ
CREリーダー就任2ヶ月ほどで着手している「ゆるラム」施策です。
上記に限らず、良さげなイベントに関しては、積極的に取り組んでいこうと思います
(アドカレ1日目の南風原さんのこの記事とかとか)
CREはもぐら叩きのようなもん
出てきたもぐらをすぐ叩くのもそうだし、
次に出てきた時に、すぐボコボコにできるように、可視化できる状態にしなければならない
結局大事なこと
ゴールとしては、
- いかに早く、調査対応やデリバリーをするか
- チームとしての生産性を高めること
- 学びのサイクルを構築すること
になるかなと
まだ、試行錯誤の段階ですが、こんな感じで、「ゆるラム」を進めていきます！！
P.S.
ここまで書いてやっと気づいたけど、スクラムの語源から考えると、
「ゆるラム」ってめっちゃ弱そうよね。。
