アジャイル・スクラムについてまとめてみる
はじめに
この記事は、アジャイルやスクラムについて、基本的な考え方をまとめるために書きました。
対象読者はアジャイルやスクラムという用語は聞いたことあるけど、あんまり自分の中で理解ができていない、人には説明できないかも...という方がアジャイルやスクラムの基本的な部分を理解できるように書いてみます。
アジャイル開発とは
アジャイル開発とは、短いサイクルで開発とリリースを繰り返す開発です。
なぜ、短いサイクルで開発とリリースを繰り返すのでしょうか。それは、現代のビジネス環境が大きく関係しています。
現代のビジネスは、数年（早いものだと数ヶ月）で栄枯盛衰があり、特に個人向けの商用サービスでは、数ヶ月や1年に1度のアップデートでは、ユーザーニーズの反映もできず、ビジネス的な観点から見ても競合よりも良いサービスを作ることができないからです。
また、ビジネス環境以外でも、私たちがUI/UXの優れたアプリケーションに慣れ、それらがものすごいスピードでアップデートされていっているのが普通、という状態になっているというのもアジャイル開発（またはそれに関連する開発手法）が必要となっている理由となります。
最近では、法人向け、社内向けのサービスですら、素早いアップデートの対応が求められるようになってきていますし、UI/UXに求められるレベルも高くなってきています。
そのため、後述するスクラム開発も含め、アジャイル開発を使って、サービスやプロダクトをより良いものにしていく必要があるということです。
流れの早い現在のビジネス環境と相性が良い開発手法がアジャイル開発であり、現代の開発においては欠かせない考え方の1つになっています。
アジャイル開発の基本
アジャイル開発では、短い期間でリリースし、フィードバックを受け、改善するというサイクルを基本としています。
アジャイル開発は、2001年にケント・ベックらがまとめたアジャイルソフトウェア開発宣言を起源としていて、「計画に従うことよりも変化への対応を」という文章などに現れているように、柔軟に変化を受け入れながら開発をしていき、本当に価値のあるソフトウェア開発を行っていこう！という考え方です。
以前にあったような、事前に全てを決めて、それに向けて開発して、もう後戻りはできない、というやり方ではないということです。
また、アジャイル開発に大きく関係している言葉があります。それは「カイゼン（Kaizen）」です。
これは、日本の製造業の現場から生まれた言葉で、「今あるものを、より良い製品にしていく」というような意味で使われています。
このカイゼンを繰り返していくことで、ソフトウェアをより良いものにしていくということですね。
そして、このカイゼンと相性が良い考え方にPDCAサイクルがあります。これは多くの人が知っていると思いますが、Plan（計画）、Do（実行）、Check（評価）、Action（改善）という言葉の頭文字をとったものです。PDCAサイクルをぐるぐると回しながら、カイゼンをし、ソフトウエアをより良いものししていく、それがアジャイル開発の特徴の1つです。
アジャイル開発では、短い期間でソフトウェアをカイゼンし、それを積み重ねていくため、ある程度ソフトウェアを作ってから検証&修正したいシーンが多くあるというケースには適しています。そして、現代のソフトウエア開発においては、多くがこのパターンに当てはまると思います。
また、これはアジャイル開発に限ったことではないですが、ソフトウェアを作る上で最も大事なことというのは、完成したソフトウェアを使ってユーザーの課題を解決し、成果をあげることです。
その成果を上げるためにアジャイル開発では、開発を以下のような方向性を持って進めていきます。
- 開発者だけではなく、そのステークホルダー含めた全員が、成果を出すためにお互いに協力する
- 一気に全て作るのではなく、小さく試行錯誤を繰り返しながら（フィードバックを受けながら）最終的な完成品を作る
- 事前に綿密な設計や見積もり、計画を立てるのではなく、作っているソフトウェア自体や、その開発計画も調整する
これは、「事前に全てを正確に予測することはできない」という考えが根本にあり、そこにある不確実性をチームで乗り切っていくということが前提になっているということでしょう。
スクラム開発とは
スクラム開発とは、アジャイル開発手法の1つです。大まかな目指す方向性はアジャイル開発と同じですが、細かい特徴としては以下のようなものが挙げられます。（以下の横文字がよくわからない場合は、もう少し下にいくとそれぞれの用語の解説があります！）
- スクラムチームを複数人で構成する
- スクラムマスターはスクラム開発がうまく回るようにするための支援をする
- プロダクトオーナーは1つのプロダクトに1人だけで、プロダクトの価値を最大化するために動く
- スクラムマスターとプロダクトオーナーは兼任しない
- 開発チームは3〜9人の規模にし、プロダクトを開発する
- プロダクトバックログを元に実現したいことをリスト化する
- プロダクトオーナーを1人だけ持つ
- 開発は1~4週間のスプリントと呼ばれる単位で切り分ける
- スプリントプランニングで、次のスプリントの計画を立てる
- デイリースクラム（朝会）は15分程度で行い、毎日、同じ時間、同じ場所で行う
- スプリントレビューで成果物をデモする
- スプリントレトロスペクティブ（振り返り）で「よかった点」「改善したい点」「次に取り組みたいアクション」を話し合う
スクラムの用語について
急に色々と横文字が出てきたので、スクラムに関連する用語もまとめておきます。
スクラムチーム
スクラム開発でソフトウェア開発をするメンバーたち全員のグループを指します。
スクラムマスター、プロダクトオーナー、開発チームのロールがあり、それぞれに最適なメンバーをアサインします。
スクラムマスター
主にスクラム開発を円滑に回していくためのロールです。割り込みタスクが入りそうになったら調整したり、管理者ではありません。
プロダクトオーナー
プロダクトの責任者です。開発チームとスクラムマスターと協力して、プロダクトの価値を最大化することを目的にしたロールです。プロダクトの向かう方向性を明確にし、周囲と協力することが求められます。リリース計画や予算などの管理もする必要があります。また、プロダクトバックログ管理者でもあり、それを常に最新の状態にし、内容を関係者に説明できる必要もあります。
開発チーム
文字通り、ソフトウェアを開発するチームのことです。規模としては3~9人が望ましいと言われています。
プロダクトバックログ
開発を通じて実現したいことをリストにしておくものです。例えば、以下のようなものが挙げられます
- ログイン・ログアウト機能の実装
- 不要なCSSの洗い出し・リファクタリング
- 管理画面が一部の管理ユーザーで閲覧できないバグを修正する
こういった、機能や要求、要望などプロダクトに必要なものを抽出した上で、優先度が高い順に並べ替えたものをプロダクトバックログといいます。これは、開発を進めると変わっていくものなので、プロダクトオーナーが最新の状態に保つことが求められます。
スプリント
1~4週間の間で、同じ期間に区切って繰り返し行う開発の単位です。開発は、基本的にこの区切られた期間で行い、プロダクトバックログの項目を完成させることを目標として行われます。私のいる会社では1週間でスプリントを切っています。
ベロシティ
スクラムチームがスプリント中に完了する平均作業量をストーリーポイントまたは時間数で表したものです。スプリントプランニングをする際に役立ちます。開発チームの過去の実績から算出することができます。
スプリントプランニング
「スプリントで何を達成するか」「選択したプロダクトバックログの項目をどう実現するか」という点を話し合い、計画を立てていくイベントのことです。
デイリースクラム
いわゆる朝会のようなものです。朝にやらなくても良いというのが朝会との違いでしょうか。こちらは15分という時間を区切って、昨日やったこと、今日やること、進捗に障害になりそうなことを共有し、別途細かい話が必要な場合、その関係者だけが集まってまた15分話す...といったことが行われます。
スプリントレビュー
スプリントの最後に成果物をレビューするためのイベントです。書籍によれば、関係者を集めてデモを触ってもらう、みたいなこともするみたいですが、私のいる会社の場合、レトロスペクティブと一緒にやって、スプリントの進捗具合をチェックするくらいでやっています。
スプリントレトロスペクティブ
自分の所属している会社では、スクラム開発に非常に近い形でやっているので、スクラム開発について書籍を読んだり、調べたりした時には、「あ、これもうちやってるな」とか「なるほど、こういう背景があってこれをやっているのか」というのが理解できました。
ちなみに、私からすると、スクラム開発の利点は
- 1週間という短いスプリントでやるので、サボれない（放っておくとサボるタイプなので...w）
- 1週間でここまでやり切ろう!という意志が芽生えやすい
- 困っていることがあったりしたらデイリースクラムで共有し、その後ペアプロなどで解決できる
- レトロスペクティブ（振り返り）で、自分やチームのことを振り返れて良い
- プロダクトバックログがあると、次の週にどんなことをやるか分かって良い
あたりにあるかなと思っております。
Discussion