引き続き、補完財

KoshigoeBLOG: RSS パブリッシャにとっての補完財って何?
Joel本に影響されて、『経済学』とかのビジネスな面も多少考えないとと暴走中。

さて、先のエントリの続きで、『RSS はいったい何に要求されるのか』という事を考えるところから始める。

『何に要求されるのか』を考えるってことは、『どんな用途があるのか』って事を考える事なきがする。これは、「こうしてああしてこれになる」っていうコンサルティングだし、「この問題はこう解決します」っていうサポートだと思う。

まあ、具体的に要求をあげられる訳じゃないんだけど、仮に決まったとする。フローを整理すると、『要求に従って企業がパブリッシャを利用して RSS を作り、パブリッシャもしくは企業が要求元に届ける』という事に。

パブリッシャにとって RSS が行き着く先は、企業に対する要求元。要求元からさらに別の要求元へっていうのは、コンサルティングとかの役割として、パブリッシャは(今は)無視。抜け落ちてるところはいっぱいあるだろうけど、こう考えるとやっぱり、『RSS の受け手をコモディティ化する』って事なのかな?

じゃあ、RSS リーダーが普及すればいいのかっていうとちょっと違う。受け手は、『RSS を読みたい』なんて要求は滅多にしない。『企業が出すプレスリリースを素早く読みたい』って要求を出したとしても、そのデータが RSS であるかメールであるかはあまり関係ない。

つまり、『要求に応えられて RSS を理解できるクライアント』がコモディティ化してくれれば、RSS パブリッシャは嬉しい訳だ。

『ドキュメントデータをプッシュして欲しい』要求に対しては、すでにコモディティ化しているメールクライアントにアドオンとして用意するだけでいい。

Podcasting の様に『メディアデータをプッシュして欲しい』要求であれば、iTunes が対応してるし、できるか知らないけど WMP で頑張ればいい。

『インターネット(ウェブブラウザで見ている)操作と連携したい』要求であれば、ウェブブラウザのアドオンとして対応させればいい。XUL だとか Flash だとか Javascript(+CSS) だとか XAML だとか。

問題は、RSS っていう規格が持つ限界をどう解決するか。『要求はあるんだけど、RSS では表現できない内容なんだ』って事があるかもしれない。けど、これもまたクライアント次第。『こういう目的でこういう情報を載せたいんだ』って事を上手くフィードバックすれば、規格を管理しているところが整理してくれるかもしれない。XML の諸刃の剣な『名前空間による拡張』を使ってもいいかもしれない。よく練られたアイデアであれば、後からついてくるかも。まあ、HTML とか Javascript とかの二の舞になるかもだけど。ただでさえ、RSS1.0/RSS2.0/AtomFeed なんて乱世な訳だし。

とにかく、パブリッシャとして生きていく事を決めたとしたら、RSS をどう使うかを考えて、使い道を考えた RSS を受け取る方法を考えなきゃってことかな。あれー?全部やんなきゃってこと?あー、クライアントアプリについては第3者パワー(親切な開発者)を活用するために、たたき台を作ればいいのか。どう使うかってのも実際に使ってる人たちのフィードバックをどうにかして受け取る努力をしたらいい訳だし、受け取る経路が企業経由(パブリッシャの顧客)でもいい訳だ。

疲れた…。久しぶりに RSS について技術じゃない方面から考えた方がいいかなぁと、思いつきで考え始めたんだけど、迷走し続けてしまった。ビジネスな話はさっぱりなので、このテーマに関しては勤め先の偉い人が考えてると思う。近々全体ミーティングがあるので、ちょっと注目。まあ、話を聞く前に自分なりの整理をしておくといい事あるかな、と。


結論を出せたようで出せてないんだけど、『RSS の普及』に関して1つみんなが知ってる事は、『最終的に受け取る人には RSS って言葉を使わせない』って事だよね。

プロフィール

このブログ記事について

このページは、koshigoeが2006年6月 7日 23:13に書いたブログ記事です。

ひとつ前のブログ記事は「RSS パブリッシャにとっての補完財って何?」です。

次のブログ記事は「RSS 普及物語」です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。