是非、ご利用のRSSリーダーにこちらのRSSファイルのURLを登録下さい。まだRSSリーダーをご利用になったことがない方も、是非この機会にRSSに触れて頂ければ幸いです。
実は、今回のRSSファイルは、futomi's CGI Cafe の新作CGI 『RSS生成CGI』 で生成したものです。ブラウザーから簡単に記事を投稿していくことで、RSSファイルを生成していきます。ついでにトップページの"What's New!"のHTMLの部分も、このCGIで生成します。実際には、SSIを使ってトップページに組み込んでおります。
『RSS生成CGI』は、RSSフィードをしたいのだけれども、サイト全体をブログ化するつもりがないというウェブマスター向けに作ったものです。RSSフィードの可能性が高く評価される一方、とはいっても、サイト全体を Movable Type のようなブログで構築し直すのも大変なことです。だったら簡単にRSSだけ作れれば便利ということで、このCGIが生まれました。
まだ当サイトにて検証中ですが、近々にリリースできそうです。是非、ご期待下さい。リリースの際には、RSSフィードにてお知らせいたします。
せっかくですので、ここで、『RSS生成CGI』の管理者画面のキャプチャーをちょっとだけご紹介します。
『RSS生成CGI』がリリースした際には、上記URLが『RSS生成CGI』の公式ページとなります。
]]>さて、今回のコラムでは、ビジネスサイトをブログ化するその意味を私なりに考察して行きたいと思います。商用サイトとしてのブログの効用とは何か、CMS (Contents Management System) としての利便性はどうなのか、などに触れていきます。
これからブログを採用しようとしている方のご参考になれば幸いです。
ブログの基本的な知識は他サイトに譲るとして、ここでは、ビジネスサイトにおいて、ブログを採用することのメリットについて考察していきたいと思います。いろいろなサイトや書籍を読んでいると、ざっくり大きく分けて次の 2 つに分類されます。
以降、それぞれについて、考察してみましょう。
CMS とは、Contents Management System の頭文字をとったもので、コンテンツ管理システムと訳されます。簡単に言えば、サイトのコンテンツを簡単に更新していく仕組みのことと考えて差し支えありません。ちょっとした記事をどんどん追加するのにも、いちいち HTML を組んで、さらにデザインまで考えながらページを作成するのはとても大変な作業です。それを、はじめから出来合いのテンプレートを使ってデザインされた枠の中に、ブラウザーを使って記事を書き込んでいきます。このような仕組みを採用することで、誰でも簡単にページを更新することが出来るというわけです。実は、CMS としての機能は、ブログに始まったものではなく、かなり以前から同様の仕組みが存在していました。CMSとしての機能は、特に目新しいものではありません。ところが、当時はビジネスでの利用はあまり盛んではありませんでした。デザインのカスタマイズが柔軟でなかったのも、一つの原因ではないかと思います。ところが、近年のブログシステムではかなり柔軟性のあるデザインカスタマイズ機能を持っています。一見ブログを使っているとは分からないようなサイトを構築することも可能となってきました。
近年は、どの企業でもホームページを運営するようになり、公開する情報も多岐に渡ってきました。商売をするにあたり、ホームページの位置づけが非常に重要なものになってきたことは紛れもない事実です。しかし、ホームページを更新するコスト、即時性に関しては、どんどん悩ましい問題となってきております。ほとんどの企業では、専属のウェブデザイナーや技術者がいるわけではありません。更新の都度、ホームページ作成代行会社に委託している法人が多いのではないでしょうか。ところが、このような業務フローである限り、即時性（すぐに情報を公開できる）という観点では優れているとは言えず、もどかしく感じている方が多いのではないでしょうか。
多くのブログシステムでは、本文とデザインとを分離した構成となっています。実際には、完全に分離しているわけではありませんが、ほとんどのデザインはスタイルシートで記述し、本文となる HTML はとてもシンプルな構成となっています。そして HTML 側では、<h1>, <h2> タグ等、文章の見出し、本文に適切なタグが適用されます。これは、検索エンジンのロボットにとっては、その文書の重み付けがしやすくなり、検索サイトでの検索結果で上位に表示されやすいという結果をもたらします。SEO 対策のテクニックが良く話題になりますが、ブログシステムでは、そのようなテクニックを意識することなく、実現できてしまうわけです。
ブログには、トラックバックという機能があることを誰もがご存知のことだと思いますが、これも Google 等の検索エンジンに対する SEO 対策として効果を発揮します。あなたのコンテンツに対してトラックバックしてくれるサイトが増えれば増えるほど、そのコンテンツへのリンク数が多くなっていくことになります。そのコンテンツに関係するサイトからのリンクが増えるわけですから、あなたのサイトへの被リンク数が増え、しいては、Google の Page Rank があがっていくことになるのです。
以上、簡単にブログのメリットをまとめましたが、自社サイトにどのようにブログを組み込んでいけばよいか、悩んでしまうのではないでしょうか。以降、システム的な話ではなく、どんなコンテンツを用意していけばよいのかを考えていきます。
よく、ブログ＝日記と思っている方が多いようですが、確かに間違いではありません。しかしブログは日記にとどまらず、考え方次第でいろいろなシーンで効果的に活用できるのです。例えば、当サイトでは本コーナー（コラム）だけにブログを採用しています。主に CMS としての効果を狙った導入だったわけですが、それ以外にも、コラムというコンテンツの特性上、ご覧頂いた方がどんな感想を持たれたのか気になりますので、トラックバックの機能が欲しかったという理由もあります。このコーナーは日記ではありませんので、毎日記事が増えていくわけでもありません。非常に気まぐれなコンテンツです。そのため、ブログシステムを使ってはおりますが、標準で表示されるカレンダーは削除しています。日記のツールだからといってネタが足りないと悩む必要はないのです。
そのほか、ビジネスとしての活用であれば、商品点数が多いショップでもブログは威力を発揮できるのではないでしょうか。1 商品 1 ページで構成していくことで、検索エンジンでその商品に関連するキーワードでの上位表示が期待できるでしょうし、どんどん追加されていく商品のページ作成の手間もかなり簡素化されます。
サイト全体をブログシステムで構築してもよいでしょう。もしくは当サイトのように部分的に採用するのでも、効果的に活用できるのではないでしょうか。
毎日かけるほどネタがないと心配されている方も多いのではないでしょうか。確かに、ブログ関連のマーケティング系書籍などでも、継続性が大事と書かれています。また、ブログサイトのうち、何割が毎日更新され、何割がすでに更新されなくなったなどといったリサーチ結果の報告があることは事実です。まるで、毎日継続的に記事を追加していかなければいけないかのごとく、マスコミでは煽り立てているようにも見受けられますよね。
ブログだからといって、必ずしも更新頻度が高くないと効果がないというわけではありません。それは、ブログシステムを使う目的次第です。ブログをメルマガと同じ位置づけ・目的で採用するのであれば、継続性や更新頻度は大事です。また、日記ブログとして認知させ、リピーターを増やしたい場合も、同様です。しかし、ブログはメルマガや日記の代用に限られるものではありません。前述の通り、さまざまな用途・目的があるわけですから、それに応じた更新頻度で良いのです。ブログだから更新頻度は高くなければいけない、と考える必要はないのです。
最近、社長日記が流行っています。まさにブログにうってつけの使い方ではありますが、あまり集客には効果がないと思っています。六本木ヒルズや渋谷の某有名 IT 企業の社長日記と同じというわけにはいきません。彼らは、彼ら自身がすでにブランド化しているわけですから、どんな些細なことを綴っていったとしても、それはそれで読む人がいるわけです。つまり、有名人は、ブログを書いているということ自体が、すでに大きな話題性を持つことになるのです。ところが、世の中で無名の方が自身の日記を書いたところで、誰が読みにくるのでしょうか。結局のところ、集客効果という意味からすれば、社長日記は時間の無駄といえます。確かに、日記を書くことで、さまざまなキーワードで社長日記が検索サイトで表示されるようになるかもしれません。ところが、それが見込み客である可能性は限りなく低いのです。
以上、社長日記に関して厳しいことを述べましたが、社長日記そのものを否定するつもりはありません。集客効果という観点から見た場合には効果がないと述べましたが、実は、それ以外の目的でとても効果を発揮すると考えています。それは、見込み客に対して信頼を得る足がかりになるという点です。
貴社の商品・サービスを求めている見込み客が、貴社にコンタクトを取る前に何をするでしょうか。恐らく、貴社サイトを見て、貴社がどんな会社なのかを念入りに調べるのではないでしょうか。ところが、ホームページからだけでは貴社の細かいところまでは分かりません。どこの会社でも書いてあるようなパンフレットレベルのありきたりな情報に過ぎないのではないかと思います。つまり一般的な会社概要ではマイナス要因になることはあっても、プラス要因になることは少ないということです。ところが、もし社長ブログを使って、社長自らが商品を開発した経緯やそのこだわり、苦労などを綴っていたらどうでしょうか。または、会社の理念を分かりやすい言葉に置き換えて綴っていったらどうでしょう。恐らく、貴社に対してある程度親近感を持つようになり、書いてある内容によっては、この会社であれば任せられる！と感じて頂ける場にもなるのではないでしょうか。
このような効果を求めるのであれば、社長日記といっても、今日は会議をしたとか、昼食はこんなものを食べたなどといったくだらないことを書いている場合ではないのです。自社のこだわりをアピールする場として戦略的に思いを綴っていくべきでしょう。そして日記ではありませんから、毎日書く必要もないのです。ただし、誠意をこめて書かなければいけないということは言うまでもありません。戦略的とはいっても、イメージ戦略をあまりにも前面に押し出した文章では、かえって胡散臭くなってしまいますので、ご注意を。
最後に、ブログを採用することによって得られるもう一つの効用について述べていきたいと思います。それは RSS です。ご存知の通り、RSS とは、更新された記事を XML のフォーマットで公開し、RSS リーダーと呼ばれるソフトを使って閲覧するものです。詳細は他サイトに譲りますが、本コーナーでも RSS に関する記事 『RSS の行方』を公開しておりますので、あわせてご覧下さい。
ブログシステムを使うと、ほとんどのシステムでは、記事を更新する都度、RSS ファイルを生成してくれます。もし貴サイトの常連さんが RSS リーダーを使っていれば、貴サイトの RSS を登録してくれることが考えられます。これは、サイトが更新されたことを通知してくれる仕組みともいえるのです。
今までは、メルマガ登録者に対して、更新情報を通知するのが常套手段だったかと思います。ところが、RSS を公開することで、メルマガに登録していない訪問者に対しても、サイトの更新通知の手段を提供することになるのです。メルマガに登録するのをためらっていた見込み客でも、RSS で公開していれば、気兼ねなく自分の RSS リーダーに登録してくれるようになるでしょう。つまり、見込み客への情報提供の手段が増えたとお考え下さい。
もちろん、RSS リーダーに登録して頂くようにするためには、それなりの魅力的な情報提供が欠かせません。これはメルマガと同じです。宣伝ばかりの情報提供では、いずれ読者は減っていきます。読む価値があるコンテンツを提供していかなければいけないことには変わりはありません。RSS を公開するだけで見込み客が増えるといったことはありません。
また、ブログを対象とした検索エンジンが数多く出てきました。RSS ファイルをロボットが読み取りにくる場合もあります。各種サイトで自サイトが露出する機会を得られる可能性もあるのです。
現状は、誰もが RSS リーダーを使っているというわけではなく、まだまだニッチな領域です。しかし、急激に RSS リーダーの利用者も増えてきましたので、今後はメールに続くメディアとして認知されていくのではないでしょうか。今のうちに RSS を公開してみてはいかがですか？
実は、ブログ関連技術の中で私が一番注目しているのは RSS なんです。今後、どれくらい RSS が商用サイトで効果を発揮するかは分かりませんが、注目に値する仕組みと考えています。ブログを導入しなければ RSS が作れないというわけでもありません。実は、ブログを導入しなくても、RSS を自分で作って、サイトに公開することも可能です。詳細は当サイトの技術文書日本語訳コーナーをご覧下さい。
RSS 自分で作るといっても、実は、かなり複雑です。簡単に作れるわけではありません。そこで、当サイトの新作 CGI として、RSS をブラウザーから簡単に生成することができる RSS ジェネレーター CGI （仮称）を企画することにいたしました。この新 CGI では、ブログツールで記事を書き込むのと同じように、どんどんと新着情報を追加していくことで、RSS ファイルを生成します。あわせて、HTML ファイルも同時に生成することができるようにする予定です。この HTML は、例えば、トップページの新着コーナーに表示させるといった目的で使うことを想定したものです。さらに、集客効果をあげるために、更新 ping を発行する機能を実装する予定です。オンラインショッピングサイトで、新規に入荷した商品をどんどん RSS として情報を公開するといった活用事例が考えられます。
まだまだ企画段階で構想（妄想？）が私の頭の中だけで勝手に膨らんでしまっているのですが、ご要望などがございましたら、遠慮なくリクエスト頂けると幸いです。可能な限り、みなさまのご要望を、企画段階である RSS ジェネレーター CGI （仮称）の機能として盛り込んでいければと考えております。
関連リンク
ちなみに本コーナーは私の日記ではありません。最近、日々思うことを日記として綴っていくことも流行の一つではありますが、このコーナーはあくまでもコラムとして綴っていきたいと思います。ネット関連のさまざまな時事ネタや興味深いトピックを、技術的なアプローチで、そして私なりの切り口で取り扱っていければと考えています。
不定期ではありますが、みなさまのインターネット知識のトリビアとして役立てるようなコーナーにしていけるよう、がんばってまいります。本コーナーには、RSSフィードもご用意しましたので、是非、ご利用のRSSリーダーに登録しておいて頂けると幸いです。
本コーナーで採用したブログシステムは、みなさまも良くご存知のMovable Typeです。ここでは、Movable Typeについて、私の感想を述べていきたいと思います。
すでに本サイトは専用サーバで運営され、独自ドメインを持っておりますので、自サーバインストール型のMovable Typeを採用したわけですが、採用の理由はこれだけではありません。一番大きな理由は、カスタマイズの柔軟性に優れいている点です。画面デザインから表示する内容に至るまで、かなり細かく設定することができます。ASP型のブログサービスとの大きな違いの一つといえるでしょう。また、記事を追加するたびに、静的なHTMLファイルを生成するというモデルを採用している点もMovable Typeのメリットの一つでしょう。もしアクセスの都度、プログラムが起動して、画面を動的に生成していたとしたら、サーバに多大なる負荷をかけることになります。このあたりの運用面にも配慮された点がお勧めのポイントです。
カスタマイズの柔軟性に優れているということは、言い換えると、ちょっとカスタマイズするだけでもとても難しいともいえます。テンプレートの編集は、XHTML, CSSを駆使します。また、RSSも自由にカスタマイズできるわけですが、当然、各種RSSのフォーマットを熟知していないとカスタマイズすることはでいません。そして、Movable Typeのテンプレトマニュアルとにらめっこになります。先日、RBB Press から『Movable Type公式タグリファレンス』が発売されました。本になるくらい柔軟性があり、また難しいということです。初心者にはちょっと難しいかもしれませんね。もし企業でMovable Typeを採用するのであれば、専門の業者に委託してテンプレートを用意してもらうのが良いかもしれません。最近、Movable Typeの設置からテンプレートのデザインまで請け負ってくれるデザイン会社も増えてきました。
柔軟性と簡便性はなかなか両立しにくいものです。私もさまざまなウェブアプリケーションを作ってきましたが、いつもこの点に悩まされます。
Movable TypeはPerlで書かれたアプリケーションです。私自身、Perlを使ったウェブアプリケーション製作に携わっているわけですが、Perlプログラマーの目から見て、Movable Typeはとてもよく出来たアプリケーションだと感心しています。これだけのカスタマイズの柔軟性を持たせるためには、かなりしっかりした設計とプログラミング技術が必要となるわけですから。
現在、Movable TypeはSix Apart社から販売される有償のアプリケーションとなりましたので、個人の趣味ではなかなか購入に踏み切れないかもしれませんが、企業でビジネスとして使うのであれば、お勧めのブログアプリケーションだと思います。
さてこのたび、皆様にご愛顧頂いております futomi's CGI Cafe を、2 月 1 日付にて下記のとおり、新たに会社として発足させる運びとなりました。これもひとえに、皆様方のご支援の賜物と、心から感謝申しあげる次第でございます。今後は、皆様のご期待にそえますよう一層の熱意を持って、製品の充実とサービスの向上につとめる所存でございます。なにぶんにも未熟者ではございますが、旧に変わらぬご指導ご鞭撻を賜りますようお願い申し上げます。
社名 ： 有限会社ｆｕｔｏｍｉ 所在地 ： 埼玉県入間市大字上藤沢５５４番地２３ 資本金 ： ３００万円 設立日 ： 平成１７年１月５日 事業開始日 ： 平成１７年２月１日 事業内容 ：
- コンピュータープログラムの開発、販売、受託開発
- コンピューターネットワークに関するコンサルティング、管理
- その他上記に付帯する一切の業務
関連リンク
]]>ブログを運営するにあたり、運営者側の興味の一つに RSS があげられるでしょう。簡単に言えば、ブログ記事の新着・更新情報をヘッドラインにまとめ、RSS ファイルとしてサイト上に公開します。もし貴方のサイトの常連がいるとすれば、その常連は RSS リーダーと呼ばれるソフトを使って、貴方の新着情報を知ることができるようになるわけです。RSS リーダーは、登録された RSS ファイルの URL に従って、巡回チェックをするのです。
当初、RSS もマニアックなツールに過ぎませんでしたが、近年は asahi.com 等の大手ニュース配信サイトでも RSS に対応するなど、コンテンツも増えてきました。また、RSS リーダーもフリーで多数出回るようになり、多くの方が利用するようになりました。RSS もメジャーなメディアとしての地位を確立してきたといえます。ただし、あくまでも RSS はサイト運営の手段の一つに過ぎません。RSS に対応したからといって、読者が急激に増えるなどということは決してありません。結局は、RSS リーダーに登録してもらえるほどの魅力的なコンテンツと更新頻度が求められるのです。しかし、地道に努力して定期的にコンテンツを更新してきたサイトにとっては、RSS は非常に有効な手段でしょう。
さて、前置きが長くなりましたが、今回は、その RSS の技術的な背景をご紹介していき、混迷する RSS 仕様の行方を占っていきたいと思います。
まずは、RSS の仕様に関してご紹介します。RSS といっても実はいくつかの派生が存在しています。恐らく、RSS、RDF、Atom といった用語を聞いたことがあるのではないでしょうか。いずれも別々の団体が仕様化したもので、技術的には全く異なるフォーマットになっています。RSS の仕様は大きく分けて、3つに分かれます。
最初に RSS をブレイクさせた仕様といってもいいでしょう。もともと UserLand Software 社が 1997 年に策定した scriptingNews というフォーマットに端を発します。その後、1999 年に、Netscape 社によって、my.netscape.com 向けに RSS 0.90 が策定されましたが、scriptingNews フォーマットをサポートしていました。同年 UserLand Software 社は RSS 0.90 すべての機能を包含し、さらに拡張をした ScriptingNews 2.0b1を発表しました。さらに同年、Netscape 社は、ScriptingNews 2.0b1 すべての機能を包含し、さらに拡張を施した RSS 0.91 を発表しました。ついに、UserLand 社は、自社の scriptingNews フォーマットを捨て、RSS 0.91 を採用することになりました。そして、Netscape は RSS から手を引くことになり、RSS 0.91 は UserLand社の RSS 0.91 として 2000 年に公開されたのです。
Netscape 社の RSS は W3C が規定する RDF ベースだったのですが、UserLand 社の RSS 0.91 からは、シンプルさを求め、独自の XML フォーマットに変更されています。
多くのブログツールが対応しているのは、この UserLand Software 社の RSS 0.91 からです。その後、RSS 0.92 を経て、RSS 2.0 にバージョンアップされました。ScriptingNews から RSS 2.0 は、UserLand Software 社の創設者 Dave Winer 氏が主体となって策定された仕様です。彼はすでに UserLand Software 社を去り、ハーバード大学法学大学院の Berkman Center の特別研究員となっているようです。RSS 2.0 以降は、Berkman Center のサイトにて公開されています。
以上の経緯の詳細は、Berkman Center のサイト内の "RSS History" で説明されています。
尚、UserLand Software 社が策定した RSS 0.9x は "Rich Site Summary" の略ですが、RSS 2.0 は "Really Simple Syndication" の略です。ただ、既にお蔵入りとなった Netscape 社の 0.9x は "RDF Site Summary" と呼ばれていたようで、次に説明する RSS 1.0 と同じです。ややこしいですね。
RSS 0.9x/2.0 系の特徴は、配信する内容はヘッドライン情報に限っている点です。そのため、フォーマットが非常にシンプルで分かりやすいのが特徴です。これは、広く普及した要因の一つでしょう。
この仕様は、RSS 1.0 とも呼ばれ、前述の UserLand Software 社の RSS 0.9x や RSS 2.0 の系統とは全く別物です。同じ RSS という略記が使われているので、まるで一連のバージョンと勘違いされている方も多いのではないでしょうか。私の感想では、どちらかというと、お蔵入りとなってしまった Netscape 社の RSS 0.9x の後継と言ったほうがいいかもしれません。UserLand Software 社の RSS 0.9x が使われだしてから、利用者が勝手に規定外の要素を追加するなどして、混乱を呈してきました。そこで、RSS 1.0 は、それまでの RSS 0.9x をより豊富なデータを転送できるよう拡張できるよう再定義するために策定されたものです。拡張とは、XML 名前空間を指定することで、さらにさまざまな要素を追加して配信できるようになったのです。RSS 0.9x/2.0 系ではヘッドライン情報といった要約情報しか遅れなかったのに対し、RSS 1.0 では拡張した XML 名前空間を使ってコンテンツの内容そのものも配信できるようになっています。
RSS 1.0 仕様は web.resource.org にて公開されており、Aaron Swartz 氏らによって作成されたものです。ちなみに彼は、W3C RDF Core Working Group のメンバーです。
大きな技術的特徴としては、W3C の RDF 仕様に準拠し、XML の名前空間を使って拡張できる点があげられるでしょう。また、名前空間を使った拡張部分を除いては、RSS 0.9x との下位互換性があると仕様で謳われております。しかし、前述の Berkman Centerの "RSS History" では、"RSS 1.0 は、0.9 のような RDF ヘッダーはあるものの、それ以外は全くの新規のフォーマットで、以前のバージョンとは関係が無い。"と謳っています。まぁ、これら言い回しの違いは、両者の立場の違いなんでしょうかねぇ。少なくとも私が見る限り、RSS 0.9x/2.0 系と RSS 1.0 系は、まったく別物という印象を持っています。
RSS 1.0 の仕様では、UserLand Software 社の RSS 0.9x のおかげで RSS が広く使われるようになったと賞賛しつつも、Netscape 社の RSS 0.91 から UserLand Software 社の RDF 0.91 に変貌する仮定で、RDF の本質が欠落してしまったことへの憤り感じているように読み取れます。確かに、RSS 1.0 を策定した Aaron Swartz 氏は、W3C RDF Core Working Group のメンバーなのですから、そう思うのは当然でしょう。そして、それを克服すべく RSS 1.0 が策定されたと読み取れます。両者のドキュメントを見る限り、それぞれに対立意識があるのは間違いないでしょうね。
すでに 2 系統ある RSS ですが、さらにもう一つ加わることになったのです。それは、Atom と呼ばれるフォーマットです。Atom は、すでに 2 系統ある RSS を一旦捨てて、ゼロベースから生み出されたフォーマットです。つまり、まったく互換性が無いフォーマットです。
では、そこまでして、なぜ Atom が考え出されるようになったのでしょうか。それは、RSS 0.9x/2.0 系フォーマットではヘッドライン情報しか送れないという点と、RSS 1.0 では拡張されたものの非常に複雑という点を克服し、分裂していた規格を一つに統合するためです。Atom というものを簡単に説明すると、記事更新情報配信とAPI の提供です。記事更新情報配信は今までの RSS と同じものです。API とは、記事の投稿・編集・削除などのオペレーションを行うためのプログラムインタフェースを定義したものです。
米国では、米 Google の「ブロガー」サービスで Atom を採用するということで議論を巻き起こしたようです（CNET Japan の記事より）。すでにブログツールで有名な Movable Type の開発元である Six Apart 社も Atom を支持していますので、Atom 陣営にとっては追い風となっています。対して、米 Yahoo! は RSS の採用を決定しており、大手サービスオペレータが分裂するという事態になっています。その後、停戦が呼びかけられ、統合の方向の可能性が出てきました。（CNET Japan の記事より）。これが 2004 年 3 月のことですが、現在はどうなっているんでしょうね。
Atom は、業界標準を目指し、現在は、IETF の Ineternet-Draft になっています。しかし、短期間にさまざまなバージョンアップが繰返され、さらにその仕様が大きく変わってしまうこともあり、混乱を招いているようです。まだまだこれからって所なんでしょう。早く RFC になることを期待しています。
| 時期 | 0.9x/2.0 系統 | 1.0 系統 web.resource.org |
Atom | |||||||
| Netscape 社 | UserLand 社 | Berkman Center | ||||||||
| RDF Site Summary | Rich Site Summary | Really Simple Syndication |
RDF Site Summary | |||||||
| 1997年 | scriptingNews | |||||||||
| 1999年 | RSS 0.90 | |||||||||
| scriptingNews 2.0b1 | ||||||||||
| RSS 0.91 | ||||||||||
| discontinued | ||||||||||
| 2000年 | RSS 0.91 | |||||||||
| RSS 0.92 | ||||||||||
| obsolete | RSS 1.0 | |||||||||
| 2003年 | RSS 2.0 | |||||||||
| 2004年 | draft-ietf-atompub-format-01 | |||||||||
| draft-ietf-atompub-format-02 | ||||||||||
| draft-ietf-atompub-format-03 | ||||||||||
| 2005年 | draft-ietf-atompub-format-04 | |||||||||
すでに 3 系統の RSS フォーマットが存在するわけですが、現状はどのフォーマットが良く使われているのでしょうか。私の所感でいうと、海外では RSS 0.9x/2.0 系が多く使われ、日本国内のサイトでは RSS 1.0 が多く使われているようです。恐らく、RSS の人気が出始めた時期の違いではないかと思います。海外（特にアメリカ）では RSS 0.9x しかない時代にすでに RSS が使われていたこともあり、そのまま RSS 0.9x そしてその後継である 2.0 が多く使われているのではないかと思われます。それに対して、日本国内では、アメリカに後れて流行りだしましたが、そのときちょうど RSS 1.0 がリリースされていたため、それが採用されてきたのではないでしょうか。Atom はまだ Internet-Draft の段階ということもあり、実運用で使われているところはまだ少ないようです。
RSS フィードをしている国内の有名なサイトと、対応している RSS バージョンをいくつかご紹介しましょう。
そして、このサイトで紹介するにはちょっと異色ですが。
もし貴サイトで RSS フィードを行いたいのであれば、どのフォーマットを採用するのがいいのかと迷うかもしれませんが、RSS 1.0 もしくは RSS 2.0 のいずれかに対応していれば全く問題ないでしょう。多くの RSS リーダは、どちらのフォーマットにも対応しています。
以上、RSS の歴史から現状までを見てきましたが、この後、どのフォーマットがデファクトスタンダードとなるかは、誰にも分かりません。ただ、開発者としての立場から言わせてもらえば、何でもいいから 1 つにしてくれ！といいたいところです。ネット業界とは関係の無い世界でも、これと同じようなことが起こりましたね。ビデオの VHS とベータ、次期 DVD の Blue Ray と HDD。それぞれが切磋琢磨に技術を革新することは良いことではありますが、2 つ以上のスタンダードが出てきてしまうと、混乱するのは結局のところ消費者（利用者）です。RSS も同様ではないでしょうか。自分が使っているブログツールは、どちらに対応しているのか、もしくはどちらにも対応してるのか、なんてことをいちいち気にしないといけないわけです。早くこの論争が収束することを望むばかりです。
では、最終的にどのフォーマットがデファクトスタンダードになりそうかといえば、私の感想では Atom ではないかと思っています。
このような規格は、開発者がそれを採用して各種プロダクトに実装されなければ使われることはありません。開発者の立場からすれば、公共的な組織によって策定もしくは認められた仕様のほうが、安心です。もしある規格を採用し一生懸命プロダクトを作ったとしても、採用した規格が廃れてしまって、そのプロダクトそのものの価値がなくなってしまってはもともこもありません。開発者に限らず、サービスオペレータも同様の立場でしょう。そういう点では、IETF の RFC になりそうな Atom に一票ってところでしょうか。
もう一つ忘れてならないのが、RPC の機能です。リモートからサーバに対していろいろな処理をコールするものなのですが、一種のウェブサービスですね。Atom は Atom API という名前で、ウェブコンテンツ更新用のインタフェースを規定しています。先日、日本国内でも「はてな」が「はてなフォトライフ」に限って Atom API を採用し、「はてなフォトライフAtomAPI」を公開したばかりです。今後も Atom API を採用するサービスオペレータが増えてくるのではないでしょうか。RSS 0.9x/2.0 系の策定に携わった UserLand Software 社も、XML-RPC という規格を策定しております。ただ、やはりある特定の企業に仕様が握られているという構図は、開発者から見れば望ましいものではありません。これは、Atom という規格ができてた理由の一つでもあるようです。IETF のような公共的な団体で、Draft 段階から一般に意見を求め、それに基づき改善された上で勧告となるほうが安心感がありますよね。こういう点でも Atom に一票です。
廃れるか、流行るかは、このような公共的な組織によって策定・認定されることで確信できるわけではないのですが、好材料の一つではあります。RSS の世界は、一つだけのプロダクトで成り立っているわけではなく、さまざまなプロダクトが有機的に連携することで、その真価を発揮するものです。このような使われ方である以上、IETF のような機関で仕様化されたほうが受け入れやすいのではないでしょうか。ただ、まだ Atom は現段階では Internet-Draft です。その後に期待ですね。ただ、RFC になったところで、すぐにそれがデファクトスタンダードになるわけではありません。それまでには何年かかかるでしょう。その間は、相変わらず各種フォーマットが混在することになるのでしょう。日本国内では、当分の間、RSS 1.0 が主流ってことになりそうですね。
関連リンク
]]>新規 CGI を企画する上で、最初に行うのがテーマ決めです。アクセス解析、掲示板、チャット、フォームメール、アクセスカウンター等、さまざまなテーマが考えられます。その中から何を選ぶべきかといえば、"ニーズをつかみ、それを満たすもの" が模範解答なのでしょう。いずれのマーケティング系の書籍にうたわれているのは、みなさまもご存知の通りです。しかし、私の場合、正直申し上げると、基本的に自分で使いたいと思うことが大前提です。企画段階では本当のニーズがなかなかつかめません。私は CGI プログラマーですが、同時に当サイトのウェブマスターでもあります。そして、シェアウェア販売というビジネスを行っています。私が欲しいと思う機能は、恐らく、私と同様に、ウェブでビジネスを営んでいる方も望んでくれるだろうという前提で企画します。私が勝手に "こんなニーズがあるだろう" と思って、自分では欲しくもないものを作ったとしても、いい物はできません。自分が欲しいと思え、こだわれるからこそ、いいものができると考えています。そして、ウェブマスターの当事者でもある自分が欲しいと正直に思う CGI を作ることが、結果的に多くのウェブマスターの方に喜んでいただけるだろうと信じて、テーマを決めます。
テーマが決まったら、次に、「誰でも、どんなサイトでも、どのサーバでも簡単で便利に使える」ことを念頭において CGI のコンセプトを決めていきます。コンセプトというと難しい感じがしますが、要は、その CGI の特徴を列挙します。コンセプトまで決まれば、あとは、それを機能という具体的な形に落とし込んでいきます。実装する機能の選定基準は、はやり自分が必要と思うもの、そして、多くの方も欲しいと（勝手に私が）思うものです。アイデアはいくつも出てきますが、殆どがボツになります。ボツになる機能は、概ね、技術的に難しいものや、殆どの方が望まないだろうと思うものです。そして、"誰でも、どんなサイトでも、どのサーバでも簡単で便利" という大前提に反するものがボツになっていきます。実はこの大前提が厄介なのです。多くの方に使っていただきたいとの思いからこの大前提を守ろうとするのですが、逆に多くの方に使っていただこうと考えたさまざまな機能を実現しようとすると、この大前提が守れなくなるという矛盾が生じるのです。さまざまなオプション機能を設けることにより汎用性や機能性は向上しますが、その分、設置が難しくなってきます。つまり、豊富な機能を設けることと、「誰でも、どんなサイトでも、どのサーバでも簡単に便利に使える」ということとは、トレードオフの関係になるということなのです。どのあたりを落としどころにするのかを悩み、いくつかのアイデアから本当に望まれる機能に限定して、CGI の製作が開始されます。
実は、CGI の製作よりも、これまでの企画・設計のほうに多くの時間が割かれます。とはいっても、パソコンの前で時間を割いているわけではなく、頭の中だけでの作業となります。歩いている時、電車に座っている時（殆ど寝てしまいますが…）、寝る前の布団の中にいる時、入浴中等、空いている時間を使って、アイデアを熟成していきます。頭の中である程度まとまってから、初めてパソコンの前で、Perl スクリプトの製作が開始されます。Perl スクリプト製作が開始されてからは、一気に作り上げてしまいます。
やっとの思いで作り上げた CGI をリリースして、ひとだんらくです。しかし、リリースしてからが、本当の意味で、みなさまに喜んで頂く CGI の企画・製作が始まるのです。新規に CGI を企画する際には、自分が欲しいものが基準となっていることは前述の通りです。自分が欲しいものは、皆様にも喜んで頂けるだろうという前提であったことは事実なのですが、やはり、基準はあくまでも自分です。多くの方のニーズから外れていることが多々あります。CGI をリリースしてから、それをお試し頂いた方から寄せられるリクエストを漏れなく記録していきます。人気のある CGI にいたっては、バグ改修も含め、短期間に ToDoList が一杯になってしまいます。すべての方に、なかなかご返信できていないのですが、必ずリクエストは拝見させて頂いております。寄せられるリクエストが本当のニーズなのですから、これほど貴重な情報源はないのです。リクエストが頂けるようになってからは、機能追加の基準は "私" ではなく、その CGI をご利用頂ける "ご利用者" に変わります。いくつか寄せられたリクエストにプライオリティーを付けて、バージョンアップという形で実現していきます。当サイトで配布しているバージョンをご覧頂くと分かるかと思いますが、バージョンが高いものほど、リクエストが多かった証です。そのような CGI は、ご利用されている方々からのリクエストの塊みたいなものです。追加したい機能によっては、ロジックから見直さなければいけない場合があります。その場合には、再度、一から仕様を練り直し、作り直すこともあります。メジャーバージョンアップ（バージョン番号の最初の数字が上がる時がメジャーバージョンアップです。）の時には、かなりのソースコードが作り直されているのが実情です。
もし私が作成した CGI をお試し頂けるようでしたら、リクエストを頂けると幸いです。なかなかご返信は出来ないかもしれませんが、必ず拝見させて頂きます。
最後に、今後作っていこうと考えているテーマをご紹介します。いつになることやら(^^; 。もしその他に、欲しい CGI がありましたら、どしどしリクエストを下さい。
▼ ショッピングカート
実は過去に何度もチャレンジした経緯があります。しかし、ご利用シーンはさまざまで、なかなか汎用的に作れず、いまだに実現に至っておりません。3 度ほど作り直しましたが、自分自身、満足いくものではなく、すべて捨ててしまいました。いつかは必ず実現したいと思っているテーマです。
▼ スレッド型掲示板
すでに数多く世に出ているテーマなので、なかなか特徴を出すのが難しいテーマです。個人サイトで利用するというよりは、企業がナレッジとして活用できるような掲示板にしたいと思っています。その他、気の利いた特徴を思いつけば、ぜひ取り組みたいテーマです。
▼ Amazon Web サービス
Amazon が提供している Web サービスを使った プチ・Amazon サイトが作れるような CGI に興味があります。XML, UTF-8, HTTP 通信などの壁があるのですが、どこまで作れるか試してみたい。。。各種 Perl モジュールを使えば、さほど難しくないのですが、それを多用しすぎると、使えるサーバが限られてしまうという問題が。。。
▼ PC 向け Web メーラー
すでに携帯電話向け Web メーラー "Kmail CGI" はリリースしましたが、PC 向けのリクエストがちらほら。。。実は、過去に作ったことがあるのですが、あれこれ機能を盛り込みすぎて、わけが分からなくなり、結局ボツにした経緯が。。。再度、チャレンジしてみようかなぁとも思ってます。
関連リンク
]]>MP Form Mail CGI
よく、"MP Form Mail CGI" の "MP" ってどんな意味ですか？ と質問されます。実は、2 つの意味を込めているつもりだったんです。もともとは "Multi Part" から取りました。最初にリリースした "MP Form Mail CGI Standard版" は、ファイルを添付してメールを送信できる点を売りにしようと作ったものなのですが、スクリプトを作るためには、それなりの技術的な下調べが必要です。当然、IETF（The Internet Engineering Task Force）のRFC（Request for Comments）文書にも目を通します。メールにファイルを添付する方法を規定しているのは RFC 2045 なのですが、その中に "multipart" という言葉が出てきます。添付ファイルやメール本文等を、一つのメールボディー内にどのように収めるかを規定しています。当然、"MP Form Mail CGI" も RFC 2045 に規定された multipart を実現しているのですが、この言葉の頭文字をそのままネーミングとして使ったのです。
もう一つの意味とは、"Multi Purpose" です。日本語で言えば "多目的" なのですが、"MP Form Mail CGI" をさまざまなシーンでご利用いただけるようにと考えて作りました。
"MP Form Mail CGI Standard版" をリリースしてから、次に "MP Form Mail CGI Professional版" をリリースしましたが、こちらは、"Multi Part" というよりは、"Multi Purpose" に重点を置いて設計したプロダクトです。
高機能アクセス解析 CGI
ネーミングってわけではありませんが、"高機能" を頭に付けた理由をご説明します。当サイトで初めてリリースした CGI は "高機能アクセス解析 CGI Standard 版" なのですが、サイトを立ち上げたときには（今でもそのつもりですが...）、世の中で配布されているどの CGI よりも便利で役に立つものを作ろう！と意気込んでおりました。当初、このサイトは Perl の技術情報を掲載する目的で立ち上げたのですが、やはり気になるのがアクセス数です。ウェブマスターであれば、誰でも気にしてしまう、もしくは気にしなければいけない情報なのですが、私個人的に満足できるアクセス解析が当時はあまりありませんでした。私が満足するポイントは "簡単設置"、"サイト全体の解析"、"多角的な分析" でした。無いなら自分で作ってしまおうと思い、"高機能アクセス解析 CGI Standard版" を作り始めました。特に、さまざまな分析ができるというメニューの豊富さを売りにしたかったのですが、それを言葉にしたら "高機能" となってしまいました。
その後、ご利用者の方からさまざまなご要望を頂き、それを実現すべく作ったのが "高機能アクセス解析 CGI Professional版" です。Standard版より断然高機能なのですが、すでに "高機能" という言葉を CGI 名称に使ってしまっていたため、後ろに "Professional版" を付け加えることに。。。本当に安易に決めたネーミングですね。。。
清き一票！
"清き一票！" は、当サイトで配布する投票 CGI の名称なのですが、この名前もリリース直前に決まりました。投票 CGI を作るなら、いたずら、不正投票を出来る限り抑えられる CGI にしようと思い、製作に取り掛かりました。このコンセプトをストレートに表現できる良い名称が思いつかなかったのですが、その時、たまたまテレビのニュースで選挙（何の選挙かは忘れてしまいました。。。）が取り上げられていました。そこから聞こえてきたのが "あなたの清き一票を！" でした。そのまま頂きました。
携帯Webメーラー Kmail CGI
"Kmail" の"K" はただ単に"ケータイ" をローマ字にしたときの頭文字です。本当にそれだけの意味でしかありません。
RevoCounter
ぐるりと数字が回転するのが売りなので、回転を意味する "revolve" の頭 4 文字を取り、"RevoCounter" としました。
さて、私のネーミングはいかがでしたか？みなさんはどのようにして商品名を考えているのでしょうね。よくネーミングを募集しているのをテレビ等で見たりしますが、以前は、何で自社の商品名を、プレゼントまでつけて他人から募集するんだろうと不思議に思っていました。でも今はその気持ち、分からないでもないです。
関連リンク
まず最初に、アクセスカウンターの役割と種類についてご説明します。当然のことながら、アクセスカウンターはアクセス数を表す指標を閲覧者に公開するという役割を担っております。ここで「指標」というあいまいな言葉をあえて使っているには理由があります。それは閲覧数なのか訪問者数・訪問数を表すかはアクセスカウンターの種類や設定によって異なるからです。また、アクセス数とはいっても、いつからのアクセス数を表しているかはサイトによってまちまちで、統一されたルールがあるわけではありません。
閲覧数をカウントするものは、ただ単にアクセスがあるたびに数字がアップしていくもので、ブラウザーをリロード（再読込）しても数は上がっていきます。この種類のカウンターの値は、ページビューを表しているといえます。それに対して、訪問者数・訪問数をカウントするものは、Cookie や IP アドレスを使って、同一の閲覧者が複数回アクセスしても１しかアップしないものです。しかし、重複アクセスをカウントしないとはいっても、永遠にアップしないわけではありません。１日経過後、再度アクセスすればカウントアップするものもあれば、時間を設定して、その時間を経過した後にアクセスすれば、再度カウントアップするものもあります。
以上の通り、アクセスカウンターのカウントアップポリシーはまちまちなのが実情なんです。従って、サイトトップページに掲載されているアクセスカウンターの値を比較するなんてことは全く無意味であることはご理解いただけるかと思います。では、ビジネスサイトにアクセスカウンターが必要かどうかという点についてはどうなんでしょうか。結論を言ってしまえば、
”アクセスカウンターは必須ではない”
というのが私の見解です。"不要" とは思いませんし、"必須" とも思いません。"不要" か "必須" のどちらかの答えを期待されていたかもしれませんが、それを言い切る必要はないのです。ようするに、私が思うアクセスカウンターの役割はただ単なる "お飾り" なんです。
意外に、自己満足のためにアクセスカウンターを設置している方が多いのではないでしょうか。しかし、あなたのサイトに訪れる方（お客様）の目的は、アクセスカウンターの数字を確認することではありません。サイトに掲載されている情報もしくはサービスを求めているのです。従って、訪問者の立場から言えば、アクセスカウンターは「お飾り」程度の意味でしかないでしょう。あえていうなら、アクセスカウンターの役割は、訪問者に「歓迎」の意を表す程度でしょう。歓迎を表すのであれば、"さりげなく" 見せるべきです。目立ちすぎてはいけません。サイトの主役は、あなたが提供する情報･サービスなのですから。でも数字だけが表示されている静的なカウンターでは寂しいですよね。「歓迎」を表すのであれば、ちょっとした会釈程度の動きがあってもいいのではないでしょうか。そこで私が作ったのが RevoCounter と FlashCounter だったんです。みなさんも、もしよろしければお試し下さい。
私が作成したCGI以外にも、世の中には非常に多くのカウンターが公開されております。あなたのサイトのイメージあった "さりげない" カウンターを探してみるのもいいかもしれませんね。しかし、この "お飾り" も場合によっては弊害にもなります。それはカウント数が少ない場合です。"お飾り" といえども、あまりにカウント数が小さいと、閑古鳥が鳴いているように感じてしまいます。ホームページとは、リアルな世界でいえば店舗の外観なんです。誰も入っていないお店には入りにくいですよね。カウント数があまりに少ないと、誰も入っていないお店のように感じられてしまうのではないでしょうか。そのようなお店では、なかなかお金を払ってまでサービスを受けようとは思わないでしょう。あくまでも心理的な影響ですが、悪いイメージをもたれるくらいであれば、無いほうがましです。どれくらいのカウント数なら問題ないかという基準はありませんが、例えば１桁や２桁では少なすぎるでしょう。もしまだサイトを立ち上げたばかりでアクセス数の合計が少ない場合には、カウンターの設置をもう少し待ったほうがいいかもしれませんね。ある程度の数字になってからカウンターを設置しても遅くはありませんし、アクセスが増えたからといって、カウンターを設置しなければいけないものでもありません。もしアクセスカウンターを設定したいのであれば、アクセスが増えるまでは、アクセス解析 CGI 等を使ってアクセス数をカウントしておけば良いでしょう。
以上、私が思うアクセスカウンターを述べさせて頂きました。みなさまが効果的にアクセスカウンターを活用されることを祈っております。
関連リンク