僕らのスクラム開発

はじめに

スクラム開発とは、システム開発を進めるための代表的な手法であり、短いサイクルで計画から完了までを繰り返す開発手法です。
本記事では、実際にスクラム開発を導入した際の取り組みや気づきをまとめます。

目次

1. 他の開発手法と比較

2. スクラム開発の条件

3. やることになった経緯

4. 進め方

5. 成果

他の開発手法と比較

スクラム開発の条件

■ チーム規模（5〜9人が推奨）
スクラム開発では、5〜9人程度のチームが推奨されます。
その理由は、チームメンバーの多様性を確保できると同時に、全員とのコミュニケーションが行き渡りやすく、各メンバーが責任を持ちやすいためです。
一方で、9人を超えるとコミュニケーション調整のコストが高くなり、チームをさらに分ける必要が出てきたり、管理する役割が追加で必要になるといった懸念が生じます。

■ 役割に適した人の確保
スクラム開発を行う際には、役割を明確に決める必要があります。
基本構造は「プロダクトオーナー」「スクラムマスター」「開発チーム」の三つで構成されます。
・プロダクトオーナー：チームで洗い出したタスクを管理し、優先順位を決定する。また、プロジェクト関係者との連携を担う。
・スクラムマスター：チームで決めたルールや計画に基づき、活動が円滑に進むよう支援する。
・開発チーム：タスクを実行し、成果物を完成させていく。

■ 透明性のある成果物管理
プロダクトバックログ、スプリントバックログ、インクリメントを常に見える化し、チーム全体で共有します。
また、完了の定義を統一しておくことで、各メンバーが全体の進捗状態を把握できるようにします。

■ イベントごとの時間を守る
各スプリントの期日やデイリースクラム、スプリントレビューといったイベントに関しては、あらかじめ決められた時間を遵守することが重要です。

■ 要求や仕様が変化しやすいプロジェクトに適していること
スクラム開発は、要求や仕様が変化しやすいプロジェクトに適しています。
このため、準委任契約とは相性が良い一方で、請負契約とは相性が悪い傾向があります。

■ ステークホルダーと頻繁にフィードバックできる体制
スプリントごとにレビューや成果物の確認を行うため、発注者や利用ユーザーを含めた関係者と短いサイクルでコミュニケーションを取る体制が必要です。

やることになった経緯

当時、チームにはスクラムを進めるための仕組みや役割分担がなく、いわば「受け入れ前提が整っていない」状態でしたが、当社には新しい開発手法を前向きに取り入れる文化があり、スクラムの採用を決定しました。
導入に際しては、スクラムマスター資格の取得支援など会社全体のサポートがあり、試行で終わらせず本格運用へ移すための土台を短期間で整えられました。
その結果、スクラム未経験のチームでも、柔軟に新しい進め方を取り込めるという会社の強みを活かし、スムーズに導入を実現できました。

進め方

①チームビルディング

・自己紹介
・インセプションデッキ：プロジェクトの全体像を明確にする
・バリューズカード：チームメンバーと価値観を共有し相互理解を深める
・チーム名をつける：チームの一体感を醸成する
・カスタマージャーニーマップ：エンドユーザーの行動や思考を分析

②ポジション(役割)決め

プロジェクトメンバーを、プロダクトオーナー・スクラムマスター・開発チームに分ける。

③プロダクトバックログ作成

作るべき機能や改善点をまとめた優先順位付きのリストを作成し、プロダクトオーナーが管理をする。
スプリント計画やチーム作業は、プロダクトバックログの中から進めていく。そのため、常に更新、見直しがされる。

④スプリントプランニング

■ 各スプリントは一週間とし、一週間ごとにリリースをしていく。
インフラ構築は一週間ごとにリリースするものではないが、インフラがないとリリースできないため、今回のチームでは、開発とインフラでは分けずに全員で両方をやった。

■ スプリントバックログを作成する
タスクを細分化し、一日で終わる作業量まで分割したタスクの実行工数を見積もる。

■ 「デイリースクラム」と「開発作業」の切り分け
毎日のデイリースクラムと開発作業の時間を決めることで、各作業に集中できる環境を作る。

■ レトロスペクティブ(1スプリントごとの振り返り)
振り返りを行い、継続的な改善を図るイベント。 喜怒哀楽、幸福度といった感情も扱うので、チーム運営上では最も重要なイベントといえる。
・GOOD/BAD系(良かったこと、悪かったことをもとに、改善策を出す)
・メタファ(チームの状況を別のものに例え、意見を出しやすくする狙い)
など

良かったこと・成果

■ 実績
1年の取り組み実績があり、導入初期は1スプリントでリリースできない回もあったが、
改善と見直しを継続した結果、現在は毎スプリントで機能をリリースできている。

■ メンバーの稼働率
スプリント計画の精度を保つには各メンバーの稼働率70%以上が望ましいが、他案件との兼ね合いで維持するのが難しい場面もあった。

■ 品質とフロー
テスト自動化＋CI/CDの採用により、回帰の早期検知が可能になり、1週間リリースを安定運用。レビュー負荷も平準化。

■ メンバーの感想・良かったこと
・レトロスペクティブでは、いろいろな振り返り手法を試すことができ、また貼り出したメモにスタンプを押したりといった作業も楽しかった。
・インフラ（AWS/Terraform）にも少し携われたこと。できることが増えたこと。
・人の設計を作成段階からしっかり聞く機会はあまりないので、とても勉強になりました。

執筆者：M.I.(プロフィール)