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

via Jackie O on Flickr – Photo Sharing!

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

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

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

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

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

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

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