言うまでもないことですが、ここ数十年の間にソフトウェアは大きく変化しました。その変化は今後も続くため、ソフトウェア開発プロセスも変わり続ける必要があります。

ただ、常に新しいソフトウェア開発プロセスを考えていくのも持続可能ではありません。ソフトウェア開発の進歩や変化に対応する柔軟性を備えた開発プロセスを創り出すのがベストでしょう。そうした場面で最適なのがアジャイルソフトウェア開発です。

アジャイルソフトウェア開発は、反復的で適応性に富んだソフトウェア開発アプローチです。この記事では、最も人気のアジャイルフレームワークの1つ、スクラムについて、スクラムとは何か、その意味とスクラムのメリットについて説明します。

スクラムとは？

スクラム方法論 (スクラムフレームワーク) とは、ソフトウェア開発のためのアジャイルフレームワークです。

具体的にはスクラムとはどのような仕組みでしょうか。

従来のソフトウェア開発プロセスは、まず計画を立て、開発を行い、テストを行うというように、直線的に進められてきました。一方、アジャイルソフトウェア開発では反復的なアプローチをとり、プロジェクトは「スプリント」と呼ばれる短い期間に分割されます (スプリントの期間は通常、2週間から1か月程度となります)。

スプリントのたびに、開発チームは段階的に最高の製品を提供することを目指して機能の追加や改善を行います。テストと開発を頻繁に、時に重複して進めていきます (アジャイルソフトウェア開発の詳しい内容はこちらの記事を読んでみましょう！)。

アジャイルにはさまざまなフレームワークがありますが、前述のスクラムもその一つです。

スクラムの手法は、チームワークとコラボレーションを重視している点が特徴で、「スクラム」という名称はそもそも、チームでの連携が必要なラグビーのスクラム(Scrum)から取られたものです。スプリントの期間中、スクラムチームは毎日ミーティングを行い、進捗状況を確認し、障壁を特定して対処し、プロジェクトを予定に沿って進めていきます (スクラムのミーティングの種類については後述します)。

スクラムの主な原則

スクラムのフレームワークは6つの基本原則に基づいて構築されており、日次のスプリントミーティングからスクラムの成果物に至るまで、スクラムのメソッドの各側面にこの原則が反映されています。その主要な基本原則は以下のようなものです。

1. 経験的プロセス制御 : 透明性、適応性と頻繁な評価に注力するスクラムのメソッドは、開発チームがプロセスの各段階で製品をテストし、改善するのに役立ちます。

2. 自己組織化 : スクラムのフレームワークを成功させるためには、チームメンバー一人ひとりがプロセスに完全に合意する必要があり、これには高いレベルの自立性と自己組織化が欠かせません。

3. コラボレーション : 最高の製品を提供するためには、ソフトウェア開発チームが協力し合う必要があり、チームは各サイクルを通して責任と説明責任を共有します。いわば、「成功も失敗も共に」という環境です。

4. 価値に基づく優先順位付け : スクラムの特徴の一つは、その柔軟性にあります。プロジェクトの新たな要求や要件に適応して対処するため、スクラムチームは達成すべき各タスクを常に評価し、優先順位を付け直します。

5. タイムボックスの使用 : スクラムの手法では、スプリントの各要素にタイムラインが明確に定義されています。スプリント自体の期間は2週間ですが、日次のミーティングにも時間が厳密に設定されています。

6. 反復的な開発 : スクラムはアジャイルフレームワークに属するため、製品は反復的に構築されます。これにより、常に改良を加え、柔軟に対応しながら最終的に高品質な製品を提供することができます。

スクラムチームの構成員

ここまで「スクラムチーム」という表現を使ってきましたが、これはある意味では単純に、スクラムフレームワークを使ってソフトウェア開発を行うチームを指します。ただ、もう少し踏み込んでその構成を見てみましょう。

一連のスプリントをスムーズに運営するために、スクラム方法論では、すべてのスクラムチームに配置すべきポジション (別名「スクラムロール」) として、プロダクトオーナー、開発チーム、スクラムマスターの3つを定めています。以下では、それぞれの役割とその担当範囲をご紹介します。

製品オーナー

最高の製品を提供するには開発チームが顧客のニーズや期待を敏感に察知する必要があり、そのためには、両者の間にオープンなコミュニケーションが欠かせません。これを達成する役割を果たすのがプロダクトオーナーです。

プロダクトオーナーは製品のあらゆる側面を知り尽くした人物として顧客と開発チームとの主要な接点となります。顧客の要件をアクションアイテムに変え、製品バックログの作成と管理を行います。

スクラムチームにはそれぞれ1人のプロダクトオーナーがおり、複数がこの役割を担当することはありません。

開発チーム

これは単純で、製品の開発を行う人たちを開発チームと呼びます。スクラムの開発チームは小規模で、設計者やコーダーなど、幅広いスキルセットが必要となります。

スクラムの基本原則にもあった「コラボレーション」が重要となる要素で、スクラム開発チームのメンバーは、ボトルネック回避のために他のチームメンバーに自分のもつスキルを教える必要があります。実際のコーディングを担当するのはこのチームとなるため、各バックログ項目に必要な時間やリソースの見積もり、割り当てにも責任を持ちます。

スクラムマスター

ここまででも多少触れてきましたが、スクラムフレームワークでは多数のミーティングを行います。こうしたミーティングのスケジュール設定、調整や進行を行うのがスクラムマスターです。

スクラムマスターはスクラムに関するあらゆる要素を担当し、チームがスクラム方法論を導入する方法、微調整や改善が必要な部分の有無、スプリントの経過と共にチームを改善する方法などを検討します。

また、スクラムミーティングの適切なスケジュール設定とスムーズな進行を確保する責任も負います。

スクラムにおける成果物

すでにスクラムの専門用語を多数取り上げてきましたが、もう一つ。スクラムでは、作業の管理や完了のための仕組み、またはツールを「成果物」と呼び、主に以下の4つが挙げられます。

製品バックログ

プロダクトオーナーが管理する製品バックログは、最終製品の要件をリスト化したものです。優先順位の変更に合わせ、プロダクトオーナーはバックログをシャッフルしたり、並べ替えたりします。各スプリントの開始時点でチームが製品バックログからそのスプリントで取り組むべきタスクをいくつか選びます。

スプリントバックログ

スプリントごとに製品バックログから選ばれたタスクはスプリントバックログに入れられ、このログは開発チームが管理し、チーム内でのみ使用します。こうしたタスクの整理は、一般に、各タスクの進捗状況と優先順位をビジュアルで追跡するスクラムボードで行います。ボード上でタスクをストア、ToDo、進行中、完了の列に分類し、完了したタスクはこれらの列に移動します。

ユーザーストーリー

ユーザーストーリーとは、バックログの項目を記述する方法です。製品バックログとは基本的に、最終製品に含めるべき機能をリスト化したもので、ユーザーストーリーはこれらの機能をエンドユーザーの視点から説明し、ユーザーがその機能を必要としている理由、実際にはどう見えるのかを検討するものです。

製品のインクリメント

各スプリントが終わる時点では、完了したタスクが山積みになっているはずです。これをまとめて製品のインクリメントと呼び、スプリント終了時の製品のバージョンのことを指します。

スクラムにおけるイベント

スクラムでのミーティングとその数の多さについては少し触れてきましたが、その内容について説明します。スクラムのフレームワークはいくつかの「イベント」を中心に構成されています。その中でも主要なものに以下のイベントがあります。

スプリント

スプリントとは、アジャイルソフトウェア開発のバックボーンであり、スクラムプロセスの要点とも言えるもので、通常2週間から4週間の期間で行われ、スクラムの組織単位となっています。作業はスプリントの枠内で計画し、スプリントに合わせてミーティングを行います。

スプリント計画の作成

慣れない土地で運転しなければならない場合、いきなり運転を始めても上手く行かないでしょう。まずは地図を見て、目的地までの最適なルートを確かめるはずです。

スクラムでも同様に、バックログタスクを適当に選んで一気にスプリントに突入することはなく、事前に綿密な計画を立てます。スプリント計画ミーティングはスプリント開始時に行いますが、数時間を費やすもので、スプリントに含まれる1週間につき2時間程度の時間を割り当てるとよいでしょう。このミーティングの場で、今回のスプリントで実現すべき内容や達成する方法などをできるだけ具体的に決めていきます。

日次のミーティング

日次のミーティング (デイリースクラム、スタンドアップミーティングとも呼ばれる) は、15分程度の短時間で時間を決めて毎朝行うミーティングで、開発チームが前日に達成した内容、今日取り組みたい予定などを話し合う場です。

スプリントレビュー

スクラム手法ではステークホルダー全員の間の透明性を保つことを重視しますが、スプリントレビューミーティングはこうした透明性の確保に役立ちます。各スプリントの終了時点に開催し、スクラムチームが他のステークホルダーに現在のイテレーションでの製品をプレゼンし、得られたフィードバックに基づいてプロダクトオーナーが製品バックログを精査します。

スプリントの振り返り

スプリントレビューミーティングにはステークホルダーが多数参加しますが、スプリントの振り返りはスクラムチームのみで行い、各スプリントの最後にチームメンバーが前のスプリントを反省するための機会となります。

スプリントの振り返りでは、チームメンバーに対し、うまく行った点、行かなかった点に加え、最も重要な次のスプリントで改善できる点などを質問していきます。

スクラムのメリット

ここまでで、スクラムの基本が理解できたことと思います。次にすべきことは、スクラム手法がチームにとって有益かどうかを判断することでしょう。

スクラムの大きなメリットに、アプローチが反復的な点があります。スクラムフレームワークを使うことで、チームは刻々と変化するソフトウェア開発の世界に適応し、スプリントを重ねながらよりよい製品を提供できるようになります。