via Red #4 on Flickr - Photo Sharing!
今更感もあるのですが、日経ビジネス2008.1.7号の岡田武史氏×平尾誠二氏の対談の中で、私が常に人にいっていることと同じ内容がありました。
岡田 …欧州などのトップレベルに比べてフィジカル面が劣ると書かれている。その差は同じ方法で追いかけている限り、いつまで経っても縮まらない。それなら、別な道と言うか、日本人にしかできないやり方があるんじゃないかと思うんだよ。…
平尾 …だから、この後を追いかけていっても絶対に勝てっこない。独自性とか、彼らにない常識感とか、こういうものを加えて強化していかないと勝てないですよ
Webサービスを作る中では特に勝ち負けが明確にある訳ではないので、単純に比較できるわけではないのですが、私見ではどうせWebサービスを作るのであれば世界を相手にできるもの、さらにそこに日本人ならではの仕組みを組み入れて欲しいと考えています。フィーリング的なものなので、人に言ってもあまり理解はされないのですが。
では日本人らしさというのは何なのかについては以下にて。
例えば未ログイン状態では機能せず、ログインしてはじめて機能するものがあるとします。ブログ記事を編集するためのリンクや、Twitterでフォローするための機能などです。未ログイン状態からそうしたものを見せてしまうと、ユーザを混乱させる可能性があります。なので、ログイン前と後の判断をして、表示/非表示を切り替えているサイトが多いです。
via I Know Who Dies! on Flickr - Photo Sharing!
が、ここで逆説的に考えてみます。あえて表示しておくメリットです。そして、個人的には予め表示しておく方が良いのではないかと思っています。
その理由は以下より。
Webサービスにおいてコンセプトは重要です。また、このコンセプトは一番最初に決められるべきものです。全ての作業はコンセプトを軸にして行い、そこから外れないように注意深く決めていく必要があります。
via Share This Icon Concept #1 With Peers on Flickr - Photo Sharing!
コンセプトは端的で分かりやすく、誰でも理解できるものが理想です。後付けで決めたり、変化していくといい結果に結びつきません。
大抵、こうしたことは誰でも理解してくれるのですが、実際のプロジェクトでは明言されることはあまりありません。何となく雰囲気で伝わるだろう的な感覚だけで共有されてしまっています。熟したプロジェクトではそのような形でも良いのですが、新しいサービスを立ち上げようとする中ではお勧めできません。コンセプトは明言すべきです。そうしないとどういう基準で、誰をターゲットにサービスを開発すれば良いのか曖昧になってしまいます。
ではどういったことをコンセプトにすれば良いのでしょうか。
OpenIDが日本で普及するかどうか。RSSがなぜ普及しないのか。ごく簡単に言えば、どちらも横文字だから普及しないだろうというのが持論です。Blogが流行ったのは、ブログという片仮名表記が三文字で気持ちよかったから。また、日本人特有の略して言うのに「モバイル＋ブログ＝モブログ」というのがちょうど語感が良く、携帯文化ともマッチしたからでしょう。Web Diary → ウェブダとか言っても流行らなかったでしょうね。
via IMG_6879.jpg on Flickr - Photo Sharing!
ということで、サービスを開発する際にネーミングセンスというのは非常に重要です。ネーミングセンスだけでサービスが流行るかどうかが決まると言っても過言ではないくらい。Webサービスはすぐに模倣できるので、同じようなサービスが二つあった時に、初見での面白そうな感じ、サービスの流行度、そしてネーミングは重要な要素です。
では日本語圏向けにサービスを提供する場合のネーミングはどのようにするべきでしょうか。
などが大事かと思います。もちろんこれはターゲットユーザ層によっても変わります。アクティブシニアを対象に老とか、健康とかそういったイメージを与える言葉は危険です。むしろ旅行、遊び、海、太陽などの言葉を連想できる物の方が良いでしょう。
格好いいイメージを、なんて理由で横文字を並べるケースが多いですが、それは罠にもなります。ユーザにとって必要なのは安心感です。心にすっと入ってくるサービスほど好まれるというのを忘れないでください。
日本ではまだまだ少ないのですが、海外ではWeb APIについてもどんどん双方向性が進んでいます。フィードを配信する、独自のXMLやJSONでデータを受け取れるようにするだけではなく、データを登録、更新、削除するのもWeb APIから可能になっています。
via Blue Keyboard on Flickr - Photo Sharing!
日本ではまだまだ囲い込みの意識が強く（囲い込みになっているかどうかは別として）、サービスを外部から変更できることに対する抵抗が少なくありません。そのため、データを外部に公開する＝Web APIであるという意識が根底にあります。これはWeb APIの第一人者でもあるAmazonやGoogleの初期段階におけるWeb APIが内部データの外部公開にあったからということもあります。
が、本来のWeb APIとはアプリケーションインタフェースのことであり、I/Oを決めたものではありません。また、最近の海外で見られるWebサービスはサービスのローンチと同時にWeb APIを公開し、さらに出力のみならず入力もWeb API経由で行っています。
これがどういった競争力を生み出すかというと、入力インタフェースを公開することで、サービス提供企業が考えているよりももっと手軽で便利なインタフェースがマッシュアップによって開発される可能性があります。が、それは全く問題ではありません。内部データの増大はコンテンツの増大を意味しますので、さらにユーザを引きつける原動力になります。その意味では、出力系のWeb APIよりも、入力系のWeb APIに力を入れるべきです。
企業がWebサービスを提供するということはビジネスなので、収益を上げる必要があります。その際の方法として考えられるものをリストアップしてみました。
via $5700 on Flickr - Photo Sharing!
これは基本ですね。PVを集めてそこに広告を打つ方法です。広告代理店またはダイレクト取引で出稿主を集めます。この場合、サイトにおけるターゲット層が明確になっている必要があります。（例：Yahoo、Google、mixi、各新聞社サイトなどなど）
これも基本的な方法です。物を売る代わりにお金をもらいます。（例：Amazon、HMVなど）
これはネットならではですね。ダウンロード販売や、iTMSなどです。（例：Vector、Amazon MP3、iTMSなど）
VPSや共用サーバ、専用サーバと言ったサービスです。これらは初期費用＋月額費用、場合によっては転送料によって構成されます。（さくらインターネット、各種ホスティングサービスなど）
これは何らかの特典をつける代わりに月額費用などでお金を徴収するサービスです。（例：ニコニコ動画、Yahooプレミアム、Napster、ぽすれん、Google Appsなど）
これは利用者間で発生する取引において、一部をサービス手数料として徴収するものです。ちょっと形式は異なりますが、金融系の手数料もこの中に含んで考えていいと思います。（例：Yahoo!オークション、Amazonマーケットプレイスなど）
広告の積極的版とも言えます。広告に関連づいた情報を提供することで、広告を結果に結びつけやすくします。
2006年くらいから登場したビジネス形態です。サービス提供側は商品を用意し、発送、収支を行います。販売は登録ユーザに任せます。アフィリエイトに似ていますが、売価が登録ユーザに任せる点が異なります。
利用度に応じて金額を支払う形式です。利用しなければ課金はされませんが（基本料はない）、利用すれば課金が発生します。（Amazon EC2、Amazon S3など）
過去においてはASP型と呼ばれていた形式です。Webアプリケーション化の波をうけて、さらにWeb上で完結できる形式になってきています。（Salesforceなど）
Paypalなどを通じた寄付です。日本ではあまり多く見かけませんが、海外ではフリーウェア、オープンソース・ソフトウェアに対するドネーションはよく見られます。（各種ソフトウェア、Wikipediaなど）
ではこれらの中で、最もビジネスとして有効なのはどれになるでしょうか。
プロジェクトの成功可否を握るのは何でしょうか。予算、スケジュール、技術力…確かにそうしたものも重要です。ですが、これらは外部に求めたり、方法を選べばまだ回避できる可能性があります。
via 12 01 07 - My New Setup on Flickr - Photo Sharing!
もっとも重要な要素は人材です。特に責任者のプロジェクトにかける情熱が一番重要になります。
外部に開発を任せた場合、仕様を策定した時点で開発作業が開始され、内部からは状況が若干分かりづらいものになります。このとき、責任者の情熱が低く、外部任せにしてしまうと、期日近くになって出てきたものは予想を裏切るものになっているはずです。
「開発するのは外部？内部？」でも書いた通り、プロジェクト管理とはプロジェクトがビジネス的に成功したかどうかの判断になります。システムがみすぼらしくとも、予測を上回る収益をあげていたら成功です。逆にシステムがどれだけ立派であっても、収益が全く駄目であれば失敗です。
仕様策定はプロジェクト管理における4分の1がようやく終わったにすぎません。その後、開発→テスト→運用のフェーズに入ります（他の要素もありますが、それらは同時進行が可能なものもあるので）。そう考えるとこの時点で外部リソースに任せてしまうのは失敗の元になるでしょう。
Webサービスを新しく構築する際に、外部のリソース（SIerなど）と内部のリソースを使うのとどちらが良いのでしょうか。
via Skype Reverie on Flickr - Photo Sharing!
これまで経験してきたプロジェクトでは、どちらかと言えば外部のリソースを使って最善の結果を得られたことの方が少ないように思えます。最も大きな原因は「プロジェクト」における両者のスコープの違いです。
外部のリソースにとってのプロジェクト管理とは、言わばプロダクト管理の範囲に収まります。つまり、開発して納品、検収をうけるまでがプロジェクト管理です。逆に内部の人にとってのプロジェクト管理とは、システムを実際に動かし、収益を黒字化することがプロジェクトになります。
外部のリソースにとってのゴールは、内部のリソースにとってみればスタートでしかありません。システムは箱であり、実際にそれを使わないと意味がないのです。その点の認識のずれが、プロジェクトの後半になるにつれてどんどん大きくなっていき、それが悪い結果につながることが多いです。
金額が大きくなればこのずれは埋められることもあるのですが、1,000〜5,000万円くらいの開発規模ですとずれの修正にかかるコストが大きく、どちらがそれを吸収するのかで外部と内部で軋轢を生みやすくなります。
|
MOONGIFT
|
Open Service
|
|
Rails 2.0
|
Residentof.net
|
|
Cool Coding
|
Producing Web
|
admin | 
04 11th, 2008| 