ユーザーの要望を知る

• Tweet
• ブックマーク

  

  

  はてなブックマーク

  Check

  mixi チェック

  

  Instapaper

  Read it Later

  Read It Later

開発の余地を残しながらサービスをリリースし、ユーザーと対話を行って継続的に改善を行っていく。こうした方法はやろうと決めれば誰でも簡単に行える、というものでも無いように思います。

サービスが魅力的でなければ意見を言ってくれるユーザーも現れないでしょうし、逆に想定した以上にサービスが盛り上がれば意見が大量に押し寄せて運営者が処理できる量を簡単に上回ってしまいます。

何でもかんでも「どう思いますか？」と聞けば良いというものでもなくて、ここまでは自分たちが決めるんだ、という決意や意思表示も必要になります。

はてなの場合、サービス開始当初から「サービスへのご意見などをお寄せください」とうたってツリー型の掲示板を開放していましたが、要望などはそれほど多く集まりませんでした。要望窓口や意思決定プロセスをオープンにすることは既存のサービスの改善を早めることはあっても、初期ユーザーを獲得してくれる魔法にはなり得ません。

幸い、その後のサービスが多くのユーザーの方々に使って頂けるようになり、次第に要望窓口の仕組みが進化を始めました。

はてなダイアリーのベータ版を開設した当初は、公式ブログを用いてユーザーとのコミュニケーションを行いました。

新しい機能の告知などをはてなダイアリー日記にて行い、要望のあるユーザーがブログにコメントを書いたりトラックバックを送れる仕組みにしました。

また、はてなダイアリーへの要望というキーワードとはてなダイアリーの自動リンクの仕組みを使って、ユーザーが自分のブログに要望を書いてキーワードに情報を集約する、という仕組みも活用しました。

毎日開発者がこれらのコメントやトラックバックをチェックし、片っ端から実装を行っていく、というベータ期間独特の密度の高い開発体制の間、これらの機能はかなり有効に機能しました。

しかし、サービス開始から時間が経ち、次第にサービスのフェーズが「初期開発」から「運用」へと変わるにしたがって、ユーザーの方々から頂いた意見を取り込むことが難しくなりました。この時期、はてなダイアリーのユーザーは数万人規模となり、要望や意見が増加する一方、次第に充実する各種機能に対しての細かい変更やマイナーな機能の要望の比率が増え、要望の採用率も低下していきました。

また、はてなダイアリー以外のサービスに対する要望の窓口が存在せず、他のサービスのユーザーからは同様の窓口設置を希望する声が高くなっていました。

こうした状況を改善するために、初期開発フェーズから運用フェーズまでの各サービスへの声を集約する仕組みを新たに構築する必要があると考えて要望窓口サービスの構想がスタートしました。

当初考えていた構想は、

• 各サービスごとに要望受付フォームがあり、ユーザーが要望を投稿可能
• 各サービスごとに登録された要望が公開されており、はてな側、ユーザ側共に閲覧可能
• 各要望を実装した場合には、「実装済み」などに状態が変更され、その旨がユーザーがに伝わるようにする

といったものでした。

しかし、このような窓口を作った場合に想定される要望の量は社内の処理能力をはるかに上回ることは確実だと思われました。そのため、こうした単純な仕組みを公開しても「要望を登録したけど全く叶えられない」「そもそも内容に目を通してさえもらえていないのじゃないか」といった状況が想定され、なかなか公式な窓口として踏み切ることができませんでした。

この問題を解決するために、各要望にモデレーション機能をつけ、ユーザーが「この要望は良い」と思ったものに投票し、得票数の多い要望が優先的に検討される仕組みを考えました。こうすれば得票数が少ないことで、その要望を発案者と同じように希望しているユーザーがあまり居ないことなども分かるようになり、納得感が増すのではないかと考えました。

ところが投票制度にはまだ問題があると考えました。例えば「有料オプションの値段を半分にして欲しい」といった要望が大量の得票を獲得する可能性があるわけです。こうした要望は基本的に票を集めはするものの、事業を運営する側としてはあまり価値がありません。

このようなユーザーと運営者の利益が相反する問題は少なからずあり、双方にとって有益な情報が効率的に集められる仕組みが必要だと考えて始めたのが、アイデアを株式に見立てた予測市場の仕組み、はてなアイデアでした。