コラム

ここまで、SIビジネスを取り巻く課題を整理してきた(Part1、Part2)。今回は、従量課金やサブスクリプション型のビジネスモデルと親和性の高いアジャイル開発について整理する。

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

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

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

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

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

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

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

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

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

では、プロダククトオーナーはどのように評価するのだろうか。受入れ試験をすればいいのだろうか？

プロダクトオーナーの頭の中に、その答えはない。

あると思っているかもしれないが、それはあくまで仮説にすぎない。

本当の答えを知っているのは利用者やお客様だ。

だからプロダクトオーナーは、スプリントの成果物を毎回速やかに公開し、実際にお客様に使ってもらって評価を得る必要がある。プロダクトオーナーはお客様の評価の中継役になるのだ。

こうした評価のことは、アジャイル開発やスクラム開発について調べても出てこない。

「リーンスタートアップ」や「リーン開発」として整理されている。

小さく作ってお客様と育てる

しかし、最終的なシステムが完成していないのにお客様は評価できるのだろうか。

確かに、最終的か完成形を想像してそれを分割していくだけでは、評価できないだろう。お客様の評価を得るには、評価してもらう成果物それ自身で価値があるように切り出す必要がある。これを「MVP：Minimum Viable Product」と呼ぶ。

次の図は、マーケティングやサービス開発界隈で良く紹介されるものだ。スウェーデンのコンサルティング会社であるCrisp社がブログ記事より引用した1。日本語版をANKR DESIGNが公開している2。

図の上は、最終的な完成形である自動車を分解して、最初にタイヤだけを提供しているが、これではお客様は評価できない。だから、お客様の顔がしかめっ面になっている。お客様が笑顔になるのは完成形の自動車を得られたときだ。それまでは、ずっとしかめ面だ。

でも図の下のように、自動車から余分な機能を削りに削って、移動のための最小限の機能を持ったスケートボードとして提供すれば、お客様は移動する楽しみを味わうことができる。お客様の顔は少しづつ笑顔になっている。

こうした最小限の製品とファンを一緒に育てていくことが、サービス開発とビジネス開発を同時に進めることになるのだ。

従量課金やサブスクリプション型のSIビジネスを進めていくとき、システムを発注するお客様にこうしたナレッジを伝えていくことも大事なのではないだろうか。

参考

• Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable – Crisp’s Blog
• MVP（Minimum Viable Product）の意味を理解する。そして、なぜ私はEarliest Testable / Usable / Lovableを好むのか。 | ANKR DESIGN