ユーティル式スクラム 2024年版
ブログに足をお運びいただきありがとうございます！
2年前に書かれたこの記事、ご覧いただけましたでしょうか？
この記事の執筆時、ユーティルの開発部はスクラムを取り入れたばかりでした。開発体制の変更によって「個人」単位から「サービスチーム」単位での開発が主軸となり、チームの状況共有を推進することが当時のスクラム目標でした。
そこから2年が経過し、ユーティル式スクラムは少しずつ形を変えています。
今回の記事では、最近の試みも含めて 2024年現在のスクラム体制をご紹介していきます！
スクラムとは
「ユーティル式スクラム」を語る前に、まず通常の「スクラム」についてご存知でしょうか。
スクラムの説明にはアジャイル開発の説明が不可欠です。
ご存知の方も多いと思いますが、システム開発の手法は次の2つに大別されます。
| 名称 | ウォーターフォール | アジャイル |
|---|---|---|
| メリット | ・スケジュール管理しやすい ・役割分担がしやすい | ・仕様変更に強い ・開発遅延時、影響が少ない |
| デメリット | ・仕様変更に弱い ・開発遅延時、影響が大きい ・ドキュメント作成時間が膨大 | ・役割で分担しづらい （全員が各役割を担える必要がある） ・ドキュメントが残らなくなりがち |
SESや受託などスケジュールを重要視した開発では、ウォーターフォール開発が多用されています。対して、仕様変更やスケジュール変更の多いベンチャー企業では、アジャイル開発を取り入れる場合が多いようです。
ここで、「スクラム」とは何かという話に戻します。
「スクラム」とは、アジャイル開発を行うためのフレームワークのひとつです。このスクラムフレームワークの目的と柱については、次のとおりです。
「価値ある」プロダクトを「迅速」にリリースすることを「反復的」に行うことが重要視されているフレームワークですね。
プロダクトに関連する全員で、そのプロダクトの価値を議論したり、開発途中のプロダクトを見ながら仕様・スケジュールを随時確認・変更していくようなイメージです。
ユーティル式スクラム
概要
現在ユーティルでは、
- 自社メディアである幹事シリーズのSEO向上対策
- 営業部の業務効率化
など、この場ではまだ言えない施策も含めて複数のプロジェクトが同時並行しています。
その中で、仕様変更が行われる場合もありますし、優先度の高い割り込みタスクがさらに入ってくる場合もあります。
これらをひとつひとつ叶えるために、少人数のエンジニア（2024年5月現在、正社員 5名＋業務委託/副業 数名）で開発業務を遂行しています。
限られたリソースで最大の成果を出すため、短期サイクル かつ 変化に強いスクラムフレームワークをベースに、オリジナルの工夫を加えたものが「ユーティル式スクラム」です。
目的
ユーティル式スクラムの主な目的はこのふたつです。
- 価値のある開発成果を迅速に生み出すこと
- 複数プロジェクトを同時並行すること
企業に従事するエンジニアであれば、目的のひとつ目は皆さん同じではないでしょうか。複数プロジェクトの同時並行についても、経験のあるエンジニアの方は少なくないでしょう。
「価値のある開発成果」には沢山の含みがあり、これらを成功させることができれば開発部として大成功です。
スプリント期間
一般的には 2週間と定めるチームが多いスプリント期間。
メリットは沢山ありますが、特にこの3つが大きく感じられます。
ユーティルではその半分の「1週間」と定めています。
- 新着依頼の着手時期が遅れにくい
タスク着手の計画（プランニング）を行う周期が1週間なので、依頼後あまり日が経たないうちにタスクに着手することが可能です。
優先度が高いことをわかりながらも「早くて着手は2週間後です…」なんてツライ返事をしなくて済みますね！
- 問題の早期発見・改善ができる
直近のスプリント期間の振り返り（レトロスペクティブ）も1週間ごとに訪れるので、チーム内でこまめに問題を共有し把握、対処することができます。
また、個人のKPTも頻繁に回すことになるため、意識強化に繋がり、KPTの共有によってメンバー同士の積極的な声掛けに繋がっています。
- タスク進捗が把握しやすい
スプリントボードに積まれるタスクが約 5営業日分であるため、ボードのタスクを簡単に把握できます。よくよく見たらタスク消化率悪くない？…なんてこともありません。
スクラムイベント
スプリント期間を1週間にしたことで、勿論デメリットもありました。
それはスクラムイベントが頻回になることです。
スクラム経験者は、スクラム特有のイベント（会議）が重い…と感じる人が多いのではないでしょうか。2週間に1度でも重いのに、それが1週間に1度やってくる…嫌ですよね。
この負担を軽減するため、ユーティルでは次のような工夫をしています。
時間の短縮
イベントの最大時間はスクラムガイドに明記されています。単純計算すると、スプリントが1週間単位の場合、
- スプリントプランニング → 約2時間
- スプリントレトロスペクティブ → 約45分間
となります。
ユーティルではこれらを合わせて 1時間半とし、1時間15分の短縮を図っています！ 1週間に 1時間半の会議であれば、ちょっと長い定例会議として受け入れやすいのではないでしょうか。
内容
時間短縮しながらも内容は充実したものにするため、次のような流れで実施しています。
- サービスチーム単位での振り返りとプランニング（45分）
- 前スプリントについて振り返り
- ゴールの達成度（未達成の場合は原因・対策の検討）
- 工数の比較（見積 対 実績）
- 完了タスク量の比較（対 他スプリント）
- 次スプリントについての計画
- リファインメント
- プランニング
※サービスチームによって多少流れに差があります
- 開発部全員（45分）
- 前スプリントについて
- 個人ごとのKPT（書き出し、発表、改善策の検討）
- 部全体としてスプリントゴール達成度の把握
- 次スプリントについて
- 部全体のスプリントゴールの把握
この流れのうち、次の2つは 2024年5月に導入したばかりです。
- 工数の比較
- 完了タスク量の比較
この振り返りを毎スプリント重ねていくことで、工数見積の精度向上やチーム生産量の可視化・計画性向上を実現し、ひいては価値のある開発成果を迅速に生み出すことに繋げていきたいと考えています。
今後の課題
ユーティル式スクラムはまだまだ成長過程です。
スプリントイベントの改善活動や、直近実施したバックログの総合的な見直しなどから、最近ようやくスクラム第一の柱「透明性」を確保することができました。
第二・第三の柱である「検査」「適応」も実現するべく、頻回リリースする新システムの社内理解を広め、プロダクトの価値を社内で健全に議論できる環境を作っていきたいと考えています。
最後に
ユーティルでは、変化に強い開発手法である「スクラム」フレームワークをベースに、オリジナルの工夫を加えながら開発業務を遂行しています。この記事によって、ユーティルがスクラムを始めた ユーティル式スクラムとスプリントプランニング の記事 からの大きな前進を感じ取っていただけましたら幸いです。
ユーティルでは、アジャイル未経験の方も、スクラムが得意な方も、一緒に新しい形を探してくれる仲間を探しています！
ご興味をお持ちいただけましたら、是非カジュアル面談でお話ししましょう！
開発部一同、エントリーをお待ちしております。