アジャイル開発

アジャイルとMVPに違いはほぼない

  • このエントリーをはてなブックマークに追加

「アジャイル開発とMVPって別のものなの?」「アジャイル開発でMVPを取り入れるためにはどうしたら良いのだろうか」

こんなことに悩んではいないだろうか。

アジャイル開発もMVPも非常に似た概念であり、特に違いを意識する必要はない。両方とも、一気に完成系を作るのではなく、開発→リリースのサイクルを小さく回すことで仮説検証を行い不確実性を下げていくというコアな部分が同じ考え方だからだ。

そこで、この記事では以下の2点をメインに解説していく。

MVP=アジャイル開発と考えていい

MVPとは必要最小限度の製品のことだ。いきなり完成品を作るのではなく、小さく作って仮説検証を回していくための製品戦略の考え方と捉えることができる。

反対に、アジャイル開発とはソフトウェア開発の方法論のことであり、MVPを実現するための手段を提供している。

どっちも似ているが、MVPの方が広い概念であり、アジャイル開発はその実現方法のことだと考えるとわかりやすいだろう。

アジャイル開発でMVPに取り組む7ステップ

この章では、アジャイル開発でMVPに取り組む方法を紹介する。全体像は、以下の図の通りだ。

ユーザーストーリーを洗い出す

まずはユーザーストーリーを洗い出す必要がある。ユーザーストーリーとはこのシステムを通して、「誰が、なぜ、何をしたいか」を表した文章のリストだ。

詳しくは以下の記事を参考にしてほしい。
アジャイル開発のユーザーストーリーとは?作成する3ステップを解説

対応する機能を洗い出す

次に、各ユーザーストーリーに対応する機能を洗い出していく。これをユーザーストーリーマッピングという。

具体的には以下のようになる。

これによって、各ユーザーストーリーを実現するためにシステムが提供する必要がある機能が特定できる。

ユーザーストーリーの優先度をつける

次に、ユーザーストーリーの優先度をつける。

例えば、八百屋のECサイトを作る例で言えば、ユーザーがオンラインで欲しい野菜などの検索を行って、購入ができるというのは優先度が高い。

しかし、逆にそれ以外のものに関しては比較的優先度が低くなる可能性がある。例えば「一度購入してくれたお客さんに対してお店側が再来店を促すお知らせを送る」などだ。

対応する機能の優先度をつける

ユーザーストーリーの優先度をつけたら、今度は対応する機能についても優先度をつけていく。

この際に以下の順番で優先度が高くなる。(実際には2と3は一概に決めつけることはできないので、適宜状況に合わせて検討が必要になる)

「対応する機能の優先度が低い」ケースとしては、その機能が高機能すぎることが挙げられる。

例えば、八百屋のECサイトで言うと「ユーザーが特定の商品を定期購入できる」と言う機能などは一般的には高機能と言える。なぜなら、そもそもユーザーがECサイトで購入してくれることが検証できていないのに、ECサイト経由で購入してくれる前提での機能だからだ。

しかし、上記はあくまでも一般論である。もしECサイトの強みが「定期購入機能」にあって、ECサイトさえあればオンラインで顧客が購入してくれる目処がついているのであればその限りではない。

そのため、システムが達成しようとしている世界観などに応じて柔軟にプロジェクトで検討する必要がある。

制作・開発を行う

ユーザーストーリーに対応する機能の優先度がついたら、次は実際にその機能を具体的な形にしていく。

この具体化の際に、実際にシステムを作ってしまう場合と、システムを作る前にワイヤーフレームなどを使って擬似的なシステムを作る場合がある。

ワイヤーフレームというのは以下のようなものだ。

実際にシステム開発が入る前に画面だけを作る。これによってシステム開発を行う際よりも早く、具体的なものを手に取ることができるので、検証までの時間が短縮される。

開発期間に多少余裕があるのであれば、ワイヤーフレームを作ってから開発をするという手順を踏むことをお勧めする。これによってユーザーからのシステムに対するフィードバックの回数を増やすことができるため、総合的にはより短期間で良いものが出来上がる。

逆に、ワイヤーフレームでの検証を飛ばすと、システムが出来上がる時間は短くなるかもしれないが、検証できる回数が減るので良いものができる確率は下がってしまう。

制作したものを顧客に使ってもらい、ソリューションとしての有効性を検証する

前のステップでユーザーに実際に触ってもらえるものができた。そのためこのステップでは、それを使って元々想定していた課題の解決が実際にできるのかを検証する。

前のステップでシステムを作っていた場合でも、ワイヤーフレームに留めておいた場合でもやることは同じだ。つまり、具体的なプロダクトをユーザーに使ってもらって、抱えている課題を解決できそうかヒアリングするだけだ。

前のステップでのフィードバックを基に必要に応じてユーザーストーリーを修正する

最後のステップでは、前のステップでユーザーからもらったフィードバックをもとに必要に応じてユーザーストーリーやそれに対応する機能を修正する。そして、ここまでのサイクルを繰り返していく。

例えば、以前のプロジェクトで家庭用の家事管理アプリを作っていた。当初は以下の2つをアプリの提供価値の柱としていた。
・家事の可視化
・子供の家事スキルアップによる家事の戦力の増加

しかし、ワイヤーフレームを作って想定ユーザーに画面を見てもらったところ以下のようなフィードバックを得た。
・お母さんの家事負担を軽減するはずなのに、お母さんが家事の割り振りや家事の実行状況を確認することになるので負担が減らなそう
・子供の家事スキルアップの記録は成長記録としてはとても良い

このフィードバックをもとにチームで話し合い、アプリの提供価値を「子供の家事スキルアップによる家事の戦力の増加」に絞ることにした。

そこで前述の1〜6までの工程をやり直した。つまり、ユーザーストーリーとそれに対応する機能を修正し、ワイヤーフレームの作成をし直した。さらに再度ユーザーテストをした結果、かなりの好感触を得ることができ、プロダクトの提供価値のレベルが一段階上がったのをチームで実感した。

まとめ

この記事ではアジャイル開発とMVPの関係性とアジャイルでMVPをと入れるための方法を7ステップで紹介した。

この記事がアジャイル+MVP開発を増やすことに繋がり、より多くのシステムが、より効率的につくられる手助けができていたら幸いだ。

  • このエントリーをはてなブックマークに追加