よくわかるIT新発見　第10回　これからのシステム開発を「スクラム」で生き抜く

アジャイル開発とは「アジャイル開発マニフェスト（以下：マニフェスト）」に則った開発方法論の総称です。マニフェストは2001年に起稿され「お客様にとって価値のあるシステムを届ける」ためのマインドが書かれています。膨大な工数を費やして構築したシステムの3分の2は使われない、という調査結果を目にしたことがある方も少なくないと思います。こういった無駄を省き、お客様にとって本当に価値あるものを届けるため、アジャイル開発を実現する具体的な手法として、プロセスフレームワークである「スクラム」や、プログラミングにおける有効なプラクティスを定めた「XP」を代表とする様々な手法が登場しました。

アジャイル開発を実現し、「お客様にとって価値のあるシステムを届ける」という目的を達成するための具体的な手法の一つがスクラムです。スクラムは、以下の特徴を備えた軽量なプロセスフレームワークで、米国ではアジャイル開発プロジェクトの7割以上で利用されています。

1. 軽量
2. 理解が容易
3. 習得は困難

開発と運用のギャップの主たる原因は、そのゴールが異なることです。そのゴールを設定しているのは、組織です。本来であれば、「新しいビジネスが収益をあげ続けること」が共通のゴールとなりますが、組織により役割が分断され、それに付随してゴールが分断されるため、ギャップが生じています。そのため、共通のゴールを目指すよう改善する必要があります。また、開発プロセスや開発プラクティスも、例えばアジャイル開発のようなより変化に強い方法を採用することが求められます。

ウォーターフォールによる大規模なシステム構築では、数年先までの未来を予測し計画することが必要です。そして要件定義からテストまでを計画通りに実施します。スクラムでは、「スプリント」と呼ばれる1週間から1か月程度の短い区間を区切り、その中で要件定義からテストまでの一連のプロセスを繰り返します。

ウォーターフォールでは開発期間が完了した時に初めて動くソフトウェアが完成するのに対して、スクラムでは動くソフトウェアがスプリントごとに完成することになります。このようにスクラムでは、実際に動作するソフトウェアを開発し市場の反応を計測しながら開発を進めます。ウォーターフォールが予見的プロセスであるのに対し、スクラムは経験的なプロセスであると言われています。ウォーターフォールは「開発を失敗させないためのプロセス」であり、大規模開発に向いています。また、スクラムは「ビジネスを成功させるためのプロセス」であり、スピードと柔軟さを求められる中小規模の開発に向いています。

前述の通り、スクラムは「軽量」、「理解が容易」、「習得は困難」なフレームワークです。では実際にスクラム開発を実践し、市場の変化に対応できるシステム開発を進めるにあたり何が重要でしょうか。CTCでは以下の3点が重要だと考えています。

1. プロセス
2. エンジニアリング
3. マインド

スクラムは軽量なフレームワークであり、スクラムの定義が掲載されたスクラムガイドに定められている内容は多くありません。スクラムのフレームワークでは以下の3つの要素が定義されています。

• イベント
• 成果物
• ロール

イベントでは、スプリント、スプリントの中で行われる計画やレビュー、振り返りなどが定義され、成果物では、全ての要求を順序付けしたプロダクトバックログや、今回のスプリントで対象とする要求を抜き出したスプリントバックログが定義されています。また、ロールでは、プロダクトに必要な機能を定義し順序付けするプロダクトオーナーや開発を行う開発チーム、スクラム開発を行う上でのファシリテーターとなるスクラムマスターが定義されています。

スクラムのトレーニングを受けても、トレーニング通りの内容を実践するだけでは、トレーニング結果を効果的に活かせません。重要なことはプロセスをそのままなぞることではないからです。従来のウォーターフォールではプロセスをなぞることにより品質の均一化を図ってきました。これに対しスクラムでは開発に携わるメンバーがプロセスをなぞるだけではなく、「なぜこのプロセスが必要なのか」を考え理解していくことが重要になります。

プロセスを理解し実践しても、そのままでは絵に描いた餅です。例として、スクラムでは実際に動作するソフトウェアを短い期間で開発し続けていきます。このためテスト工数は大きくなり、手動によるテストはいつか限界を迎えます。このような問題に対処するためにも、テストの自動化をはじめとするエンジニアリング観点のアプローチがスクラムの実践には必要となります。

スクラムの考え方の本質には「カイゼン（改善）」があります。スクラムではスプリントの最後に振り返りを実施し、どうすれば次回のスプリントでより良く出来るのかを考えていくことになります。一人ひとりが責任あるチームメンバーとして仕事に取組むマインドを持ち、「どうすればもっとうまく出来るか」を意識することが重要となります。

アジャイル、そしてスクラムは開発における万能薬ではありません。スクラムを導入したことで、問題が減るわけではありません。しかし問題を共有し、チーム一丸となって改善に取り組むことは可能になります。本コラムで紹介したポイントが、スクラムを実践する際の一助となれば幸いです。

CTCではアジャイル、特にスクラムへの取り組みを開始しており、今回はアジャイルおよびスクラムについて紹介しました。次回は、アジャイルとも関連の深いソフトウェア開発手法の一つであるDevOpsを実践するためのツールについて紹介します。