Google、YouTube買収って？

【事実】　Googleが、動画投稿サイト運営会社YouTubeを買収した。買収額は16.5億ドル（日本円で約2,000億円）見込み。YouTubeは2005年に設立し、全世界から一日約6.5万本の動画投稿を受けて、無料で公開し1日1億本以上が見られているという。

ITpro「特集　YouTubeショック」
http://itpro.nikkeibp.co.jp/99/youtube/index.html

【気づき】　また一つ、ネットのサクセスストーリーが生まれた。劇的な急成長ぶりを見せながらも、それに見合ったビジネスモデルが見えにくかったYouTubeにとっては、最良のシナリオだったと思う。

検閲や著作権強化、情報の整理を図るGoogleの下で、YouTubeが今後、どのような展開をしていくのか、気になるところだ。日本版へのローカライズも早いのではないだろうか。
【教訓】　はじめてにアイデアありき。突き抜ければ、収益モデルは後づけできる。

【宣言】　まずは、YouTubeに動画を投稿してみよう。

『ウェブ進化論』の梅田望夫さんやマイネットの上原仁さんも、このニュースについてブログに書かれている。

「My Life Between Silicon Valley and Japan」梅田望夫さん
http://d.hatena.ne.jp/umedamochio/20061009/p1

「近江商人 JINBLOG」上原仁さん
http://ceonews.jp/archives/2006/10/googleyoutube.html

ここまでの所要時間：25分
（昨日、アップするはずのネタだったが……）

Googleカレンダーの共有機能

パソナテックの「あすなろBLOG」にGoogleカレンダーの共有に関するエントリーをアップした。

こちらと「あすなろBLOG」と２つのブログをやっているが、連動がうまくいっていないのでもう少し工夫してみたい。

もっと便利に「Googleカレンダー」

【事実】　先日、日本語版の「Googleカレンダー」が公開されて、今まで英語表記で使いづらかった部分が解消された。日本語版になったことで、モット便利な使い方がないかと探していたら、IT media Biz.IDで「もっと便利にGoogleカレンダーを使う7つのTips」という記事と「みんなのTips――Googleカレンダー」という記事が掲載されていて役に立ちそうで興味深かった。

【気づき】　とくに「みんなのTips」は、Web2.0的な展開で、なるほど、みんな考えているなあと感心させられた。Googleの公開されているカレンダーから、日本の祝日をインポートしたり、天気予報やアマゾンのWebサービスと組み合わせたり、個人のタスク管理につかったりと、いろいろなアイデアが紹介されている。

「Google Calendarの使い方」というサイトもぜひ、参考にしたい。

【教訓】　Googleカレンダーは、単なるスケジュール管理用のWebアプリケーションでなく、いろいろな可能性を秘めている。

【宣言】　Googleカレンダーを自在に使いこなせるようになろう。

会社で使用している人など、セキュリティーが気になる人は、SSL版を使うといいかもしれない。（私はSSL版に切り換えました）

ここまでの所要時間：28分
（本当は昨日アップしようと思っていたエントリー。ちょっと、バタバタしていて…）

コミュニティをどう作るか悩んでいるが…

【事実】　新サイトでは、メインのサービスのほかに、コミュニティ・コンテンツを用意したいと思っている。

コミュニティを運営する目的は、
１．集客効果
２．SEO効果
３．サービスの利用促進
４．サービス利用者の成約率向上
が考えられる。

【気づき】　優先度を考えると、３→１→２→４。まず、サービスの利用者の利便性を図ることが先決かな。

【教訓】　ユーザー目線から考えれば、答えはおのずと導かれる。

【宣言】　サービス提供側からの論理ではなくて、ユーザー目線からも考えてみよう。


ここまでの所要時間：15分
（雨の中、朝から業務委託先へ打ち合わせに出かけた。上司のHさんにが車を出していただいたので、行き帰りともスムーズで楽をさせていただいた。感謝♪）

Wikiを活用してプロジェクトをたのしく

【事実】　Pukiwikiというフリーソフトウェアとして配布されているWikiツールを実験用のサーバーにインストールした。

Wiki（ウィキ）は、Webブラウザから簡単にWebページの発行・編集などが行なえる、Webコンテンツ管理システム。複数の人が共同でWebサイトを構築していく利用法を想定していて、閲覧者が簡単にページを修正したり、新しいページを追加したりできるようになっている。フリー百科事典『ウィキペディア (Wikipedia) 』は、Wikiを活用した事例として有名。

Wikiのメリットは、以下の通り。

１．誰でも自由に書き直せる
２．Webブラウザを使用し、特別なツールは不要
３．簡単な整形ルールを覚えるだけ
４．参加登録不要でやる気のある人が、すぐに参加できる
５．情報を探しやすい
６．プロジェクトや作業タスクごとに項目をまとめられる
７．作業を途中で中断しても、その成果がそのまま残る

もちろんデメリットもある。

１．誰が更新したか、記録が残らない
２．内容やスタイルが、一貫している保証がない
３．イタズラされる可能性がある
４．URIが長くなる

【気づき】　ハワイの言葉で、素早いことを意味するWikiwikiが語源。その名の通り、Wikiは従来の方法に比べてウェブページの作成や変更がすばやくできることが魅力。

【教訓】　Wikiの手軽さは、共同作業のツールとして活用できる。

【宣言】　Wikiを効果的に仕事に活用していきたい。

Wikiに注目したのは、ある勉強会で議事録として、livedoor Wikiを利用したことがきっかけ。Wiki＝Wikipedia（百科事典）、事典作成ツールというイメージしかなかったので新鮮だった。

ここまでの所要時間：28分
（夕方にエントリーをアップロードすると、PV数が減少する。当たり前のことかな）

AlligatorとRSSフィード

【事実】　金曜日に「Alligator（アリゲーター）」というアプリケーションソフトを紹介してもらった。「Alligator」は、音声コンテンツやビデオコンテンツの再生もできるRSSリーダーである。

「Alligator」の主な特徴は以下の通り。
１．専用ブラウザタイプのRSSリーダー。「RSS」や「Podcast」と記載されたバナーを“ドラッグアンドドロップ”するだけで、登録可能。
２．MOV/MP4/WMA/WMVなどのファイル形式の映像コンテンツをも収集・再生することができる。
３．ダウンロードしたコンテンツをiTunesと同期することができて、iPodで視聴することができる。
４．Windows2000/XP、Mac OS X 10.3.9以降対応。

Alligatorのダウンロードはこちら。
http://www.blogcasting.jp/alligator/index.html

【気づき】　ブログなどの最新情報を配信してもらう機能RSSフィード。それを受け取るRSSリーダーは、メールソフトベースのものやウェブベースのものなどいろいろなタイプがある。そんな中で、音声や映像といったマルチメディアコンテンツも扱うことができるRSSリーダーというのは価値があるだろう。

【教訓】　Web2.0は、RSSフィードの時代でもある。コンテンツを提供する側ではRSSフィードをどのように活用していくかがポイント。

【宣言】　RSSフィードについてもっと研究しよう。

RSS/Atomフィードを用いたビジネスモデルなどは、以下のサイトで取り上げている。
Feed Business Syndication
http://www.feedsphere.com/

ここまでの所要時間：32分
（iPodユーザーでないせいか、ポッドキャスティングについて感度が悪いなあ）

Gmailが招待状なしで利用可能になった

別のエントリーを考えていたが、IT Mediaニュースで「Gmailが国内でも登録制に、招待状なしでも利用可能」という記事が載っていたので、記事を差し替えることにした。

【事実】　前からGmailのアカウントを取りたいと思っていたので、ちょうど良い機会なので早速Gmailに申し込んだ。Gmailは、これまでは招待制のサービスで、すでにGmailを利用しているユーザーから招待状を受け取らない限りは利用できなかった。裏技として、検索サイトで招待サイトを見つけてそこから申し込むという手はあったが、需要に比べて供給量が少なくてでここで入手するのが困難だった。

【気づき】　Gmailのアカウントを取ったことで、Google Calendarなどで使用していたアカウントが、新しいGmailのアカウントに寄せられてしまった。最初にこのことに気づかずに、ログインでエラーを出し続けてしまった。

【教訓】　Gmailは、Googleの提供するサービスの中心にあるツールである。

【宣言】　Gmailの何がありがたいのかについては、いろいろと使用した上で、記事に書きたい。

Gmailの登録の仕方や使い方は、Biz.IDの「初心者のためのGmail入門」がわかりやすく解説している。（タイムリーな企画だなあ）

ここまでの所要時間：29分
（朝、私用で出社が遅れたので、ランチタイムにこのブログを書いている）

ユーザーの声にすぐに対応できる柔軟さ

今日の分のブログはすでに書いているが、うれしかったのでもう1本エントリーを書いた。

【事実】　Biz.IDで「読者から見たBiz.ID（8月10日～16日）」に、このブログのことを紹介していただいた。8月10日に実施された、ブロガー応援企画「GTD徹底研究会」の参加者の声としてである。Biz.ID編集部で、研究会の最後に、編集部へ期待すること、ウェブサイトへの要望などを取材されていたが、そのフィードバックを早速実現されたわけだ。

そのとき、以下のような意見が出されていた（記憶があいまいになっているが……）

・参加者のブログを記事の中で紹介してほしい
・GTDの記事がバラバラと掲載されているのでまとめページがほしい
・一般の人のブログでも参考になるものにはリンクを張ってほしい
・トラックバックの位置がわかりにくいので目立つ位置に変えてほしい

【気づき】　Biz.ID編集部は読者重視で、柔軟性は高いと思った。「読者から見たBiz.ID」は、Biz.IDの記事へのトラックバックなどを中心にどの者からのフィードバックを紹介するという企画。読者を巻き込んでコンテンツを作っていくところは、Web2.0的である。読者に対して編集部の目が配られているのが伝わってきて、記事をちゃんと読まなきゃ、いい記事にはトラックバックをつけようという気になる。

【教訓】　情報発信側は、一方的に情報を公開するだけでなく、読者からのフィードバックもちゃんと受け入れることが大切。

【宣言】　読者の声を受け取る仕組みを取り入れて、すぐに対応できる柔軟さをもとう。

感謝♪　記事を書いていただいた吉田記者に。


ここまでの所要時間：27分
（先週の木曜日にブログのPV数が突然増えて、何が起こったのかと思っていた）

ロングテールで行こう

【事実】　会社でやっているウェブサイトで、もう少し広告収入を上げられないかと思っている。そこで、最近、気になっているのがGoogle AdSense型のテキスト広告配信システムである。

【気づき】　ウェブサイトのPV数を調べてみると、現在、広告スペースを販売しているページのPVは全体の1/5（20％）程度である。残りの4/5（80％）では広告を取らずにコンテンツ提供のみ行っている。もったいない。これじゃあ、パレートの法則よりも効率が悪い。

「パレートの法則とは｜マーケティング用語集｜ミツエーリンクス」

【教訓】　上位2割を重視しつつ、残り8割も活用するのがロングテール。

ロングテールを実践する場合には、扱うアイテム数が多数になるために、以下の各段階で、どのようなメリット・デメリットがあるか検証する必要がある。
１．製造（量産コスト）
２．販売（宣伝、営業）
３．在庫（資産評価、倉庫代）
４．流通（物流、送料）
５．決済（代金回収）

ウェブまわりだと、２と３と４をほとんどコストをかけずに行うことができるメリットがある。

【宣言】　データベースサーバーと組み合わせることで、簡単な広告配信システムなら作れそうだ。絵に描いてみよう。


ここまでの所要時間：29分

50％の完成度でリニューアルサイトを公開

【事実】　日曜日の深夜に、プライベートでやっている趣味のウェブサイトをXOOPS（ズープス）というCMS（コンテンツ作成管理システム）ベースのサイトにリニューアルした。思い立ってからほぼ2週間（仕事があるので実質2回の週末のみ）でのリリースである。とはいえ、データ移行には手付かずの状態で、旧コンテンツと混在した状態で、完全にXOOPS化したわけではなく、半分ぐらいの完成度である。

【気づき】　十年以上ウェブサイトをやっていて、サイト更新を止めて何週間もリニューアル作業に取り組むのは、おかしいと思っている。また、いつも通りにコンテンツ作成をしながら、リニューアルに取り組んでいたら、半年たってもできないかもしれない。

「はてな」の精神をを見習って、「エイ、ヤー」と新サイトへの移行を敢行してしまった。

何か不具合なども出るかもしれないし、ユーザーの評判も気になり、内心ビクビクである。

CNET Japanに掲載された「はてな」の近藤淳也さんのブログで、

はてなでサービスを出す時に心がけていることとして、「50%くらいの完成度でサービスを出す」という事があります。

と書かれていた。

近藤さんが挙げていた、100％まで到達しない時点で公開をしたほうが良い理由は、以下の通り。

１．サービスはなるべく早くリリースした方が有利。1カ月、2カ月の遅れが命取りになることがある。
２．作る人間の想像力には限界がある。あるサービスが数十万人に利用された時に、その中で何が起きて、どのような機能が必要になるかをすべてて想像することはできない。

まさに、「Web2.0」の「永遠にベータ版（Perpetual Beta）」という考え方と同じだ。

【教訓】　ウェブサービスの場合、実際は半分くらいの完成度で出した方がうまく行く確率が高い。

【宣言】　「はてな」と比べたら、スタートのレベルはずっと低いかもしれないが、今後、どんどんユーザーが使いやすいウェブサイトにしていきたい。


ここまでの所要時間：24分
（今朝も朝から会議。ちょー眠かった）