Webサーヴィスに必要なこと

コンピュータは仕事の労力を軽減し、インターネットは情報の取り扱いを迅速にした。
今やアイディアと多少の技術さえあれば、Webサーヴィス業界への参入は極めて容易になっており、個人レヴェルでの提供も珍しいものではなくなった。
逆に言えば、類似するサーヴィスもまた多いということだ。発案がいかに独創的であれ、それだけで人気を集められるとは限らない。ユーザの不満を放置してしまえば、その部分を改良した後発サーヴィスにシェアを奪われてしまう。

どんなサーヴィスであれ、最初から完璧ということはまずない。いや、むしろコンセプトモデル段階で暫定的にサーヴィスインしておいて、必要に応じて手直し可能なのがWebの利点のひとつでもあり、いかにユーザの要望を吸い上げて使い易い仕組みを作り上げるかというのは非常に重要なポイントだ。そのためには、ユーザからの直訴窓口が必須となる。
また(とりわけ初期段階では)ユーザと開発者の垣根は低く保たれるべきであろう。開発者と親しくなることでサーヴィスへの親近感が生じ、熱心なサポーター層の形成に繋がる。
ベータテスタの公募はサーヴィスの改善点を洗い出して満足度を高める効用だけではなく、予め活発なコミュニティを形成しておいて正式サーヴィスイン時点での活性度を保つ役割もある。
ただ、ここで重要なのは「ユーザの声を聞く体制を保つ」こと。必ずしもすべての要望を叶える必要はない(そんなことは不可能だ)が、「こういう判断によりこの機能は実装しない」「こういう構想からこんな風に機能を変更した」という風に、仕様変更の可否だけでなく設計者の考えも伝えるようにすることで、最終的な結果に理解(あるいは更なる要望)が得られる。
逆に言えば、「声が届かない」と思われた時点で熱心なユーザは離れてしまう。完成して不満の少なくなったサーヴィスならばともかく、発展途上のサーヴィスでユーザと開発者の相互理解が失われるのは、サーヴィスの将来性が失われることと等しい。

サーヴィスの拡大に伴い、直談判のキャパシティが飽和することは避けられない。そうなった時にどのような手段で要望を捌くかというのは悩ましい問題だ。例えばはてなでは「はてなアイデア」という専用窓口を用意しているが、あまり有効に機能しているとは言い難い。
可能であれば要望を取り纏めるサブグループを用意するなどして対応したいところだが、正直言って開発者としては新機能実装と既存機能メンテナンスではモティヴェーションに大きな差があるものと思われる。その辺りに何らかのインセンティヴがあると良いのだが……