反復的な開発工程により変化に柔軟な対応ができるアジャイル開発。その中でも多くのプロジェクトで取り入れられている『スクラム』は、チームメンバーの役割分担や『顧客が本当に求めているもの』へのアプローチついて独自の方式を採用しています。
今回はアジャイル開発とスクラム開発について、既存のウォーターフォール開発との違いなどを踏まえながら解説していきます。
1. アジャイル開発とスクラム開発の違いとは？
従来、ソフトウェア開発方式の主流はウォーターフォール開発でした。しかしウォーターフォール開発は『最初に要件定義を厳格に固める』という性質のため、クライアントの柔軟な仕様変更に対応できないことに難を抱えます。
そこで米国で主流になっているのが、短期間で実現できることを見積もって期間を細かく区切ることにより、速やかなリリースを実現するアジャイル開発です。
アジャイル開発に分類される開発手法は複数ありますが、中でも多くのプロジェクトで採用されている「スクラム開発」はチームのコミュニケーションを重視することで、組織的なプロジェクト管理の課題に対応できるという特徴があります。
1.1 アジャイル開発とは
アジャイルは『個人との対話』『動くソフトウェア』『顧客との協調』『変化への柔軟な対応』に重点を置く一連のソフトウェア開発手法を示す用語です。
アジャイルに属する開発手法は『スプリント』と呼ばれる1～4週間の開発プロセスを反復しながらリリースを繰り返すことを特徴としており、『メンバー間のコラボレーション』『変化への柔軟な対応』を重視する傾向にあります。
参照元：Manifesto for Agile Software Development
1.1.1 アジャイル開発はウォーターフォール開発の欠点を解消するべく生まれた
アジャイルが導入されるまでソフトウェア開発の主流とされていた『ウォーターフォール開発』では、開発工程を要求・設計・実装・テスト・運用などのフェーズに分割し、より上流のフェーズから下流のフェーズへと直線的に工程を進めていきます。
しかしこの方式には『開発中の仕様変更に柔軟に対応できない』という問題を抱えていました。工程が直線的に進む開発方式であるがゆえに、仕様変更が生じたときの『工程の後戻り』に対応できないためです。
この課題に対応するべく生まれたのがアジャイル開発です。開発工程を反復して進めるアジャイル開発は、変化を『起こるべきではない否定的なもの』『想定外のもの』として捉えるのをやめて、日常的な現実として柔軟にプロダクトへと反映させることができます。
1.2 スクラム開発とは
スクラム開発はアジャイル開発の一手法として生まれ、アジャイル開発の自由さを守りつつも『プロダクトオーナー』『スクラムマスター』『開発メンバー』という役割分担を決め『チームとしての仕事の進め方』に特化した開発方式です。
1.2.1 スクラム開発はアジャイル開発の手法の1つ
出典：Agile Methodology: A Beginner's Guide To Agile Method and Scrum
アジャイルは開発スタイルの総称であり、アジャイルという開発スタイルの中に『スクラム』をはじめとする様々な手法があります。スクラム以外で代表的なアジャイル開発手法には以下のようなものがあります。
◆ リーン
無駄を『価値の対極的なもの』と捉え、最小化することで顧客価値の最大化を目指す手法。トヨタ生産方式をもとに生み出された。
◆ かんばん
『作業の視覚化』により生産性を最大化する手法。ホワイトボードやWebボードに付箋やラベルを貼り付けていことで、『コラボレーションの活性化』『プロジェクトの状況把握』などを組織にもたらす。
◆ XP（エクストリームプログラミング）
『コミュニケーション』『シンプルさ』『フィードバック』『尊重』『勇気』を重視する開発手法で、テスト駆動開発などを取り入れることによる短期開発と変化への対応を実現した。
1.2.2 スクラム開発の主要な要素
スクラム開発はアジャイル開発の自由さを守りつつ『プロジェクトの状況や進め方に問題がないか、メンバー同士で毎日確認しあう』『作っている機能が正しいかどうか、定期的に確認の場を設ける』といったチームとしてのコミュニケーションを重視しています。これはメンバーがその日こなすべき仕事を認識し、課題解決のために互いが助け合うためです。
また顧客の要望を優先度で順位付けした『プロダクトバックログ』を作成し、それを共有することで、仕様変更が要求の追加が生じたとき、何を優先してリリースしていくべきかの判断をすみやかに行うこともスクラムの特徴です。
特にスクラムで作成されるプロダクトバックログは『ユーザーストーリー』と呼ばれる形式のものである場合が多いです。ユーザーストーリー形式のプロダクトバックログは、ユーザ目線の自然な言葉でソフトウェアの機能を説明します。これにより開発メンバーが自分たちが実現しようとしているものについて明確なイメージを共有することができ、チームでのスムーズな開発を実現します。
2. アジャイル開発・スクラム開発とウォーターフォール開発の違い
アジャイル・スクラム開発は、顧客へ迅速に高品質のプロダクトを届けるために、従来のウォーターフォール開発とは異なる複数のアプローチを採用しています。そういったアジャイル・スクラム開発ならではの特徴を、以下でウォーターフォール開発と比較しながら紹介していきます。
2.1 優先順位の高い機能から開発
アジャイル・スクラム開発ではプロダクトへの要望を優先順位ごとに並べかえ、その順に機能を作ります。この方式を採用すると、顧客にとってもっとも必要な機能を最短で提供でき、ユーザーにもいち早くサービスが届きます。
2.2 工数見積もりが正確
アジャイルやスクラムでは機能を細かく区切って機能ごとにリリースしていくため、作業の工数見積もりが小規模な分、巨大なスケジュールのズレや認識誤りの発生を抑えることができます。
一方、ウォーターフォール開発は仕様変更や開発チームのトラブルなどが存在しない前提であれば、工数見積もりが正確です。しかし長期にわたる開発では、一番最初の段階で数ヶ月・数年先の見積もりをするのは難しく、ズレや認識間違いが生じるケースも多いです。
2.3 開発メンバーの責任感が強くなる
アジャイル・スクラム開発では、短く区切った期間内での工数見積もりを各開発メンバーが自律的に行います。そのため個々人の開発メンバーが自分たちのミッションを明確に自認することで、協調性の優れた連帯感をチーム全体で共有できます。
しかしウォーターフォール開発ではひとつのプロジェクトが長期間に渡るため、工数見積もりの担当者と実際に設計や開発、テストを行う担当者が別であるケースも多いです。そのため制作するプロダクトについて高レベルの責任感を維持・共有するのが難しいという課題があります。
2.4 PDCAサイクルを高速で回せる
アジャイル・スクラム開発では、デイリーミーティングで不明点や開発のボトルネックをすり合わせることで、素早い軌道修正・開発方針の見直しが可能です。その結果、チーム全体でPDCAサイクルの回転数を上げていくことができます。
一方でウォーターフォール開発では開発工程を反復しないので、同じ案件に取り組んでいる間のPDCAサイクルは機能しません。
2.5 問題発生時の修正が素早くできる
ウォーターフォール開発では最初に定義した要件に沿って厳格に開発を行うため、仕様変更が発生すると手戻りが大きいという難点を抱えています。しかしアジャイルやスクラムでは細分化した機能ごとに開発を行うため、手戻りがウォーターフォールより小さいです。
3. スクラム開発におけるチームメンバーの主な役割
スクラム開発では、チームが高度な連携を取れるよう『プロダクトオーナー』『スクラムマスター』『開発メンバー』の3つにメンバーの役割を分割しています。以下でこれらについてひとつずつ説明していきます。
参照元：Scrum Guide
3.1 プロダクトオーナー
プロダクトの方向性や優先順位について顧客と打ち合わせを行い、それらについてチーム全体へ共有する役割や、プロダクトの機能開発のゴールがどこなのかを定義するのがプロダクトオーナーです。
開発チームと顧客の間に立って、顧客に価値を提供するための管理・調整の役割に徹するため、プロダクトオーナー自身は開発を行いません。
3.2 スクラムマスター
スクラムのルールや進め方をプロダクトオーナーとの調整のもと決定し、それを開発メンバーに納得させる役割がスクラムマスターです。また、開発メンバーが前進するための障害を取り除いたり、プロダクトオーナーと開発メンバーの双方に働きかけ、チーム全体のプロダクトや開発方針についての共通理解を築く役割も担います。
3.3 開発メンバー
スクラムにおける『開発メンバー』はプロダクトの開発そのものを専門的に担う役割です。従来のアジャイル開発が開発メンバーの自主性に多くを依存するのに対し、スクラムでは管理体制があり、開発以外の細かな調整はスクラムマスターやプロダクトオーナーが行う方針を採用しています。
4. スクラム開発のスプリントの主な流れ
スクラムでは、スプリントと呼ばれる短期間の開発プロセスを繰り返しながらプロダクトの機能を順次リリースしていきます。スプリントの期間は『変化への柔軟な対応』『リスクの削減』のために、1ヶ月以内に収めて計画するのが通常です。
ひとつのスプリントは以下のフェーズを順に辿りながら進んでいきます。
- バックログ作成
- スプリントプランニングミーティング
- デイリースクラム
- スプリントレビュー
- スプリントレトロスペクティブ
以下でこれらについてひとつずつ紹介していきます。
4.1 バックログ作成
スプリントでは、まず製品で実現することを優先順位づけした『バックログ』と呼ばれるリストを作成します。バックログの作成にあたっては、ユーザ目線の自然な言葉でプロダクトの機能について説明します。難解な言葉や必要以上に詳細な定義書ではなく、誰にでも理解できる言葉で記すことで、メンバー全体が製品で実現することについての共通認識を持つことができます。
4.2 スプリントプランニングミーティング
スプリントプラニングミーティングは、作成したバックログに沿ってバックログごとに工数見積もりを行い、作業の分担やスケジュールの検討を行うイベントです。スケジュールの検討にあたっては、開発チームのキャパシティを確認し、潜在的なリスクがどれほどあるのかについても分析を行います。
4.3 デイリースクラム
スクラムでは、予定された開発のゴールへすみやかに到達できるよう、『デイリースクラム』と呼ばれる打ち合わせを毎日行います。およそ15分間のうちに『前回のデイリースクラムから行った作業』と『次の24時間の作業』についての確認を行うことで、開発チームのパフォーマンスを引き上げます。
4.4 スプリントレビュー
スプリントレビューは、スプリントの最後に行われるプロダクトオーナーによる製品のチェックのイベントです。開発したプロダクトの機能について、スプリントの最初のフェーズで作成したバックログとの確認を行い、顧客へ届ける価値を最大化・最適化するために次にできることが何かについてチームで話し合います。
4.5 スプリントレトロスペクティブ
スプリントレトロスペクティブは、スプリント最終日に『人』『関係』『プロセス』『ツール』の観点から行うスプリント全体の振り返りです。スプリントを通じて得たノウハウや課題、今後に行かせることをクリアにすることが目的です。
5. まとめ
プロダクトの開発工程を反復的なものとして捉え、細かな単位でのリリースを繰り返すアジャイル開発。アジャイル開発に分類される開発手法にはリーン開発やかんばんなど、様々なものがあります。
その中でも『スクラム開発』は、プロダクトがもたらす価値についての共通認識や、メンバーが一体となって価値向上を目指すことなどを重視する開発手法です。ユーザ目線でプロダクトの機能を表現した『バックログ』の利用や、明確な役割分担により、顧客が望むものを速やかにリリースできることが特徴です。
