ハーバード・ビジネス・レビューの2006年6月号
最近は「シンプルな製品/サービスを作ろう」というキャッチフレーズが流行っていて、特にWeb 2.0系の企業ではこの信条を掲げているところが多く見られます。僕もこの考え方に大賛成なのですが、果たしてそれ一辺倒で良いのでしょうか。
ハイテク製品/サービスは、必ずイノベーターやアーリーアダプターと称される先進的な人々がファーストユーザーになります。彼らは新しいもの好きで、少々の不具合やバグがあったり、使い勝手が悪かったとしても、製品のコンセプト自体に魅力を感じてくれれば使い続けてくれます。そればかりか、自分たちの手でそれを改善し、フィードバックまでしてくれるというありがたい人々です。ならば、このステージでは斬新な機能を盛り込めるだけ盛り込んで（この際デザインも一切無視）、どの機能が「キラーアプリケーション」となるのかを確かめる---という戦略を取っても良いのではないでしょうか。
そしてライフサイクルが進み、いざキャズムを越えるぞ！という段階になったら、できるだけ機能を取り払ってシンプルにする---そして使い勝手を重視し、ヘルプやサポートといった煩わしい以外の何者でもない機能/サービスがなくても使えるようなものにするわけです。前のステージで「機能てんこ盛り」バージョンをテストしておけば、ターゲットとなるセグメントごとに「何を捨てて、何を売りにするか」をコントロールして、いくつか異なるバージョンを用意するといった戦術も可能になるでしょう。
ただ、実際にこの戦略を実行するとしたら、初期の開発リソースはどうするんだとか、メジャー市場のユーザーは初期市場のオタクたちとは根本的に思考回路が異なっているだろうとか（それがメジャー市場に受け入れられる製品を開発するのに失敗してしまう理由の1つですが）、様々な問題点があると思います。要は「シンプルイズベスト」というアドバイスは、生まれたばかりのハイテク・プロダクトには厳密に適用しなくてもいいんじゃないかなぁと、おなじみの天邪鬼的発想なわけですが。機能の数と使い勝手のバランスは、決して恒常的なものではないのではと思います。
<追記>
HBRの記事タイトルですが、「機能過多を拝す」ではなく「排す」でした（当然ですね）。凡ミス失礼しました。
お詫びついでに、HBR記事の中で指摘されていたこんなポイントを：
不要な機能を排除しないのは、エンジニアやアーリー・アダプターが製品の使い勝手には無頓着だからである。あるリード・ユーザー（先行購入者）は、ウェブサイトに次のような感想を書き込んだ。
「ソニー・エリクソンの<T610>か<P800>にするかで、つくづく迷ったよ。
（中略）
直感に従って<P800>を選んだところ、結果は大正解。<P800>を悪く言う奴らには、『おあいにくさま』としか言いようがないね。そうは言っても、機能が多すぎて手に余るという人が多いのもわかるけどね」
これは少数意見である。しかし、このリード・ユーザーは購買製品に精通しているだけでなく、競合製品の使用経験もあり、自分の意見を持っている。エンジニアが対象顧客に設定すべきは、このようなリード・ユーザーだろうか、それとも宣伝に影響されやすい一般ユーザーだろうか。
長い引用になってしまいましたが、非常に重要な点だと思います。確かにエンジニアの視点から見れば、「製品そのものにキチンと目を向けてくれない一般ユーザーよりも、知識があり多くのフィードバックを返してくれるリードユーザーの方をターゲットにしたい」という気持ちになるのも分かります。しかし一度メジャー市場を狙うと決めたならば、「宣伝に影響されやすい一般ユーザー」だけを見るように180°意識を変えなければならないのでしょう。
コメント