従量課金やサブスクリプション型のビジネスモデルは注目を集めるアジャイル開発と親和性が高い。そこで、アジャイル開発について整理する。

ウォーターフォール開発とアジャイル開発

　従来のシステム開発で主流だった、ウォーターフォール型の開発プロセスは、事前に仕様を確定できるシステム開発プロジェクトで有効だ。既存の業務をシステム化する場合などに用いられてきた。しかし、お客様や市場の反応を見ながら柔軟に内容を変えていくようなサービスでは不都合が多くなる。

　そこで、スピーディーな開発を繰り返して市場が求めるシステムを突き詰めていくアジャイル開発が注目を集めている。アジャイル開発は、厳密には開発手法ではなく、考え方や枠組みを提供するものだ。その考え方に沿った開発手法として「スクラム」「エクストリームプログラミング」「リーンスタートアップ」「ドメイン駆動設計」などがある。

スクラム開発で重要な役割を果たすプロダクトオーナー

　では、アジャイル開発の一つであるスクラム開発について解説する。これはチームワークを重視する開発手法だ。ユーザーへの価値を示すプロダクトバックログと作業計画のスプリントバックログを定義して、短い期間で開発サイクルを回してシステムを改善していく。

　スクラム開発では、スクラムチームと呼ぶ小さなチームを作る。ここで大きな役割を果たすのが「プロダクトオーナー」だ。プロダクトオーナーは、システム化の対象について深く理解している人間が担当する。多くの場合、発注側が担当することになるだろう。つまり、発注側もスクラムチームの一員なのだ。プロダクトオーナーは、実際の開発作業は行わないが、状況変化にあわせてプロダクトバックログを更新していく。
 

ミニウォーターフォールになってしまう原因は？

　しかし、こうしたスクラム開発が小さな開発を繰り返すだけのミニウォーターフォールになることが少なくない。事前に作っておいた機能仕様書を細かく分解して、プロダクトバックログに振り分けるためだ。状況変化に合わせてプロダクトバックログを更新しなければ、順番に機能を作っていくことになる。

　スクラムチームは、スプリントという短い開発サイクルで毎回何らかの評価できる成果物を提供する。プロダクトオーナーは、これを毎回評価して、機能不足や変更があればプロダクトバックログに反映する。

　では、プロダククトオーナーはどのように評価するのだろうか。答えはプロダクトオーナーの頭の中にはない。本当の答えを知っているのは顧客となる。プロダクトオーナーは、スプリントの成果物を毎回速やかに公開し、実際に顧客に使ってもらって評価を得る。顧客との中継役というわけだ。

　なお、この評価はアジャイル開発やスクラム開発について調べても出てこない。「リーンスタートアップ」や「リーン開発」として整理されている。
 

小さく作って顧客と育てる

　ただ、最終的なシステムが完成していないのに顧客は評価できるのかという課題が残る。最終的か完成形を想像してそれを分割していくだけでは、評価できないだろう。そのため、顧客の評価を得るには評価してもらう成果物自体に価値があるように切り出す必要がある。これを「MVP（Minimum Viable Product）」という。

　例えば、最終的な完成形である自動車を分解して、最初にタイヤだけを提供しても顧客は評価できない。ところが、自動車から余分な機能を削って、移動のための最小限の機能を持ったスケートボードとして提供すれば、顧客は移動する楽しみを味わうことができる。こうした最小限の製品とファンを一緒に育てていくことが、サービス開発とビジネス開発を同時に進めることになる。従量課金やサブスクリプション型のSIビジネスを進めていく時、システムを発注する顧客にこうしたナレッジを伝えていくことも大事ということだ。