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さえ抜き去っています。にわかには信じられないですね。
日本はやたらと休みが多いように感じます。例えば、今からWebサービスを開発した場合、お盆休みが問題になりがちです。学生を対象としたサービスであれば、夏休みの影響も忘れられません。9月あたりも連続休暇があると言いますし…（５連休だそうです）。
via Roatan - Paradise, Please Enter on Flickr - Photo Sharing!
休みの日というのは総じてネットへのアクセス量が減る傾向にあります。短い時間を効率的に使える（移動が不要、どこでも使えるなど）ネットではなく、移動時間も増え、自由な時間が長く取れるためにそうした時に適したことをするためです。普段仕事でネットやコンピュータを使わざるを得ない中で、休みの日まで…という感情もあるでしょう。
サービスを開発している中でも休みの影響度は常に考えておくべきです。長期休みの前後は仕事モードが低減しているので、ミーティングに身が入らなかったり、回答が遅くなりがちです。また、稼働日で20日程度を考えていた場合、お盆休みで1週間つぶれたりすると15日程度の稼働日になってしまうことがあります。
ちょうど良い題材が。
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をオープンソース化すると言う記事です。おお、素晴らしいと思う反面、非常にもったいない点が二点ほど。
Webサービスの企画を行う際に、企画書を作られることがあるかと思います。個人で作るサービスであれば作らないこともあるでしょうが、企業として取り組む場合には必要なものです。
via Changes to site permalink page on Flickr - Photo Sharing!
なぜ必要かと言えば、プロジェクトメンバーと意識を共有するためです。これがずれていると、プロジェクトの進行方向が徐々にずれていってしまいます。そうならないよう、初志を書き出しておくことで、定期的に見直し、改訂してプロジェクトを進めていくのが重要です。
そこで今回は私がWebの企画書（自分用ではなく、他社への提案用）を作る際に注意している項目を書き出してみました。実際は、これらを必要に応じて削除/追加したりします。
囲い込みしないのに、囲い込む…矛盾しているような気もしますが、実際そうなっているケースが多いです。2.0系のサービスのYoutube、Wikipedia、Facebook、digg.com、Googleドキュメント、twitter、Flickr、del.icio.usなど様々なサービスがありますが、これらはデータをどんどん公開し、Web API等を通じてたのアプリケーションと組み合わせられるようにする、ユーザ登録をせずともある程度楽しむことができるなど、それまでのWebで当たり前になっていた囲い込み戦略を殆どとっていません。
via Jackson’s Haircut on Flickr - Photo Sharing!
が、二番手、三番手のサービスとは大きく差を広げてサービスを展開しています。これは先駆者有利もありますが、それ以外の理由もありそうです。詳細は以下にて。
プロデューシングは、相手の要望を聞き、それを具体化し、計画を立て、推進する技量が必要になります。そのため、まずは相手のニーズを聞く必要があります。が、大事なのはご用聞きになってはいけないということです。
via In Every Dream Home a Heartache on Flickr - Photo Sharing!
予算がきちんと確保されている場合はそうでもないのですが、大抵はそうではありません。限られたリソースの中で、相手に言わせすぎると、後々不要な問題を生み出します。
それは何でしょうか。
ビジネスは100%うまくいくという保証はありません。これはWebに限らず当たり前のことでしょう。うまくいくはず、と信じることは必要ですが、絶対ではありません。そうした不安定な中で、ハードウェアに関してはどう対応すべきでしょう。
via IMG_0905 on Flickr - Photo Sharing!
今から7、8年前のベンチャーブームくらいの頃は、ベンチャーキャピタルから入ったお金をハードウェアにも潤沢にまわしている企業が多かったと思います。ハウジングでサーバを構える場合、複数台のサーバはもちろん、ロードバランサやSSLアクセラレータ、ルータなど様々なハードウェアを購入する必要がありました。
それから数年経って見返してみると、ハードウェアの進化は目覚ましいものでした。数年前に最高だと思ったパーツは陳腐化し、それよりも高性能なものが格安で手に入るようになっていました。DellやHPの台頭も大きかったように思います。
その頃のことを思うと、ハードウェアを購入するという選択はあまり良くないように思えます。技術の進歩は凄まじく、数年後がどうなっているのか分かりません。そうした中でハードウェア資産を無下に増やすのは得策ではありません。
では次にどういった選択があるでしょうか。
Webサービスのコンサルティングは新規ばかりに限らず、現状の改善も行うことがあります。その際に注意すべきなのは、改善のためのプロジェクトチームを組み、何度も会議を重ね、レポーティングし、優先順位をつけ、承認を経て、そして実行に移す。では駄目だと言うことです。
via Sifting Lines: Looking For Evidence at Fresh Kills on Flickr - Photo Sharing!
大手企業であればまだしも、私がおつきあいする中小企業であればそのようなゆったりとした時間で物事は考えていられません。ましてやWebサイトは既に動いています。悠長に分析などやっていたら、どんどん時間の流れが状況を変えていってしまいます。
ではどのような改善方法をとるべきなのでしょうか。
最近、Webサービスを開発中だったり、その後の企画を練っていたりするのですが、ここ数日連続して似たような企画のサービスを見かけてしまいました。一人が考えていることは、他人も同じように考えているものなので、仕方がありませんが。
via Jackie O on Flickr - Photo Sharing!
もちろん、内容は全く同じではなく、というよりも個人的には全く違うコンセプトだと思ったのですが、他人から見た場合はどう思うでしょうか。恐らく、ちょっと似ていたら「似たようなサービス」になってしまうのではないでしょうか。
もちろん、模倣する場合は似たようなサービスと認識されることが大事になるかも知れませんが、それはただのパクリです。普通は差別化をはかりたいと思うところでしょう。ではどうやって差別化を図れば良いのでしょうか。
Webサービスが流行るか否かに担当者の情熱は大きく関わっていますが、情熱があるから必ず流行る訳ではありません。情熱がなければ必ず流行らないと言えるだけです。では実際に流行るかどうかは何で決まるのでしょうか。
via Panama Business 2 on Flickr - Photo Sharing!
正直に言って、運やタイミングなど超自然的要素が大きく関わっているとさえ思えます。どれだけ良いと思えるサービスをリリースしたところでユーザの心に響かないケースは多々ありますし、逆に何となく作った物が爆発的にヒットすることもあります。
もちろん、流行らせるための仕組みなどは考えるのですが、それが本当に流行るかどうかは全くの未知数です。たまたま大きなサイトのプレスリリースに重なってしまい、パブリッシュが全く効果なく終わったら、悲惨なことになります。
そう考えるとプランニング時点で収益モデルを策定することは大事ですが、収益分岐点などは全くの未知数と考えた方が良さそうです。考えたとしても、実際にその通りになる可能性は低いからです。
ではそうした現状を踏まえて、どういう対処法が考えられるでしょうか。
|
MOONGIFT
|
Open Service
|
|
Rails 2.0
|
Residenton.net
|
|
Cool Coding
|
Producing Web
|
admin | 
09 6th, 2008| 