| « 2007年2月15日 | 2007年2月16日の投稿 |
2007年2月18日 » |
前々回の記事「Web 2.0のセールスマンなら最低限。。。」で、Web 2.0なサービスを選ぶ場合、パンフレットの説明だけでベンダーを決めてしまってはいけないといった内容のことを書いた。
ブログにしてもSNSにしても、最近ではほとんどのベンダーが自社のサービスが体験できるデモサイトを用意している。実際にデモサイトを使い比べてみてからベンダーを決めるというやり方は、確かにパンフレットによる説明だけで決めてしまうよりは理にかなっているし、機能や使い勝手を実際に自分の目で確かめることができるので、完成したサービスがイメージしやすい。
ただ、デモには落とし穴も多い。所詮デモはデモだ。デモには実際のサービスでは実現できないような機能が実装されていることも多く、100%信用していると痛い目をみることになる。そこでお勧めしたいのが、デモではなく実際に動いているサービスを自分で使ってみること。
SNSベンダーだったら、その会社が開発したサービスに招待してもらうか、登録制のサービスを教えてもらって、ユーザー登録して使ってみることが大事だ。できることなら、自分たちが考えているサービスに一番近いSNSがいい。または、ベンダーが一押しのSNS。できるだけ機能が豊富で、ユーザー数の多いサービスに登録してみよう。
実際に動いているサービスを使ってみることで、その会社の製品・サービスの品質がある程度わかってくる。意外なほど基本的な機能が出来ていなかったり、使い勝手が思っていたほど良くなかったりとか、デモでは知ることができなかったマイナスな部分が見えてくる。
逆な見方をすれば、完成度の高い実際に動くサービスは、その会社の格好の宣伝材料になるということだ。「あんな凄いSNSを開発した会社なら信用できるだろう」という感じで。ということは、開発する側はリリースしたサービスに対して責任を負わなければならない。リリースしたお客のサービスの成功/不成功が、開発した会社の善し悪しを判断するバロメーターになる。
デモだけでは、それを開発した会社の本当の実力は判断できない。実際に動いているサービスを自分で使ってみる。Web 2.0の世界では、結構重要なことだ。
今の仕事に関連して言えば、アップロードされた楽曲がどんなに素晴らしくても、実際のライブが思っていたほど大したことがないというアーティストがいる。デジタルの世界もWeb 2.0の世界も、本物を見極める能力がカギになりそう。
リリースしてから2ヶ月ちょっとが経って、faamにもユーザーから日々いろんな意見・質問が寄せられてくるようになった。大別すると、①使い方に関する質問、②バグに関する指摘・報告、③機能追加・変更の依頼の3通りだ。
ちゃんとデータを取っているわけではないが、感覚的には①の使い方に関する質問が一番多く、次が③の機能追加・変更の依頼になる。②のバグに関する指摘・報告は、①の使い方に関する質問と③の機能追加・変更の依頼に比べればはるかに数は少ない。もっとも、バグに関する指摘・報告が多いようでは、サイト運営者としては失格なわけだが。。。
つまり、ユーザーの声を発生する数の多い順番に並べると次のようになる。
1.使い方に関する質問
2.機能追加・変更の依頼
3.バグに関する指摘・報告
ところが、これを対応しなければならない優先度の高い順番に並べてみると次のように入れ替わる。
1.バグに関する指摘・報告
2.使い方に関する質問
3.機能追加・変更の依頼
いくら十分なテストをして臨んだとしても、バグは出てしまう。ユーザーでなければ気がつかない視点や、ユーザー数が増えてこないと発生しない種類のバグがあるからだ。バグは発生しないことに越したことはないが、もし発生したとしても、即座に対応できる体制を作っておくことの方がよほど重要だ。
使い方に関する質問は本当に多い。ヘルプを用意していれば解決するといった問題ではない。ユーザーにしてみれば早くいろんな機能を使ってみたいわけだから、直接問合せてきたとしても何ら不思議はない。サイトのファンを一人でも多く増やすためにも、迅速で丁寧な対応が求められる。
ただ、バグに関する指摘・報告と使い方に関する質問のどちらを優先するべきかは、程度によって順番が入れ替わることを頭の中に入れておく必要がある。程度・内容によっては、すぐに対応できないバグがあるからだ。バグに関する指摘・報告と使い方に関する質問の優先順位には、ほとんど差がないと思っていていい。
機能追加・変更の依頼にも即座に対応するのがWeb 2.0なんじゃないのか、という意見があるかもしれない。でも、先の二つに比べれば対応は遅くても構わないと考えている。それが簡単に実装できる機能だとしてもだ。
一人のユーザーの意見をすべて聞いていては、サイト全体の基本構造が崩れてしまう。たとえそれが簡単な機能の追加・変更依頼だったとしても、社内のスタッフで十分協議した上で決定を下すべきだ。SNSを運営する側の責任として、基本的な機能やコンセプトは守り抜かなければならない。ユーザの意見を聞くことと、ユーザーに媚びることは別物だから。
ただし、サイト運営者側が必要だと思った機能については、すぐにでも実現するべきだ。機能やサービス内容については、それくらい主体的であってもいいのでは。ユーザーと直接触れ合う機会が他のサイトと比べて格段に多いSNS。基本的にはスピード重視。ただ、それを大前提に、スロー&ファストを使い分けることが重要。
それにしても、SNSを運営している人間が寝る時もパソコンを抱いて布団に入れというのは、まんざら冗談でもないみたい。
| « 2007年2月15日 | 2007年2月16日の投稿 |
2007年2月18日 » |

顧客に“ワォ!”という体験を提供――ザッポスに学ぶ企業文化の確立
ちょっとした対話が成長を助ける――上司と部下が話すとき互いに学び合う
悩んだときの、自己啓発書の触れ方
考えるべきは得意なものは何かではなく、お客さまが高く評価するものは何か
なんて素敵にフェイスブック
部下を叱る2つのポイント
第6回 幸せの創造こそ、ビジネスの使命