Blog
前のページ
|
次のページ
2008/04/23のBlog
[ 02:20 ]
(ちょっとタイトルが大げさすぎです。ごめんなさい)
先日、CTCが、インドの大手開発会社と業務提携したという話しが発表になっていた。
ここ数年、いろいろな大手SIベンダーが、インドをはじめ中国・ベトナムの開発会社と提携するようになった。
そして、良く言われるのが、日本語の教育を施し、日本語が出来る人材を日本にブリッジSE として常駐させる、という話し。
一見よさそうな話しに見えるが、
実は、世界のIT技術者と直接コミュニケーションが取れない日本の技術者が、
自分たちの心地よい鎖国された世界の中で、世界の優秀な技術者に日本語で話してもらうという状況だ。
ソフトウェアのオープンソース化の流れの中で、良いソフトウェアは世界規模で優秀な技術者が集い、コミュニティを形成し、ソフトウェアを改善していく。
そんな中、自分たちが世界の優秀な技術者コミュニティに参加することをせずに、世界の技術者に対して日本の言語に合わせて仕事をさせるというやり方で、どれだけ優秀な技術者がそんな要望に対応してくれるのだおう。
そんなので、いつまで戦っていけるのだろう。
少なくとも、日本における英語教育レベルは低くない。
7年前のホットリンクは、7カ国の人種がおり、経営会議も英語だった。
転職してきたメンバーは、みんなおっかなびっくりで、英語なんて話せませんと言っていたものだが、
数ヶ月もすると、誰もが平気で英語でコミュニケーションをしていた。
(ただし、納期前にトラブルが発生したりすると、さすがにスムーズに意思が伝わらないイライラが爆発したりするのだが・・・・。)
少なからず、小規模なベンチャーであれば、
自分たちが英語を学習し、世界の技術者のコミュニティに入っていき、
世界のスピードで進歩を遂げるべきではないだろうか?
X人の技術者に日本語を勉強させてチームに加えても、追加メンバーが必要になると、またプラスY人に日本語を勉強させる必要がある。
ところが、自分たち数人が英語を勉強すれば、追加メンバーが必要になると、どこにでもメンバーがいることになる。
もちろん、インターフェースやお客さんが日本語にならざるを得ない、という状況はあるだろう。
その場合には、せめて、
エンジン部分とインターフェース部分を切り離し、
エンジン部分の開発チームは、公用語を英語にし、広く門徒を広げ、世界から優秀な人材をメンバーに迎え入れ、
インターフェース開発チームは、公用語を日本語とし、日本人のメンバーで構成する、
という編成がよいと思う。
ホットリンクでも、
昔と違いブログ・SNSが収益の基盤となっていたここ数年は、日本人のメンバーがほとんどになってしまったが、
昨年後半から、対象分野をエージェント技術に特化し、かつSaaS 型での事業構造に切り替えたので、
外国人メンバーが再び加わりやすくなった。
いつ開発拠点を海外に移せるかなぁ・・・・・。
楽しみ、楽しみ。
先日、CTCが、インドの大手開発会社と業務提携したという話しが発表になっていた。
ここ数年、いろいろな大手SIベンダーが、インドをはじめ中国・ベトナムの開発会社と提携するようになった。
そして、良く言われるのが、日本語の教育を施し、日本語が出来る人材を日本にブリッジSE として常駐させる、という話し。
一見よさそうな話しに見えるが、
実は、世界のIT技術者と直接コミュニケーションが取れない日本の技術者が、
自分たちの心地よい鎖国された世界の中で、世界の優秀な技術者に日本語で話してもらうという状況だ。
ソフトウェアのオープンソース化の流れの中で、良いソフトウェアは世界規模で優秀な技術者が集い、コミュニティを形成し、ソフトウェアを改善していく。
そんな中、自分たちが世界の優秀な技術者コミュニティに参加することをせずに、世界の技術者に対して日本の言語に合わせて仕事をさせるというやり方で、どれだけ優秀な技術者がそんな要望に対応してくれるのだおう。
そんなので、いつまで戦っていけるのだろう。
少なくとも、日本における英語教育レベルは低くない。
7年前のホットリンクは、7カ国の人種がおり、経営会議も英語だった。
転職してきたメンバーは、みんなおっかなびっくりで、英語なんて話せませんと言っていたものだが、
数ヶ月もすると、誰もが平気で英語でコミュニケーションをしていた。
(ただし、納期前にトラブルが発生したりすると、さすがにスムーズに意思が伝わらないイライラが爆発したりするのだが・・・・。)
少なからず、小規模なベンチャーであれば、
自分たちが英語を学習し、世界の技術者のコミュニティに入っていき、
世界のスピードで進歩を遂げるべきではないだろうか?
X人の技術者に日本語を勉強させてチームに加えても、追加メンバーが必要になると、またプラスY人に日本語を勉強させる必要がある。
ところが、自分たち数人が英語を勉強すれば、追加メンバーが必要になると、どこにでもメンバーがいることになる。
もちろん、インターフェースやお客さんが日本語にならざるを得ない、という状況はあるだろう。
その場合には、せめて、
エンジン部分とインターフェース部分を切り離し、
エンジン部分の開発チームは、公用語を英語にし、広く門徒を広げ、世界から優秀な人材をメンバーに迎え入れ、
インターフェース開発チームは、公用語を日本語とし、日本人のメンバーで構成する、
という編成がよいと思う。
ホットリンクでも、
昔と違いブログ・SNSが収益の基盤となっていたここ数年は、日本人のメンバーがほとんどになってしまったが、
昨年後半から、対象分野をエージェント技術に特化し、かつSaaS 型での事業構造に切り替えたので、
外国人メンバーが再び加わりやすくなった。
いつ開発拠点を海外に移せるかなぁ・・・・・。
楽しみ、楽しみ。
2008/04/20のBlog
[ 11:05 ]
[ ITと政治 ]
昨日、映画「大いなる野望」を見た。
トムクルーズ主演だし、ハリウッドの娯楽映画だろうと思って観に行ったら、全く娯楽映画ではない。
娯楽映画だと思ってみた人にとっては、尻切れトンボで、????という感じ。
しかし、気持ちを切り替えて考えると、それなりに考えさせられる映画ではある。
大統領とマスコミと市民(教授・学生)というそれぞれの立場で、
現状の世界情勢を憂い、
過去の反省をし、
より良い未来を考えそれぞれが正しいと思う決断をし、行動を起こす。
しかし、過去から学んで正しい決断をしたはずなのに、
結果は、あたらな過ちの繰り返しになり、
世界は変わらない( ← ここまで言っているかどうかは、解釈による)。
映画の主題が、
「みんなが行動を起こさないと世界は変わらない」と言っているのか?
「行動を起こしても変えられない大きな渦の中に現実世界がはまっている」と言いたいのか?
ちょっと分からないが、それなりに考えさせられるのは確かだ。
今の日本に例えて考えると、
ちゃんと考える基礎情報とグローバル視点と参加意識がない国民。
国民に正しく情報を伝えられないメディア。
大局を見ながら正義に突き進めない政治家・国家。
自分で政党や総理大臣を選んでおきながらトップを支えず、こき下ろす国民文化。
正義を貫くと力をなくす政治構造。
どんなに個々の人が何とかしなければと思っても、そう簡単に変えられる状況ではない。
さっさと日本を出たくなる。
ホットリンクの仕事の面からいっても、
WEB2.0は、規模によって価値が指数関数的にあがる仕組みだ。
日本語という言語に縛られていては、このWEB2.0世界で勝つことは出来ない。
だから、私は早く海外に出たいと思っている。
しかし、世界に出たら、良い世界が待っているのか?
日本を出たら、良い政治が行われている国があるのか?
サブプライム問題に端を発して、
ある国の失策は世界中に広がる。
自分の国だけうまく回そうとしても、どうにもならない。
結局は、一人が動いたとしても簡単には変えられない大勢とわかってはいても、
動かないと何も始まらない。
そういう時の心の動きって、
企業の創業者精神と似ているものが一部ある。
国民・政治家・メディア、いろんな人たちが変わらなければならない中で、
時代を変えるような新しい価値を生み出すパワーを持っているベンチャー起業家たちも、
自分の会社のことだけ考えているわけにはいかなくなっているんでしょうね。
そんな状況の中で、
みんなのちょっとした変えようという力をうまく集約できる可能性があるのがITだと思うんだよね。
何回か、ITを政治に応用するとどうなるか考えてみようかな?
けど、国が発表する電子立国とかeJapan 構想みたいになっちゃうと、全然だめだめなので、その辺はご安心を。
トムクルーズ主演だし、ハリウッドの娯楽映画だろうと思って観に行ったら、全く娯楽映画ではない。
娯楽映画だと思ってみた人にとっては、尻切れトンボで、????という感じ。
しかし、気持ちを切り替えて考えると、それなりに考えさせられる映画ではある。
大統領とマスコミと市民(教授・学生)というそれぞれの立場で、
現状の世界情勢を憂い、
過去の反省をし、
より良い未来を考えそれぞれが正しいと思う決断をし、行動を起こす。
しかし、過去から学んで正しい決断をしたはずなのに、
結果は、あたらな過ちの繰り返しになり、
世界は変わらない( ← ここまで言っているかどうかは、解釈による)。
映画の主題が、
「みんなが行動を起こさないと世界は変わらない」と言っているのか?
「行動を起こしても変えられない大きな渦の中に現実世界がはまっている」と言いたいのか?
ちょっと分からないが、それなりに考えさせられるのは確かだ。
今の日本に例えて考えると、
ちゃんと考える基礎情報とグローバル視点と参加意識がない国民。
国民に正しく情報を伝えられないメディア。
大局を見ながら正義に突き進めない政治家・国家。
自分で政党や総理大臣を選んでおきながらトップを支えず、こき下ろす国民文化。
正義を貫くと力をなくす政治構造。
どんなに個々の人が何とかしなければと思っても、そう簡単に変えられる状況ではない。
さっさと日本を出たくなる。
ホットリンクの仕事の面からいっても、
WEB2.0は、規模によって価値が指数関数的にあがる仕組みだ。
日本語という言語に縛られていては、このWEB2.0世界で勝つことは出来ない。
だから、私は早く海外に出たいと思っている。
しかし、世界に出たら、良い世界が待っているのか?
日本を出たら、良い政治が行われている国があるのか?
サブプライム問題に端を発して、
ある国の失策は世界中に広がる。
自分の国だけうまく回そうとしても、どうにもならない。
結局は、一人が動いたとしても簡単には変えられない大勢とわかってはいても、
動かないと何も始まらない。
そういう時の心の動きって、
企業の創業者精神と似ているものが一部ある。
国民・政治家・メディア、いろんな人たちが変わらなければならない中で、
時代を変えるような新しい価値を生み出すパワーを持っているベンチャー起業家たちも、
自分の会社のことだけ考えているわけにはいかなくなっているんでしょうね。
そんな状況の中で、
みんなのちょっとした変えようという力をうまく集約できる可能性があるのがITだと思うんだよね。
何回か、ITを政治に応用するとどうなるか考えてみようかな?
けど、国が発表する電子立国とかeJapan 構想みたいになっちゃうと、全然だめだめなので、その辺はご安心を。
2008/04/05のBlog
[ 16:11 ]
[ レコメンドエンジンの話 ]
最近は、本当にいろいろな会社からレコメンデーションエンジンのASPサービス(リコメンデーションエンジンASPサービス)が出てきています。
なぜこんなに雨の後の竹の子のように同じようなサービスが出てくるのでしょうか?
私は、オープンソース技術やWEB2.0サービス・技術が普及したことが非常に大きな要因になっていると考えています。
協調フィルタリングアルゴリズムの基礎自体は、既に30年程度前に最初の論文が発表され、アルゴリズムも公開されています。
その後、様々な改良版のアルゴリズムが公開されているし、大学の研究室からオープンソースのものが提供されていたりもします。
ですので、2000年当時でも自分で提供しようとすれば、ちょっとしたプログラマであれば、すぐに作れてしまいました。
しかし、アルゴリズム自体は作れたとしても、それを「レコメンドASPサービス」(リコメンドASPサービス)として提供するとなると、話は全く異なる技術分野に飛び火します。
どういうことかというと、
ASPサービスの場合、
・顧客のWEBサイトへの訪問顧客の履歴データがリアルタイムでこちらのサーバにやってきます。
・個々のWEBサイト自体が、増大するトラフィックを処理するために非常に苦労しています。
・更に、そのような顧客を複数抱え、
・それぞれの顧客のWEBサイトをユーザが閲覧する度に、閲覧履歴データがリアルタイムでこちらのASPサーバに送信されるのです。
・それを蓄積し、
・更にリアルタイムでレコメンド結果(リコメンド結果)を返信する
という必要があります。
また、
・その履歴データは、日々増大していきます。
即ち、レコメンデーションエンジン(リコメンデーションエンジン)をASPで提供するためには、
1.大量のトラフィックをさばく仕組み
2.大量のデータを効率的に分散し、蓄積する仕組み
3.分散された大量の履歴データから現実的なレスポンス時間でレコメンド結果(リコメンド結果)を計算する仕組み
が必要になります。
言い換えると、
アルゴリズムを考える行動心理学および数学的な研究開発力とは別の、
大規模なWEBシステムを構築する工学的な力が別途必要になるのです。
2000年の当時に、このような大規模なデータベースシステムや分散システムの開発を経験できる会社は、大手ポータルの仕事を請けているような会社しかなく、非常に稀でした。
更に、それを構築するために、オラクルなどの高価なデータベースを利用すると、コスト的に事業が成り立ちませんでした。
2000年当時のWEBシステム開発の市場には、大量のトラフィックを扱い、低価格で分散データベースを構築する技術が成熟していなかったのです。
そんな中、2003年からブログブームがおき、その後WEB2.0サービスがどんどん普及しました。
その時に、開発会社は上記で語ったことと全く同じ問題に直面したのです。
・日々ユーザは増え続け、
・時が経つにつれて、ユーザが書き込んでデータが多くなっていき、データベースが肥大化していく。
・データベースが大きくなると、システムのレスポンスが低下し、更には、一つのデータベースで扱えるデータサイズを超えていく。
・サービスの競争激化でどんどん機能が増えいく。
そんなWEB2.0サービスの狂騒の中を戦ってきた開発会社は、
知らず知らずの内に、
レコメンデーションエンジンをASPで提供できるだけの、大量のトラフィックを扱うWEBシステムを開発する技術・ノウハウを蓄積していたのです。
そして、時代は、
WEB 2.0系サービスの第一段階である、「ユーザに(明示的に)参加してもらう」という段階を終えます。
この時、WEB2.0系システム会社は次の事業の稼ぎネタを探さなければならなくなります。
そんな中、これまでのシリーズで述べて来た、
①EC市場の成熟によるニーズの顕在化
②市場やサービス提供者のプライバシーに関する警戒感の低下
を迎えるのです。
と考えると、
ブログ・SNSブームに乗っかり、ブログ・SNS構築の受託開発を請け負っていた会社が、こぞってレコメンドASP市場(リコメンドASP市場)に売って出てきている理由が分かるのではないでしょうか?
2000年のレコメンド(リコメンド)と2008年のレコメンド、何が違う?かというと、
「WEB2.0 ブームを経験したことで、大量のトラフィックを扱うWEBシステムを構築するためのシステム構築ノウハウを利用できたこと」
でしょう。
読者の中で、
レコメンデーションのASPサービス(リコメンデーションASPサービス)の導入を考えられている方は、
サービス提供会社が、大規模なブログコミュニティやSNSを構築した経験のある会社かどうかも、一つの判断材料にされるとよいと思います。
**************************************************************
このシリーズは、これにて一旦終わりにしたいと思います。
今後は、レコメンデーションエンジン(リコメンデーションエンジン)を実際に導入した効果などをお知らせできればよいなと思っています。
またのお楽しみに。
なぜこんなに雨の後の竹の子のように同じようなサービスが出てくるのでしょうか?
私は、オープンソース技術やWEB2.0サービス・技術が普及したことが非常に大きな要因になっていると考えています。
協調フィルタリングアルゴリズムの基礎自体は、既に30年程度前に最初の論文が発表され、アルゴリズムも公開されています。
その後、様々な改良版のアルゴリズムが公開されているし、大学の研究室からオープンソースのものが提供されていたりもします。
ですので、2000年当時でも自分で提供しようとすれば、ちょっとしたプログラマであれば、すぐに作れてしまいました。
しかし、アルゴリズム自体は作れたとしても、それを「レコメンドASPサービス」(リコメンドASPサービス)として提供するとなると、話は全く異なる技術分野に飛び火します。
どういうことかというと、
ASPサービスの場合、
・顧客のWEBサイトへの訪問顧客の履歴データがリアルタイムでこちらのサーバにやってきます。
・個々のWEBサイト自体が、増大するトラフィックを処理するために非常に苦労しています。
・更に、そのような顧客を複数抱え、
・それぞれの顧客のWEBサイトをユーザが閲覧する度に、閲覧履歴データがリアルタイムでこちらのASPサーバに送信されるのです。
・それを蓄積し、
・更にリアルタイムでレコメンド結果(リコメンド結果)を返信する
という必要があります。
また、
・その履歴データは、日々増大していきます。
即ち、レコメンデーションエンジン(リコメンデーションエンジン)をASPで提供するためには、
1.大量のトラフィックをさばく仕組み
2.大量のデータを効率的に分散し、蓄積する仕組み
3.分散された大量の履歴データから現実的なレスポンス時間でレコメンド結果(リコメンド結果)を計算する仕組み
が必要になります。
言い換えると、
アルゴリズムを考える行動心理学および数学的な研究開発力とは別の、
大規模なWEBシステムを構築する工学的な力が別途必要になるのです。
2000年の当時に、このような大規模なデータベースシステムや分散システムの開発を経験できる会社は、大手ポータルの仕事を請けているような会社しかなく、非常に稀でした。
更に、それを構築するために、オラクルなどの高価なデータベースを利用すると、コスト的に事業が成り立ちませんでした。
2000年当時のWEBシステム開発の市場には、大量のトラフィックを扱い、低価格で分散データベースを構築する技術が成熟していなかったのです。
そんな中、2003年からブログブームがおき、その後WEB2.0サービスがどんどん普及しました。
その時に、開発会社は上記で語ったことと全く同じ問題に直面したのです。
・日々ユーザは増え続け、
・時が経つにつれて、ユーザが書き込んでデータが多くなっていき、データベースが肥大化していく。
・データベースが大きくなると、システムのレスポンスが低下し、更には、一つのデータベースで扱えるデータサイズを超えていく。
・サービスの競争激化でどんどん機能が増えいく。
そんなWEB2.0サービスの狂騒の中を戦ってきた開発会社は、
知らず知らずの内に、
レコメンデーションエンジンをASPで提供できるだけの、大量のトラフィックを扱うWEBシステムを開発する技術・ノウハウを蓄積していたのです。
そして、時代は、
WEB 2.0系サービスの第一段階である、「ユーザに(明示的に)参加してもらう」という段階を終えます。
この時、WEB2.0系システム会社は次の事業の稼ぎネタを探さなければならなくなります。
そんな中、これまでのシリーズで述べて来た、
①EC市場の成熟によるニーズの顕在化
②市場やサービス提供者のプライバシーに関する警戒感の低下
を迎えるのです。
と考えると、
ブログ・SNSブームに乗っかり、ブログ・SNS構築の受託開発を請け負っていた会社が、こぞってレコメンドASP市場(リコメンドASP市場)に売って出てきている理由が分かるのではないでしょうか?
2000年のレコメンド(リコメンド)と2008年のレコメンド、何が違う?かというと、
「WEB2.0 ブームを経験したことで、大量のトラフィックを扱うWEBシステムを構築するためのシステム構築ノウハウを利用できたこと」
でしょう。
読者の中で、
レコメンデーションのASPサービス(リコメンデーションASPサービス)の導入を考えられている方は、
サービス提供会社が、大規模なブログコミュニティやSNSを構築した経験のある会社かどうかも、一つの判断材料にされるとよいと思います。
**************************************************************
このシリーズは、これにて一旦終わりにしたいと思います。
今後は、レコメンデーションエンジン(リコメンデーションエンジン)を実際に導入した効果などをお知らせできればよいなと思っています。
またのお楽しみに。
2008/04/01のBlog
[ 11:31 ]
3月31日付けで、株式会社ガーラおよびガーラバズ社から、
口コミの収集・分析の事業「電通バズリサーチ事業」を買い取りました。
約2年間前にガーラおよびガーラバズ社と資本提携を行ってから、
電通バズリサーチのシステムおよび技術開発を委託されていました。
口コミ分析の分野、まだまだ発展途上の分野であり、
より一層の研究開発投資と、サービスへの反映スピードを上げていく必要があります。
本事業を買い取ることで、
ホットリンクとして、創業以来培ってきた、
テキストマイニングの技術、嗜好性把握技術、WEBマイニングの技術、クロール技術、分散システムの技術と人的リソースを思う存分投下し、
口コミ分析の分野での世界有数のサービスに仕立て上げたいと考えています。
詳細は、こちらのプレスリリースをご覧ください。
ちなみに、電通バズリサーチのDB にある現状の口コミ総数は、
掲示板を含めると、19億5228万2848記事
ブログのみだと、3億8168万5800記事
おそらくですが、日本最大ではないのかな?
口コミの収集・分析の事業「電通バズリサーチ事業」を買い取りました。
約2年間前にガーラおよびガーラバズ社と資本提携を行ってから、
電通バズリサーチのシステムおよび技術開発を委託されていました。
口コミ分析の分野、まだまだ発展途上の分野であり、
より一層の研究開発投資と、サービスへの反映スピードを上げていく必要があります。
本事業を買い取ることで、
ホットリンクとして、創業以来培ってきた、
テキストマイニングの技術、嗜好性把握技術、WEBマイニングの技術、クロール技術、分散システムの技術と人的リソースを思う存分投下し、
口コミ分析の分野での世界有数のサービスに仕立て上げたいと考えています。
詳細は、こちらのプレスリリースをご覧ください。
ちなみに、電通バズリサーチのDB にある現状の口コミ総数は、
掲示板を含めると、19億5228万2848記事
ブログのみだと、3億8168万5800記事
おそらくですが、日本最大ではないのかな?
2008/03/30のBlog
[ 03:12 ]
[ レコメンドエンジンの話 ]
2000年のレコメンド(リコメンド)と2008年のレコメンド、何が違う?④
さて、いよいよシリーズ第四弾です。
今回は、ちょっとばかりアルゴリズムの話をしようと思います。
レコメンドエンジンのアルゴリズムで有名なものといえば、
・ルールベースのエンジン
・協調フィルタリングのエンジン
です。
また、他には、
・コンテンツベース(属性ベース)のエンジン:商品属性の似たものを推薦
・コンテキストベースのエンジン:主に文章の中身が似ているものを推薦
・ベイジアンネットのエンジン:ユーザの行動をプログラムで予測して推薦
などがある。
さて、ここでは、アルゴリズムの詳細には深入りせずに、どのアルゴリズムが良いのかをユーザ視点で考えてみよう。
2000年当時にレコメンデーションエンジンを導入しようとする顧客は、まだ導入実績が少なかったこともあって、いろいろなアルゴリズムを勉強し、耳年増になり、その効果よりもそのアルゴリズムに興味を持った。
しかし、アルゴリズムの優劣ってどうやって決めるのだろうか?
私は、レコメンドエンジンを考える際には、常に「現実の店員さん」に当てはめて考える。
つまり、どんなお客さんに、どんなお勧めをする店員さんが優秀なのか?を考えてみるのだ。
では、実際の現実のお客さんへの対応を想像してみよう。
1.ある店員さんは、「このお店の売れ筋商品はこれですよ」といきなりお勧めをする。
2.ある店員さんは、「何をお探しですか?」とまず問いかける。
そして、
2-1. 「○○メーカの○○型番の黒のものが欲しいんです」といわれると、「そうですか」とその商品を持ってくる。
2-2.「デジカメを買いたいんです」といわれると、
2-2-1.ある店員さんは、「最新のデジカメの売れ筋ランキングはこれですよ」とお勧めする。
2-2-2.ある店員さんは、「画素数とシャッタースピードなど、どこにこだわられますか?」と問う。
2-2-3.ある店員さんは、「どんな目的に使われますか?」と問う。
2-2-4.ある店員さんは、彼がプロのカメラマンであるということを知っていて、プロ仕様のデジカメのリストをお見せする。
2-3.お客さんが、どれかのデジカメを手に取っていると、
2-3-1.ある店員さんは、「そのデジカメを検討したお客さんは、このデジカメも検討しましたよ」とお勧めする。
2-3-2.ある店員さんは、「そのデジカメを検討したお客さんは、最終的にこのデジカメを購入しまたした」とお勧めする。
2-3-3.ある店員さんは、「そのデジカメと似た性能のデジカメはこれですよ」とお勧めする。
2-4.更に、お客さんがあるデジカメを購入することが決まったら、
2-4-1.ある店員さんは、「そのデジカメを買ったお客さんは、この大容量のメモリカードも買ってますよ」とお勧めする。
2-4-2.ある店員さんは、「外は雨が降ってきたので傘もどうですか?」とお勧めする。
さて、あなたなら、どの店員さんに接客されたいですか?
と言われても、一言で答えを言えないですよ。
それはなぜか?
自分がその時に、
・欲しい商品が決まっているのであれば、それを聞いて、さっと出してくれる店員がよいし、
・デジカメを買いたいけど、全く機械のことを知らなければ、最近の売れ筋ランキングを教えてもらって参考にしたいし、
・または、目的を聞いてくれて、目的にあったものをお勧めしてくれると楽チンですね。
・または、自分がある程度デジカメに詳しければ、画素数やシャッタースピードなどの詳しい商品性能を教えて欲しい。
・更に、デジカメを買った時に、メモリも一緒に買うことを薦めてくれるのもよいですね。
そうなんです。
自分が、買いたいものがどれくらい決まっているか?知っているか?という「自分の状態によって」、最適な接し方を変えて欲しいんです。
いつも同じお仕着せの接し方をされてはイヤなんです。
いろいろなタイプのお客さんに合わせて対応の仕方を変えて欲しいのです。
さて、ここで話をアルゴリズムに戻しましょう。
今の例で分かりましたでしょうか?
そうです、ある完璧な一つのアルゴリズムで、全てのお客さんを満足させることなどできないのです。
ですので、
あるお客さんには、店舗の売れ筋ランキング(統計によるレコメンデーション)
あるお客さんには、デジカメの売れ筋ランキング(統計によるレコメンデーション)
あるお客さんには、性能を元にした絞込み検索(条件検索によるレコメンデーション)
あるお客さんには、このデジカメを検討した人が他に検討したデジカメ(閲覧履歴ベースの協調フィルライング&コンテンツフィルタリングの組み合わせ)
あるお客さんには、このデジカメを検討した人は、結局購入したデジカメ(閲覧履歴ベースと購入履歴ベースの協調フィルライング&コンテンツフィルタリングの組み合わせ)
あるお客さんには、このデジカメを購入した人が他に購入したメモリカード(購入履歴ベースの協調フィルライング)
あるお客さんには、プロ仕様のデジカメのリスト(ユーザ属性と、コンテンツフィルタリングの組み合わせ)
あるお客さんには、急に雨が降ってきているので傘(自然環境とルールベースの組み合わせ)
と、「いろいろなお勧めが出来る」店員さんがよいんです。
話は変わって、2000年の当時の営業した時の例をお話すると、
タワーレコードさんにレコメンデーションエンジンを営業に行くと、「うちは、ヒットチャートTOP10を並べておけば売れるんだよ」とおっしゃり、
HMVさんに行くと、「顧客嗜好に合わせて、商品推薦をしたい」とおっしゃられた。
お店によって、お客さんの嗜好が違うので、お店によっても必要なレコメンデーションエンジンのアルゴリズムが違う、という例ですね。
導入するお店によっても、利用するアルゴリズムが変わってくるんですね。
結局、気の利く店員さんというのは、いろいろな対応の仕方を知っていて、お客さんに合わせて対応を使い分けてくれるんです。
そして、たくさんのアルゴリズムをもっていて、お客さんやそのお客さんの購入プロセスの段階に応じて使い分けられる必要があるんですね。
このようなことから、一つのすごいアルゴリズムで売上が大幅にアップする、という幻想を抱いてはいけない!ということが終わりでしょうか?
さて、話を今回のテーマに戻しましょう。
2000年の当時から、ホットリンクでは、上記のことは分かっていました。
なので、
松下電器さん経由で総務省のプロジェクトで納入したレコメンデーションエンジンは、
・ランキング
・属性ベース+ランキング
・コンテキストベース
・ユーザ嗜好ベース
などの複数の要素やアルゴリズムを組み合わせ、
ユーザ毎に推薦するアルゴリズムを変化させました。
しかし、市場的には、早すぎたし、受託開発として納品するまでのものにはなりましたが、多数のお客様に納入するようなパッケージ製品になるまでの開発を行うには至りませんでした。
我々だけでなく、他のレコメンデーションエンジンのメーカも生きていくだけで精一杯であり、あらゆるアルゴリズムを実装するまでの余力はなかったのでしょう。
どの会社も、一つのアルゴリズムで勝負!という段階でした。
2008年現在、複数のレコメンデーションASPサービスがありますが、
複数のアルゴリズムを用意し、お客様のニーズに応じて使い分けられるようになっているようです。
ということで、
2000年のレコメンド(リコメンド)と2008年のレコメンド、何が違う?④かというと、
ずばり、
「2000年当時:一つのアルゴリズムで勝負
2008年現在:複数のアルゴリズムを実装し、うまく使い分けをする」
ということでしょう。
次回に続く。
さて、いよいよシリーズ第四弾です。
今回は、ちょっとばかりアルゴリズムの話をしようと思います。
レコメンドエンジンのアルゴリズムで有名なものといえば、
・ルールベースのエンジン
・協調フィルタリングのエンジン
です。
また、他には、
・コンテンツベース(属性ベース)のエンジン:商品属性の似たものを推薦
・コンテキストベースのエンジン:主に文章の中身が似ているものを推薦
・ベイジアンネットのエンジン:ユーザの行動をプログラムで予測して推薦
などがある。
さて、ここでは、アルゴリズムの詳細には深入りせずに、どのアルゴリズムが良いのかをユーザ視点で考えてみよう。
2000年当時にレコメンデーションエンジンを導入しようとする顧客は、まだ導入実績が少なかったこともあって、いろいろなアルゴリズムを勉強し、耳年増になり、その効果よりもそのアルゴリズムに興味を持った。
しかし、アルゴリズムの優劣ってどうやって決めるのだろうか?
私は、レコメンドエンジンを考える際には、常に「現実の店員さん」に当てはめて考える。
つまり、どんなお客さんに、どんなお勧めをする店員さんが優秀なのか?を考えてみるのだ。
では、実際の現実のお客さんへの対応を想像してみよう。
1.ある店員さんは、「このお店の売れ筋商品はこれですよ」といきなりお勧めをする。
2.ある店員さんは、「何をお探しですか?」とまず問いかける。
そして、
2-1. 「○○メーカの○○型番の黒のものが欲しいんです」といわれると、「そうですか」とその商品を持ってくる。
2-2.「デジカメを買いたいんです」といわれると、
2-2-1.ある店員さんは、「最新のデジカメの売れ筋ランキングはこれですよ」とお勧めする。
2-2-2.ある店員さんは、「画素数とシャッタースピードなど、どこにこだわられますか?」と問う。
2-2-3.ある店員さんは、「どんな目的に使われますか?」と問う。
2-2-4.ある店員さんは、彼がプロのカメラマンであるということを知っていて、プロ仕様のデジカメのリストをお見せする。
2-3.お客さんが、どれかのデジカメを手に取っていると、
2-3-1.ある店員さんは、「そのデジカメを検討したお客さんは、このデジカメも検討しましたよ」とお勧めする。
2-3-2.ある店員さんは、「そのデジカメを検討したお客さんは、最終的にこのデジカメを購入しまたした」とお勧めする。
2-3-3.ある店員さんは、「そのデジカメと似た性能のデジカメはこれですよ」とお勧めする。
2-4.更に、お客さんがあるデジカメを購入することが決まったら、
2-4-1.ある店員さんは、「そのデジカメを買ったお客さんは、この大容量のメモリカードも買ってますよ」とお勧めする。
2-4-2.ある店員さんは、「外は雨が降ってきたので傘もどうですか?」とお勧めする。
さて、あなたなら、どの店員さんに接客されたいですか?
と言われても、一言で答えを言えないですよ。
それはなぜか?
自分がその時に、
・欲しい商品が決まっているのであれば、それを聞いて、さっと出してくれる店員がよいし、
・デジカメを買いたいけど、全く機械のことを知らなければ、最近の売れ筋ランキングを教えてもらって参考にしたいし、
・または、目的を聞いてくれて、目的にあったものをお勧めしてくれると楽チンですね。
・または、自分がある程度デジカメに詳しければ、画素数やシャッタースピードなどの詳しい商品性能を教えて欲しい。
・更に、デジカメを買った時に、メモリも一緒に買うことを薦めてくれるのもよいですね。
そうなんです。
自分が、買いたいものがどれくらい決まっているか?知っているか?という「自分の状態によって」、最適な接し方を変えて欲しいんです。
いつも同じお仕着せの接し方をされてはイヤなんです。
いろいろなタイプのお客さんに合わせて対応の仕方を変えて欲しいのです。
さて、ここで話をアルゴリズムに戻しましょう。
今の例で分かりましたでしょうか?
そうです、ある完璧な一つのアルゴリズムで、全てのお客さんを満足させることなどできないのです。
ですので、
あるお客さんには、店舗の売れ筋ランキング(統計によるレコメンデーション)
あるお客さんには、デジカメの売れ筋ランキング(統計によるレコメンデーション)
あるお客さんには、性能を元にした絞込み検索(条件検索によるレコメンデーション)
あるお客さんには、このデジカメを検討した人が他に検討したデジカメ(閲覧履歴ベースの協調フィルライング&コンテンツフィルタリングの組み合わせ)
あるお客さんには、このデジカメを検討した人は、結局購入したデジカメ(閲覧履歴ベースと購入履歴ベースの協調フィルライング&コンテンツフィルタリングの組み合わせ)
あるお客さんには、このデジカメを購入した人が他に購入したメモリカード(購入履歴ベースの協調フィルライング)
あるお客さんには、プロ仕様のデジカメのリスト(ユーザ属性と、コンテンツフィルタリングの組み合わせ)
あるお客さんには、急に雨が降ってきているので傘(自然環境とルールベースの組み合わせ)
と、「いろいろなお勧めが出来る」店員さんがよいんです。
話は変わって、2000年の当時の営業した時の例をお話すると、
タワーレコードさんにレコメンデーションエンジンを営業に行くと、「うちは、ヒットチャートTOP10を並べておけば売れるんだよ」とおっしゃり、
HMVさんに行くと、「顧客嗜好に合わせて、商品推薦をしたい」とおっしゃられた。
お店によって、お客さんの嗜好が違うので、お店によっても必要なレコメンデーションエンジンのアルゴリズムが違う、という例ですね。
導入するお店によっても、利用するアルゴリズムが変わってくるんですね。
結局、気の利く店員さんというのは、いろいろな対応の仕方を知っていて、お客さんに合わせて対応を使い分けてくれるんです。
そして、たくさんのアルゴリズムをもっていて、お客さんやそのお客さんの購入プロセスの段階に応じて使い分けられる必要があるんですね。
このようなことから、一つのすごいアルゴリズムで売上が大幅にアップする、という幻想を抱いてはいけない!ということが終わりでしょうか?
さて、話を今回のテーマに戻しましょう。
2000年の当時から、ホットリンクでは、上記のことは分かっていました。
なので、
松下電器さん経由で総務省のプロジェクトで納入したレコメンデーションエンジンは、
・ランキング
・属性ベース+ランキング
・コンテキストベース
・ユーザ嗜好ベース
などの複数の要素やアルゴリズムを組み合わせ、
ユーザ毎に推薦するアルゴリズムを変化させました。
しかし、市場的には、早すぎたし、受託開発として納品するまでのものにはなりましたが、多数のお客様に納入するようなパッケージ製品になるまでの開発を行うには至りませんでした。
我々だけでなく、他のレコメンデーションエンジンのメーカも生きていくだけで精一杯であり、あらゆるアルゴリズムを実装するまでの余力はなかったのでしょう。
どの会社も、一つのアルゴリズムで勝負!という段階でした。
2008年現在、複数のレコメンデーションASPサービスがありますが、
複数のアルゴリズムを用意し、お客様のニーズに応じて使い分けられるようになっているようです。
ということで、
2000年のレコメンド(リコメンド)と2008年のレコメンド、何が違う?④かというと、
ずばり、
「2000年当時:一つのアルゴリズムで勝負
2008年現在:複数のアルゴリズムを実装し、うまく使い分けをする」
ということでしょう。
次回に続く。
2008/03/24のBlog
[ 00:17 ]
[ レコメンドエンジンの話 ]
いよいよ第三弾です。
そろそろ技術的な側面からの話をいれていきたい気もするが、
少しずつにしていきたいと思う。
2000年の当時に有名だったレコメンデーションの会社は?というと、
・???(んーーー。ルールベースのエンジンのアメリカの会社。ど忘れ。)
・Net Perceptions(協調フィルタリングのエンジン。アメリカの会社)
・シルバーエッグテクノロジー(人工知能と言っていましたが、ニューラルネット的なエンジンでした。日本の会社)
・ホットリンク(協調フィルタリング・コンテキストベースフィルタリング・属性ベースフィルタリング・それらの掛け合わせのエンジン)
でした。
導入するのにかかる費用は、
・???で、1億円以上
・Net Perceptions で、2000万円以上。
・シルバーエッグテクノノロジーで、500万円程度だったかな?
・ホットリンクでは、お客さんの要望に応じてですが、やっぱり500万円以上の見積もりを出していた
という感じでした。
どこのエンジンも、
導入するためには、既存の商品データベースや、顧客データベースとの連携などのシステム開発が必要で、
更には、初期のルールの設定などの初期費用がかかりました。
そんな中で、お客さんから言われるのは、
「リコメンデーションエンジン(←当時は、『レ』コメンドではなく、『リ』コメンドという表記が一般的でした(笑)を導入して、投資対効果は?」
という問いです。
数千万円の投資をして、それをリコメンデーションエンジンの効果で回収するとしたら、いったいどれほどの効果が必要なのでしょうか?
月商1000万円のオンライン書店だとして、
書店の利益を、20%とすると、
月額の利益は、200万円。
仮に、リコメンデーションエンジンにより、売上が20%(そんなに上がるわけがないが、仮定として)上がるとすると、
リコメンデーションエンジンによる、書店の月額利益の増加は、40万円。
これで、仮に2000万円の投資を回収しようとすると、
2000万円/40万円/12ヶ月=約4年間。
しかし、実際には、その4年間の間に、リコメンデーションエンジンやサーバの運用コスト・保守費用がかかる。
月額の運用コスト・保守費用が40万円を超えると、もう回収は永遠に不能。
となって、全く持って投資対効果が合わない。
ましては、2000年当時で、月商2000万円のオンラインショップなどまだあるはずもなく。
こうして、当時のリコメンデーションエンジン市場は、できるはずがなく、消えていったのである。
米国の???の会社は、私の記憶ではどこかに買収され、Net Perceptions Japan は、消えてなくった。
そんな中、シルバーエッグさんは、同じ日本のベンチャーとして、今までこつこつを生き延びてこられたことは、本当に敬意を表したい。
さて、2008年になった今、レコメンデーションエンジン(←2008年なので、あえて『レ』コメンデーションといいましょう)の会社はというと、
実は多くが、レコメンドのASPサービスになっているんです。
価格帯は、
初期費用 10万円~150万円程度。
月額費用 10万円~数十万円。
と、とってもお安くなっています。
更に、
既存システムとの連携はほとんど必要なく、
ホームページにタグを埋め込むだけで、導入が可能になっています。
ここまでにくると、
投資対効果を問われても、かなり現実味がありますね。
もちろん、ASP でやろうという発想は、2000年の当時もあったわけです。
ただし、当時は、
WEB2.0という概念が全くなく、
マッシュアップなどという概念も当然なく、
自社の顧客の行動データが他社のDBに蓄積されるということに対して、
プライバシー問題からくる異常な嫌悪感があり、どう提案しても受け入れられませんでした。
前回までに述べてきた
①EC市場が成熟してきたことで、レコメンドエンジンに投資を出来るサイトがそれなりに多くなり、
②プライバシーに関する抵抗が低下し、
また、
WEB2.0という概念で、他社のサービスと連携することに対しての抵抗感が薄れたこと、
これらの要因が複雑に絡み合い、偶然にも今の時代に、レコメンデーションエンジンのASPサービス、という市場ができたのです。
さあ、もう答えは分かりましたよね。
2000年の(リコメンド)と2008年のレコメンド、何が違う?③かというと、
「導入方法が、パッケージからASPに変わったこと。
価格が、高価格から低価格になったこと」
です。
次回は、もうちょっとアルゴリズムに入ろうかと思います。
つづく。
そろそろ技術的な側面からの話をいれていきたい気もするが、
少しずつにしていきたいと思う。
2000年の当時に有名だったレコメンデーションの会社は?というと、
・???(んーーー。ルールベースのエンジンのアメリカの会社。ど忘れ。)
・Net Perceptions(協調フィルタリングのエンジン。アメリカの会社)
・シルバーエッグテクノロジー(人工知能と言っていましたが、ニューラルネット的なエンジンでした。日本の会社)
・ホットリンク(協調フィルタリング・コンテキストベースフィルタリング・属性ベースフィルタリング・それらの掛け合わせのエンジン)
でした。
導入するのにかかる費用は、
・???で、1億円以上
・Net Perceptions で、2000万円以上。
・シルバーエッグテクノノロジーで、500万円程度だったかな?
・ホットリンクでは、お客さんの要望に応じてですが、やっぱり500万円以上の見積もりを出していた
という感じでした。
どこのエンジンも、
導入するためには、既存の商品データベースや、顧客データベースとの連携などのシステム開発が必要で、
更には、初期のルールの設定などの初期費用がかかりました。
そんな中で、お客さんから言われるのは、
「リコメンデーションエンジン(←当時は、『レ』コメンドではなく、『リ』コメンドという表記が一般的でした(笑)を導入して、投資対効果は?」
という問いです。
数千万円の投資をして、それをリコメンデーションエンジンの効果で回収するとしたら、いったいどれほどの効果が必要なのでしょうか?
月商1000万円のオンライン書店だとして、
書店の利益を、20%とすると、
月額の利益は、200万円。
仮に、リコメンデーションエンジンにより、売上が20%(そんなに上がるわけがないが、仮定として)上がるとすると、
リコメンデーションエンジンによる、書店の月額利益の増加は、40万円。
これで、仮に2000万円の投資を回収しようとすると、
2000万円/40万円/12ヶ月=約4年間。
しかし、実際には、その4年間の間に、リコメンデーションエンジンやサーバの運用コスト・保守費用がかかる。
月額の運用コスト・保守費用が40万円を超えると、もう回収は永遠に不能。
となって、全く持って投資対効果が合わない。
ましては、2000年当時で、月商2000万円のオンラインショップなどまだあるはずもなく。
こうして、当時のリコメンデーションエンジン市場は、できるはずがなく、消えていったのである。
米国の???の会社は、私の記憶ではどこかに買収され、Net Perceptions Japan は、消えてなくった。
そんな中、シルバーエッグさんは、同じ日本のベンチャーとして、今までこつこつを生き延びてこられたことは、本当に敬意を表したい。
さて、2008年になった今、レコメンデーションエンジン(←2008年なので、あえて『レ』コメンデーションといいましょう)の会社はというと、
実は多くが、レコメンドのASPサービスになっているんです。
価格帯は、
初期費用 10万円~150万円程度。
月額費用 10万円~数十万円。
と、とってもお安くなっています。
更に、
既存システムとの連携はほとんど必要なく、
ホームページにタグを埋め込むだけで、導入が可能になっています。
ここまでにくると、
投資対効果を問われても、かなり現実味がありますね。
もちろん、ASP でやろうという発想は、2000年の当時もあったわけです。
ただし、当時は、
WEB2.0という概念が全くなく、
マッシュアップなどという概念も当然なく、
自社の顧客の行動データが他社のDBに蓄積されるということに対して、
プライバシー問題からくる異常な嫌悪感があり、どう提案しても受け入れられませんでした。
前回までに述べてきた
①EC市場が成熟してきたことで、レコメンドエンジンに投資を出来るサイトがそれなりに多くなり、
②プライバシーに関する抵抗が低下し、
また、
WEB2.0という概念で、他社のサービスと連携することに対しての抵抗感が薄れたこと、
これらの要因が複雑に絡み合い、偶然にも今の時代に、レコメンデーションエンジンのASPサービス、という市場ができたのです。
さあ、もう答えは分かりましたよね。
2000年の(リコメンド)と2008年のレコメンド、何が違う?③かというと、
「導入方法が、パッケージからASPに変わったこと。
価格が、高価格から低価格になったこと」
です。
次回は、もうちょっとアルゴリズムに入ろうかと思います。
つづく。
2008/03/20のBlog
[ 23:04 ]
友人と日銀総裁問題の話をしていた時に友人が出したアイデアなんだが、
日銀総裁は、竹中さんがよいと思う。
日本があれだけの不況のタイミングで、
銀行の不良債権を洗い出させるという施策を
日本中の猛反対の中で実現した実行力はすごいじゃないか。
あの時は、マスコミも猛反対したはずだが、
結局あれが有ったから、日本の経済は少しは上向いたのだ。
ところが、である。
実は、
今の自民党の幹事長である伊吹さんは、大蔵省出身らしく、
竹中さんが、くだんの不良債権問題で、大蔵省と大喧嘩して強行した時のしこりがあるんらしい。
不良債権問題の時からの経緯から考えて、
伊吹さんは、絶対に竹中さんが日銀総裁になることには反対するだろうし、
だから自民党としても、絶対に竹中さんを推さない、
という構図が現実的なところのようだ。
民主党がんばってごり押ししないかな?
日銀総裁は、竹中さんがよいと思う。
日本があれだけの不況のタイミングで、
銀行の不良債権を洗い出させるという施策を
日本中の猛反対の中で実現した実行力はすごいじゃないか。
あの時は、マスコミも猛反対したはずだが、
結局あれが有ったから、日本の経済は少しは上向いたのだ。
ところが、である。
実は、
今の自民党の幹事長である伊吹さんは、大蔵省出身らしく、
竹中さんが、くだんの不良債権問題で、大蔵省と大喧嘩して強行した時のしこりがあるんらしい。
不良債権問題の時からの経緯から考えて、
伊吹さんは、絶対に竹中さんが日銀総裁になることには反対するだろうし、
だから自民党としても、絶対に竹中さんを推さない、
という構図が現実的なところのようだ。
民主党がんばってごり押ししないかな?
[ 22:01 ]
[ レコメンドエンジンの話 ]
前回は、
2000年のレコメンド(リコメンド)と2008年のレコメンドの違いの第一として、「市場の有無」
をあげました。
さて、長らく間が開きましたが、今回は、2番目の要素を話したいと思う。
レコメンドエンジンを広告業界に適用するとどうなるでしょうか?
話を広告業界の技術進歩から進めてみよう。
最近広告業界で効果が高いといわれる行動ターゲッティング型の広告配信はご存知だろうか?
あるユーザが、どんな分野のホームページを見たか?という履歴を蓄積していって、そのユーザの興味分野を推定する。
そして、そのユーザがどこかのホームページを訪れると、きっとこの人はこの分野に興味があるんだろうということで、その分野にマッチした広告を表示するわけだ。
やり方はいろいろ工夫できるが、ベタなやり方をすると、その人がどんなホームページを訪問しても、ずっと同じ広告が表示させられる。
それには2つのメリットがある。
1つは、ユーザの興味にあった広告が表示されるというメリット。
もう1つは、ユーザに同じ広告を何度も見させられる、というメリットだ。
2つ目のメリットを掘り下げて説明すると、ある広告にユーザが反応するかどうかは、興味のある・なしだけではなく、その広告を何回見たのか?という認知した回数も重要な要素になる。
例えばコカコーラのCM に例えると、一回みてもコカコーラ飲みたいなとは思わないが、5回同じCM を見たタイミングで、コカコーラが飲みたくなったりするらしい。
従って、あるユーザに対して、どんな分野のホームページを見ていっても、同じ広告が表示されるというのは、広告効果を底上げするわけだ。
さて、実はこれは、ユーザの嗜好を分析し、そのユーザに合った広告をレコメンドするという、
レコメンドエンジンを広告配信に応用した例
なのだ。
ECサイトの商品やamazonの本をレコメンドするのではなく、広告をレコメンドしたわけだ。
実は、行動ターゲッティング型広告は、最新のテクノロジーのように言われているが、2000年の当時から既にあった技術でありサービスだったのだ。
当時のダブルクリック社は、ユーザの行動履歴をCookie で取得し、ユーザの閲覧履歴に応じて配信する広告を変えていた。
しかし、なぜ2000年にあったサービスがほとんど盛り上がらずに、今になって勢いを出しているのか?
それは、市場のプライバシーに対する過敏な反応が原因だ。
当時、米国の消費者団体が、ブラウザのCookie でユーザの行動履歴を取得することは、プライバシーの侵害だ!と強く反対運動を起こしたのだ。
今でこそ、Cookie を利用したホームページ制作は至極当たり前になっているが、当時は危機感だけが先走りして、ユーザにブラウザのCookie をオフにしろ!なんて、大々的にキャンペーンをやっていた。
そんな市場の反対に押されて、ダブルクリック社は、Cookie でユーザ個人を特定して広告効果を測定することを断念したのだ。
では、今はなぜそんなことが問題にならなくなったのか?
それは、
1.いろいろな要因でCookie を使うことが当たり前になったこと
だって、Cookie を利用したほうが便利だもんね。
会員制のホームページを見るにもいちいちIDやパスワードを入力しなくてよいし。
2.市場が、ネットに親しみ、単なる警戒感だけで拒否するよりも、その利便性を受け入れるようになったこと。
ユーザは、便利さの欲求には抗(あらが)えないからね。
3.市場の裾野が広がり、Cookie なんて言葉を聞いたことも無いユーザが増えたこと
4.ネットビジネスの先導者であるネット広告業界の相対的な力が圧倒的に、彼らが次の商材として行動ターゲッティングを強く求め、それに反対する勢力の力が弱まったこと
5.ブログやSNSの普及により、消費者が自分をネットにさらけ出すことになれてしまったこと
があげられるだろう。
という訳で、
レコメンドエンジンは、実は、2000年の当時から、既にコンセプトして当たり前にあり、そして既に当たり前のように広告配信の世界で利用されていたんですね。
つまり、2000年の(リコメンド)と2008年のレコメンド、何が違う?というと、
市場のプライバシーに対する警戒感の薄れ
が非常に大きな要素といえる。
次回に続く。
2000年のレコメンド(リコメンド)と2008年のレコメンドの違いの第一として、「市場の有無」
をあげました。
さて、長らく間が開きましたが、今回は、2番目の要素を話したいと思う。
レコメンドエンジンを広告業界に適用するとどうなるでしょうか?
話を広告業界の技術進歩から進めてみよう。
最近広告業界で効果が高いといわれる行動ターゲッティング型の広告配信はご存知だろうか?
あるユーザが、どんな分野のホームページを見たか?という履歴を蓄積していって、そのユーザの興味分野を推定する。
そして、そのユーザがどこかのホームページを訪れると、きっとこの人はこの分野に興味があるんだろうということで、その分野にマッチした広告を表示するわけだ。
やり方はいろいろ工夫できるが、ベタなやり方をすると、その人がどんなホームページを訪問しても、ずっと同じ広告が表示させられる。
それには2つのメリットがある。
1つは、ユーザの興味にあった広告が表示されるというメリット。
もう1つは、ユーザに同じ広告を何度も見させられる、というメリットだ。
2つ目のメリットを掘り下げて説明すると、ある広告にユーザが反応するかどうかは、興味のある・なしだけではなく、その広告を何回見たのか?という認知した回数も重要な要素になる。
例えばコカコーラのCM に例えると、一回みてもコカコーラ飲みたいなとは思わないが、5回同じCM を見たタイミングで、コカコーラが飲みたくなったりするらしい。
従って、あるユーザに対して、どんな分野のホームページを見ていっても、同じ広告が表示されるというのは、広告効果を底上げするわけだ。
さて、実はこれは、ユーザの嗜好を分析し、そのユーザに合った広告をレコメンドするという、
レコメンドエンジンを広告配信に応用した例
なのだ。
ECサイトの商品やamazonの本をレコメンドするのではなく、広告をレコメンドしたわけだ。
実は、行動ターゲッティング型広告は、最新のテクノロジーのように言われているが、2000年の当時から既にあった技術でありサービスだったのだ。
当時のダブルクリック社は、ユーザの行動履歴をCookie で取得し、ユーザの閲覧履歴に応じて配信する広告を変えていた。
しかし、なぜ2000年にあったサービスがほとんど盛り上がらずに、今になって勢いを出しているのか?
それは、市場のプライバシーに対する過敏な反応が原因だ。
当時、米国の消費者団体が、ブラウザのCookie でユーザの行動履歴を取得することは、プライバシーの侵害だ!と強く反対運動を起こしたのだ。
今でこそ、Cookie を利用したホームページ制作は至極当たり前になっているが、当時は危機感だけが先走りして、ユーザにブラウザのCookie をオフにしろ!なんて、大々的にキャンペーンをやっていた。
そんな市場の反対に押されて、ダブルクリック社は、Cookie でユーザ個人を特定して広告効果を測定することを断念したのだ。
では、今はなぜそんなことが問題にならなくなったのか?
それは、
1.いろいろな要因でCookie を使うことが当たり前になったこと
だって、Cookie を利用したほうが便利だもんね。
会員制のホームページを見るにもいちいちIDやパスワードを入力しなくてよいし。
2.市場が、ネットに親しみ、単なる警戒感だけで拒否するよりも、その利便性を受け入れるようになったこと。
ユーザは、便利さの欲求には抗(あらが)えないからね。
3.市場の裾野が広がり、Cookie なんて言葉を聞いたことも無いユーザが増えたこと
4.ネットビジネスの先導者であるネット広告業界の相対的な力が圧倒的に、彼らが次の商材として行動ターゲッティングを強く求め、それに反対する勢力の力が弱まったこと
5.ブログやSNSの普及により、消費者が自分をネットにさらけ出すことになれてしまったこと
があげられるだろう。
という訳で、
レコメンドエンジンは、実は、2000年の当時から、既にコンセプトして当たり前にあり、そして既に当たり前のように広告配信の世界で利用されていたんですね。
つまり、2000年の(リコメンド)と2008年のレコメンド、何が違う?というと、
市場のプライバシーに対する警戒感の薄れ
が非常に大きな要素といえる。
次回に続く。
2008/02/27のBlog
[ 00:13 ]
[ レコメンドエンジンの話 ]
先週、日経産業新聞の2面で、ホットリンクが提供するレコメンドASP サービス「レコナイズ」が大きく取り上げられた。
実は、ホットリンクは、2000年の頃からレコメンドエンジンを開発していた。
当時、レコメンドエンジンを提供するベンチャー企業として投資家にプレゼンをしたものだ。
当時導入した事例でいうと、
・総務省のプロジェクトで、松下電器経由で岐阜県教育委員会のe-Learning のシステム
・日本テレコム様へのレコメンドエンジン付き映画のブロードバンド配信ポータルサイト
・東大総研様経由で、自己組織化MAPを利用したエコ情報検索・レコメンドシステム
・ホットリンクの自社サービスで、オンラインブックマークとホームページ&ユーザのレコメンドサービス
・上記オンラインブックマークとホームページ&ユーザのレコメンドサービスの、日経就職ナビへのOEM提供
・情報処理推進機構:中小ITベンチャー支援事業の2004年度に採択された自社製品「レコメンド機能付き文書管理システム」
などがある。
こんなにずっと昔からやっているのに、なぜ「レコメンドエンジンといえばホットリンク」と言われるようになっていないのか?
その理由は、レコメンドエンジンに市場が無かったから。
もし、ホットリンクがずっとレコメンドエンジンにフォーカスしていたら、とっくに会社が倒産していただろう。
そう少し噛み砕いて書いてみたい。
2000年当時にレコメンドエンジンを組み込んだECサイトといえば、アマゾンくらいだった。
今後は、絶対にレコメンドエンジンが大事だとお客さんに提案をしまくった。
だって、お客さんが折角お店に来てくれたのに「いらっしゃいませ。いつもお世話になっています」の挨拶一つせずに、「カタログあるから勝手にクリックしてみろよ」というお店。
顧客対応としてありえないですよね。
しかし結果として、2007年時点で、まともにレコメンドエンジンを組み込んだECサイトは?と聞くと、市場全体で実は両手で数えるほどしかない。
楽天の例でお話しよう。
2000年当時に、僕たちは、楽天にレコメンドエンジンを提案していた。
窓口になってくれたのは楽天の副社長だった本城さん。
本城さんは熱心に話を聴いてくれた。
しかし、最終的に楽天はどういう判断をしたかというと、
収益を上げるために楽天が今一番力を入れなければならないのは、「ユーザのトラフィックを集めること」と「お店の開拓」という判断だった。
実際、その後楽天は、ユーザのトラフィックを集めるためにInfoseekを買収したりと様々なトラフィックを集める施策を打ち、また、「店舗を増やす」ための営業力を徹底的に強化した。
結果として、ものすごく収益が伸びたのだ。
そう、当時の楽天の判断は正しかった。
さて、そして2008年。市場の状況はどうか?
これ以上インターネットユーザは増えない。
ECの出展店舗もそろそろ頭打ち。
となると、次の施策は、来てくれたユーザにどうたくさん買ってもらうか?ということになる。
そうです。
8年かけてやっと、ECサイトがレコメンドエンジンを必要とする外部環境が整ったのです。
2000年のレコメンド(リコメンド)と2008年のレコメンドの違いの第一は、市場の有無だったのです。
第二・第三・第四の違いは、また続く。
実は、ホットリンクは、2000年の頃からレコメンドエンジンを開発していた。
当時、レコメンドエンジンを提供するベンチャー企業として投資家にプレゼンをしたものだ。
当時導入した事例でいうと、
・総務省のプロジェクトで、松下電器経由で岐阜県教育委員会のe-Learning のシステム
・日本テレコム様へのレコメンドエンジン付き映画のブロードバンド配信ポータルサイト
・東大総研様経由で、自己組織化MAPを利用したエコ情報検索・レコメンドシステム
・ホットリンクの自社サービスで、オンラインブックマークとホームページ&ユーザのレコメンドサービス
・上記オンラインブックマークとホームページ&ユーザのレコメンドサービスの、日経就職ナビへのOEM提供
・情報処理推進機構:中小ITベンチャー支援事業の2004年度に採択された自社製品「レコメンド機能付き文書管理システム」
などがある。
こんなにずっと昔からやっているのに、なぜ「レコメンドエンジンといえばホットリンク」と言われるようになっていないのか?
その理由は、レコメンドエンジンに市場が無かったから。
もし、ホットリンクがずっとレコメンドエンジンにフォーカスしていたら、とっくに会社が倒産していただろう。
そう少し噛み砕いて書いてみたい。
2000年当時にレコメンドエンジンを組み込んだECサイトといえば、アマゾンくらいだった。
今後は、絶対にレコメンドエンジンが大事だとお客さんに提案をしまくった。
だって、お客さんが折角お店に来てくれたのに「いらっしゃいませ。いつもお世話になっています」の挨拶一つせずに、「カタログあるから勝手にクリックしてみろよ」というお店。
顧客対応としてありえないですよね。
しかし結果として、2007年時点で、まともにレコメンドエンジンを組み込んだECサイトは?と聞くと、市場全体で実は両手で数えるほどしかない。
楽天の例でお話しよう。
2000年当時に、僕たちは、楽天にレコメンドエンジンを提案していた。
窓口になってくれたのは楽天の副社長だった本城さん。
本城さんは熱心に話を聴いてくれた。
しかし、最終的に楽天はどういう判断をしたかというと、
収益を上げるために楽天が今一番力を入れなければならないのは、「ユーザのトラフィックを集めること」と「お店の開拓」という判断だった。
実際、その後楽天は、ユーザのトラフィックを集めるためにInfoseekを買収したりと様々なトラフィックを集める施策を打ち、また、「店舗を増やす」ための営業力を徹底的に強化した。
結果として、ものすごく収益が伸びたのだ。
そう、当時の楽天の判断は正しかった。
さて、そして2008年。市場の状況はどうか?
これ以上インターネットユーザは増えない。
ECの出展店舗もそろそろ頭打ち。
となると、次の施策は、来てくれたユーザにどうたくさん買ってもらうか?ということになる。
そうです。
8年かけてやっと、ECサイトがレコメンドエンジンを必要とする外部環境が整ったのです。
2000年のレコメンド(リコメンド)と2008年のレコメンドの違いの第一は、市場の有無だったのです。
第二・第三・第四の違いは、また続く。
2008/02/24のBlog
[ 03:08 ]
昨年は、週刊現代で、毎週コラムを書いていた。
そうすると、毎週・毎週、公証30万人の読者に語りかけていたわけだ(読んでいただいていたかどうかは別として)
すると、ブログを書かなくとも、なぜか書いたような気になってしまう。
ブログに限らず、毎週情報を出しているという事実だけで、かなりのレベルで自分の情報発信欲求が満たされてしまようだ。
また、昨年後半から、Twitter に呟きを吐くようになった。
(http://twitter.com/ucchy/)
ただし、週刊現代とは異なり、Twitter の場合は、一投稿で140文字しか書けないので発信している内容・密度はたいしたことがない。ただし、発信頻度は非常に高い。
週刊現代の連載を終えてからも、情報発信しているような錯覚を覚え、ブログを書かなくとも満足していられるということは、
実は、情報発信欲求が満たされるかどうかというのは、発信している情報の量や密度ではなく、頻度が関係しているのだろうか。
昨年の後半に入ってからは研究開発室長を兼務するようになったので、これまでよりも社内のメンバーとのコミュニケーションの頻度が高くなった。
そうすると、これによりまたまた情報発信しようという欲求が下がっている気がする。
ということは、情報発信欲求とは、実は誰かとコミュニケーションしたいという欲求と関係するのか?
そりゃしそうな気がするなぁ。
ただし、それらはどういう関係か?
・・・・・・・・
ここで、話は変わるが、
久々にブログを開いてみて書いてみたが、Twitter ばっかりやっていたからか、長い文章を書いたり、ちゃんと思考してから書く、という能力が落ちている気がする。
いかんなぁ。
そうすると、毎週・毎週、公証30万人の読者に語りかけていたわけだ(読んでいただいていたかどうかは別として)
すると、ブログを書かなくとも、なぜか書いたような気になってしまう。
ブログに限らず、毎週情報を出しているという事実だけで、かなりのレベルで自分の情報発信欲求が満たされてしまようだ。
また、昨年後半から、Twitter に呟きを吐くようになった。
(http://twitter.com/ucchy/)
ただし、週刊現代とは異なり、Twitter の場合は、一投稿で140文字しか書けないので発信している内容・密度はたいしたことがない。ただし、発信頻度は非常に高い。
週刊現代の連載を終えてからも、情報発信しているような錯覚を覚え、ブログを書かなくとも満足していられるということは、
実は、情報発信欲求が満たされるかどうかというのは、発信している情報の量や密度ではなく、頻度が関係しているのだろうか。
昨年の後半に入ってからは研究開発室長を兼務するようになったので、これまでよりも社内のメンバーとのコミュニケーションの頻度が高くなった。
そうすると、これによりまたまた情報発信しようという欲求が下がっている気がする。
ということは、情報発信欲求とは、実は誰かとコミュニケーションしたいという欲求と関係するのか?
そりゃしそうな気がするなぁ。
ただし、それらはどういう関係か?
・・・・・・・・
ここで、話は変わるが、
久々にブログを開いてみて書いてみたが、Twitter ばっかりやっていたからか、長い文章を書いたり、ちゃんと思考してから書く、という能力が落ちている気がする。
いかんなぁ。
2007/12/18のBlog
明後日(12月29日(木) 19:00~)、
サイボウズ、メディア&テクノロジー様主催で、
「次世代WEBサービスの台頭!レコメンドエンジンと対話型WEBサービス・擬人化プログラムの展望」
というセミナーの講師をします。
7月から、CEO兼研究開発室長として、思いっきり研究開発をやってきた成果を思う存分、発表しちゃいます。
内容をちょっと抜粋すると、
・ユーザの行動予測、意図・ニーズを把握するアプリ
・レコメンドエンジンの台頭
・対話型WEBサービス事例紹介
ECサイトにキャラクター店員(プログラム)を配置
フローティングアド活用の事例
・検索エンジンの擬人化が進むとどうなる?
プログラムが1ユーザとなってあなたの友達や秘書に!?
インスタントメッセンジャー(IM)×プログラム
・コンテンツ自発型プログラムの誕生
プログラムが自発的にコンテンツを作る
・ホームページがなくなる日
「メッセンジャーポータル」の可能性
詳細・お申込は、こちらからどうぞ。
サイボウズ、メディア&テクノロジー様主催で、
「次世代WEBサービスの台頭!レコメンドエンジンと対話型WEBサービス・擬人化プログラムの展望」
というセミナーの講師をします。
7月から、CEO兼研究開発室長として、思いっきり研究開発をやってきた成果を思う存分、発表しちゃいます。
内容をちょっと抜粋すると、
・ユーザの行動予測、意図・ニーズを把握するアプリ
・レコメンドエンジンの台頭
・対話型WEBサービス事例紹介
ECサイトにキャラクター店員(プログラム)を配置
フローティングアド活用の事例
・検索エンジンの擬人化が進むとどうなる?
プログラムが1ユーザとなってあなたの友達や秘書に!?
インスタントメッセンジャー(IM)×プログラム
・コンテンツ自発型プログラムの誕生
プログラムが自発的にコンテンツを作る
・ホームページがなくなる日
「メッセンジャーポータル」の可能性
詳細・お申込は、こちらからどうぞ。
2007/12/06のBlog
[ 00:13 ]
昨日、バンダイさんのホームページに、キャラクターエージェントを派遣しはじめました!。
何だそれって?って思うでしょ。
ホームページって、会社の玄関だったり、店舗そのものだったりするはずなのに、
お客さんが訪問してくださっているのに、「いらっしゃいませ」ひとつ言わないっていうのは、ありえなくないですか?
実際の店舗だったら、
「いらっしゃいませ。○○さん。先日の○○はいかがでしたか?」
なんて、挨拶してくれるじゃないですか?
そんな当たり前の接客を、ホームページ上でやりましょうというサービスです。
さらに、
いちいち、受付の社員を教育していられないだろうから、
ホットリンクのASPサーバーから、教育されたエージェントをあなたのホームページに上に派遣します、っていうサービスです。
詳しくはこちら。
特徴としては、
1、自社のホームページに、タグをはるだけで、導入ができます。
後は、キャラクタにしゃべらせたい内容、どのキャラクタにするのかを、テキストファイルに書くだけ。
後は、勝手に、ホームページ上でキャラクタが動いてくれます。
2、選択肢のダイアログを利用して、ユーザと対話をして、ユーザの意図にあったページにナビゲートします。
3.時間によって、対話のシナリオを変えることができます。
4.ユーザのサイト訪問回数によっても、シナリオを変えることができます。
5、検索エンジンからどのキーワードでやってきたかで、シナリオを変えることができます。
6.サイト内検索エンジンと連動させることができます。
てな、特徴があるんです。
本当は、ホットリンク創業して1年くらい後(2001年当時)の事業計画には、
「バーチャルサービスマン派遣サービス」をしますって、書いて、
投資家からお金をあつめようとしていたんですよ。
で、キャラクターエージェントは、賢くないといけないので、
Web2.0 的に、ソーシャルブックマークや、ユーザの口コミを利用して、シナリオを自動的に作ったり、レコメンデーションエンジンとくっつけたりしてました。
そのサービスが、7年ぶりに、新しくなって帰ってきました。
時代の流れって大事だよなぁと思う出来事でした。
何だそれって?って思うでしょ。
ホームページって、会社の玄関だったり、店舗そのものだったりするはずなのに、
お客さんが訪問してくださっているのに、「いらっしゃいませ」ひとつ言わないっていうのは、ありえなくないですか?
実際の店舗だったら、
「いらっしゃいませ。○○さん。先日の○○はいかがでしたか?」
なんて、挨拶してくれるじゃないですか?
そんな当たり前の接客を、ホームページ上でやりましょうというサービスです。
さらに、
いちいち、受付の社員を教育していられないだろうから、
ホットリンクのASPサーバーから、教育されたエージェントをあなたのホームページに上に派遣します、っていうサービスです。
詳しくはこちら。
特徴としては、
1、自社のホームページに、タグをはるだけで、導入ができます。
後は、キャラクタにしゃべらせたい内容、どのキャラクタにするのかを、テキストファイルに書くだけ。
後は、勝手に、ホームページ上でキャラクタが動いてくれます。
2、選択肢のダイアログを利用して、ユーザと対話をして、ユーザの意図にあったページにナビゲートします。
3.時間によって、対話のシナリオを変えることができます。
4.ユーザのサイト訪問回数によっても、シナリオを変えることができます。
5、検索エンジンからどのキーワードでやってきたかで、シナリオを変えることができます。
6.サイト内検索エンジンと連動させることができます。
てな、特徴があるんです。
本当は、ホットリンク創業して1年くらい後(2001年当時)の事業計画には、
「バーチャルサービスマン派遣サービス」をしますって、書いて、
投資家からお金をあつめようとしていたんですよ。
で、キャラクターエージェントは、賢くないといけないので、
Web2.0 的に、ソーシャルブックマークや、ユーザの口コミを利用して、シナリオを自動的に作ったり、レコメンデーションエンジンとくっつけたりしてました。
そのサービスが、7年ぶりに、新しくなって帰ってきました。
時代の流れって大事だよなぁと思う出来事でした。
2007/11/03のBlog
[ 14:31 ]
今日、有楽町のエンジニアTYPE の「エンジニアの適職フェア」に行って、
いろいろな企業の会社説明を受けてきた。
僕は大学院のときに一つ前の会社の起業に関わってそのまま中退したので、就職活動をしたことが無い。
もちろん自分の会社の就職説明をしたことは何度もあるが、人の会社の就職説明を聞くのは初めてだ。
どの会社も、ブースにいる人とわずか十分強話すだけで、
勢いのある会社かどうかや会社の特徴など、好き嫌いの方向性は簡単に分かるもんだ。
やっぱり、他社との違いが明確になっていないところは横並びだよね。
また、会社名を知っている会社のブースには、就職したいかどうかに関わらず、好奇心からか、やっぱりちょっと寄ってみようかなと思ってしまう。 → 知名度は大事ですね。
また、ある程度会社が出来上がっているところ(ベンチャーでも上場し終わったところなど)はもう道ができているので、それを推し進めるのに必要な「部品」を必要としているような気がする。
スキルがあれば、きちんとはまる、みたいな感じ。
いわゆるベンチャーにある、「自分が会社作りに参加している感」というのは、どうしてもないものなんだねぇ。
技術者として安全にスキルアップしていきたい人と、同時に自分も何か会社や新しいサービスを作ることに参加してみたいという人とは、来る場所が異なるじゃんないかな?
そういう意味では、ベンチャーフェアみたいなところの方が、ホットリンクを求めているような技術者が多いのかもしれないのかな?と思った。
と、ここまで来て、落ちを漏らしちゃいましたが、
もちろん、僕が転職活動しているわけじゃないですよーーーー。
今日はホットリンクもブースを出していたので、行ってきたんです。
タイトルをみて、びっくりして読みに来た読者の方、すみません(笑) m(_ _)m
いろいろな企業の会社説明を受けてきた。
僕は大学院のときに一つ前の会社の起業に関わってそのまま中退したので、就職活動をしたことが無い。
もちろん自分の会社の就職説明をしたことは何度もあるが、人の会社の就職説明を聞くのは初めてだ。
どの会社も、ブースにいる人とわずか十分強話すだけで、
勢いのある会社かどうかや会社の特徴など、好き嫌いの方向性は簡単に分かるもんだ。
やっぱり、他社との違いが明確になっていないところは横並びだよね。
また、会社名を知っている会社のブースには、就職したいかどうかに関わらず、好奇心からか、やっぱりちょっと寄ってみようかなと思ってしまう。 → 知名度は大事ですね。
また、ある程度会社が出来上がっているところ(ベンチャーでも上場し終わったところなど)はもう道ができているので、それを推し進めるのに必要な「部品」を必要としているような気がする。
スキルがあれば、きちんとはまる、みたいな感じ。
いわゆるベンチャーにある、「自分が会社作りに参加している感」というのは、どうしてもないものなんだねぇ。
技術者として安全にスキルアップしていきたい人と、同時に自分も何か会社や新しいサービスを作ることに参加してみたいという人とは、来る場所が異なるじゃんないかな?
そういう意味では、ベンチャーフェアみたいなところの方が、ホットリンクを求めているような技術者が多いのかもしれないのかな?と思った。
と、ここまで来て、落ちを漏らしちゃいましたが、
もちろん、僕が転職活動しているわけじゃないですよーーーー。
今日はホットリンクもブースを出していたので、行ってきたんです。
タイトルをみて、びっくりして読みに来た読者の方、すみません(笑) m(_ _)m
2007/10/14のBlog
[ 09:39 ]
今月の20日から書店に並ぶのですが、
「『仮想世界の暮らし方』 内山幸樹 講談社ブルーバックス出版」
が出版されます。
最近のネットの最新情報をわかりやすく説明しながら、
私なりの仮想世界に対する予測や思想をちりばめています。
1年間週刊現代のコラムを書き続け、それをまとめ、かつ大幅に再構成・加筆したものなんだけど、
今から振り返って思うのは、
「書く」という行為によって、自分のあいまいな考えがまとまったなあということ。
あまり仕事につながらない趣味の領域だなあと思っていたけれども、
創業当時の大きなビジョンや、
経営している中でお金にならないから忘れていた面白いアイデア、
等など、いろいろな自分の頭の中をきちんとまとめることにつながった。
だからこそ、TOM君みたいな、創業当時のエージェントの概念を、再度形にしようとし始められた。
非常に良い経験になりました。
読みやすいので、ぜひ読んでみてください。
アマゾンに登録されたらリンク張ります。
PS. 早速時事通信社の湯川さんが、ちょっとうれし恥ずかしな書評を書いてくださりました(感謝)。
http://it.blog-jiji.com/0001/2007/10/post_4d24.html
PS2. 創業前からずっとずっとお世話になっている市場通信の波多野先生が、書評を書いてくださりました。僕自身のことを理解した上でのコメントありがとうございます(感謝)。
こちらです。
「『仮想世界の暮らし方』 内山幸樹 講談社ブルーバックス出版」
が出版されます。
最近のネットの最新情報をわかりやすく説明しながら、
私なりの仮想世界に対する予測や思想をちりばめています。
1年間週刊現代のコラムを書き続け、それをまとめ、かつ大幅に再構成・加筆したものなんだけど、
今から振り返って思うのは、
「書く」という行為によって、自分のあいまいな考えがまとまったなあということ。
あまり仕事につながらない趣味の領域だなあと思っていたけれども、
創業当時の大きなビジョンや、
経営している中でお金にならないから忘れていた面白いアイデア、
等など、いろいろな自分の頭の中をきちんとまとめることにつながった。
だからこそ、TOM君みたいな、創業当時のエージェントの概念を、再度形にしようとし始められた。
非常に良い経験になりました。
読みやすいので、ぜひ読んでみてください。
アマゾンに登録されたらリンク張ります。
PS. 早速時事通信社の湯川さんが、ちょっとうれし恥ずかしな書評を書いてくださりました(感謝)。
http://it.blog-jiji.com/0001/2007/10/post_4d24.html
PS2. 創業前からずっとずっとお世話になっている市場通信の波多野先生が、書評を書いてくださりました。僕自身のことを理解した上でのコメントありがとうございます(感謝)。
こちらです。
[ 09:33 ]
最近、「HPがなくなる日」というタイトルで、HPをなくすプロジェクトの紹介をしている。
HPが無くなった時は、どうなっているのか?
それは、
「Web上のすべてのコンテンツやサービスが、
擬人化されたエージェントとの対話のみ利用できるようになっている
」
ということです。
既にその兆候はでていて、
僕は、
Twitter は、既にホットリンクのTOM(http://tom.hottolink.com)君とIMや携帯メールをすることのみで読み・書きをしているし、
リクルートのHotPepper も、(実験用)TOM君と携帯メールでやりとりすることで利用しているし、
まあ、古くは
ニワンゴも、ニワトリとのメールの対話である程度のサービスを利用可能にしている。
SNS の中のユーザとして、プログラムがユーザのふりをして発言していたりもする。
近々某大きなカンファレンスで発表するので、お楽しみに。
HPが無くなった時は、どうなっているのか?
それは、
「Web上のすべてのコンテンツやサービスが、
擬人化されたエージェントとの対話のみ利用できるようになっている
」
ということです。
既にその兆候はでていて、
僕は、
Twitter は、既にホットリンクのTOM(http://tom.hottolink.com)君とIMや携帯メールをすることのみで読み・書きをしているし、
リクルートのHotPepper も、(実験用)TOM君と携帯メールでやりとりすることで利用しているし、
まあ、古くは
ニワンゴも、ニワトリとのメールの対話である程度のサービスを利用可能にしている。
SNS の中のユーザとして、プログラムがユーザのふりをして発言していたりもする。
近々某大きなカンファレンスで発表するので、お楽しみに。
2007/10/03のBlog
[ 10:26 ]
Twitter をYahoo メッセンジャーから利用できるように、
TOM 君をバージョンアップしました。
Yahoo メッセンジャーで、お友達を追加してください。
お友達のYahoo! ID またはメールアドレスを求められるところで、
「hotto_tom」
と入力してください。
後は、TOM君が会話でナビゲートしてくれます。
TOM 君をバージョンアップしました。
Yahoo メッセンジャーで、お友達を追加してください。
お友達のYahoo! ID またはメールアドレスを求められるところで、
「hotto_tom」
と入力してください。
後は、TOM君が会話でナビゲートしてくれます。
