スクラム実践入門という、技術評論社からリリースされている本を読みました。
スクラム開発という言葉は、IT業界以外ではあまり馴染みがないかもしれませんが、数ある開発手法の中の一つです。
アジャイル開発の中ではもっともメジャーであり、約7割がスクラムを採用しているというデータもあるようです。
約7割がスクラム採用ということになっちゃっています。
引用：アジャイルの採用状況レポート2016の要約
本書は、ソフトウェア開発にフォーカスし、アジャイルの中のスクラムという開発手法について解説した本です。
ソフトウェア開発は困難である
本書がまず述べていることは、ソフトウェア開発は難しいということです。
ソフトウェアは、多くの機能やアルゴリズムによって構成されることが多く、複雑な仕様や設計になりやすいものです。認識違いや仕様変更などによって、手戻り作業を経験された方も多いのではないでしょうか？
また、ソフトウェアはリリースしたら終わりではなく、常に変化していきます。
このように、ソフトウェア開発は変化への対応を常に求められます。そこで登場するのが、スクラム開発という手法なのです。
スクラム開発とは？
従来のソフトウェア開発では、ウォーターフォール型という「仕様策定 => 設計 => 実装 => テスト」を、一本線で行なうスタイルのプロダクト開発が普通でした。
ウォーターフォール型とは、システムの開発を「基本計画」「外部設計」「内部設計」「プログラム設計」「プログラミング」「テスト」という工程に分けて順に段階を経て行う方法です。前の工程には戻らない前提であることから、下流から上流へは戻らない水の流れにたとえてウォータフォールと呼ばれています。
引用：ウォーターフォール型
しかし、このウォーターフォール型は、後戻りをせず一気通貫で行なう必要があります。変化にとても弱い開発スタイルなのです。
そこで登場するのが、スクラムという開発手法です。スクラムは、細かいスパンで設計からリリースまでを繰り返すことで、少しずつ動作するソフトウェアを育てていく手法です。
リリースという区切りが頻繁に発生するため、途中での横槍に強い(変化に強い)という特徴があります。
スクラムチームとは？
プロダクトの開発は、スクラムチームが一丸となって行ないます。なお、スクラムチームには、大きく分けて3つのロール(役割)があります。
プロダクトオーナー
スクラムチームが作ろうとしているプロダクトの最終責任者です。
開発チーム
プロダクトオーナーが要求する順番に従って、実際に開発していくチームです。
スクラムマスター
プロダクトオーナーと開発チームによるスクラムの実行を支援し、スクラムの円滑な遂行を支援するスクラムの推進者です。
なお、上記のロールはざっとした概要の説明になります。詳しい解説は本書をご確認下さい。
スクラムイベント
スクラムは、実際の開発作業とミーティングやコミュニケーションを中心に進んで行きます。
スプリント
スクラムでの開発単位です。1〜4週間のいずれかになることが多いです。スプリントの期間は、チームの趣向や特性によって決定します。
スプリントゼロ
開発環境の整備や、ビジネスモデルの検討など、最初に1回だけ行なう特別な事前準備スプリントです。
スプリントプランニング
スプリントで何をやるかという、計画を立てるミーティングのことです。
デイリースクラム
1日1回15分のタイムボックスで、進捗や予定の共有、問題の共有を行なうミーティングです。一般的には、朝に開催されることが多いです。
スプリントレビュー
スプリントが完了したら、スプリントの成果を確認します。成果物のことをインクリメントと呼びますが、要は動作するプログラムのことです。
実際にプログラムを動かして行ないます。
スプリントレトロスペクティブ
振り返りミーティングのことです。スプリント内で発生した良かった事、悪かった事、改善点などを振り返ります。
スプリント毎に振り返りを行なうことで、チームはどんどん良いチームへと進化していくことが理想です。
なお、上記のイベント概要はざっとした概要の説明になります。詳しい解説は本書をご確認下さい。
スクラムの成果物
スクラムには、3つの成果物があります。プロダクトバックログ、スプリントバックログ、インクリメント(成果物)です。
プロダクトバックログには「○○サイトにログインすることができる」といった、要求事項が書かれています。スプリント毎に優先度の高いプロダクトバックログを取り出し、スプリントバックログとして実際に開発できるレベルのタスクに落とし込んでいき、実装を開始します。
スプリントが終わると、インクリメント(成果物)が出来上がります。Webシステム開発の場合であれば、動作するプログラムが出来上がりますので、実際に動作させて確認します。
スクラムを支えるプラクティス
スクラム開発には、様々なツールやプラクティスがあります。
- インセプションデッキ
- リーンキャンバス
- ユーザーストーリー
- プランニングポーカー
- バーンダウンチャート
- KPT
- 技術的負債
・・・といったものです。
スクラムには「理解は容易だが習得は困難」という特性があります。スクラムを遂行していると、必ずつまづくことがあります。そんなに時に役立つのが、本書で紹介されているプラクティスなのです。
理解は容易だが習得は困難である
スクラム開発そのものは、理解することは難しくありません。本書も、実際の活用事例の紹介も含めて200ページ前後であり、分厚い本ではありません。
スクラムでは「デイリースクラム」や「スプリントレビュー」「スプリントレトロスペクティブ」といった多くのミーティングを開催するため、コミュニケーションが非常に重要になります。
しかし、コミュニケーションにはトラブルがつきものです。プロダクトオーナーが高圧的であったり、ミーティングの場の空気が重いといったトラブルも想定できるでしょう。
また、スプリントの遂行中に、上司から別件のタスクをお願いされてしまった時はどうすれば良いでしょうか？もちろん、タスクを安易に引き受けてしまっては、目先のスプリントの完了に支障をきたすことになります。
本書には、完全網羅ではないものの、多くのスクラムの活用事例やトラブルシューティングが掲載されています。
読んでみて良書だと感じましたので、スクラム開発を知らない方も、お手にとってみてはいががでしょうか。
