最近のWebサービス向け企画術

MOONGIFTではWebサービスの企画、プロデュースを承っております。ご用命、ご質問などはinfo@moongift.jpまでお気軽にどうぞ!

Webサービスは日々生まれ、そして消えています。MOONGIFTではWebサービスの企画、コンサルティングをメイン業務に行っていますが、ここ数年で企画する際の注意点が大きく変わってきました。要因としてはソーシャル型サービスの活用、モバイル(スマートフォン含め)、フリーミアムと小さなビジネスなどが挙げられます。インターネット上のビジネスにおいて時代の変化を正しく掴むことは成功への一歩であり、認識を誤ると大きな損失を出す結果になります。そこで今回は最近のWebサービスを企画する上で重要な要点をまとめてみたいと思います。

日本のマーケットの場合

日本の場合、高齢化社会への変化を受けてサイトのターゲットを50〜60代にする動きがありました。が、こうしたサイトは広告の割にユーザがつかず、幾つも閉鎖に至っています。こと日本においてはこうした層をターゲットにWebサイトを企画するのは間違っていると言えます。50〜60代の人たちはITリテラシーが高くなく、ネットを使いこなすのは非常に困難です。もちろん中には使いこなす方もいますが、ビジネスになるほど大きなマーケットではなく、さらに言えばリテラシーの高い方は20代向けのサービスでも難なく使いこなすことが可能です。

コマース系のサービスを考えるのであれば、より収益性をあげるなら女性かつモバイルが最良になります。また年代としては20〜30代までを考えるのが良いようです。ニッチな層を狙うのであれば40代や10代を狙うという方法もありますが、成功につなげるのは困難と言えます。

個人向けか企業向けか

サービスの作りやすさを考えた場合、個人向けにアドバンテージがあります。ですが個人向けのサービスではビジネスモデルが構築しづらく、さらに数字の予想もできないのが実情です。対して企業向けの場合は固定金額で収益を得るのが個人向けに比べると容易であり、ビジネス化しやすい面があります。もちろんそのためにはワークフローであったり契約書を作成するなど、Webサービス以外の面で決定すべき部分も多数あります。ですがそうしたことをきちんと考えた上でサービスを提供するのであれば、企業向けのモデルの方が大きく成長できる可能性は持っています。SNSが時々、若者を食い物にしている、広告を無理矢理クリックさせている、出会い系になっているなどと言われますが、個人への課金ができない中で生み出されている収益は得てして批判の対象になったり、何らかの問題が起きた時に一気にユーザ離れを引き起こす可能性を秘めています。企業向けの場合はそうした批判を受けることなく、サービス受給者の方を向いてビジネスが展開できるというのは幸せではないでしょうか。

フリーミアム

フリーミアムの根幹として「無限なものは無料、有限なものは有料」という考えがあります。ソフトウェアやコードなど幾らでも劣化せずにコピーできるものは無料になります。この中には音楽データや動画データも含まれます。逆に限られたリソースを使うものについては有料課金を考えます。個人的な企画手法として「公開できるものは無料、公開しないものは有料」があります。インターネット上に公開できるものは、共有するデータの元になったり、サービスの価値を引き上げるデータベースになります。そのため、公開されるデータについては全て無料で利用できるようにします。対して公開しないデータは公開データベースにならず、個人の利便性のために使われます。こうしたデータについては有料ユーザのみ登録できるようにします。

もう一つの決まり事として、有料ユーザは全体の5%(理想)を想定すべきです。例えば100万人登録したとすれば、5万人が有料ユーザのマックスであると考えます。例えば500円の課金であれば、2,500万円程度の利益がマックスと捉えることができます。その他広告やアフィリエイトなどを設けることはできますが、そうした利益は変動するために予測が難しい面があります。

ソーシャル型

ここ数年の流行としてソーシャルがあります。去年からはモバイルのソーシャルゲームが流行始めています。ソーシャルにすることによって単独で遊んだり、サービスを利用するのに比べてコラボレーションが促進されたり、一緒にサービスを使っている人たちのことを考えてサービスを利用するようになるという相乗効果が臨めるようになります。人は元々社会性をもった生き物なので、インターネットの中であっても人目であったり、他のユーザの動きに反応します。とは言えmixi疲れで言われるようにあまりに密なコミュニケーションはユーザを疲弊させ、サービスから離れていくきっかけになってしまいます。ほどよい距離感、ほどよい交流を促せる仕組み作りが重要と言えます。

インターネット上にサービスが溢れ、類似したサービスも多数存在します。そのような中にあって、必須のサービスになるというのは非常に困難です。現時点でそのレベルに達しているのはGoogle検索やGmailをはじめとするメールサービス、社内であればグループウェア程度ではないでしょうか。人によって観点は変わりますが、Facebookやmixi、ニコニコ動画、Twitterなどは非常に面白いサービスではあるものの、万が一1日落ちたとしても致命的な問題に繋がる可能性は高くありません(代替えのサービスも多数あるので)。そういう点においてユーザにとって最重要なサービスになるのは難しく、ソーシャルという仕組みは必須ではないものの、ユーザが手放せなくなるための手段としては有効です。

他社と異なるビジネスモデル

今のWebサービス企画において最も重要なのがビジネスモデルの構築です。特に他社と違う観点で捉えてサービスの形にすることが重要です。個人的にここ数年で最も素晴らしいと感じたのはAmazon EC2になります。自社の強みを無数のサーバを安定的に管理する技術力と捉え、それまではネットの本屋でしかなかったAmazonを一気にITエンジニア羨望のブランドへとのし上げました。単なるEコマース企業としては自社の強み、アドバンテージを想定する中でサーバに目を向けるのは非常に難しいことで、そこに目を付けた人はとても優れたプロデューサと言えそうです。

同様に自社の強みがどこにあり、それをどう提供することで新たな利益に繋がるかを良く検討する必要があります。この強みというのは現状の延長線上で捉えるのでは意味がなく、全く異なる視点、観点から見つめ直す必要があります。とは言え無理矢理ひねり出したものは一般的に捉えた時にどうしても無理なものにしか見えないため、他社が全く気付かなかった自社の強みを活かしたビジネスプランの構築ができればベストです。

このこれまでと違った見方から創出するビジネスモデルというのは、他社のビジネスモデルと衝突する場合があります。例えばAmazon EC2の登場によって多くのVPS業者がダメージを受け、ビジネスモデルの転向を余儀なくされました。同様にGoogleマップによって地図業者が、AdSenseによって多くの広告配信業者が淘汰されました。しかしAmazon、Googleは個々に別なビジネスモデル(AmazonはEコマース、Googleは検索)があるために、無料で提供することは問題視していません。他社のモデルを破壊することによって自社の利益に転じた形になります。そのようなビジネスモデルが考えられれば、素晴らしいことです。

モバイルの考え方

日本はモバイルの機能、シェアが高いこともありますのでこれからのサービスの企画においてモバイルを外す選択はあり得ません。むしろビジネス向けのモバイル提供や、スマートフォンを使った情報提供など積極的に関わっていく必要があります。現状、法人契約をした場合でもモバイルサイトの利用率は高くないと言われています(そのためキャリアはスマートフォンへの乗り換えを促進しています)。その見方では今後、PCを使ったビジネス時に利用されているサイト、サービスをモバイル向けに提供していくだけでも需要が発掘できる可能性はありそうです。

スマートフォンについてはネイティブアプリと最適化サイトの二つの選択肢があります。ネイティブアプリについてはこれ単体で収益化を成すというのは難しいというのが持論です。Webサービスと組み合わせつつ、サービスへのコミットを強めるものや(Flcikr向け写真アップロードなど)、ユーティリティ系のアプリであれば単体での収益化はできそうですが企業として提供するためには継続的なヒットが必要になるため、現状の価格帯(高くても1,000円程度)では計画を立てるのが難しそうです。むしろ最適化されたWebサイトの方が手軽、かつ多数のスマートフォンに対してサービスが提供できるメリットがありそうです。

Web API

Web2.0という単語が広く知られていた頃に多く取り上げられたのがWeb APIです。単純なものとしてはGoogleマップを使ったマッシュアップであったり、Youtube動画を検索したり閲覧できるようなものが流行りました。現在ではWeb API自体はサービスにとけ込んでおり、それ単体のリリースがパブリッシングに大きな意味を持つものではなくなっています。ですがWeb APIを使えばスマートフォンとの連携が容易になったり、自社のリソースだけでは足りないデータを利用できるようになります。欠点としてモバイルには弱いということがありますが、検討する価値は十分あると思われます。

なお、当たり前ではありますがWeb APIを利用するのは自社サービスで提供するコアの部分以外にすべきです。Web APIの停止によってサービス自体が動かなくなったり、無価値になってしまうような事態は避ける必要があります。

小さなビジネス

かつてのITバブルを未だに引きずる方は多く、世界中でサービスが普及し、Googleを抜くなんて言うケースが未だにあったりしますが、夢を見るのは個人レベルまでです。企業で取り組むのであればきちんと地に足を付けて取り組むべきです。そのためにはサービスの機能を絞り込み、必要最低限なレベルまでそぎ落とした上でマイルストーン重視で企画を立てる必要があります。機能が少なければ開発期間も短縮され、予定通りにリリースが出来ます。機能追加やカスタマイズ、作り込みは後からでも可能です。

小さく離陸し、徐々に高度を高めたり、補正したり進めることが大事だと考えています。そのため、プロジェクト予算の半分以上が運営開始後にかかるようにするくらいの施策が必要になります。機能を絞り込むことでターゲットを明確にし、効率的にアプローチできるようにするというメリットもあります。

継続性

上記ともかぶりますが、サービスを絶えず修正し、機能追加し、ユーザの声に応え続けることこそがサービスの成功率を高めると考えられます。リリースまででリソースを100%使い切ってしまうと、実際に使ってみた時点で分かった不具合への対応が遅れたり、その後の機能追加がされないためにいつまでもα版でい続けることがあります。また全くの新規性のあるサービスを構築したと思っても、同じようなサービスというのは世界中で何人もの人が考えていて、同じくらいのタイミングで次々に登場していきます。その時に差を生むのは継続的な開発、コミットメントです。プロデューサは得てして初期リリース時点で機能の豊富さを誇る傾向がありますが、それを堪えていかに初期リリース時点での機能を絞り込みつつ、リリース後の開発リソースを確保できるかを意識しなければなりません。

なお、継続的にサービス開発を行う場合、収益性を見いだすことは重要になります。収益増が見込めるからこそ継続的に資金を投入できる訳で、とりあえずサービスを立ち上げてビジネスはその後考えると言った手法はある程度まとまった予算がなければ難しいのが実情です。Webアプリケーション系サービスではリリース当初は無料で使わせ、ビジネスモデルが構築できずに運営費がまかなえずに閉鎖するケースが少なからず存在します。収益計画が元々の予定通りに進むことはまずありませんが、だからといってビジネスモデルを構築しないで良いという訳ではありません。

デザイン

類似したサービスが乱立している現在において、他サービスとの一線を画す要素が必要になっています。その最も重要なものはインタフェースであり、デザインであると考えています。機能的な面については利用しているうちに慣れたり、違いが分かってくるものですが、まずはサービスに触れて貰わなければ意味がありません。そこで重要になるのがデザインです。よりユーザビリティの高い、より触れてみたいと思わせるようなデザインと機能性(紹介動画など)をバランスよく配置できるデザイン力が必要です。技術的に優れたサービスは多数ありますが、技術に傾倒するとインタフェースが合理的になりすぎてしまい密集したデザインになったり、あまりに簡素なデザインになったりします。ちょっとしたアイコン、背景画像、左右のバランスなどに気を配れるかどうかでサービスの成功率が変わってくるのは間違いありません。

システム開発とデザインを平行で行うパターンは多いのですが、できればデザインから行うことをお勧めします。デザインを初期段階で詰めておけば、それによって必要な機能が分かってきます。実際のコーディングレベルまで落とし込む必要はありませんが、モックレベルでのデザインをある程度固めた段階でシステム開発とデザインコーディングを行うべきと言えます。時々あるのはトップページだけのイラストを作成して承認を得るパターンですが、これだけではあくまでもイメージに過ぎないため実際の開発段階で乖離する危険性があります。一通りのインタフェースについて作成する方が良いでしょう。

持たざる運営

ニコニコ動画やYoutubeのようにハードウェア、ネットワークリソースを過剰に消費するサービスでもない限り、自社の資産になるハードウェアリソースは極力持たないのが得策です。ごく小規模なサービスであればVPSで十分ですし、ある程度の拡張性を持たせたいならばAmazon EC2を使ったり、ニフティクラウドを採用することも考えられます。またGoogle App Engineを使えば拡張性もGoogleに任せることが可能になります。このような余計な資産を持たないことで、運営コストを低減させることはもちろん、撤退時のライン引きが容易になります。ハードウェアが勿体ない(または減価償却が済んでいない)から継続すると言ったような曇った判断をしなくて済みます。

最近話題になっているロシアの高校生が開発したオンラインチャットサービスChatrouletteはオンラインでWebカムを通じた膨大なチャットデータをやり取りしているのですが、実際のデータ授受はP2Pによって行われています。そのためサーバ側のリソースは殆ど使わずに済んでいるとのこと。このように一見すると中央管理サーバのリソースが膨大に必要に思えてしまうサービスであっても技術的な手法によってはほぼフリーに構築できてしまう時代ということです。元々のニコニコ動画がYoutubeやその他の動画アップロードサービスのコンテンツを使っていたように、いかにリソースを使わないで済むかを考えるのも面白いのではないでしょうか。

まとめ

サーバサイドJavaScript、クラウド、iPhone/Android、Rails、Zen-coding、フリーミアム、ソーシャルなど多数の言葉が出ては消えています。数年前ではWeb2.0が大きく注目され、去年であればSaaSのような*aas(〜as a Service)といった言葉が度々聞かれました。こうした単語は言わばバズであり、一つ一つの言葉について深く知る必要はあまりありません。が、その言葉の本質にあるものであったり、その流れが何であるかを知ることによって、次のクール(Webの世界では本当に3ヶ月程度で新しい流れがきます)ではどういったニーズが発生してくるか、それがどうビジネスに結びつくかを考えられるようになります。それが自社のビジネスとクロスオーバーするのであれば積極的に関わっていくべきであり、そのためには企画からリリースまでを短ければ3ヶ月、長くとも6ヶ月程度でリリースできるようなシンプルかつ拡張性を持たせられるような企画を考えていくべきです。

MOONGIFTではWebサービスの企画、プロデュースを承っております。ご用命、ご質問などはinfo@moongift.jpまでお気軽にどうぞ!

Leave a Comment

Please note: Comment moderation is enabled and may delay your comment. There is no need to resubmit your comment.

MOONGIFTネットワーク。こちらもぜひご覧ください。
MOONGIFT

Warning: array_slice() [function.array-slice]: The first argument should be an array in /virtual/producing/public_html/producing-web.com/wp-content/themes/network.php on line 15
  • No items
Open Service
Rails 2.0
Resident on Net
iPhone最適化
リーンソフトウェア
MarketPedia
Producing Web
Cool Coding