第15章 ユーザーモニター制度
製品開発のパートナーたち
マーケティングの人たちなら、製品を発売するときは、確実に製品を買って製品レビューなども公開してくれる顧客 (リファレンスカスタマー)、プラットフォーム製品であるならは、そこで動くアプリケーションで目玉となるもの (リファレンスアプリケーション) ほど重要で説得力のあるものはない、と口をそろえるだろう。それなのに、実に多くの製品が、リファレンスカスタマーやリファレンスアプリケーションがないまま発売されていることには、相変わらず驚かされる。
発売の時点で、名前の知られた人が何人か、製品を使っていて満足しているとおおっぴらに言ってくれれば、営業担当者の仕事は劇的に楽になる。このおかげで、買おうかどうか考えている人が直面している最大のリスクをぐんと減らせるからだ。逆に、いいリファレンスカスタマーがいないと、どんなに独創的なマーケティングや知恵を絞った販売戦術があっても、結果は限られている。
製品にリファレンスカスタマーやリファレンスアプリケーションがないとしたら、それはかなりまずいかもしれない。普通、それは、製品がダメか、まだいちばんいい発売のタイミングになっていないかのどちらかだ。だれだって、最初のユーザーという実験台にはなりたくないだろうし。
製品についてコメントしてくれたウェブサイトがほんの 1つ、2つぐらいしかないとすれば、基本的に、特別な製品か特注の製品が作られてしまったということで、みんなが使えるものではないのでは、と心配になる。
この話は、プラットフォーム技術を使った製品、ビジネス用アプリケーション、あるいは、一般消費者向けのインターネットサービスであっても同じように当てはまるので、注意してほしい。買うかどうか検討中の人々は、製品が自分たちにとって本当に使いものになるのかどうかを知る必要があるのだ。
ここで、ちょっとの間、製品を発売するときの話から、開発プロジェクトが始まるときの話に移ろう。
プロダクトマネージャーとしての仕事は、ご存じのとおり、ターゲットとする顧客と解決すべき問題を深く理解して、ニーズに合った製品を考え付くことができるかどうかをじっくり検討することである。何百社もの顧客 (実際に使う人の数は何千人、何百万人という単位になる) のニーズに合う製品を開発するためには、顧客と直接接しながらやっていかなければならないこともおわかりだろう。でも、これまた明らかなのが、1日の時間は限られているので、それほど多くの顧客と直接接するだけの十分な時間はない、ということだ。
ターゲットとする顧客をしっかり理解することと、製品の発売までに確実なリファレンスカスタマーを確保しておくこと、この 2つの課題に取り組むために私がお勧めするのは、ユーザーモニター制度 (charter user program) を利用することだ。これは、「カスタマーアドバイザリーボード」、「カスタマーカウンシル」、「カスタマーの声」などの名称でも知られている。これは特に新しい手法ではなく (私は 20年ほど前に HP で初めて利用した)、多くの企業で採用されている。でも、この手法を使っていない会社が多いことにも驚いている。
この制度はすこぶるわかりやすいものだ。目指すところは、ターゲット市場から少なくとも 6人のユーザーに集まってもらった上で、この人たちの意見を聞きながら、この人たちが満足して、実際に使ってくれて、製品レビューなどを発信してくれるような製品を実現することである。このためには、最初は 8～10人で始める必要があるだろう。よって、プロダクトマネージャーは、プロジェクトがこれから始まるというときに、顧客を募集することになる。ターゲット市場から、確実にリファレンスカスタマーとなってくれそうな顧客を探すのだ。今いる顧客から集めてもいいだろうし、今後顧客になってくれそうな人たちからでもいいし、あるいは、その両方というのもよくある。ここで肝心なのは、この製品化で解決しようとしていることが、彼らにとっても現に問題と感じているものであり、みんなできるだけ早く解決してほしいと思っている、という点である。
ここに、製品開発をやる側とユーザーとの間にギブアンドテイクの関係が成り立つ。
モニターとして参加する顧客やユーザーにとってのメリット
• 早くから、製品に関する重要な情報を得ることができる。この製品が解決しようとしている問題を認識し、その問題で不都合を感じ、よいソリューションが見つかることを望んでいる。
• 早くから製品に触れてみて、またここで不都合を感じるので、解決されるのは早ければ早いほどよい。
• 今までコストがかかっていたのであれば、たいていは大幅なコスト削減につながる。
プロダクトマネージャーにとってのメリット
• 今まさに問題となっていることに取り組みながら話し合えるユーザーや顧客が何人かいてくれる。
• 顧客企業のオフィスやそこで働くユーザー (プラットフォーム製品である場合は、その会社にいる開発者) に連絡して話すことができる。
• 顧客やユーザーが、定期的なグループセッションのために顔を出すことに同意してくれる。
• 顧客は、製品のテスト版をすぐに試してみて、随時フィードバックすることに同意してくれる。(プロダクトマネージャーもその場にいることが多いだろう。)
• 製品の正式版に満足すれば、その顧客は、広く製品レビューを公開することに同意してくれる。
気を付けなければならないこと
• 肝心なのは、モニターとして参加する場合、あらかじめ製品の代金を支払うのではないという点だ。そのため、製品を作って売る人とそれを買う人、という関係とはずいぶん違ったものになるだろう。製品を開発するときはパートナーが必要だ。そして、その製品は、モニターになってくれるユーザーの注文に応じてソリューションを提供するわけではないし、また、会社は特定のユーザーのためだけにプロジェクトを請け負うわけでもない。でも、モニターが満足してくれる製品を提供できて初めて、彼らから代金をもらうことができる。
• たいていの会社であれば、製品開発に関わってみたいという顧客が少なくないことに圧倒されるだろう。そういう顧客が相当いるということは、彼ら自身も知っている。営業部門を抱える会社であれば、駆け引きの材料に使われて、対応しきれないぐらいの数のモニターを受け入れさせられるかもしれない。こうなると、よほどうまく仕切らなければならないだろう。とにかく、メンバーの顔触れは重要だ。(会社は、開発中のソフトウェアを早く使いたいという顧客に先行公開版を提供することがあるが、そういうタイプの顧客はこの制度のモニターにはふさわしくない。まあ、それでもいいが、その代わり、10人以上にはしないことだ。それ以上になると、対応しきれなくなり、一人一人と必要な作業を緊密に進めることができなくなるからだ。）
• モニターの募集が難航するとすれば、製品化によって解決しようとしている問題がそれほど重要なものでない可能性が高いので、おそらく、製品を売るのにも相当苦労するだろう。モニターの募集は、やる価値のある仕事に時間を費やしているのかどうかを実際に確かめる最初の試金石にもなる。顧客がこの問題に興味を示してくれないのであれば、この製品化の計画を見直すことになるだろう。
• モニターは、間違いなくターゲット市場からの顧客やユーザーでなければならない。よく、アーリーアダプター (初期採用者) が集まってしまった、ということなりやすいものだ。こういう人々は、本来のあるべきモニターよりもずっと寛容なので、結局はアーリーアダプターしか興味を持ってくれない製品になりかねない (第35章「Emotional Adoption Curve」参照)。
• モニターの一人一人に、できるだけ多くの人が買ってくれるような一般向けの製品を開発しようとしていることを説明する必要がある。特定の会社だけで役に立つような特注のソリューションを開発しようしているわけではないし、モニターもそういうものは望んでいない (その製品をビジネスとして成り立たせることができなければ、プロダクトマネージャーであるあなたは行き詰まり、モニターになってくれた人たちは、だれからも支持されない将来性のないソフトとともに取り残されることになるからだ)。そうではなくて、プロダクトマネージャーは、彼らにとってもちゃんと役に立つ製品を作ることをきちんと約束したのだ。
• モニターになってくれた人々は、開発のパートナーであると考えよう。みんながこの開発に参加している。モニターの人たちには、同僚のように接するようにしよう。お互いに助け合うのだ。ここで築いた関係は、その後何十年も続くことだってあるかもしれない。
• プロジェクトの間ずっと、プロダクトマネージャーはモニターの人たち付き合うことになる。彼らにプロトタイプを見せて、いっしょにテストして、細かい質問を何百もぶつけて、彼らの使用環境で正式リリース版の候補をテストするのだ。
• 製品の正式版を一般に公開する前に、必ずこの人たちに先にリリースしよう。そして、一般公開の前に、実際に使ってもらって、満足してもらえるようにしよう。発売するときになったら、彼らは一肌脱いでくれるにちがいない。
• モニターにリファレンスカスタマーとして製品レビューなどを出してもらうときには、たぶん、マーケティングの担当者とも緊密に協力しながら活動することになるだろう。マーケティングの人たちは、パートナー (モニター) を探すときも力を貸してくれることが多い。
• プラットフォーム製品である場合も (他の会社が、その上で動くアプリケーションを開発して、プラットフォームとセットで販売することになる)、このモニター制度は十分使える。大きな違いは、6人のモニターではなくて、目玉となるアプリケーションを 6種類ほど確保することだ。アプリケーションパートナーとしっかり協力して、そのプラットフォーム用に開発したアプリケーションもユーザーに受け入れてもらえるようにする必要がある (そのためにうってつけの方法が、アプリケーションパートナーにもユーザーモニター制度を取り入れるよう働きかけることだ）。
ここで挙げた例の多くは、企業向けソフトウェア製品やプラットフォーム製品の顧客に関することだが、ここまで紹介してきた手法は、一般消費者向けインターネットサービスや家庭用電子機器のエンドユーザーにも応用できる。一般消費者向けサービスでは、モニターの人数は 10～15人に増やしたいところだろうが、大切なのは、この人たちのことや、この人たちが製品を使う環境 (自宅か会社か) をよく知るということだ。一般消費者向けサイトを設計するときに、開発プロセスのかなり遅い段階 (ベータ版の公開や正式版の発売の時期) まで、実際のターゲットユーザーにきちんとサイトを見てもらっていない、といったことになりがちである。だが、これはかなりまずい。ユーザーモニター制度のようなものがあると、プロダクトマネージャーにとしては、現実のユーザーに対して実際に価値のあるものを提供すること、このことをいつも忘れないでいることができるだろう。マーケティングの観点からいうと、消費者がある製品を買おう、使おう、と決めるとき、彼らは、企業向け製品のユーザーのようにはリファレンスカスタマーには注意を払わないかもしれない。むしろ、マスコミや他のユーザーが書き込む製品レビューサイトの影響を受けやすい。マスコミが製品に関する記事を出すと、人々がまず見るのは、現にユーザーである人のコメントなのである。
確実に顧客が求める製品を開発するために、そして、これから顧客になってくれる人に対しては、この製品を使えばうまくいくし満足できる、と確実に証明してみせるためには、ユーザーモニター制度は手軽だが強力な手法である。
Inspired日本語版 