先端技術ソリューション事業部 メディアソリューショングループ 金丸真之と申します。
今回、当社が取り組んでいる開発技法についてご紹介します。

アジャイル型開発技法

アジャイルとは『すばやい』『俊敏な』という意味で、反復 (イテレーション) と呼ばれる短い開発期間単位を採用することで、リスクを最小化しようとする開発手法の一つです。アジャイル型開発手法にはいろいろなバリエーションがありますが、例えば次のような進め方で開発をします。

上記の2から4のサイクルを繰り返して開発を進め、全体の完成度を高めていきます。

このような手法では次のようなメリットが得られます。

このような開発プロセスで、顧客の要件をすばやく反映しながらプロダクトを開発することを『アジャイル型開発技法』と呼びます。たくさんの詳細な仕様書を作るよりも実際に動く、顧客が実際に使えるプロダクトを作ることを重視し、変化にできるだけ柔軟に対応し、チームの協調と個人の活躍を動機付け、プロダクト価値の最大化を目指すことに特徴があります。

ウォーターフォール型開発とアジャイル型開発

ウォーターフォール型開発の基本的な考え方は、『区切られた全ての工程が正しい』という前提で進める方法です。この前提を守りながら進めるため、プロダクトはプロジェクト立ち上げ当初作成した要求仕様を忠実に実装し、その仕様を全て満たした時点で開発完了となります。
当初の要求仕様通りに進むという特徴から、契約時に契約内容、責任範囲が明確となるメリットがある一方、要求仕様作成時に要求ミス・漏れがあった場合や、開発途中で要求に変更があった場合、別途仕様変更として追加費用や開発期間が発生する可能性があるというデメリットがあります。

アジャイル型開発の場合は、このように工程分けされて進むのではなく、プロジェクトは変化するものと決め、イテレートと呼ばれる小さなサイクルを何度も回し、プロジェクトが生み出すプロダクトを最大化することを重要と考えます。そのため、当初計画された機能が100%完成することは困難です。その代わり、プロダクトがリリースされる時点で、顧客を含む全てのステークホルダーが『最大の価値がある』と思えるようなプロダクトが完成するのです。

ウォーターフォール型開発、アジャイル型開発のそれぞれの特徴を表したものを以下に示します。

スクラム

次に、当社が取り組んでいるアジャイル型開発手法の1つ、スクラムを用いた開発についてご紹介します。
『スクラム』開発の語源は、ラグビー等スポーツの『スクラム』から来ています。コラムを読んでる皆さんの中にも、ラグビーを思い浮かべた方も、きっと多いのではないでしょうか。

スクラムは、竹内弘高氏、野中郁二郎氏が1986年にハーバードビジネスレビュー誌にて発表した『The new new product development game (*1) 』という論文を元に、Jeff Sutherland氏らが1993年に考案、適用したアジャイル型開発手法の1つです。
この開発技法は、アジャイル型開発技法の中でもチーム一体となってプロジェクトを遂行して行くことに重点を置いている、という特徴があります。この開発技法の名前からも、顧客も巻き込んでスクラムを組んで進んでいく、という光景が目に浮かんできますね。

スクラムでは、チーム一体となって活動するために、以下の様なプロセスが定義されています。

デイリースクラムは、毎朝チームメンバーで集まり、15分など短い時間を区切り、昨日やったこと、今日やること、障害となっていることを一人一人報告・共有します。このミーティングにより、チーム全員の状況、障害や問題の共有、今日どこまで完了するかの宣言を行い、プロジェクト全体の見える化を行います。

リリースプランニングは、プロジェクト立ち上げ時に、どのようなプロダクトをどのような機能優先順で、どのくらいの期間で実施するかをチーム全員でプランニングします。万が一実態とのずれが大きくなってきた場合には、随時見直しを行います。プランニングを実施した結果は、『プロダクトバックログ』という名前の、機能優先順で並べた機能一覧により管理します。

スプリントプランニングは、ひとつのイテレーション期間（1～4週間程度）で、全体のプロダクトバックログの中からどの範囲の機能を実現するかをチーム全員でプランニングします。プランニングした結果は、『スプリントバックログ』という名前の、機能優先順で並べた機能一覧により管理します。チームが毎スプリント内でどのくらいのタスクを消化できるかは、毎回計測し、精度を高めて行きます。

スプリントは、実際のひとつのイテレーション期間の開発フェーズです。チームメンバーは、宣言通りにスプリント内で安定したプロダクトがリリースできるよう、最善を尽くします。基本的に、スプリント内の変更（機能の追加や変更、削除）は認められません。

スプリントレビューは、ひとつのイテレーション期間で完成したプロダクトを、ステークホルダを集めデモを行います。このフェーズでは、チームメンバー達の作ったプロダクトが安定して動くことをアピールすると共に、要求の伝達ミスや漏れがないことを必ずチェックし、チームメンバー全員が正しい方向を向いてイテレーション開発を進めているかを確認します。

ふりかえりは、基本的に毎スプリント終了時に行います。ふりかえりにはKPT法などが用いられます。今回のスプリントの良かったこと、問題点、挑戦したいことをメンバー全員で出し合い、次のスプリントでさらにチームメンバーが高い価値を生み出せるように、メンバー同士話し合いを行い、確認し合います。

上記のように、スクラムはフレームワークとしては非常に軽量なものです。しかし、スクラムには、『軽量』、『理解が容易』という特徴がある一方、『習得が困難』という特徴もあります。（この特徴はスクラムガイドに詳しく書かれています。(*2)）

このフレームワークを形式的に適用しただけでは、真のスクラムを行っているという状態にはならないのです。次回は、実際の当社の事例や、今回説明しなかったスクラムの役割等を含め、スクラムをどのように進めて行ったら良いかをお話しいたします。