はじめに
はじめまして。 Musubi 開発チームで SRE を担当している、家事育児 🧹🍳👧 の負担率がイレブンナインの大山です。
この記事はカケハシ アドベントカレンダー🗓 part2の 12 日目の記事です。 そして入社してそろそろ 2年になりますが初投稿です。
この記事 is 何
ゆるふわスクラムをしていた私（38歳）がはじめてガチのスクラムにチャレンジし、継続的に課題を解決しながらスプリントを走った備忘録です。 また課題に対するカウンターや、スプリントを 4回ほどこなしたイマココの所感をまとめています。 記事のタイトルにあえて年齢を入れたのは下記の対象読者に向けた意図がありました。
対象となる読者
- しっかりめにスクラムをすることに興味がある方
- 年齢を理由に何かをはじめることにためらいがある方
スクラム未経験🐤 〜 ゆるふわスクラム時代
早速ですがスクラムの話です。
まず、筆者のこれまでの経験としては
- カケハシに入るまでスクラムは未経験（〜2021/12）で、
- スクラムの知識は「SCRUM BOOT CAMP を読んだことがある」程度です。
- カケハシでは全社的にスクラムを採用しており、入社したての私は
上からスクラムが降ってくるから楽しみに口を開けて待つ他力本願寺どのようにスクラムをするのかウキウキしていましたが、わりとゆるふわなスクラムをしているチームに配属されました。（2021/12〜2023/10）
どれくらいゆるふわだったかというと
- エピック、ストーリー、プランニングポーカー、ストーリーポイント、ベロシティなどをあまり使わず
- 全社のスプリントの期間に合わせて 2週間のタイムボックスを設け
- スプリントのスタートでざっと 2週間以内にやりそうなことを列挙して
- スプリントの最後に振り返りだけする
感じです。 これには理由があり、エンジニア一人一人がわりと自律的に仕事ができていて、プライオリティが高そうなチケットをアジャイルに対応するスタイルだったからです。
つまり入社後もしばらくスクラムらしい（？）スクラムはしてこなかったわけです。
※ 当然教科書的なスクラムをどの程度取り入れるかは仕事の内容やチームによってグラデーションがあるため一概に良し悪しを決めることはできません。
ガチスクラムのはじまり💪
2023/10 頃なので 2ヶ月ほど前ですかね、主にインフラを担当している私ともう1名を「Musubi の SRE チーム（インフラサブチーム）」として別チームに外出しできるようになりました。 そして教科書的なスクラムに興味があった私は「この機会を逃す手はない」と考え、見切り発車でスクラムを始めることにしました。
スクラムの構成メンバー
前述の通り 2名です。超ミニマム構成。（私と業務委託メンバーの Sさん）
内訳:
- PO（プロダクトオーナー）: 私（Devと兼任） ※ インフラの構成やその背景を知っているため
- スプリントの計画
- スプリントのテーマやビジョンの検討・設定
- スプリントで実施すべきタスクの優先順位付け
- 必要タスクの洗い出し
- ステークホルダーとの調整
- スプリントの計画
- ScM（スクラムマスター）: Sさん（Devと兼任） ※ ScM 経験者だったため
- スクラムイベントの運用
- スクラムイベントのファシリテーション
- スクラムイベントの準備
- ストーリーやタスクのチケット交通整理
- スクラム運用プロセスの障害を排除
- チームのスクラム実践の教育と改善
- スクラムイベントの運用
- Dev（ディベロッパー） : Sさんと私
- 必要ストーリやタスクの実現に向けた実作業
- クロスファンクショナル（設計、開発、テストなど全てのスキルをチーム内でカバー）
※ ちなみにプロダクトの PO は別にちゃんといます。
スプリントゼロ
「さぁ！スクラム（スプリント）がはじまりました！🏃💨」... と、いきなりはじめることはできません。 まずは継続的にスクラムを回すためにはじめのスプリントを「スプリントゼロ」と定義し1週間を準備期間に充てました。
スプリントゼロでやったこと
- スクラムイベントの設定
- プランニングポーカーの基準
- 使用するツールを決める
- バックログの整理
1. スクラムイベントの設定
大枠のイベントについて開催するタイミングを決めていきます。 参加メンバーは基本的に全員（2名）です。
| スクラムイベント(メンバー) | 開催のタイミングと内容 |
|---|---|
| スプリントの期間 | 全社やプロダクト（Musubi）の開発チームに合わせて 2週間に設定（月〜金） |
| デイリースクラム | 毎朝実施。スクラム2日目から最終日前日まで、日々の進捗確認や共有事項の連携などのミーティングを行う |
| スプリントプランニング (PO, ScM, Dev) | スプリントの初日に開催。当該スプリント内で実施するストーリーやタスクのストーリーポイント設定や、工数見積り、担当者設定などを行う。 |
| スプリントセットアップ (ScM) | （イベントというか作業ですが）スプリントプランニングの結果から、JIRA で必要なものの作成や調整を行い、スプリントの開始をする。 |
| 次期スプリントの計画 (PO) | （イベントというか作業ですが）次のスプリントに向けて、スプリントのテーマや概要の検討や、必要なストーリーやタスクの設定、必要に応じて関係者とのコミュニケーションをする。リファインメントまでに実施。 |
| リファインメント (PO, ScM, Dev) | スプリントが始まるまでに次のスプリントでやるべきストーリやタスクをメンバーに先出しをする。前スプリントの半分を過ぎた最初の営業日に実施。 |
| リプランニング (PO, ScM, Dev) | 突然の差し込みや障害対応などで発生します。 ※独自ルール |
| スプリントレビュー(PO, ScM, Dev) | スプリント最終日の午後にスプリントのクロージングイベントの一つとして、スプリント全体のレビューを実施する。 |
| レトロスペクティブ(ScM, Dev) | スプリント期間内で良かったことや改善点を議論し、次のスプリントに向けての学びとアクションプランを共有する。スプリントレビューの後に実施する。 |
スクラムイベントの日程が決まり次第 Google カレンダーに登録しておきます。
2. プランニングポーカーの基準
プランニングポーカー時にポイントの目安として、過去に実施したタスクをサンプルストーリーとしてピックアップしました。 このポイントを相対的に見てポーカー時の基準としています。
| サンプルストーリー | ポイント |
|---|---|
| ◯◯ の S3 バケットと関連するリソースの Terraform コード化 | 3 |
| Datadog に ◯◯ のモニターを追加する | 2 |
3. 使用するツールを決める
プロジェクト管理としては JIRA を使うことにしました。
今年から Musubi のプロジェクト管理ツールが Trello から JIRA へ移行しており、渡りに船で採用しました。移行のタイミングは最高だったというべきか。いま思うと Trello でスクラムは無理ゲーだったな、という感想です。 理由としては、カケハシはフルリモートで仕事ができるように環境が整備されており、こういったツールにおいても「物理のホワイトボードと付箋」ではなく専用の SaaS をフル活用する文化なので「スクラムを想定してデフォルトである程度運用可能なツール」として JIRA は最適だったなと。
チャートが多くてふむふむ面白い。（使いこなせてはいない）
あとレトロスペクティブは FigJam のボードで KPTA というフレームワークで実施しています。
xKPTA
4. バックログの整理
次期スプリントの計画は PO の役割です。 バックログに溜まっている腐り荒れ果てたチケットを確認し、分類・破棄・詳細化などを実施します。 分類はコンポーネントの設定、破棄はコメントを付けてクローズ、詳細化はエピック、ストーリーなど適切な粒度へ作り直します。 （エピックは1スプリント内に終わらないものを目安に作成します。） とはいえスプリントゼロで使える時間も限られているため、比較的「緊急で重要そう」なものから整理していきます。
ちなみにひたすらチケットと格闘するためつらいときもありますが、私は比較的整理整頓が好きなのでそこまで苦ではありませんでした。
スプリントで発生した課題とそのカウンター
スプリントのカレンダー
Sprint 0（2023/10/02）からはじまり、現在 Sprint 5（執筆時点で 2023/12/07）ですね。
決めることを決めて走り出したスプリントですが、日々のスクラムイベントで課題が出るわ出るわ...。 都度対応をメンバー全員（2名！）で話し合い改善を続けました。
課題.1 不確定要素が多いとスプリント内に終わらない 🤯
たとえばなんらかの「調査」を行うとき不確定な要素が多いです。 1スプリントに収まる作業量ではなかったり、「受入条件」に「見積もり時間を大幅にオーバーしたときの考慮がなかった」など。
カウンター
「スパイク」と呼ばれる調査用のチケットを発行して「実行」とは別にスプリント分けるといったプラクティスで対応が可能です。
- 「受入条件」に見積もり時間をオーバーしたときに調査を次スプリントに持ち越すようにして、
- 調査用のチケットをクローンして進捗のサマリを書いて引き継ぐようにしました。
また、納期に余裕のあるタスクにおいては明示的に
- Phase.1 XXXXX: 調査
- Phase.2 XXXXX: 実行
のようにストーリーを分解して、スパイク（調査）と実行を分け、見積もりの精度を向上させることで対応できました。
課題.2 自分たちで完結しないタスクがスプリント内に終わらない 🤯
たとえ 1スプリントで終わる作業量だとしても、「別のチームやセクションへ協力依頼や問い合わせなどが発生しレイテンシーがどの程度か読めないタスク」は、スプリントの後半で着手すると高い確率でスプリント内に終わりません。
カウンター
「プランニングの段階で他所へ協力依頼が発生するかを精査しスプリントボードの上に置く」ことで対応できました。
課題.3 スクラムイベントが月曜・金曜にあると休みづらい🤯
お休みは土日をくっつけて連休にしたいパターンが多いと思いますが、スプリントの期間を月〜金にしたままだと
- 月曜 ... スプリントの Day.1 のスプリントプランニングと
- 金曜 ... スプリント最後のスプリントレビュー・レトロスペクティブ
のときは 休めない（休みにくい） です。
厳密には休めますが調整コストを考えると少し めんど 手間があります。
カウンター
「スプリントの期間を水〜火へ変更して、単純にスクラムイベントを月・金に開催しないようにする」ことで対応できました。 火・水に休暇を取得する可能性もゼロではありませんが、月・金よりは減るので一旦これで OK にしました。
課題.4 バックログの整理が終わらない 🤯
スプリントゼロでバックログのチケットを整理したものの（インフラのみですが）全体の 10% 程度しかおわらず。 日々のスプリントで Dev ばかり優先していると PO としての業務がおろそかになり、リファインメントに間に合わせるため「前日に慌ててチケットを整理する」ことがありました。
カウンター
この課題のカウンターは 2つあり
- 「PO 業務」をきちんとタスクとして計上し「スプリントごとにチケットを整理する時間を確保する」ことと、
- 未整理のチケットは icebox（新規のビュー）を設けてバックログから全て移動させ、バックログを空にしました。
- PO 業務で整理が完了したものを順次 icebox からバックログに戻します
所感
総括としてはやってよかったです。
何よりプランニングが重要だということを学びました。プランニングを制するものはスクラムを制す。事前に不確定な要素をどこまで減らせるかが重要で、ここがきっちりしているかどうかでメンバーのスピードがダンチで違います。リプランニングが発生したら負けだと思うようになりました。
コンテキストスイッチが減ったのもよかった点だったかなと。 いままでは「バックログ」の存在が常に頭にありましたが、スプリントが走り出してからは「スプリントボード」のみが頭にある状態になりました。 思考リソースやマインドシェアを無駄に取られることが減った肌感です。
最後に
毎日家事育児 🧹🍳👧 仕事で忙殺され 38歳を迎えたいま「何か新しいことにチャレンジすることの楽しさ」を忘れかけていましたが、今回「はじめてのスクラム」を通して様々なことを学び、さらに毎日楽しく仕事ができるようになりました。
株式会社カケハシでは、一緒に開発していただけるエンジニアを募集しています。 フロントエンドやバックエンドはもちろん、インフラエンジニアにも楽しいお仕事が沢山あるのでぜひぜひご一緒できればと思います。
