私たちのスクラム紹介 ～守破離の守を目指して～
はじめに
Agile Studioの岡本です。
今回は私たちのチームがやっているスクラムのスタイルと、チームで独自に工夫している点について紹介してみます。
チーム構成
PO1名（組織体制上の上司でもある岡島さん）、SM1名（岡本、DEVも兼任）、DEV3名（坂部さん、見澤さん、三田村さん）で構成しています。
各メンバ紹介はこちらにも書いています。
メンバ全員のスクラム経験が浅い（SMの岡本も！）ため、まずは教科書通りのスクラムつまり『守破離の守』を目指してやってみよう、という所から始まっています。
スクラムイベント
下記のような基本パターンをかなり忠実（意図的）に実施しています。
「守破離の守」ですので！
スプリントプランニング
- 開催：水曜日（11:00-12:00）
- 参加者：PO、DEV、SM
- 目的：次のスプリントの計画
- アクション
- スプリントゴールの設定：スプリントのゴールについて合意する
- タスクの優先度決定：PBIを優先順に並べかえる
- スプリント達成条件の確認：POと達成条件について合意する
- スプリントバックログの作成：チームのベロシティ分だけPBIをスプリントバックログに積み上げる
デイリースクラム（朝会）
- 開催：毎日（09:15-09:30）
- 参加者：PO、DEV、SM
- 目的：一日の起動トリガ、タスク状況確認、情報共有
- アクション
- あいさつ：気持ちを仕事モードに入れる
- 昨日のタスク：各自で昨日やったことを共有
- 今日のタスク：全員でカンバンをみながらタスクの確認
- 連絡事項：休みや直近の予定があれば共有
バックログリファインメント
- 開催：火曜日（15:00-16:00）
- 参加者：DEV、SM
- 目的：次のスプリントプランニングの準備
- アクション
- タスクの細分化：プロダクトバックログアイテム（PBI）を見積もり可能＆完了定義が可能なレベルまで分割する
- タスクの見積もり：PBIにストーリーポイントを設定する
スプリントレビュー
- 開催：水曜日（10:00-11:00）
- 参加者：PO、DEV、SM
- 目的：今スプリント成果の確認
アクション
- デモ：成果物をPOに対してデモする
- 受け入れ：成果物が完了条件を満たしているか確認する
- フィードバック：POからスプリントに対するフィードバックを受ける
完了の定義
当初は完了の定義を明文化しておらず、スプリントレビューの度にPOへの補足説明に追われたり、微妙な空気のOKになったりして不安定だったので、最近になってカイゼンしてみました。
- 受け入れ条件の一例
レビューを受けるユーザーストーリーの単位でPOがスムーズ＆客観的なチェックが出来るようにテスト項目的に書き出しています。
受け入れ条件の例
レトロスペクティブ（ふりかえり）
- 開催：水曜日（13:00-14:00）
- 参加者：DEV、SM
- 目的：
- アクション
- ネタ出し：KPTをベースに各自が感じていることを付箋に貼りだす
- 感想戦：付箋を見ながらチーム内で雑談する、結論は出さなくていい、改善Tryも無理に出さなくていい
ツール
スクラムのワークで中心的な役割を持っているツールです。
カンバン（GitHub Projects Beta）
こちらのエントリでも紹介している通り、GithHub Projects（Beta）をカンバンとして使っています。
プロジェクト開始当初（学習メインのフェーズ）ではツールに不慣れなメンバもおり、とっつきやすさを重視してMiroでカンバンを運用していましたが、開発メインのフェーズに入ってくるとソースコードから離れて生きることは不可能なので、チームで相談してカンバンを含めてプロジェクト管理の大半をGitHubに寄せてしまいました。
ホワイトボード（物理）
リモートワーク主体のチームですが、たまに出社するとホワイトボードを使っての議論や説明をすることもあります。
言葉では上手く説明できないのですが、個人的に手描きのスピード感と温度感が好きなので、使える場面では割と積極的に使っています。
その他
リモートワークを効率的に行うために他にもいろいろなツールを試しながら使っています。
カスタマイズポイント
冒頭で書いた通り、初心者スクラムチームなのでまずは可能な限りシンプルなルールでやってみようというところから始めています。
とは言っても、開始から3か月近くスクラムを回していると、色々と自分たちの文脈に沿って調整したい点も出てきました。
以下、チームで考えて工夫している点をいくつか挙げてみます。
タスク単位の見積もり
通常のスクラムではストーリー（＝PBI）単位にストーリーポイントを付けて見積もりますが、私たちのチームではもう一段階詳細化したタスク単位で見積もりを行っています。
このようにしている理由は、今回の開発対象ドメインにチーム全体が不慣れだったため、ストーリーの粒度では必要になる作業の大きさがサッパリ想像できなかったためです。
そのために、より具体的な作業がイメージできるタスク単位に分解してから、そのタスクの大きさを見積もることにしました。
PO（顧客）目線から見ると『このプロダクトはいつ頃完成するのか？』という問いには答えにくくなりますが、今回はそれよりもメンバ自身が自分たちの作業量やベロシティを把握しやすくなることを優先しました。
見積もりの粒度はS・M・Lの3段階
いわゆる『Tシャツサイズの見積もり』です。
これも自分たちが見積もりに不慣れなため、詳細なポイント付けは不可能（やっても意味はない）と考え、であれば一番シンプルなやり方でということでこの3段階にしています。
ストーリーポイントは、S（1ポイント）、M（3ポイント）、L（5ポイント）と単純明快になっています。
カイゼンタスク
スプリントプランニングで洗い出したタスクとは別に、途中で発生した/やりたくなった作業については カイゼン という扱いにして自由に追加するようにしています。
外部からの割り込みに似ていますが、こちらはチーム内部で発生した（もしくは発見された）作業が中心になります。
プランニング時により精緻な洗い出しをしていれば最初から計画できた作業もありますが、今はそこに時間を掛けるよりは気が付いたらすぐに手を動かせるスピード感を優先してこのような運用にしています。
もちろん弊害も認識していて、このカイゼンタスクはポイントとして計上していないために、チームのベロシティを正しく把握できなくなるリスクも あります。これは次に解決したい課題だと思っています。
バーンダウンではなくバーンアップチャート
プロジェクト開始時に全てのストーリーとタスクを洗い出しポイントを付けることが出来なかったため、一般的なバーンダウンチャートを描くのは困難になってしまいました。頑張って描いたとしても、途中でストーリーやタスクの追加が頻発して、チャートが乱高下するのは必至です。
こうなると本来の目的であるベロシティの可視化が難しくなるため、今回はベロシティ（の変化傾向）の把握を最優先として、バーンアップチャートを描くことにしました。
またこれは各スプリント内のペース変化よりも、全スプリント期間を通しての傾向を掴む意味でも良かったのではないかと考えています。
ちなみに現在のチャートからは以下の点が可視化されています。
- チームのベロシティはプロジェクト開始当初からほぼ一定であり、チームはあまり改善されていない
- タスクに対する見積もりの精度は、それなりに安定している（大きく外している訳ではなさそう）
- スプリント終盤（最終日）に駆け込みで達成するタスクが多く、計画的に消化できていない
こういうところを見つけて改善のアクションに繋げていく必要があると思っています。
夕会
デイリースクラムとしては一般的な朝会をやっていますが、それとは別に一日の締めくくりとして夕方に軽く雑談を兼ねて各自の状況共有を行う時間を作りました。
最初はやっていなかったのですが、タスクの進み具合に不安があったり他のメンバにヘルプを求めたいときには、次の日の朝会まで持ち越さずに早めに共有したいという意見が出てきたのでスクラムイベントとして追加しました。
想定していた『困っていること』の共有の他に、『今日はここまでできた!』といった前向きな情報も共有できるので、以前よりもスッキリした気分で一日を終えられる感じがして気に入っています。
ミニマムで始める
これは具体的なカスタムポイントではありませんが、SMとして意識している点です。
スクラムはシンプルなルールであると言われますが、それでもいきなり全部を理解して実践するのは難しいと考えました。
形を真似て実行することは出来ると思いますが『本当に腹落ちしているか？』と聞かれるとかなり怪しいと思います。
そこで最初は必要最小限の決め事だけでやってみて、メンバ自身が『何か足りないな』『これはもうちょっと決めないとダメかも』と感じたタイミングで、そこに必要なプラクティスを追加したり、簡略化したルールを本来の定義に戻したりするように心掛けています。
内部プロジェクトかつ育成のミッションを持っているからこそできる贅沢とも言えますが、一年かけて色々と実験してみようの精神でトライ＆エラーを沢山積み重ねていきたいと思っています。
さいごに
『守破離の守』ということでベーシックな運用をしているつもりですが、思った以上に自分たちで考えるポイントがあったかな、というのが正直な感想です。
これは足りていないから考えるという訳ではなく、スクラム的にはこれ位のカスタマイズをするのが標準（変な日本語ですが）なんだろうと思います。
スクラムの研修などを受けると『スクラムプレイブック（自分たちのチームのルール）を作りなさい』と言われますが、今回やってみてその意味が良く分かりました。
