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

via Jackie O on Flickr - Photo Sharing!

もちろん、内容は全く同じではなく、というよりも個人的には全く違うコンセプトだと思ったのですが、他人から見た場合はどう思うでしょうか。恐らく、ちょっと似ていたら「似たようなサービス」になってしまうのではないでしょうか。

もちろん、模倣する場合は似たようなサービスと認識されることが大事になるかも知れませんが、それはただのパクリです。普通は差別化をはかりたいと思うところでしょう。ではどうやって差別化を図れば良いのでしょうか。

コンセプトが分かりづらいのは問題です。コンセプトを理解しないと使えないようなサービスは敬遠されてしまいます。なので、コンセプトが明確であるというのは前提条件だとします。

そして、使わないと何が違うのか分からないというのも問題です。ユーザはまず使う前に何が違うのか知りたいと思うでしょう。両方使ってみていい方を選ぶ等という時間がたくさんある人は殆どいません。何となく触れてみたり、画面のスクリーンショットを見たりして、自分に合った方を選択するのではないでしょうか。さらに言えば、最初に見た方を選択する、知名度のある方を選択する可能性の方が高いと思います。

これらの点を踏まえてサービスを考えると、出てくる答えは一つです。トップページだけで他の類似サービスと何が違うのか、はっきりと分かってもらうのです。他のサービスとの比較ではなく、自サービスの特徴や得意としている点を全面的に打ち出す必要があります。

例えばSNSというカテゴリーの中で、ビジネス系/地域系/趣味系と様々に分かれると思いますが、それでも似たようなサービスは多いと思います。さらに細分化して考えたときに、自分たちのサービスはこういう特徴がある、というのを訴えられなければなりません。特に日本のSNSのようなクローズ型の場合は中に入らないと（登録障壁を越えないと）次のステップが見えないため、登録を促せるような特徴を予め出さなければ登録者が増えるはずもありません。

サービスの明確な違いが打ち出せれば、ユーザにもそれは伝わるはずです。それがユーザにヒットするかどうかは分かりませんが、違いが打ち出せないサービスよりはよっぽども良いのは確実です。

via Panama Business 2 on Flickr - Photo Sharing!

正直に言って、運やタイミングなど超自然的要素が大きく関わっているとさえ思えます。どれだけ良いと思えるサービスをリリースしたところでユーザの心に響かないケースは多々ありますし、逆に何となく作った物が爆発的にヒットすることもあります。

もちろん、流行らせるための仕組みなどは考えるのですが、それが本当に流行るかどうかは全くの未知数です。たまたま大きなサイトのプレスリリースに重なってしまい、パブリッシュが全く効果なく終わったら、悲惨なことになります。

そう考えるとプランニング時点で収益モデルを策定することは大事ですが、収益分岐点などは全くの未知数と考えた方が良さそうです。考えたとしても、実際にその通りになる可能性は低いからです。

ではそうした現状を踏まえて、どういう対処法が考えられるでしょうか。

そのための最も最適な方法は、低い予算で発進することです。そのためには外部リソースを使ったウォーターフォール型の開発は避けないといけません。既存のリソース（オープンソースなど）を利用してプロトタイプをごく簡易的に立ち上げて市場を調査します。初期のシステムを改変することで間に合うならそれで良いですし、どうしてもスクラッチで開発しなければならないのであれば、期間に合わせた仕様を策定すべきです（例えば1週間程度の開発期間でできる範囲を考える）。

結果として今後も開発を続けてもビジネスになりそうだと判断できれば（3ヶ月程度を目安に）、継続的に開発またはオリジナルの開発を行います。それまではできるだけ低空飛行で考えていくべきです。

もちろん、サービスのコンセプト的に予算がかかってしまう場合もあります。その場合であってもハードウェアの予算を削ったりできるはずです。結果としてサービスの質が落ちる可能性がありますが、それはサービスのニーズが存在するということです。ニーズがあるのであれば、そのために追加予算を投じやすくなります。

サービスが流行るかどうか分からないのであれば、余計なリスクは避けるべきです。余計なリスクとはシステム面の固定資産になりやすいものを極力省くということです。空いた予算をマーケティングや営業資金として投入すれば、成功に近づくことができるはずです。

MOONGIFT: » [PR] プロデューシング/コンサルティング承ります:オープンソースを毎日紹介
　http://www.moongift.jp/2008/04/producing_and_consulting/

via on Flickr - Photo Sharing!

営業窓口として

これは基本だと思います。企業サイトの大半はこれだと思います。

ブランディング

ブランディングのためにWebサイトを立ち上げる場合は、企業イメージを変えていくためであったり、情報を流したい相手を集めるために旗を立てる目的が多いです。

SEOのため

あまり褒められたものではありませんが、ある目的に合わせたサイトを乱立させ、そこからリンクを貼ることでSEO上の目的に役立てるものです。

調査目的

ある目的のサイトを立ち上げるにあたり、ニーズがどれくらいあるのかを測定するために使います。簡易的なブログやCMSの形式を取ることが多いです。

ラボ

技術者向けの情報や、自分たちの技術力を外部にアピールする目的で運営します。本業サイトに適用する前の実験や実験的サービス立ち上げの場としても利用されます。

社長ブログ含む企業ブログ

IRやラボなどの目的で運営されます。

オープンソース

企業内の技術力アピールをさらに進め、マーケティング目的やそこからのサポート、カスタマイズ要件で仕事を獲得したい等の意図があります。

買収待ち

人気のあるサービスを立ち上げて、大手企業による買収を待ちます。海外のスタートアップに多いですね。

ここまではおおよそ企業向けですが、さらに個人の場合が入るとパターンが増えます。

腕試し

何となく面白いサービスを作りたくて作るパターンです。数日で立ち上げることが多いです。

マッシュアップ

面白いWeb APIがあった時に、それを使って注目を集めたいなどの目的があります。

個人のブログ含め個人サイト

メモ、日記、技術アピール、映画の感想…などなど人によって目的が変わります。趣味の場合も多いです。

最近のWebサイトは開発コストも運営コストも相当低減しているので、何となく立ち上げたサービスでそのまま放置していても殆どコストはかからずに動き続けます。また、日々新しいサービスが立ち上がるために、ユーザの心変わりもはやく、初日から二、三日でアクセスが急激に下がってしまいます。そのため、目的を明確にして、その目的を達成するまでは継続的にサービスをアップデートしていく必要があります。

また、最近のWebサービスの特徴として、無料が前提という流れがあります。実際、有料でコンテンツを提供しているサイトというのは数えるほどです。有料だとしても、一般ユーザからは徴収していない場合が多いです。その意味では企業向けサービスの方が料金を取りやすいと言えます。

ブランディングなどは無形資産で、その価値換算が難しいので、予めどれくらいのコストで実施するかを定めておく必要があります。そしてその結果の測定方法を明確にしておくことが重要です。