はじめに
アイキューブドシステムズでCLOMOのサーバーサイドを担当している Kakuno です。
前回のブログでCSEサーバーチームについての紹介がありました。
tech.i3-systems.com
こちらの記事にもあるように、CSEサーバーチームでは既存のバグ修正や改善をメインに行っており、スクラムを用いてサイクル（スプリント）を繰り返す手法を用いています。
今回はCSEサーバーチームがスクラムを組むうえでどのような点で工夫が必要なのかをお伝えします。
スクラムとは
スクラムとはアジャイル開発の一手法で、プロジェクトを短いスプリント（通常2〜4週間）に分割して進めることで柔軟性を高めます。スクラムチームは自己組織化し、定期的にミーティング（デイリースクラム）で進捗と調整を行います。スクラムは透明性・検証・適応を重視し、効果的な製品開発を目指します。
以下では一般的なスクラムの仕組みの説明とCSEサーバーチームのスクラムのルーティンの説明をします。
スプリント
CSEサーバーチームではスプリント期間は長すぎず短すぎない2週間にしています。この期間で成果物を完成させるのがゴールです。
バックログ
優先度順に並べられた課題の一覧がバックログです。
バグ修正の課題は日々増えるので、適切に並び替えをしていきます。
スプリントプランニング
スプリントプランニングでは、2週間のスプリントの中で何をやるのかという計画を立てていきます。基本的にはバックログの優先順位に応じてどこまでやり切るかを決めていきます。
デイリースクラム
毎朝10:00にデイリースクラムとして朝会議をしています。
- 昨日やったこと
- 今日やること
- 困っていること
３つを報告して各々のタスクと状況を確認します。
スプリントレビュー
2週間のスプリントで完成したものを発表する会がスプリントレビューです。
ここではエンジニアだけでなく様々な関係者が参加し、成果物をレビューしてもらいます。
成果物をデモすることで、フィードバックをもらう事が狙いです。
ふりかえり
スプリントの内容を振り返る場です。
振り返りでは主に良かったこと、悪かったことを話し合い、このチームとしてやってみたいこと（StartDoing）とやめるべきこと（StopDoing）を決めます。
CSEサーバーチームのスクラム
ここまでは一般的なスクラムの説明になります。これらを参考にしつつ、CSEサーバーチームでは繰り返しの中で出てきた改善点を取り込み、より良いスクラムを目指しています。
今回はこの中からデイリースクラムとふりかえりで工夫している点を説明します。
デイリースクラムの工夫
デイリースクラムでは見える化を行う事を意識しています。
見える化とは、スクラムボードを用いてチームのタスクや進捗状況を明確に表示し共有することです。これにより、誰がどの課題に取り組んでいて、それはどのような進捗度なのかを明確にします。
また、新しいことをはじめずに終わらせることをはじめる、という事も意識しています。
自分の担当課題が終わり手が空くと、スプリントに入っていない新しい課題に着手してしまいがちですが、他の人の課題を手伝う、レビューを進めるなど今のレーンにある課題を右へ流すことを意識しています。
各レーンには最大制限数を設けており、それを超えた際には警告が出るようにしています。これにより滞留している課題をわかりやすくし、全ての課題を完了にまで持っていくというゴールをチームとして共通認識で持ち心がけるようにいています。
ふりかえりの工夫
スクラムの一般的な振り返りでは主に良かったこと、悪かったことを話し合い、このチームとしてやってみたいこと（StartDoing）とやめるべきこと（StopDoing）を決めます。
CSEサーバーチームでは、これに加えてそのスプリントのクライテリア（指標）をもとにスプリントの評価を行っています。
クライテリアとしてQCD(Quality, Cost, Delivery)に分類分けし、チームが達成すべきものを以下のように定義しています。
CSEサーバーチームと密接に関わるCSチームやQAチームとのやりとりも指標として取り入れています。
Quality
- 設計書の質
- バグ件数
設計書の質を上げることでQA検証時にバグ発見をしやすくし、またQA検証でバグが見つかった件数に応じて採点をしています。
Cost
- チームのベロシティ
- 効率的な開発
SP(ストーリーポイント）を評価に用いてはいけない、という定説はありますが、CSEチームでは部分的に評価に取りいれています。チームとして達成すべきSPを定義し、それに達しているか評価をしています。また余計な会議などが行われていないかもチェックしています。
Delivery
- マイルストーン
- 優先度対応
様々なマイルストーンを適切に守れているかを基準としています。開発や検証はもちろん、CSチームと連携してマニュアルサイトの修正などのマイルストーンも定義しています。
また、課題によっては優先度を高く設定してあるものもあり、それが早くデプロイ出来たかという観点も入れています。
また、長期的なクライテリアのチーム達成率を分析することによって、チームとしてどのような問題を抱えているのかを分析することも出来ます。例えば直近のチームの状態を見てみるとCostが安定していない傾向にあります。これはCSEサーバーメンバーに入れ替わりがあり、稼働が安定しない事が原因です。
まとめ
CSEサーバーチームではチームとして成長する事を意識しており、様々な話し合いのもとスクラムを改善しています。しかしながら、課題としてまだ以下のような点が残っています。
- 組織の壁を超えたチームづくりが出来ていない
- 高頻度でデプロイする仕組み作りがまだ出来てない
- 1日以内で開発が終わるような規模まで課題を細かく分割出来ていない
これらの課題を解決することにより、より良いスクラムを用いてユーザーにより早くバグ修正を届けられるチームを引き続き目指していきます。
