こんばんは！ エンジニアのナカハシです。
UUUMコンテンツの総合アカウント「UUUM FANS」、カリスマブラザースのファンサイト「CBF」がオープンしました！ 開発に携わるUUUMエンジニア陣も、これらのサイトがよりよいサービスになるよう、日々精進しまくっております！！！！！！！！
さて、UUUMでのソフトウェア開発は、どのチームもアジャイルで進めています。
「アジャイル開発」と一口にいっても、体制やアウトプットの形式によって様々な手法が考えられます。
今回はそのうちの一つである「スクラム」の概要を軽くまとめてみました。
スクラムってなに？
スクラムは「変化の激しい問題に対応するためのフレームワーク」です。
なので、実はソフトウェア開発にのみ利用するものではなく、家のリフォームからNGOの途上国援助といった、様々なプロジェクトで使うことができます。
そして
- 軽量（取り入れやすい）
- チームで自律的に問題に対処できる
- フィードバックが組み込まれている
といった特長があり、何かと状況が変化するソフトウェア開発プロジェクトには適しています。
スクラム開発の流れ
スクラム開発は、1〜4週間単位で「スプリント」をこなしていくのが基本です。
スプリントはざっと以下のような流れで進みます。
- スプリントプランニング … スプリントの初めに、そのスプリントのタスクを決める。（タスクのリストは、優先度や重みを考慮）
- デイリースクラム … 毎日開発チーム全員で、「昨日の実績」「今日の予定」「困ったこと」を発表する。
- スプリントレビュー … スプリントの終わりに、そのスプリントの成果物を関係者でレビューする。（なるべく「動くソフトウェア」などの最終的に近い成果物が望ましい）
- スプリントレトロスペクティブ … スプリントレビューの後、次のスプリントに向けて改善策を検討する。
これらの1〜4を繰り返しすことで、プロダクトの完成度を徐々にあげつつ、生産性の低下を招く要素をリアルタイムに取り除くことができるわけです。
生産性の低下を招く要素って？
例えば以下の表は、プロジェクトを掛け持ちした場合の作業時間の割合を示しています。掛け持ちするプロジェクトが増えるほど「コンテキストの切り替えによる損失」が大きくなり、作業時間が（ただの割り算以上に）減ってしまうのわかります。
| プロジェクト数 | プロジェクトごとの作業時間(%) | コンテキストの切り替えによる損失 |
|---|---|---|
| 1 | 100% | 0% |
| 2 | 40% | 20% |
| 3 | 20% | 40% |
| 4 | 10% | 60% |
| 5 | 5% | 75% |
※『ワインバーグのシステム思考法 ソフトウェア文化を創る』より
スクラムでは、こういった「生産性の低下を招く要素」をなるべく早く見つけ出し、改善していくことを重視しています。
スプリントに組み込まれているミーティングも、開発時間を削る「生産性の低下を招く要素」です。スクラムではこれをなるべく効率的に行えるよう、ミーティング時に確認すべき内容やかける時間をある標準化しています。
まとめ
スクラムは過去の知見を集積してできたフレームワークで、導入することでチーム運営の効率化が見込めます。
ただ、ある種のプログラミングのパラダイムや設計手法と同様に、スクラムも「銀の弾丸」にはならないでしょう。
スクラムには、「ベロシティ」といった見積もり・進捗管理の手法など、選択可能な構成要素はまだあります。
チームの抱えている問題がスクラムの導入で解決できるか検討し、見込みがあれば導入しましょう。
参考文献
スクラムの参考文献はたくさん出ていますが、考案者自身の本『スクラム 仕事が４倍速くなる“世界標準”のチーム戦術』（早川書房）(*)と、Webで見れるガイド「スクラムガイド」はおすすめです。
(*) 記事中のプロジェクト切り替えの資料は、この本でも言及されています。