スクラムにおける前提知識と業務分析＆設計（前編）

アジャイル開発センターです。

システム開発において業務分析と設計は必須であり、これはウォーターフォール開発でもアジャイル開発でも同じです。しかし、ウォーターフォール開発は最初に全ての業務を分析・設計した後に開発するというフローですが、アジャイル開発は、ある程度のまとまりのある業務に分割して分析と設計・開発を繰り返して進めます。

このアジャイル開発における業務分析と設計は、どのように進めるとよいのでしょうか。
前回の記事「アジャイル開発に必要な3つのファクター」にてお届けした3つのファクターのうち、業務分析について、代表的なフレームワークであるスクラムをベースにお届けします。
スクラムを採用した場合に前提となる知識についても、合わせてお届けします。

まずはスクラムガイドを読もう

アジャイル開発を実行する手法は様々ありますが、その中でも代表的なフレームワークがスクラムというものです。スクラムでアジャイル開発を遂行しているプロジェクト数が多く、情報量も多いためアジャイル開発に取り組むにあたってスクラムを採用すると、進め方や疑問への回答を参照しやすくなります。

また、スクラムガイドというハンドブックがあるので、まずはスクラムガイドを読み込んでスクラムについての知識を集めるとよいでしょう。

参考：2020年11月版のスクラムガイド

アジャイル開発における業務分析

ウォーターフォールでは、要件定義・基本設計・機能設計・詳細設計・実装・テスト・リリースの順に工程が進みます。このうち業務分析に関わる工程は主に要件定義・基本設計・機能設計で、完成予定となるシステムの全ての業務分析を行うことを目的とし、各工程に応じた分析とその結果に基づいた設計がその工程の成果になります。

一方、アジャイル開発におけるフレームワークの1つであるスクラムでは、開発サイクルの単位であるSprint^※を基準として作業を進めます。

※ Sprint：
一定量の作業を完了させる際の短く区切られた期間のことであり、開発サイクルの単位となるもの。
期間は1か月以内で設定する必要があり、1～2週間で設定されることが多い。スクラムチームは各Sprintでプロダクトバックログ・スプリントバックログ・インクリメントを作成する。
各Sprintにおいて、スプリントプランニング・デイリースクラム・スプリントレビュー・スプリントレトロスペクティブという4つのイベントすべてを行う。

ウォーターフォールにおいては、システムの全ての業務を詳細化して業務分析を行います。しかし、スクラムでは一度に全ての業務分析を行うのではなく、Sprint毎にある程度のかたまりに分割した業務に対し、分析と設計を繰り返して開発を進めます。

ここではスクラムを大きく3つのフェーズに分け、Sprintを始める前を「Sprint 0」、最初のSprintを「Sprint 1」、2回目以降のSprintを「Sprint N」として、各フェーズで行う業務分析と設計について述べます。

Sprint 0で行う設計

プロジェクトを開始したらすぐにSprint 1を始めたいところですが、プロジェクト開始直後はSprint 1を始めるのに必要な準備ができていません。そのため、Sprint 0ではSprint 1を始めるのに必要な準備を行います。

システムで提供する価値の決定

Sprint 0では、このプロジェクトは何を目指してどのようなシステムを作るのかの共通理解を築き、要件定義や基本設計に相当する設計を行います。そして共通理解を基に業務分析を行い、システムで提供する価値を決めます。
システムを提供することそのものも価値として決定することもありますが、システムを提供することで何を生み出すか、生み出したことにより得られる価値は何なのか、ということを重点にシステムで提供する価値を決めていきます。

共通理解の共有

プロジェクトやシステムに関する共通理解を共有するには、システムの説明資料のみではメンバー全員が共有できない場合があります。

プロジェクトやシステムに関する共通理解を築くための1つの方法として、インセプションデッキがあります。インセプションデッキとは10個の質問に答える形の資料で、プロジェクトやシステムに関することをチームで共有・検討するためのものです。インセプションデッキを作ることで、チームがプロジェクトやシステムに関する共通理解を持つことができます。

インセプションデッキの10個の質問

インセプションデッキの質問	質問の意図
我われはなぜここにいるのか	何のためにプロジェクトが発足してチームを組んでいるのか、プロジェクトのミッションやビジョンを共有する
エレベーターピッチ	システムが誰向けでどのような価値や特長を持つのか共有する
パッケージデザイン	システムの完成イメージを文字だけでなく視覚的に共有する
やらないことリスト	システムで実現しないこと（スコープ外のこと）を共有する
「ご近所さん」を探せ	プロジェクトに関わる人物を共有する
技術的な解決策	技術的に必要となることを検討する
夜も眠れない問題	リスクの洗い出しと対策を検討する
期間を見極める	期限を確約するためではなく、目標とするスケジュールを検討する
トレードオフスライダー	スコープ、予算、期間、品質などの優先順位を検討する
何がどれだけ必要か	予算、期間、要員などがどれだけ必要か検討する

プロダクトバックログの作成

次にプロダクトバックログ^※を作ります。

※ スクラムで作成するものの1つであり、システムで提供する価値が列挙され、それが価値の高い順に並べ替えられているリストのこと。

インセプションデッキによってチームで共有した共通理解を前提として、業務分析を行っていきます。業務分析の結果、必要であろうと判断された価値はインセプションデッキと照らし合わせて適合するようにPBI^※としてプロダクトバックログに入れます。列挙したPBIについて、どのPBIがより高い価値を提供できるかで並び替えをします。

※ PBI：
プロダクトバックログアイテム（Product Backlog Item）の頭文字を取ったもの。
プロダクトバックログに追加された1つ1つの項目のこと。

1Sprintの期間をどの程度にするか、ということもこのタイミングで決めておくとよいでしょう。次に決めるMVP^※にも関係してきますが、ここで気をつけるべき点は、1Sprint内で提供する価値を多くしたいからSprintの期間を長くする、という決定は行わないことです。Sprint期間を短く取る理由は、計画の精度が高くなる・価値を出せない結果となっても（＝失敗しても）取り返しがしやすい・改善がしやすい、といったメリットがあるためです。

※ MVP：
Minimum Viable Productの頭文字をとったもの。
実用できる最小限の機能を持った製品のこと。
MVPを満たしていれば、実際に使用することで提供した価値が本当に価値として実現できているか検証することが可能となる。

このメリットを捨ててまで、多くの価値を提供したいからとSprint期間を長く取ってしまうと、スクラムの良さ（≒アジャイル開発の良さ）がなくなってしまいます。

MVPの決定

プロダクトバックログを作成したら、次にMVPを決めます。MVPが最小限の機能を持った製品であるとはいえ実用できるものではあるので、初回にリリースするシステムとしての目安となります。実際にはビジネス上の理由から、初回リリースの時期や初回リリースでシステムが提供する価値は調整が必要ですが、少なくともMVPを下回る場合は実用できないのでリリースはできません。実際にMVPを決める際にはプロダクトバックログの先頭から、実用できるために必要なPBIを複数個選択します。

前編のおわりに

スクラムを大きく3つのフェーズに分け、前編ではプロジェクト開始前までのフェーズで行う業務分析と設計についてお届けしました。プロジェクトを開始する前に準備する内容は、ウォーターフォールとアジャイルで異なることが分かると思います。

アジャイル開発センターでも、上記に記載したSprint 0に従って対応を取りました。
PBIを追加しながらプロダクトバックログを作成し、MVPを決定し、Sprintをいくつか進めていきました。
しかし、いつまでたってもPBIが完了とならず、誰が何をどこまで完了していて、今現在提供できる価値は何なのか、が報告を聞いているだけでは判断をつけづらい状況になっていました。

原因は何か、を確認したところ、PBIを定義したメンバーがウォーターフォールに慣れ過ぎてしまっていたのか、各PBIの品質基準を高く設定しており、PBIが完了したと判断するための観点が多かったためでした。つまり、Sprint 0で定義したPBIの段階であれも、これも、それも、全て提供して完成、としていたためです。
いくつかのSprintを経過してしまいましたが、この失敗したという経験は以降のSprintで活かせる価値でもある、ということも気づかせてくれました。

後編では、Sprint 1以降で行っていく内容についてお届けします。