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までお気軽にどうぞ!

via Just Full Of Ideas on Flickr – Photo Sharing! [ Flickr ]

そこで必要なのがアイディア・モデルです。MOONGIFTでは概ね3つのモデルがあると考えています。

• コンサルティング型
• プロデュース型
• クリエイティブ型

になります。個々については詳細にて説明を。

コンサルティング型

コンサルティングの場合、マーケティングデータや信頼できる数値データ、白書などをベースとして考えられる施策を練ります。そのため、大筋として間違った提案は出てきません。むしろ数字の後ろ盾があった上で出てくるので、信頼感があり、提案している本人も内容に自信が持てます。

また数値をベースにして考える案も、フレームワークを組み合わせて出されるものになっており、論理的には正しい答えが出てきます。逆に言うと突拍子もない意見は出てきませんので、新規性を求める場合には向かない形になります。

コンサルティング型が向くのは、社内業務の改善や顧客向けの提案の場合になります。特に業務カイゼンなどでは数値化、見える化する必要性がありますので特に有効です。

プロデュース型

プロデュース型は音楽の世界などでよく使われてきました。プロデュースの場合、クリエイティブな要素が必要とされているように思えますが、実際のところそうでもありません。むしろ一つ当たりを引くと、それを水平展開する傾向にあります。そのためJ-POPでは同じようなグループ、同じような歌ばかり叛乱する結果になりました。とは言え、プロデューサーとしては、自分の嗅覚を頼りにビジネス的な成功を保証しつつ進める必要があるため、チャレンジングな試みはあまりしたがらないのが通常です。

プロデュース型の場合、トレンドを掴んでいるプロデューサがいる限りは問題ありません。時代の流れを掴みきれず、過去の栄光に固執する可能性がある点が注意です。コンサルティング型よりはフィーリングに依るところがありますが、ビジネス的な実務面も含んで考えられているのでより具体的、より実践的なアイディアが出てきます。

クリエイティブ型

クリエイティブ型はこの中で最も新規性、感性に頼ったモデルになります。目新しさはあるのですが、成功する後ろ盾はあまりありません。先駆者がいないため、成功したとすればブルーオーシャンが広がっている可能性があります。失敗した場合は全く日の目を見ずに終わります。

クリエイティブ型の場合は新規事業を創出する場合や、全く違いアイディアを求める時に利用できます。また、そのようなアイディアの出し方が許されるような環境があることが重要です。

お勧め

お勧めなのはプロデュース型、もしくはクリエイティブ型を発端にコンサルティング型で補強するというパターンです。ケースによりますが、最初から数値に頼って話を進めると途中で頓挫することが少なくありません。そもそも魅力的な市場であれば誰かが先鞭をつけている訳で、それがないということは市場が魅力的でないか、何らかのリスクが隠れているということになります。とは言えリスクを取らずに旨味だけを得ることは難しいのは事実です。その辺りは次回に書きたいと思います。

It’s real? Sure, my site “MOONGIFT” is introduce opensource software and there is a trend toward big Firefox’s share. But Google Chrome is growing after Sept 1st. It’s already got ahead out Opera. I don’t bereave that.

9月1日から5日のアクセスログからなのですが、Firefoxのシェアが50%近くを占めているのは良いとして、Google Chromeの急成長が目立ちます。すでにOperaさえ抜き去っています。にわかには信じられないですね。

via Roatan – Paradise, Please Enter on Flickr – Photo Sharing!

休みの日というのは総じてネットへのアクセス量が減る傾向にあります。短い時間を効率的に使える（移動が不要、どこでも使えるなど）ネットではなく、移動時間も増え、自由な時間が長く取れるためにそうした時に適したことをするためです。普段仕事でネットやコンピュータを使わざるを得ない中で、休みの日まで…という感情もあるでしょう。

サービスを開発している中でも休みの影響度は常に考えておくべきです。長期休みの前後は仕事モードが低減しているので、ミーティングに身が入らなかったり、回答が遅くなりがちです。また、稼働日で20日程度を考えていた場合、お盆休みで1週間つぶれたりすると15日程度の稼働日になってしまうことがあります。

また、休みの前後にパブリッシングを行うのも危険です。最近は情報の新鮮度がすぐに劣化してしまうので、休み前にリリースなどするとすぐに忘れ去られてしまいます。さらにメディアによって取り上げる日はずれることがあるので、休み中に記事になるか、そもそもメディア自体休みの間は稼働率が低下する恐れがあります。

そうなると休みがあるからと開発が若干遅れる→パブリッシングが遅れる→さらに週末→週明けにリリースといった具合に数日の遅れのはずが、リリースまでに一週間以上遅れてしまうことが多々あります。三連休程度でも、1日の開発の遅れが全体の足並みを乱してリリースまでに5日遅れるといったこともざらです。

タイムラインを定める際には、休暇も頭に入れた上で計画を組むのが重要です。自分たちは頑張れるから大丈夫、と思っても世間的にはお休みになるので外部との接触部分は世間のスケジュールにあわせて組んでおく必要があります。そのためには元々きつきつのスケジューリングを避け、余裕をもたせておくのが重要です。

実際、数日の遅れでビジネスがどうこうなることはそれほど多くないと思います。が、ビジネスうんぬんではなくスケジュールから脱線すると大勢が影響を受け、稼働率を上げざるを得なくなるので、注意が必要です。

TISがRuby on RailsベースのSNS「SKIP」をオープンソース化：ITpro
　http://itpro.nikkeibp.co.jp/article/NEWS/20080519/302686/

via Someone’s Lost Schedule Book on Flickr – Photo Sharing!

自社のSNSをオープンソース化すると言う記事です。おお、素晴らしいと思う反面、非常にもったいない点が二点ほど。

まず一点目。記事内にある、

2008年夏に公開する。

…そう、この時点ではまだ公開されていません。ネットの社会になって情報の新鮮度とその劣化がどんどん激しくなってきています。一時の炎上した、というニュースが数日のうちに風化してしまうことなどざらです。同様に広まったニュースもあっという間に話題性がなくなっていきます。

夏、となっているのですが実際に公開された時点で覚えている人がいるでしょうか。また、メディアも既にこうして記事にしている中、公開したということで再度取り上げてくれるかは疑問です。

二点目。それはSKIPという名称まで決まっているのに、専用のURLがないことです。skip.comというような独自ドメインを取るか（さすがにこのドメインは無理でしょうが）どうかは分かりませんが、せめてComing soonのページは欲しいところです。

また、そこにはRSSフィードか、メールアドレスを入力して案内を受け取れるページがあるべきです。それがないので、恐らくリリースや記事を見て数日は覚えていても、あっという間に忘れ去られてしまうのではないでしょうか…。良さそうなだけに非常にもったいないですね。

ということで、リリースをするならせめてタイムラインが決まってから、さらに風化させないために一両日中に追加のアクションが打てるようにする。もう一つはプッシュ型の案内を出す方法を用意しておくのが大事だと思います。

RSSフィードなんて普及率を考えると登録してくれるの、と思うかも知れません。ですがそうしたニュースを捉えたいと思っているブロガーや記者は登録してくれます。そして（面白い内容であれば）配信と同時にブログなどで記事にしてくれ、波及させてくれます。その意味で大人数の登録ではなく、ネットリテラシーの高い、影響度の高い人たちに対してRSSフィードでの情報配信は重要と考えられます。

via Changes to site permalink page on Flickr – Photo Sharing!

なぜ必要かと言えば、プロジェクトメンバーと意識を共有するためです。これがずれていると、プロジェクトの進行方向が徐々にずれていってしまいます。そうならないよう、初志を書き出しておくことで、定期的に見直し、改訂してプロジェクトを進めていくのが重要です。

そこで今回は私がWebの企画書（自分用ではなく、他社への提案用）を作る際に注意している項目を書き出してみました。実際は、これらを必要に応じて削除/追加したりします。

□ コンセプト

最も大事ですね。端的な言葉でサービスの概要を言い表す必要があります。

□ サービス名

これは二番目に大切です。といってもまだ決まっていない場合もあるので、その場合はプロジェクトAとか適当に…。

□ 概要

こちらはコンセプトの詳細です。とは言え長ったらしく書くと理解に苦しむので分かりやすく。

□ ターゲット

ターゲットユーザ層を明確にします。性別や肩書き、職業、年齢その他条件をできるだけ絞り込みます。そうすることで自分たちがどういった人を相手にWebサービスを提供するのか再認識できます。

□ 特徴

Webサービスの特徴を書き出します。

□ 機能

Webサービスの主な機能を書き出します。

□ キーワード

サービスのコンセプト内で使われている用語などで、サービスのキーになる単語を書き出します。これを使ってSEMを考えたり、競合サービスを明確にしたりします。

□ 利用メリット

サービスのメリット（使い手）を書き出します。これがよく分からないようだとサービスとしてどうなのでしょう、となります。

□ 予算

リリース前、リリース後の概算の予算を出します。金額が分からない場合は○○円でとりあえず項目だけ挙げておきます。

□ 収益予測

予想される収益ラインを想定します。

□ 開発体制

リリース前の体制図です。情報伝達方法や決裁者も明確にしておきます。

□ 運用体制

リリース後の体制です。こちらも開発体制同様に、連絡先や利害関係者を明確にします。

□ 主なコンテンツ

Webサービスで提供する主なコンテンツをリストアップします。

□ リリース時のコンテンツ

リリース時点でのコンテンツ（とその量）を書き出しておきます。言わばリリース目標です。

□ 運用時のコンテンツ

運用時のコンテンツ拡充方法です。これによって運用体制や方法が決まってきます。

□ パブリッシング

パブリッシングを行う先やその方法です。ターゲットユーザによって異なります。

□ タイムライン

プロジェクトのタイムラインです。何があるか分かりませんが、とりあえず決めておきます。

□ セキュリティ

情報漏洩防止策、運用管理方法などの注意点を定めておきます。

□ 法律

Webサービスをリリースする上で関わってくる法律とその対処法をリストアップしておきます。

□ 対応言語

Webサービスの言語（日本語、英語など）です。

□ 開発言語

プログラム関係の話です。これによって開発体制が異なってきます（逆に開発体制がこれだから、言語が決まるという場合もあります）。

□ ハードウェア

調達先や設置場所、配置図を考えます。

□ ネットワーク

ハードウェア同様です。

□ SEO/SEM

SEOは業者を使うか否か、同様にAdWordsやOvertureといった広告をどう扱うかになります。SEOは一からコンテンツを積み上げる場合、いきなり結果が得られづらいので、パブリッシングや事前のコンテンツ拡充などが必要になります。

□ 集客

サイトへの集客方法です。SEOや口コミ、ブログからの誘導、電話、広告、FAX…などなどです。

□ オフラインの捉え方

オンラインだけでなく、オフラインに対してどうアプローチするか考えます。

□ ターゲット環境（モバイル/PC等）

Webサービスのターゲット環境を想定します。

□ デザイン

デザイン上の注意点を書き出します。ターゲットユーザを意識して行う必要があります。

□ 競合

競合サイトをリストアップします。

□ マーケティングデータ

Webサービス企画を押し進める上での第三者データがあれば書きます。

□ 権限

Webサービス内に存在する権限を書き出します。

□ ビジネスフロー

Webサービスを含めたビジネスフローを定義します。

□ プロジェクトの進め方

企画が通ったとして、プロジェクトをどのように進めていくか書いておきます。

□ 備考

その他備考や注意点をリストアップします。

主立った項目としては以上でしょうか。もちろん、企画段階ですべてを決められる訳ではないので書けない項目もあります。が、単なるアイディアを書き出したところで会議の場で企画としては浅いと思われてしまうのがオチです。アイディアから企画へ押し上げることで、プロジェクトとして認可され、開発がスタートする可能性が上がってくるのではないでしょうか。

via Jackson’s Haircut on Flickr – Photo Sharing!

が、二番手、三番手のサービスとは大きく差を広げてサービスを展開しています。これは先駆者有利もありますが、それ以外の理由もありそうです。詳細は以下にて。

まず大事なのが、できるだけ手軽に利用できるという点です。そこには従来のPVを増やせば…的な考えはありません。実際、twitter等専用のアプリケーションを通じて利用し、Webの画面は殆どみないという人も多いのではないでしょうか。

また、Youtubeも閲覧するだけの人にとっては、ブログやその他の紹介サイト等で見るだけで、Youtube自体を強く意識することはないかも知れません。この方法を使う場合、PVというのは殆ど意味がなくなってきます。

そしてPVを気にしないことによって、ユーザにどれだけ手軽にストレスフリーに使ってもらえるかを追求できるようになります。野暮ったい画面はなし、何度もクリックさせる必要もなし、シンプルにユーザの要求を達成できるような仕組みを考えられるようになります。

その好循環が生まれるようになると、ユーザはよりシンプルで使い勝手の良いサービスを利用するようになります。さらにUGM（ユーザ・ジェネレーティッド・メディア）がベースになっているため、ユーザの登録したコンテンツが価値を生み出していきます。ユーザにとっては多数のデータを移動させるコストが徐々に増大していくことになり、いつしか同じサービスだけを使い続けることになります。

つまりオープンにする（PVを気にしない）→ユーザにとって使いやすい仕組みを提供→コンテンツが増える→ユーザが固定化する、という循環になります。PVやUUといった指標の中だけで判断していると、このスパイラルが生み出せません。そしてその中でどうビジネスとして考えていくかが重要になってきます。

via In Every Dream Home a Heartache on Flickr – Photo Sharing!

予算がきちんと確保されている場合はそうでもないのですが、大抵はそうではありません。限られたリソースの中で、相手に言わせすぎると、後々不要な問題を生み出します。

それは何でしょうか。

まず、相手には何となくのイメージしかありません。それは人に話している内に徐々に具体化していきます。そして具体化していく過程の中で、徐々に羽がはえ、顔ができ、勝手に話し始めたり、走っていってしまったりします。

そして、相手は話した内容が全て実現するものだと思い込んでしまっています。もちろん、説得すれば分かってもらえるのですが、満足度は低くなりがちです。また、相手の要望を聞いた挙げ句にスクラッチで開発する必要があります、予算はこれこれです、と伝えて通った試しがありません（これは相手にもよるのでしょうが）。

そうなると願望から具体化の、現実を見る作業へと移る必要が出てきます。この作業は非常に辛く、生産的ではありません。長くやっていれば、満足度やモチベーションはどんどん低下していきます。これはまずい例です。

ではどうするかと言うと、願望の段階で簡易的なもの（できればオープンソースやフリーウェア）で見せてしまうのです。悪く言うと、はじめに現実的な解を提示して、型にはめてしまうということです。しかし願望が広がる前なので、相手はそれほど不満を覚えません。むしろ形が一つ出てきたことによる満足感があります。

そして、どうしてもゆずれない部分（これがないのは逆に問題です）について話し合います。それが初期段階から必要であれば実行計画を考え、もし延期可能であれば保留にするといった具合です。絶対に願望が先走るようなことは避けないといけません。

または紙に落とし込むのも大事です。とにかく初期の段階から何らかのアウトプットにしていくことで、願望が小さい段階から具体化していくのがコツと言えます。

via IMG_0905 on Flickr – Photo Sharing!

今から7、8年前のベンチャーブームくらいの頃は、ベンチャーキャピタルから入ったお金をハードウェアにも潤沢にまわしている企業が多かったと思います。ハウジングでサーバを構える場合、複数台のサーバはもちろん、ロードバランサやSSLアクセラレータ、ルータなど様々なハードウェアを購入する必要がありました。

それから数年経って見返してみると、ハードウェアの進化は目覚ましいものでした。数年前に最高だと思ったパーツは陳腐化し、それよりも高性能なものが格安で手に入るようになっていました。DellやHPの台頭も大きかったように思います。

その頃のことを思うと、ハードウェアを購入するという選択はあまり良くないように思えます。技術の進歩は凄まじく、数年後がどうなっているのか分かりません。そうした中でハードウェア資産を無下に増やすのは得策ではありません。

では次にどういった選択があるでしょうか。

リースという選択肢もあります。小規模なベンチャーで、まとまったお金はなくとも、立派な機器を揃えられる可能性があります。ですが、これも先と同様の理由であまりお勧めできません。途中で止めることもままならず、陳腐化していくハードウェアに対して、当初の高い金額を支払い続ける必要があるからです。

そこで考えてみたいのがホスティングやVPSの類のサービスです。VPSは海外のものであれば相当格安で提供されるようになっています。また、日本でも数万円/月から提供されるものも少なくありません。

ハードウェアのスペックも上がってきています。セットアップ、ハードウェアのサポート、障害対応の要員等も考えると、それらを全てアウトソースしたと考えても悪いものではないと思います。

他にもAmazon EC2/S3を利用するという選択肢もあります。SSHは日本からでは若干遅めですが、OSの幅広い選択肢、セットアップの容易さ、堅牢性等を考えると個人的にはお勧めの選択肢です。他の専用サーバなどのサービスと異なり、初期費用がないのも利点です。

サーバ（インスタンス）を停止するとデータが消失するということがあるので、その運用には別な注意点が必要ですが、慣れてしまえば問題ありません。必要になったら即座にサーバを追加することもできます。

Webサービスではニーズやウォンツに合わせ、日々変化していくことが求められます。ハードウェアも同様に変化に柔軟になれる選択肢を考えるべきです。

via Sifting Lines: Looking For Evidence at Fresh Kills on Flickr – Photo Sharing!

大手企業であればまだしも、私がおつきあいする中小企業であればそのようなゆったりとした時間で物事は考えていられません。ましてやWebサイトは既に動いています。悠長に分析などやっていたら、どんどん時間の流れが状況を変えていってしまいます。

ではどのような改善方法をとるべきなのでしょうか。

単純に言うと、アクションを起こすのです。そのアクションははじめは小さいものから、徐々に大きいものへと変えていきます。小さなものは単純に担当者レベルでできるものや、数日でできるものもあります。ただ、大事なのはアクションを起こすということです。

測定値は予め決まっている訳ですから（現状の売上、PV、勤務時間等）、小さなアクションの積み重ねであっても、結果が出てくれば良いはずです。大きな旗を一つふろうと思うと色々と準備が必要で、その結果が正しいかどうかは数ヶ月間の結果測定を行う必要がありますが、小さな旗の積み重ねであれば、どんどん振って、どんどん状況を変えていくことができます。

また、大きな承認はとれづらいですが、小さな承認は担当者レベルで進めることだってできます。結果が出てくれば、徐々に大きな話にしていっても、全体の納得感が得られやすくなります。

Webサイトは玄関としては大事ですが、中の人も、ユーザも人間同士です。多少の見栄えよりも、丁寧な対応や迅速な行動の方がインパクトが大きいものです。仰々しく考えるのも良いですが、今の状況からでもできることをやってみるところからはじめてみましょう。