家電メーカでのアジャイル開発

P社は、中堅の家電メーカである。従来、家電量販店を通した拡大戦略で事業を伸ばしてきたが、ここ数年の競争激化によって収益性が急速に悪化している。そこで、P社は、ビジネスモデルを、家電量販店を通した間接販売から、顧客となる消費者へ直接販売するインターネット販売へ転換する戦略を打ち出した。これを受けて、消費者向けのシステムの整備が急務となり、CDO（Chief Digital Officer）は、インターネット販売システム開発プロジェクト（以下、本プロジェクトという）を発足させた。

本プロジェクトの計画

1. 本プロジェクトの目的
   • インターネット販売は競合相手が多く、インターネット販売システムへの要求が満たされないと顧客は簡単に競合相手に移ってしまうので、P社として、顧客からの要求に対して、競合相手と比べてより迅速に対応できるようにする。
   • これまで一部のプロジェクトだけで用いていたスクラムによるアジャイル開発を採用し、今後同社での利用を拡大させていく端緒とする。
2. 本プロジェクトの方針
   • P社にはスクラムの経験者が少ない。そこで試行開発の段階を設けて、スクラム開発の理解を深め、スクラムの開発要員を育成し、プロセスを確立しながら本プロジェクトを遂行する。
   • 試行開発を経て、本格的なスクラム開発の人材を確保し、顧客からの要求に迅速に対応できるようにする。
3. 本プロジェクトのスコープ
   • インターネット販売システムは、Webストア、モバイルアプリケーションソフトウェア（以下、モバイルアプリという）及びSNSの三つのサブシステムから構成される。Webストアから開発に着手することにして、これを試行開発と位置づける。
   • Webストアのプロダクトバックログアイテムのうち、本プロジェクトの開始時点で洗い出した要件をユーザストーリの形式で記述して、開発の規模、難易度、複雑さなどによる開発作業の量（以下、サイズという）と優先順位で分類し、ストーリポイントを算出した。Webストアのユーザストーリ数と、サイズごとのストーリポイントの合計を表1に示す。

   表1　Webストアのユーザストーリ数とサイズごとのストーリポイントの合計

   サイズ	ユーザストーリ数				ストーリポイント合計
   	優先順位A	優先順位B	優先順位C	合計
   小	9	0	4	13	26
   中	7	0	4	11	33
   大	2	1	5	8	40
   合計	18	1	13	32	99

   注1) ユーザストーリをサイズに応じて小、中、大の三つに分類する。
   注2) 優先順位は高い順にA、B、Cで表す。プロダクトバックログアイテムをスプリントバックログに割り当てるときに、この優先順位を尊守するものとする。
   注3) ユーザストーリには、サイズに応じて小に2、中に3、大に5のポイント（以下、ptという）を付与して、これをストーリポイントとする。
4. 本プロジェクトの体制

   本プロジェクトの体制を表2に示す。

   表2　本プロジェクトの体制

   チーム	役割	役割の説明	担当者名	担当者の開発経験	所属・職位
   スクラムチーム	プロダクトオーナー	a	R氏	システム開発プロジェクトの経験はあるが、アジャイル開発プロジェクトは初めてである。	営業部門・課長
   	スクラムマスタ	スクラムの実施方法を計画・助言する。 必要に応じてプロジェクトの関係者とのコラボレーションを促進する。	S氏	システム開発プロジェクトの経験は豊富で、スクラムによるアジャイル開発プロジェクトを多く経験している。	情報システム部門・主任
   	開発チーム	スプリントの計画を作成する。 実際の開発作業に携わる。	（略）	情報システム部門と営業部門の混成で、専任8名をアサインする。8名のうち、3名はスクラムによるアジャイル開発プロジェクトを多く経験している。	情報システム部門及び営業部門・スタッフ
   ユーザチーム	ユーザチーム代表	顧客からの要求を調査・調整するユーザチームの代表	T氏	アジャイル開発プロジェクトに参加した経験はない。 競合相手の状況や顧客の要求などを把握している。	マーケティング部門・課長
   	（以下、省略）

①開発チームは、まずは全メンバでWebストアの開発チームを編成し、Webストアの開発の完了後に、モバイルアプリの開発チームとSNSの開発チームを編成することとする。

本プロジェクトの実行と管理

スクラムチームは、本プロジェクトを次のように進めることになった。

1. スケジュールとその管理方法
   • 競合相手のWebストアは、1年に1～2回程度のリリースであるのに対して、P社のWebストアは、②リリースのサイクルを3か月に1回とした。
   • Webストアのリリースは、リリース1とリリース2から成る。プロダクトバックログアイテムは優先順位によって次の計画でリリースする。
     • 優先順位A･･･リリース1
     • 優先順位B･･･リリース1　ただし、今後の進捗状況でリリース2でも可
     • 優先順位C･･･リリース2
   • リリース内では一連のスプリントを繰り返し実施し、各スプリントはS-01、S-02というように連番を付けて表す。
   • スプリントは2週間を1単位とする。
   • 本プロジェクトの進捗状況が計画からどのくらい離れているのかを管理するために、横軸に時間、縦軸にストーリポイントを割り当てて、残りのストーリポイントを折れ線グラフで示すbを用いることにした。
2. スプリントバックログの対応実績

   Webストアのスプリントバックログ対応実績集計表（S-04終了時点）を表3に示す。

   表3　Webストアのスプリントバックログ対応実績集計表（S-04終了時点）

   サイズ	リリース1							リリース2 S-07～S-12
   	S-01	S-02	S-03	S-04	S-05	S-06	合計
   小	A2個			A2個			4個
   	4pt			4pt			8pt
   中	A2個	A1個	A3個				6個
   	6pt	3pt	9pt				18pt
   大		A1個		A1個			2個
   		5pt		5pt			10pt
   合計	4個	2個	3個	3個			12個
   	10pt	8pt	9pt	9pt			36pt

   注記1　サイズ別の各スプリントバックログの上段は、優先順位別のユーザストーリ数を表す。下段は、ユーザストーリのptを表す。合計行は終了したスプリントのユーザストーリ数及びptの合計を表す。
   注記2　サイズ、優先順位、ptの意味は表1の注を参照すること。
3. プロダクトバックログアイテムの追加依頼

   S-04の途中で、T氏とR氏の間で次の会話が交わされていた。

T氏： 重要な新規要件を優先順位Aとして追加することがビジネス上必須となった。

R氏： その要件が重要なことは理解したが、サイズ大のプロダクトバックログアイテム1個を新規追加することになるので、リリース1でリリースする計画のプロダクトバックログアイテムを見直すことになる。

T氏： アジャイル開発なので、要件の柔軟な追加や変更ができると思っていた。新規追加のプロダクトバックログアイテムは優先順位Aなので、これは必ずリリース1に入れてほしい。その上で、アジャイルの作業生産性は高いはずだから、計画したプロダクトバックログアイテムも全てリリース1に入れられるのではないか。

R氏： 依頼については理解したが、リリース1でリリースするプロダクトバックログアイテムの見直しは不可避だ。

T氏： 納得できないので、別途調整させてほしい。別件だが、機能的に重複するところがある類似の要件を、今後数件追加させてもらう可能性が高い。

R氏： 了解した。その件については、プログラムの外部から見た動作を変えずにソースコードの内部構造を整理するcを実施することで、今後の拡張性・柔軟性を高めたいと思う。

プロセスの確立と実施

1. S-04終了時のレトロスペクティブ
   • 開発チームは、人、関係、プロセス及びツールの観点からS-04のレトロスペクティブを実施し、うまくいった項目とうまくいかなかった項目を特定・整理した。
   • 開発チームは、S氏の助言を得て、③R氏とT氏との今回のプロダクトバックログアイテムの追加依頼の会話を踏まえて、関係者間でのプロセスの確立について検討することにした。
   • R氏は、S氏の支援のもと、アジャイル開発は作業生産性の向上を目的とするものではないことをT氏に認識してもらうことにした。
2. S-05開始時のスプリントプランニング
   • S-05、S-06及びリリース2のベロシティとして、S-01～S-04の各スプリントで測定したベロシティの平均値を用いる。
   • R氏は、確立したプロセスに則って調整した結果、リリース1については、T氏依頼のプロダクトバックログアイテム1個を新規追加した上で、優先順位Aのプロダクトバックログアイテムのリリース日を守り、リリース2については、残りの全てのプロダクトバックログアイテムをリリース日までに完了することでT氏と合意した。このとき、リリース2で対応予定のストーリポイントはdptとなり、ベロシティ上の問題はない。