スタートアップ企業や、スタートアップ企業から成長したような企業はいつでも、できるだけ早くマーケットに製品を出したいと考える一方で、リスクを最小化する方法を探しています。なんといっても、開発中の製品というものは利益を生み出さないにも関わらず一定のリソースを必要とするからです。
デジタルな製品であれアナログな製品であれ、より早くリリースするためにはさまざまなアプローチがあります。2000年代初頭からよく聞かれるようになっているのが、リーンスタートアップメソッドの一部として有名になった「実用最小限の製品（MVP= Minimum Viable Product）」という考え方です。
しかしMVPは、多くの企業において製品を迅速にマーケットに出すための「最善の」方法であるとして歓迎されている一方、反対意見もまた多いのです。そこで、「価値ある最小限の製品（Minimum Valuable Product）」という考え方が生まれました。
MVPとはなにか
基本的にMVPは、完成版の製品よりも大幅に早くリリースできる、機能限定版の製品です。MVPにはアーリーアダプターを満足させるだけの幅広い機能が組み込まれていることが理想です。
MVPをつくる動機は、製品を素早く売り出すことによって、①利益を稼ぎ始めること、②製品を改善するためのフィードバックを得ることです。誰も欲しがらないような完成版の製品のために何ヶ月も何年も無駄にすることが無くなるのですから、明らかに利点があるように思えます。しかし実際は、深刻な欠点もあるのです。
そうした欠点の一つが、あまりにも機能が限定されたMVPをつくってしまう傾向があるということです。この場合、MVPはチームがつくっているアプリなどの製品の基本的な機能のみを備えたものになるでしょうが、ユーザーにとってはごく普通のものに感じられます。多くの製品についてもっとも基本的な機能だけしか残らなかったら、その製品は競争力を失い、すべてが同じ見た目で同じ機能をもつようなものになるでしょう。
たとえばToDoリストのアプリについて考えてみます。ベーシックなToDoリストのアプリには、新たなタスクを記録する、タスクを完了済としてマークする、また多くの場合はタスクに優先順位をつけるといった機能があるでしょう。他には、期日を設定する、タグを付けるまたはカテゴリに分ける、誰かに割り当てるといった機能もあるかもしれません。これらの機能を備えたとしても、競合と差別化することはできません。さらに、MVPをデザインするとなったら、多くのチームがそのような機能をもった、似たようなものをつくることになるでしょう。
MVPをデザインするに当たっては、ユーザーのニーズが見過ごされることもあります。ですがその製品が本来もつ機能を考えれば、それがどのような形であれ、デザイナーが考え方を変えることに役立つはずです。
MVPの欠点
MVPには他にも潜在的な欠点があります。手抜きをすることもその一つです。機能を限定した製品をつくることが目標なのですから、やることを最小限にすることは仕方ありません。しかし、手を抜くべきではない部分もあるのです。
これは、ユーザー体験を犠牲にするということについては特に顕著です。製品にとってUXは生命線です。製品を使うことに伴うユーザー体験を犠牲にすることは、製品の成功に悪影響を与えるでしょう。この場合、MVPにおいて得られる体験が完成品で得られるものとみなされてしまい、MVPは完成品が実用的ではないことを示すことになります。
MVPの最大の欠点は、MVP自体にはまったく関係ありません。LinkedInの創業者であるReid Hoffmanの次のような言葉がよく知られています。
世に出すのが恥ずかしいような段階でいち早く最初のリリースを行うべきだ
このような考え方は会社にとってもユーザーにとっても、良くありません。
多くのチームがMVPをつくり出すときに採用するアプローチ自体が問題なのです。MVPは、ユーザーのニーズを満たすような、価値ある完成版をつくり上げるための一つのプロセスであるはずです。ですがそうではなくて、デザイナーはそれぞれのMVPを最終的な完成版をつくるための一歩とは考えず、独立したものと捉えがちなのです。さらに重要なことに、彼らは製品のリリース前に「社内で」評価されるべきレベルのMVPをリリースしてしまうことが多いのです。
価値ある最小限の製品を提供すべきです。MVPは、機能を限定し過ぎてユーザーを混乱させてしまうことが多いからです。
価値ある最小限の製品とはなにか
価値ある最小限の製品（MVaP = Minimum Valuable Product）は、MVPのコンセプトの延長上にあります。しかしMVaPの場合は、実用的な最小限の製品を指向するのではなく、デザイナーは本当に価値のある最小限の製品をつくります。
ですが、ここで言う「価値」とはなんでしょう。どういったものがこれに含まれるのでしょうか。
まず、エンドユーザーにとっての価値を第一に考えるべきです。MVaPは、ユーザーのニーズと期待を最優先に考える必要があります。つまり、ユーザーのニーズを満たす最善の方法を決定するために、製品のタイプにとってのベストプラクティスを考え、ユーザーリサーチやユーザビリティスタディを行い、ユーザーのペルソナやユーザーケースをつくるということです。
ユーザーのニーズを満たす方法についてはいくつも考え方があり、プロトタイプによるユーザーテストもその一つです。機能を実装したプロトタイプを実際のユーザーにみてもらい、どのプロトタイプがもっともユーザーのニーズを満たすかを確認することは、MVaPをつくるための重要なステップです。
プロジェクト自体に対する価値もあります。MVaPは、目の前にあるプロジェクトを前進させるようにデザインされなければなりません。すなわちMVaPは、製品がどのようにマーケットに受け取られるかについての有用な気づきを集めるために十分な機能を備えている必要があるのです。
最後に、MVaPはビジネス全体に価値を提供する必要があります。MVPをリリースすることに伴うリスクの一つは、そのリリースによって会社のブランドによい影響を与えないかもしれないということです。たとえ製品の完成版ではないとしても、MVaPはブランドに価値を付加するものでなければなりません。
MVaPが独特なのは、競争力のある差別化にフォーカスしているということでもあります。デザイナーは競合が他より優れている部分を客観的にみて、それから自分たちの製品が差別化できる部分を考えます。この作業はMVPには必ずしも必要ではありませんが、MVaPをつくる上では不可欠です。
ここで説明しているように、MVaPは世にあるMVPの単なる強化版ではありません。また、Roman Pichlerが提唱する商品価値のある最小限の製品（Minimum Marketable Product）という考え方もあります。彼の考えによれば、最初期にマーケットに出せる製品には、リリース可能で、売り出すことができ、十分に売れるだけの機能をもつ必要があるということになります。
SLC（Simple, Lovable and Complete）はWP Engine社が使っている、似たようなコンセプトです。顧客が嫌っているのにも関わらず、なぜスタートアップ企業はユーザーにMVPを提供するのかを彼らは問いを投げかけています。ユーザーは実際には、シンプルで完成された製品、そしてもっとも重要なことは、愛すべき製品を手にする必要があるはずなのです。なぜ、ユーザーに愛されないような製品を打ち出す必要があるのでしょうか。
MVaPをつくることのポイントは、製品の最初のバージョンであっても、顧客やユーザーにとって便利で、喜ばれるものであるべきだということです。ユーザーに喜んでもらうこと、あるいは最低限、彼らのもっとも差し迫ったニーズを満たすこともできないのであれば、その製品は間違いなく失敗するでしょう。
図の上半分に表示しているのがMVPの例ですが、これはユーザーが本当に求めているものを見過ごしてしまうことがよくあります。各パーツや機能はすべて重要なのですが、組み合わされなければ誰の得にもなりません。下のMVaPの場合は、ユーザーのニーズを満たすための最善のやり方がみつかるまで、あらゆるステップにおいてユーザーのニーズを考慮します。この場合の製品は、最初の段階から「飛ぶ」ためにデザインされています。
MVaPに必要なもの
MVaPをつくるためには、MVPの場合よりも多くのリソースが必要になりそうです。しかし、得られる効果は間違いなくMVaPの方が高く、それだけのリソースを投入する価値が有ります。MVaPをつくる際には、いくつか頭に置いておくべきことがあります。
最初に考えるべきなのは、MVaPにもたせる機能のセットです。最小限の有用な機能のセットはどのMVaPにも含まれる必要があります。先に言及した通り、このセットに含まれる機能はその製品を競合から差別化するような機能です。このステップには、競合の製品がどの機能をもっているのかを特定することも含まれます。だからといって、競合がもっているすべての機能をMVaPにもたせる必要があるということではありません。
たとえば、初代のiPnoneについて考えてみましょう。当時のスマートフォンには、Appleが意図的に初代iPhoneから取り除いた機能が多くありました。コピー＆ペースト、ソフトウェア開発キット（SDK）、果ては複数の宛先にテキストメッセージを送る機能や3G接続さえも、iPhoneでは省かれていました。
初代iPhoneはMVaPの絶好の例です。当時マーケットに出ていた他のスマートフォンと差別化を図るために、いくつかの機能が省かれていました。そしてAppleは、新たなバージョンを出すたびに価値を追加し続けたのです。（写真：Josh Miller/CNET）
iPhoneのあとのバージョンにはそれらの機能が含まれましたが、最初のバージョンはあえてそれらを省き、その代わりにソフトウェア（iOSは当時革新的なものでした）やマルチタッチ機能など、周囲と差別化できる機能にフォーカスしたのです。この初代iPhoneは、iPhone 3Gのために生産が打ち切られるまでに600万台を売り上げるという圧倒的な成功を収めました。
MVaPをつくるからといって、MVPの考え方をすっかり捨てる必要はありません。実際、社内向けのMVPをつくることから始めることは有効です。ですが、MVPは公の場に出せるようになるまで、さらには社外のアーリーアダプターにさえも出せるようになるまで強化し続けなければなりません。社内におけるテスト、そして小規模なフォーカスグループを対象としたテストを行えば、会社の評判やブランドを傷つけるリスクを冒すことなく、あるいはユーザーを置いてけぼりにすることなく、MVPをMVaPのレベルに引き上げることができます。
デザイナーは、最初に公開されたMVaPに、なんであれ製品の主要な目標に寄与する機能を組み込むようにしなければなりません。最終バージョンにはもっと多くの機能や改善が含まれるとしても、MVaPの目的はユーザーを満足させる製品をつくることです。製品チームが考えている、それらの機能についての最終的なビジョンがもっと複雑なものだとしても（あるいはまったく異なる場合でも）、重要な機能を最低限備えたバージョンをリリースすることをおすすめします。
実際、製品チームは機能セットについてだけ考えるのではなく、ちょっと目線を変えて、ユーザーのニーズについても考える必要があります。競合他社が実践している方法よりも、より良くユーザーのニーズを満たせる方法はないでしょうか。競合他社はまだ採用していないものの、ユーザーの生活を楽にするような、製品に容易に組み込める実験的な機能はないでしょうか。競争がユーザーのタスクを完了するための15の異なる方法を提供しているからといって、業界のすべての製品が同じことをする必要があるということではありません。
結論
MVPを出発点にしようがMVaPを出発点にしようが、最終的な目的が「最大の価値をもつ製品」であることには変わりありません。どちらのやり方も、競合と差別化できて、ユーザーのニーズを可能な限り完璧にかつ効率的に満たすことで彼らを喜ばせ、すべての関係者（ここにはブランドも含まれます）にとって価値がある製品をつくるためのものなのです。
MVPが有効な場合もありますが、最初の段階から価値をつくり上げる分、MVaPの方がより短い時間でチームをゴールに近づけることができます。どのようなビジネス、あるいはブランドにとっても、目的は提供する製品によって人々に価値を提供することであるはずです。価値があれば信用が生まれます。そのことによってリピーターと口コミが増えてきます。
