アジャイル開発とスクラム

アジャイル開発

1からアプリケーションを完成させるためには様々な障壁がある。その課題を少しでも解決し、スムーズな開発実現するために様々な開発手法が用いられてきた。その中でも今回はアジャイル開発をピックアップ。

アジャイル開発について

アプリケーションの開発過程で、依頼者の要望が変わるということは頻発する。なぜならば、ビジネスが変わればアプリケーションも変わるからである。こうした頻繁な仕様変更に対応するためには、細かく作って細かく確認する必要があり、これに最適なのがアジャイル開発である。

アジャイル開発とは

アジャイル開発は、一度にまとめてでは無く、少しずつ確認をはさみながら開発を進めていくことが特徴。利用者の反応や、関係者からの継続的なレビューを得ながら、計画を調整しつつ進めていく。

アジャイル開発におけるキーワード

以下にアジャイル開発におけるキーワードを列挙する。

• スプリント
  • 1つの開発の周期。概ね1週間ずつスプリントを設置することが多い。
• スプリント計画ミーティング
  • 各スプリントが始まる日に実施。当該スプリントでやることや、到達すべき点について、開発チームで共有する場。
• スプリントレビュー
  • 各スプリントの終了日に実施。プロダクトオーナーやプロダクトに関わる関係者にスプリントでの成果をレビューしてもらう場。
• スプリントレトロスペクティブ
  • スプリントレビュー終了後に実施。スプリントでの反省点や、維持すべき施策などについてチームで共有する場。

スプリントの考え方は以下の図のとおり。

他の開発手法について

他の手法を考えると、「開発初期段階に要件を決定し、完成までの実装スケジュールまできっちり決めて開発に取り掛かる」方法が考えられる。この方法で主流なのが、ウォーターフォール開発である。

ウォーターフォール開発とは

初めに決めた要件を、ある期限までに完了するという手法。元来からの契約→開発→納品というフローに則ったシンプルなもの。厳密な要件定義と納期に合わせた進捗管理を行うことができれば、大きな問題は発生しない。しかし、はじめの要件定義が上手く行っていなかった場合や、作りたいものが途中で変わってしまった場合に対応することが難しくなる。

開発手法の比較

上記2種類のメリット・デメリットを比較。

	アジャイル	ウォーターフォール
メリット	手直しが容易で仕様変更に柔軟に対応可能	開発計画がシンプルで、進捗管理がしやすい
デメリット	進捗が把握しづらい	仕様変更に対応しにくい

上記の図からアジャイル開発では、進捗が把握しづらいというデメリットが存在することがわかる。というのも、アジャイル開発では実施方針が厳密ではないため、スプリントごとに担当する箇所や実装内容が変わることが想定されるためである。

このデメリットを回避するためには、チーム内での合意形成やコミュニケーションが重要である。そこで以下のようにスクラムを用いることにする。

スクラム

アジャイル開発と呼ばれる手法にも、様々な種類がある。その中でも有名なのが、スクラムと呼ばれる手法。

スクラムについて

チーム開発を進めるための手法の１つ。リーダー・マネージャー主体ではなく、チームメンバー全員が主体性をもって、プロダクト完成に向けた責任を持つことが特徴。

スクラムの大まかな進め方

以下の流れでスクラムは進んでいく。

• （1）アプリケーションの要件を決定
  • 依頼者からヒアリングをして、どのようなアプリケーションを作成するのか決める
  • アジャイル開発においても大枠の要件定義は必須
• （2）開発の意図を、開発する人々が完全に把握する
  • 何を達成するためにそのプロダクトを作るのかを把握する
  • 目的と矛盾する機能や優先順位付けは排除することが求められるため、開発メンバー全員がこれを理解していることが重要
• （3）実装すべき作業を洗い出す
  • 完成までに行うべき作業を洗いだすリスト化しておく
• （4）作業の量を見積もる
  • 上記作業のそれぞれにおける作業量を見積もる
• （5）スプリントごとに実装する
  • スプリントの期間を設定し、スプリント開始時にスプリント計画ミーティングを行う
• （6）スプリントの成果を発表する
  • スプリント計画で定めた実装が計画通りに終えられたかどうかチェックをする
• （7）振り返りを行う
  • 次の期間でより早く進めるための対策を立てる

上記のスクラムにおけるフローは非常にシンプルだが、これを忠実に守ることが重要である。個々人の主体性を重視した手法であるからこそ、より良いプロダクトを作成するためにしっかりと各々が責任を持つことを求められる。

スクラムにおける役割分担

スクラムにおいて大切な役割分担を以下に挙げる。

• プロダクトオーナー：プロダクトバックログの管理責任者
  • プロダクトの結果責任を追う
  • 開発チームを活用して、プロダクトの価値を最大化する
  • スクラムは各々の主体性を意識した手法であるが、最終決断を下すのはプロダクトオーナー
• スクラムマスター：スクラムの調整役
  • スクラムが上手くいくようにサポートする
  • 人間関係に起因するような妨害を排除し、推進役となる
  • 決してリーダーではなく、スクラムを円滑に回すための世話役のようなポジション
• 開発チームメンバー：実際に開発に携わる
  • 計画に沿って、プロダクトを作っていく
  • 日々開発計画について話し合い、必要であれば計画の変更を申し入れる
  • 上下関係はなく、チーム内での仕事の進め方は、チーム内のメンバー間で決める

この3つの役割を合わせて、スクラムチームとなる。

スクラムを用いたアジャイル開発

開発が必要となりスクラムチームが組まれてから、開発が終了するまでの流れをもう少し詳しく見てみる。

開発時に必要な事前準備について

要件とゴールの確認

まずは全員で集まって、プロダクトオーナーから「何を作るのか」、「作ることで達成したいことは何か」の説明を受ける。

作業を洗いだしてリストを作成

プロダクトが完成するまでに必要な工程(要件定義、実装、テスト、公開など)すべてを洗い出し、ひとつのリストにまとめる。これをプロダクトバックログと呼ぶ。スクラムの考え方を用いてプロダクトを作成するメンバーは、基本的にはこのプロダクトバックログの中から作業を分担し、遂行していく。開発全体のToDoリストと捉える。

開発開始から終了までのサイクル

ゴールやミッションを確認し、やるべきことを一通り洗い出したら、スプリント単位で期間を区切り、開発を進める。スプリントで区切ることで、1期間あたりのチームの開発量が把握しやすくなり、計画が立てやすくなる。

スプリント計画ミーティングの実施

当該スプリントで開発する内容を、プロダクトバックログから選別する。選別してきた作業は、具体的なタスクに分割し、スプリントバックログというリストにまとめる。当該スプリントでのToDoリストと捉えて問題ない。プロダクトバックログからスプリントバックログに移行した際は、以下の様にタスクの細分化をしてから取り掛かる。

タスク細分化の例

1 2 3 4 5 6 7

#プロダクトバックログ - Pictweetのツイート機能を作成する ↓ #スプリントバックログ - ツイート保存用のテーブルを作成する - 投稿の一覧画面の見た目を作成する - ツイートが保存されるまでの処理を書く..など

なお、各タスクには予め担当者を決めるということをしない。実際に作業をする時に、開発メンバーがスプリントバックログの項目を選択するようにする。

デイリースクラムの実施

毎日決まった場所で、15分間のミーティングを行う。夜間休日スタイルの方は、オンラインで実施しても良い。

スプリントレビューの実施

スプリント計画ミーティングで合意した、リリース判断可能なプロダクトになっているかどうかレビューを受ける。

スプリント振り返りの実施

スプリントレビューでの振り返りを行う。これをスプリントレトロスペクティブと言う。「スプリントのよかった点」「改善したい点」「次回のスプリントで挑戦すること」の3項目について話し合う。

開発に関わる人々は以下のような流れで進めていくことになる。以下は短期集中スタイルの例。

開発の終了の定義について

スプリントを繰り返して作業を進めて行き、プロダクトバックログの内容を全てクリアできたらプロダクトの完成。