Web屋のネタ帳

（前回からの続き） しかし、気象庁が天気予報をXMLで配信するようになる可能性は、実は低い。

2002年6月、気象庁は、気象庁のWebサイトで天気予報の掲載を始めた。 XML形式ではなく、ごく一般的なHTML形式のホームページだ。 このとき、気象情報会社の各社から「官による民業圧迫にあたる」 といったクレームがあがり、ちょっとした騒動になったのだ。 結局は気象庁のWebサイトから気象情報各社へのWebサイトへのリンクも張るということで決着した。

• 気象庁の天気予報ネット提供は「民業圧迫」　事業者が懸念(mainichi interactive 2002/6)
• 気象庁のトップページ
  （ページ中ほどに未だにポツンと残る「民間の気象情報サービス」というリンクがこの騒動の顛末を物語っている）

たかがホームページ(HTML)形式の配信という程度でこのような抵抗運動が起きたのだ。 気象庁以外の個人、企業、団体問わず誰もがアクセスできる形で、 しかもほぼ無限ともいえる利用方法があるXML形式での配信となると、 民間の気象情報会社の抵抗も2002年の騒ぎの比ではないだろう。

しかし民間の気象情報会社ならまだ話がわかりそうだからいい。 もっと問題なのは、天下り官僚による組織の存在だ。

Yahoo!天気にある天気予報は次のような流れで作られている。 （以下はあくまで筆者の予想ではあるが、たぶんあたっているだろう）

1. 各地の気象台の予報官が天気を予測して気象庁に報告する
2. 財団法人 気象業務支援センターが 天気予報データをオンライン配信する
3. 大手の民間気象情報会社や、財団法人 日本気象協会が配信されたデータを受信する。 （全国データだと月間100万円くらい気象業務支援センターに払う。詳しくはこちら）
4. 日本気象協会がYahoo向けにデータを整形して配信しなおす。 （もちろんYahoo!と日本気象協会とはこの情報提供にまつわるなんらかの金銭契約があるかもしれないし、無いかもしれない）
5. Yahoo!天気（の国内の天気）のできあがり

Yahooだけでなくほとんどのポータルサイトがこうした流れで天気予報のページを自動的に生成しているはずだ。 Yahoo天気のページ生成システムの詳細は不明なので、4はもしかしたら間違いかもしれないが、 いずれにせよ気象業務支援センターと日本気象協会なる財団法人が間にはさまっていることに間違いはない。 ここで、もしも気象庁が天気予報のXML配信を自前ではじめたらどうなるか？ 上記の流れのうち、2,3,は必要なくなる。4のところでYahooはもちろん企業サイト個人サイト問わずあらゆるサイトは気象庁から直接、天気予報のデータを取得するようになるだろう。 これで気象業務支援センターも日本気象協会も商売あがったりだ。 この流通構造が崩れるようなことになればそこに摩擦が起きるのも当然だ。 民間の小さなところではこんな気象情報ビジネスもあるが、気象庁が天気予報のXMLデータ提供をはじめたらこれこそひとたまりもなくつぶれてしまうだろう。

なお、お察しのとおり、財団法人 気象業務支援センターも財団法人 日本気象協会も 気象庁の官僚の天下り先である。

前回書いたように、天気予報のXML配信が実現すると、気象庁発表の正式な天気予報をもとにしたソフトウェアをYahooのような大きな企業だけでなく、誰でも自由に作ることができるようになる。 気象ビジネスの裾野が気象予報士の制度の導入のときなんかよりよほど大きく拡大するだろう。

もちろん、民間の気象情報会社も件の財団法人も、は相当な大打撃を受けることになる。 しかし、だからといって気象庁による天気予報のXML形式での無償配信は すべきではないのだろうか？ いいや。もちろんやるべきだ。 気象庁発表の天気予報はどう見ても立派な公共財であり、 日常生活はもちろんあらゆる経済活動に非常に大きな影響を及ぼす情報である。 天気予報はできる限り多くの形式で広くかつ無償で公表されるべきものだ。そのために税金でやってるんだから。 気象庁による天気予報のXML形式配信は「官による民業圧迫」などではなく単なる「技術の進歩」であり、それによって起こる淘汰は市場経済の必然ととらえるべきことだ。

天気予報はすでにある程度定型化されているのでそのXML形式の仕様を策定するのにそう手間も費用もかからない。 予報官が予想した天気予報をXMLに変換するソフトウェアも難しいものではないだろう。 天気図や気象衛星画像はどうするんだと言うかもしれないが、 画像ファイルをWebサーバに置いてそのURLをXML上に書けば事足りる。 XMLデータを配信する方法も、通常のWebサイトと同様の設備があれば十分。 心配があるとすれば、XMLデータを求めるアクセスが殺到してWebサーバがパンクしがちになりそうなことだが、データ自体は小さなものだから技術的な工夫次第でどうにでもなる。 HTTPを使ったWebサーバーからの配信に限らず、SOAPを使ったWebサービスを使うことも十分可能だろう。

つまり、法律的にも技術的にも経済的にも、気象庁それ自体の存在意義からしても、 気象庁自らの手で天気予報のXML配信が無償でできない理由は、無い。

郵政省とその関連機関である通信総合研究所が日本標準時を短波ラジオで放送するアンテナを福岡と福島にひとつずつ建設することで、 電波時計という新しい市場が生まれた。 無料で誰もが自由に利用できるインフラをお役所がつくり、そこに新しい製品市場が生まれるという、まさに理想的な流れだ。

しかし気象庁とその天下り先である財団法人気象業務支援センターに、 いま、そうした行動をはたして期待できるだろうか。

See Also:
天気予報をXMLで提供すると気象庁が発表してから半年が経った(2005/7)
天気予報のXMLはFTPでGETできる。ただし月額10万円超(2005/8)

天気予報のXML化の話をする前に、まず、XMLとはつまりなんなのかという話をしたい。 論より証拠。XMLの実物をごらんいただきたい。

商品情報をXMLで書くと？

アマゾンWebサービスの特徴のひとつは、在庫状況を含むあらゆる商品情報を XML形式で一般公開していることだ。

直木賞作家の綿矢りさの「蹴りたい背中」のアマゾン上のXML形式の商品情報

Webサイトの新着情報をXMLで書くと？

ご存知のとおり、この「ネタ帳」を含むほとんどのブログサイトは記事のタイトルやURLなどをXML形式でも公開することができる。 これはXMLの一種であるRDFという形式だ(RSSとも言う)。

• このサイトの新着情報のXML配信

もしそのWebサイトが例えば新聞社のサイトであれば、その新着情報はそのまま速報ニュース情報だ。 そう。朝日新聞や日経ＢＰははつい最近それをはじめた。

朝日新聞の速報ニュースのXML(RDF)配信 （説明はこっち）

日経BPの各種のサイトのXML(RDF/RSS)配信 説明はこっち

上の例を見てもらえればわかるとおり、XMLは人間の目でも読むことができる。 しかし人間向けにつくられた情報記述方法ではもちろんない。 人間の目でもなんとか読めて（＝人間の手で編集が可能で）かつ、 コンピュータに情報を理解させやすくするための情報記述方法だ。

ではXMLという情報記述方法によってコンピュータが情報を理解しやすくなると、 どんな具体的な利便性が生まれるのだろう？ 上で紹介したXMLで言えば、たとえばこんな感じだ。

アマゾンの支店を勝手に開く

hon-cafeは アマゾンWebサービスの利用例として典型的なものだ。 直木賞作家の綿矢りさの「蹴りたい背中」のアマゾン上のXML形式の商品情報 を自動的に変換してかつ自社のコメントも付加し、 こんなページを自動的に作っている。 もちろんアマゾンアフィリエイトに対応しており、 hon-cafe経由で本が売れるとhon-cafeに幾ばくかの報酬がアマゾンから支払われるという仕組み。

新しい形のニュース配信

RDF/RSS情報を自動的に取得してまるでメールソフトにニュースメールが届いているかのように表示してくれるソフトもある。 下はsharpreaderというニュースリーダーで朝日新聞の速報ニュースのXML(RDF)配信を表示させている様子。

まるでメールソフトでメルマガ形式のニュースでも読んでいるかのようなインターフェース。 これらのソフトはプログラミングの技術が無い個人でも利用可能だ。 蛇足だが、昔はニュースリーダーといったらネットニュースを見るためのものだった。 XML（RDF/RSS）の出現によって意味合いが変わってきたようだ。これも時代の流れか。

早い話が、ある程度形の決まったテキスト情報の羅列であるならばそれがなんの情報であってもXML化は可能だ。そしてその使い方も定まっていない。アイデア次第。好きなように使っていいのだ。（著作権がらみの話はおいといて）

ある程度形の決まったテキスト情報の羅列で、誰もが見るような、つまり需要がある情報とはなんだろうか？ ビジネス用途ならいろいろだが、一般の人にもっとわかりやすいほうがいい。 ニュース速報がXMLだったら？テレビ番組表がXMLだったら？

筆者が思うに、いま最もXML化されるべき情報のひとつは天気予報だ。

例えばこんな感じで天気予報が気象庁のWebサーバー上にあって誰でもアクセスできたら？

ちょっとしたプログラミング技術があれば、誰もが例えばYahoo!天気のようなサイトをつくることができるだろう。 自分のホームページに自分が住んでいる地域の天気予報を表示するCGIスクリプトをつくるなんてのも十分に可能となるのだ。

特に日本のように気候の変化が激しい国では、 天気予報という情報はあらゆる経済活動に大きくかかわってくる。 いつでもどこでもどんな形でも天気予報という情報にアクセスできるということは非常に重要な情報インフラだ。

しかし、気象庁が天気予報をXMLで配信するようになる可能性は、実は低い。 （次回に続く）

たとえばの話、

いかりや長介さん通夜、別れ惜しむファン２５００人記帳

みたいにしてココにリンクを張ったとしよう。上の見出しを考えたのは朝日新聞の人間だ。 ではここにその見出しを書いてしまうのは、許されざる著作権の侵害か？許される範囲の引用か？ ってなことになる。

で、とりあえず裁判所が出した結論は

見出しに著作権認めず＝ネット引用めぐり読売敗訴−東京地裁

ということのようです。 件のデジタルアライアンスという企業がどういうビジネスをしていたのかは知りませんので なんともですが、それはさておき、例に挙げたようなリンクの張り方は著作権違反なんてことになったら WEBの世界は大混乱に陥っていた可能性があったわけで。 この手の問題はほんと微妙ですね。

よくわからんタイトルになってしまった・・・。 今朝（3/23)の日経に面白い記事が載っていた。 インターネット上の市場（特にオークションなど）における統計と心理学の話。

• 評判には追い出し効果（ネガティブ）と呼び込み効果（ポジティブ）がある。 単純に言えばだが、ヤフオクの「良い」評価には呼び込み効果があり、 「悪い」の評価には追い出し効果がある
• 「追い出し」効果ばかり気になりがちだが、市場全体としての活性化には ポジティブ評判のほうがむしろずっと重要である

おおまかにいうとそういうような話。 こうまとめてしまうとなんだかあたりまえすぎる話に思えてしまうが、 とにかく心理学的なアプローチがなされているのが面白かった。 マグリブ商人とジェノバの商人、レモン市場、などなどちょっと変わったキーワードも出てる。 １１へぇ。

おおもとの統計結果はjapan.internet.comに掲載されたもの。 ↓
http://japan.internet.com/research/20040317/1.html

で、SEOルートディレクトリ by ジェフ・ルート の以下のコメントに激しく同意したい。

うーん、「楽しんで見ることもある」と答えた人を「楽しんでいる人」に数えるのはどうなんでしょう？
企業ホームページなどのフラッシュなど、「楽しんで見る」傾向 (SEOルートディレクトリ by ジェフ・ルート 2004/3）より

この手のアンケート調査は調査対象者の質と質問のしかたと統計の取り方しだいで どうにでもなっちゃうのが怖いところです。 筆者としては過去にも書いたように、FLASHはむやみに使うべきではないと今もそう考えています。

過去記事： スタージュエリー：使い勝手の悪いサイトの例

大きな企業、大きな資本が、「俺も一口乗らせろ」といわんばかりによってたかって金をかけ人を投入し、 なにもそこまで焦るこたぁ無いというのに妙に焦って突貫工事でWebサイトをつくりあげたものの、 できあがったサイトを見て喜んでいるのはマウスの使い方もおぼつかないお偉方だけで、 実際のユーザーからみると「このサイト、なんだかなぁ」という出来。 閑古鳥サイトの一丁あがり。

2000年前後のITバブル期は、ほんとうにそんなWebサイトが大量生産された時期だった。 原因はこんな感じ。

• とにかく作れ！の号令の元に作戦も考えずに人と金だけ投入して期限を切った
• 作戦もノウハウもないのでWebサイト上で何をどう表現したらよいかすらわからない
• そうこうしている間に最初に切られた期限に追われ、「Webサイトを作ってユーザーに見てもらって儲けること」が目的のはずなのに「Webサイトを作る」という手段が目的化してしまった

そのころ生まれたサイトのうち、着実に自身のサイトを継続的に進化させてゆくことができたのはYahooと楽天をはじめとするごくごく少数の企業だけ。 ほかの企業は初期段階で間違った方向に焦りすぎた、 いや、ノウハウはともかく方向性も考えずにWebサイトを作ったせいで 金も人も疲弊し企業体力を失い、サイトを継続的に進化させることができないまま、現在を迎えている。 いまもその残骸はそこかしこに見られる。 有名な企業がやっているサイトなのに「妙に凝ってる感じがするけど、なんだかなあ」とか 「はやってなさそうだけどなあ」と感じたら、 サイトの開設時期を調べてみてほしい。 2000年〜2001年前半に始まったサイトが多いことに気がつくだろう。

正直なところ、bk1.co.jpもそうしたネットバブルの残骸の一片だと、筆者は考えていた。 （bk1のみなさん気を悪くされるでしょうがごめんなさい。でもそれが個人的な正直な感想です）

しかし、bk1にも若いセンスをはぐくむ土壌が、かろうじてあったようだ。

bk1、トラックバック対応サイト「bk1.jp」をオープン
(InternetWatch 2004.3)

bk1.jpを作った張本人が自身のblogで語っている。

当時はバイトだったこともあって、 社内のバックアップはあまり得られませんでしたが、 やってることに自信というか、まちがったことはしていないという 自負みたいなものがあったのでどんどん進めました。 今思えばよくストップされなかったと思います。
(bk1.jpってなんなんだ? より)

bk1.co.jpでは、どうやら、現状に疑問をもった一人の元バイト君が中心となって 独自のアイデアとノウハウと技術でサイトを進化させることができたらしい。

お金をかければ。人をたくさん呼べば。有名な会社に頼めば。高価なソフトウェアを使えば。 そんな他力本願ではじめたサイトのほとんどが閑古鳥サイト化する一方、 楽天、アマゾン、Yahoo、うまくいっている企業のほとんどは 自社サイトを自社の社員のノウハウとアイデアでサイトを進化させてきた。 ノウハウやアイデアを持っているのは、 ユーザーの立場に最も近い考え方を持つことができる社内の若い人材だ。 必要な技術は誰でも学べる。オープンソースソフトがそれを後押ししてくれる。 そういったことをトップ層の人間がわかっているかどうかが、 閑古鳥サイトと生き残るサイトの違いだろう。

Javaってどうよ？(F's Garage 2004/3) より。

プロトタイプを作って、ユーザーニーズを汲み取ってすかさす変更をかけていくような開発スタイルを取った時に、Servletを入れ替えるのって大変じゃないですか？Tomcatだからかなぁ。プログラム一つ入れ替えるのに再起動するの辛いんですけど
(途中省略）
JSPってすごく嫌いだったんですけど、動的に入れ替え可能という意味では便利ですね。でも、だったらASPやPHPの方がもっと楽だよなぁと思ったりします。単純に、動作環境の入れ替えや頻繁な更新（スピーディーな更新）を考えたら、スクリプト言語を使うほうが便利かなぁとか思ったり。

激しく同意。

自分はJava大嫌いというわけではない。どんな道具であれハサミは使いようだと思う。 でもそれにしたって最近だれもかれもＪａｖａジャバ言い過ぎだ。 ちゃんと考えて言語を選んでますか？と。

• PHPは再起動の必要がない。逆にほとんどのJavaのAPサーバは再起動の必要がある。 24時間稼動が当たりまえの昨今のWebシステムにおいて、 APサーバ再起動してセッション情報とかが消えちゃってもいいタイミングなんてほとんど無いのに。
• PHPはセッション情報をファイルで逐一保存しているため再起動してもセッション情報は回復する。
• JAVAは再起動するとセッション情報が消えてしまう。 ＝ログインしなおしとか、買い物カゴの中が消えちゃうとか。 もちろんセッション保存にＤＢを使うなら事情は違うがそれは少数ケースだろう。

上に書いた、JAVAだとAP再起動でセッション情報が消えてしまう不便利というのは、 APサーバのセッティング次第かもしれないので誤解を招くかもしれない。（識者のツッコミを待ちたい。） しかし、おおかたそういう理解とそういう前提で開発／運用しているところがほとんどなのではないだろうか。

関連：
Javaジャバ言ってる間にも
いまおすすめの言語はPHP −Javaジャバ言ってる間にも（３）

ここ2,3日の間、またウイルスメールが蔓延しているようだ。 企業の情報システム担当者はネットワークの調整やらメールサーバの監視やら問い合わせ対応やらで こまごまと作業していることだろう。ご苦労様です。

最近ではホスティングサービス業者やプロバイダのメールサーバー上でウィルスチェックをやってくれる ことが多いが、その方法では新種のウィルスにはすぐには対応できない。 最近の「社内でウィルスメールが蔓延して大変だ」という事態は たいていの場合この間隙をぬってウィルスに侵入されたケースだろう。

ところで、「効果的なウィルス対策といえば？」と聞かれたらちょっと詳しい人なら十中八九こう答えるだろう 「まあとりあえずアウトルックやアウトルックエクスプレスを使うのをやめることが一番手っ取り早いよね」。 実際この記事を書いている間にもアウトルック系のメールソフトに脆弱性が見つかった。

Outlook 2002に「重要」のセキュリティ・ホール，任意のプログラムを実行させられる :IT Pro ニュース 2004/3

しかしメールソフトを使わないわけにはいかないのでかわりのソフトが必要だ。 AL-Mail? Becky? ユードラ?いっそのことサイボウズについてるWebメール機能を使うようにしようか？ でもWebメールは使い勝手に限界があるし・・・？

そこで筆者は「鶴亀メール」 を提案したい。 あの有名な秀丸（ひでまる）エディタを開発した人が作ったメールソフト。 見た目も使い勝手も秀丸によく似ているため、非常に使いやすい。 ここで注目したい隠れた機能はウイルス対策機能だ。

上の画像は鶴亀メールの設定画面の一部。 受け取ったメールの添付ファイルがこれらの拡張子である場合に 添付ファイルを削除してくれる。

拡張子	説明
*.pif	Windows上でDOSアプリを実行する特殊ファイル
*.scr	Windows上のスクリーンセーバー
*.lnk	Windows上のショートカット
*.vbs	Windows上で動作するVisualBasicスクリプトによるプログラム
*.com	Windows上で動作するプログラム(*.exeと同等)

ウイルスはこれらの拡張子のファイルに化けているケースが多い。 過去数年、そして今後数年も、この傾向は変わらないだろう。 そこで、鶴亀メールではインストール直後のデフォルトの状態で、 これらの種類の添付ファイルを自動削除するようになっている。 （もちろん種類を増やすこともできるしこの機能を使わないようにすることも可能）

一般ユーザーを困らせるウイルスの感染経路の過半数はメールだ。 正確に言うとメールの添付ファイル。 わかりやすいことに、ある種の特定の拡張子を持つ添付ファイルがもっとも怪しい。 しかもそれらは普段使わないものばかり。だったら自動的に消してしまえばいい。 鶴亀メールは単純だがよいところに目をつけた。 「おいおい、いきなり削除ってそれは乱暴なんじゃない？」と言う方もよく考えていただきたい。 「あなたは、ウイルス以外のケースでこれらの種類のファイルを メールの添付で受け取ることがありますか？」 よほど特殊な仕事をする人を除き、99%の人が「そういえば無いな」と 答えるだろう。システム屋である筆者にすら無い。

さて、この記事のタイトルは「ウイルス対策に秀丸エディタを買う？」だが、 ここまで秀丸の話ではなく鶴亀メールの話ばかりなことに疑問を持った方もいるだろう。

鶴亀メールで特筆すべきなのはその機能ばかりではない。 意外と安くつくのだ。 ライセンス体系と、料金の例を以下に示す。

秀丸エディタのライセンス＝鶴亀メールのライセンス

秀丸エディタのライセンスを買うと、鶴亀メールも使ってよいことになっている。 しかも秀丸エディタにはボリュームライセンスがある。 したがって、鶴亀メールを使いたければ秀丸エディタのライセンスを買うのがオトクである。

台数ではなく使うひとの人数で数える

たとえばMS-Officeなどは「インストールしたパソコンの台数」ぶんのライセンス料金を払うが、 秀丸エディタは「使う人の人数」ぶんのライセンスでよい。 したがって、例えば社員30人+アルバイト10人の計40人がソフトを使うが、 そのソフトをインストールして使うパソコンは50台以上ある、というような場合であっても、 買わなければいけないライセンス数は40本ぶんだけである。

100人でも8万円

しかも、2,3年ごとに更新といったようなことはまったくない。 ちなみに筆者は7年も前に秀丸エディタ一本のライセンスを買ったがそれ以降は一円も払わずに 秀丸と鶴亀メールそれぞれの最新版を使い続けている。 詳しいボリュームライセンス体系についてはこちら↓を参照してほしい
秀まるおのホームページ−ご購入方法−商品の価格一覧

くれぐれも誤解しないでいただきたいのだが、 鶴亀メールを使うからといってウイルス対策ソフトがいらないということではまったくない。 しかし悩みや不安や余計な作業を減らすことはできる。

パソコン上ではなくメールサーバー上で稼動するタイプのメール監視ソフトで、 特定の拡張子の添付ファイルを削除するという動作をやってくれるものもある。 しかし、自前でメールサーバーを持っているのならともかく共用のホスティングサービスなどを 使っている場合には、導入できないかあるいは費用がかかりすぎてしまうだろう。

ウイルス対策ソフトを使っていても定義ファイルの更新をしてない社員が多くて意味無し状態になっているとか、 ウイルス騒ぎのたびにネットワークの調整やらメールサーバの監視やら問い合わせ対応やらで一日仕事にならないだとか、 パソコンの管理にからむ社員教育が手間だとか、 とにかく企業の情報システム担当者の悩みは尽きない。 鶴亀メールの導入は、社員にメールソフトの乗り換えというやや面倒な作業をさせることにはなるが、 100人分でも8万円（すでに秀丸エディタを導入済みの場合はタダ）というコストで メール感染型ウイルスの悩みが半減、いや、もしかしたら3分の1になるくらいの可能性があるのなら、検討してみる価値はあるはずだ。

ウイルス対策に秀丸？と聞いただけでは全くの論理の飛躍に感じてしまうかもしれない。 しかし、「そもそもアウトルック使うのもやめたいんだよな」とか 「よからぬ添付ファイルが悪いんだよな」といったことを突きつめてゆくと、 こういう結論もアリなのではないだろうか。 単純で有効で低コストな解決策は、視点を変えれば必ず見つかる。

メール配信ASPのメールマーケティングコンサルティング＆アウトソーシングのカレン、自社のサイトをMovableTypeでリニューアル

• カレン自身のプレスリリース(PDF)
• enatural.orgによるちょっとした解説

MovableTypeをはじめとする各種のblogツールは、 「あなたの日記サイト簡単につくります」的なサービスで使うよりも、 企業サイトの構築ツールとして使うほうが実はビジネスとして見込みがあるだろう という話は以前の記事でも書いたとおりだ。 （参照：blog(ブログ)でビジネスになるか？(2)） 今後この動きはますます加速するだろう。

この次にくる動きはもちろん 「あなたの会社のサイトをblogツールで簡単に更新えきるようにしてあげますよ」的なサービスだ。 ココログをやっている@niftyがその果実に一番近いといえる。 なにしろblogツールのデファクトスタンダードであるMovableTypeを開発しているSixApａｒｔ社と提携しているのだから。

SixApartと@niftyとの間の契約が独占的なものなのかどうかは定かではないが、 Webの世界での「一番乗りが全部獲る」「一番最初にデファクトをおさえた者が勝つ」 の公式はまだ生きている。@niftyの今後の展開は楽しみだ。

昨日の記事で、「 ほしいのはもっと単純な悩みの解決策だ」と書いた。blogツールによる企業サイト構築サービスも、 まさにそういうニーズのためにある。 楽天が出展者に一番喜ばれた機能は、メルマガ機能でも懸賞機能でもオークション機能でもない。 「とにかく店舗のページを簡単に更新できる機能」が一番支持された。 もっとも喜ばれるニーズは、もっと単純なことなのだ。それは今も昔もかわらない。

サイボウズ社の製品といえば「サイボウズ Office」が有名だ。 スケジュール管理、会議室予約、簡単な掲示板などのグループウェアが 一通りすべてブラウザだけで利用可能というやつ。

しかしいま筆者が注目しているのは同社の「サイボウズ メールワイズ」。 試用版をダウンロードしてざっと見たところ、これ、かなりよくできている。 効果を簡単に書くと以下のとおり。

メールワイズ導入前

メールワイズ導入後

お客様から担当者個人にメールが届いてしまう場合 その人が休暇を取ったら対応が遅れる。退職してたらそれっきり。 仕方がないから「Cc:でこの人にも送って」とお客様に頼むが 所詮人間のやることなのでCCし忘れることもある。 「Cc:って何？」状態のお客様すらいる。 そうこうしている間にどのお客様に誰が いつどんなメールを送ったかわからなくなる ＝「対応が悪い！同じことを何度も言わせるな！」とクレームに・・ お客様から代表アドレス(info@,support@とか)にメールが届いてしまう場合 そもそも代表アドレスのメールチェックを忘れることがある（末期的） 代表アドレスをチェックする担当者は一人だけだ ＝個人が受け取る場合と同等のトラブルが起こる 受け取るのは代表アドレスだが、 返信するときは担当者個人のメールアドレスになってしまう＝ それ以降もやはり個人の場合と同様なトラブルにつながる 代表アドレスにどんなメールがとどいて、それに対して だれがどんな返信をしたんだ？という基本的な情報が上司にはわからなくなる

お客様から代表アドレスにメールが届く サイボウズメールワイズにメールを読み込んでメールを一箇所に蓄積 複数人の担当者がいつでもメールをチェックできる 返信しなければ「誰か対応しようよ」みたいなマークがつく（対応漏れ防止） メールワイズ上でメールに返信したらその内容もメールワイズ上に記録される ＝誰がいつどんな対応したか履歴を見ることができる 送ったメールの送信元は担当者個人ではなく代表アドレスにすることができる ＝顧客は何も考えなくともまた代表アドレスに返信してくれる

上記はものすごい簡単な説明だが、そういうことだ。 （もちろんもっと細かい機能はあるが書ききれないので省略）

顧客との電子メールのやり取りが担当者と顧客の個人間にとどまってしまって 会社全体としての対応と情報共有になっていない。

どんな企業もこうした悩みをかかえているのではないだろうか。 担当者に営業報告を書かせるという手もあるが、 ある程度定型化された業務であればやりとりされているメールを直接見れたほうが話が早い。 臨場感や現実感もあり、報告と実際との言葉のニュアンス的なズレも無くなり、 そしてなにより報告書を書く手間とそれを管理するコストが省ける。

コールセンターがどうとか、コンタクトセンターがどうとか、CRMがどうとか、顧客情報の活用がどうとか、 大きな視点で難しく考えるのが悪いとは言わない。 しかし、よくよく考えてみれば、実際に使う立場の人間に喜んでもらえるのは、 もっと単純な悩みを解決するソフトではないだろうか？ サイボウズ社はそういううまい視点で製品を出している。 その戦略はたぶん正しいだろうことは業績が示している。

サイボウズが過去最高の売り上げを達成(日経Biztech 2004/3)
昨年7月に出荷を開始した、中小規模向けグループウエアの「Office 6」。既存製品ユーザーの47％がバージョンアップし、売り上げに貢献した。

以前、「アダルトの分野におっかなびっくり手を出す大手企業」といった内容の記事を 書きましたが、最近、こんな記事がありました。

BIGLOBEがギャルゲーを開発する理由(ITmedia 2004/3)

なるほど、そっちの方向ですか・・・っていう感じ。

関連記事： オ・ト・ナの楽天って知ってました？

八千代銀行の住宅ローンの申し込み者のうち同社のメールマガジンを購読している人に0.5%の金利低減の特典をつけるらしい。

八千代銀行、BIGLOBEのメルマガで購読者に住宅ローン金利優遇を
(Japan.internet.com 2004/2)
NECからのプレスリリースがここ

実際やってみなければわからないかもしれないが、 住宅ローンの金利の0.5%優遇というエサを持っていかれるだけの結果を招くのではないだろうか。 メールマガジンをいくつも購読しているが「届いても未読のまま放置」or「数秒で流し読み」しているものが少なくない、というのは筆者だけではないだろう。 メールマガジンの精読率は下がる一方なのだ。 限定的とはいえ住宅ローンの0.5%というのは金額的にはかなり大きい。 はたしてそれだけの投資対効果が得られるかどうか疑問だ。

メールなりWebなりをなんとかして顧客とのコミュニケーションに活用したい、という企業姿勢は評価したい。 しかし、何かこう、「小泉内閣メールマガジン」以来学習していないように感じてしまう。 いや、学習しているのだが、世の中の変化に追いついていないというべきか。

同じメールを使ったサービスならソニー銀行のほうがまだ気が利いている。

ソニー銀行のページより抜粋：
■ ペットが貯金箱を見張ります。
目的別貯金箱にはそれぞれ、PostPetキャラクターを「見張り番」として設定することができます。この見張り番はあなたの目的別貯金箱が目標額に届くまで、ずっと見張っています。 見張り番は貯金箱の残高が目標額に近づくにつれ、幸せな気持ちになります。忘れられた目標やなかなか達成しない目標には気持ちが沈んでしまうこともあります。ときには励まし、ときには厳しい態度で接するかもしれません。 また、見張り番からはメールが届くことも。ペットのメッセージに一緒にがんばる気持ちがますます強くなります。

これは昔流行ったPostPetの、ペットが勝手にメールを書いて飼い主や友人にメールを送ってしまうという「ひみつ日記（だったっけ？）」にヒントを得ているサービスだ。 メールの内容的には銀行のサービスにまったく無関係かもしれないが、 とにかく定期的にメールを読んでもらって顧客の意識をつなぎとめる、 ソニー銀行という存在を頭の片隅にとどめてもらう、 いう点において、読まれないメルマガを量産するよりもずっと効果的だろう。

参考記事：【波多野blog】 No.47 「Ｅメールの開封促進とは」

少し前の話になるが、銀座のアップルストアに立ち寄った際に、 「アップル魂」とも言うべきものを垣間見たのでそのときの話。

店内をひととおり見終わって店を出ようとエレベータを降りたところで、 appleの社員らしき白人が日本人スタッフになにかまくしたてている。 私のつたない英語力でもなんとか理解できた。翻訳すると、 「ここだ、ここで、店員と顧客が何か話していてほしいんだ！」ということらしい。 立ち位置まで指し示しながら力説していた。 そこはデスクトップのiMacとiPodを並べて展示しているテーブルで、 入り口から真正面に進んでエレベータのドアにさしかかるあたりのところだった。 そこで店員と客が話している様子は確かに奥からよく見え、かといって邪魔にならず、 たしかに「何の店だろう？」と思って前を通り過ぎようとする人の意識をうまくつかめるような シチュエーションとなりそうだった。

店員と顧客の立ち位置にまで演出を試みるとは。アップル魂を見たような気がした一瞬だった。

例えば日本のメーカーがショールームをつくるようなケースは多々あるが、 広告代理店やらグラビアアイドル事務所やらに 金を落とすだけのような中途半端なイベントをするばかりだ。 ここまで入れ込んで直営店を盛り上げようとするメーカーがほかにあるだろうか。

アップルは一時期ほんとうにダメで、つぶれるんじゃないかとうのも冗談ではない時期があったが、 創業者のスティーブジョブスが戻ってきて以来生まれ変わった。 UNIX(FreeBSD)と従来のMac-OSの融合をMacOSX（テン）で実現し、 iBookやiPodを開発し、 音楽のダウンロード販売を本格化させ、稼ぎに稼いでついには負債をゼロにしてしまった。 そしていまだにスティーブジョブスは年収1ドル（！）でCEOをやっている。

日本マクドナルドはわけのわからない価格競争に始まる 戦略の迷走をやらかして先が見えなくなり、藤田社長は退陣。 これに対し、米国マクドナルド本社は、元日本アップルコンピュータ社長の 原田氏を日本マクドナルドの社長に招聘した。 人選としてかなり的確だろう。 いまのマクドナルドに足りないのは戦略とか価格とか味ではなく、 ブランドとかスピリッツ（魂）とかそういう面だ。 アップル魂を持つ人間に来てもらうことは決してはずれではないと思う。

（前回からの続き）さんざん脅かして不安をあおるだけではなんなので、 現実的に、Webシステムにおいてパスワードをどう取り扱うべきなのか、 ということについて述べてゆこう。

前にも書いたがパスワードを暗号化（ハッシュ化）保存する場合の 基本的な流れは次のようになる。

1. ユーザーがWeb上の登録画面からユーザー登録(会員登録)する。 その際にパスワードを入力させるが、 Webシステムはそのパスワードを暗号化（ハッシュ化）してデータベースに記録する。
2. ユーザーがWeb上でユーザーIDとパスワードを入力してログインを試みる
3. Webシステムは入力されたIDをもとにデータベースからパスワードを探し出す
4. 入力されたパスワードを暗号化（ハッシュ化）し、 データベースにあったパスワード＝すでに暗号化（ハッシュ化）済み＝ と照らし合わせ、合致すれば認証ＯＫ。 間違っていれば「IDまたはパスワードが違います」を表示

ユーザーから「パスワードを忘れました、どうしたらよいのでしょう」 という問い合わせがあった場合は次のような流れになる。

1. 管理者が新しいパスワードを考えて データベース上のそのユーザーのパスワードを新しいパスワードで上書きする （上書きしたパスワードももちろん暗号化(ハッシュ化)保存される）。
2. 管理者はユーザーに新しいパスワードを知らせる

より安全性を高めるなら、このあと 「ユーザーは新しいパスワードを使ってログインし、改めて自分にしかわからないパスワードに変更する （まずパスワード変更しなければ他の機能を利用できないようにする）」 という流れを追加する。 これで管理者にもユーザーのパスワードがわからない状態を完全に実現できる。

Webシステムの詳しい仕組みについては技術的な話になりすぎるのでここでは省く。 ただ、上のような仕組みをつくることは技術的に難しいことでは まったくないはずだということは念を押しておきたい。

技術的な話の代わりに、あらゆるECサイトのお手本、アマゾンの場合の話をしよう。

「パスワードがわからなくなりました、どうしたらよいでしょう？」 と困っているユーザーに対する対処は、あらゆる会員制サイトにおいて「よくあるサポート業務」のベスト５に必ず入る。アマゾンはそこもよく考えぬいていて、 パスワードを忘れたユーザーへの対処には非常に簡潔かつ安全性の高い方法が用いられている。 次のような流れだ。

1. ここでパスワードを忘れたユーザーに自分のメールアドレスを入力させる （アマゾンではユーザーIDとしてメールアドレスをそのまま使っている）
2. Webシステムはパスワードの再登録ができるURLをそのメールアドレスに送る。 URLにはアトランダムな文字列がしこまれていて、 いわゆるワンタイムパスワードならぬワンタイムURLとなっている。 このワンタイムURLは発行後一定時間（おそらく24〜48時間程度）経つと無効化される
3. ユーザーはそのURLにアクセスし、新しいパスワードを登録する

アマゾン方式がすばらしいのは、

• アマゾンのサポート担当者がパスワードを知ってしまう過程が無い
• 生のパスワードがWeb画面やメールや紙の上に記録または表示される過程が無い
• ユーザーは自分にしかわからないパスワードを用いて即座に利用を再開できる

ということだ。もちろんパスワードの暗号化（ハッシュ化）保存も なされているのだろう（なされているよなあ？笑）。だとすれば アマゾン内部の人間であっても顧客のパスワードを知ることはできないし、 万が一何かの間違いがあっても暗号化（ハッシュ化）されたパスワードが 知られてしまうだけ（＝知られても安全）という状態をほぼ完全に実現しているのだ。

話は変わるが、この記事を書いている間にも、ヤフーの450万人分の顧客情報漏えい事件があった。 YahooIDまでもれていたことに関する問題については別な機会で記事にしたい。 また、いただいたコメントのいくつかについても興味深く、コメント返しやあるいは 記事にしたいものがあるのだが、このところ書きすぎで疲れ気味？なので またの機会とさせていただきたい。

最後に。 パスワードの暗号化（ハッシュ化）保存の重要性と最近の状況について書き始めたら、 全５回という本人もびっくりな長文になってしまった。
「そうまでして改めて力説するほどのことでもない、当然のことだろう？」 とお考えの方も少なからずいるだろうが、 その当然のことがなされていないWebシステムが急増しているのが現実ではないだろうか。 パスワードの暗号化（ハッシュ化）保存について 「知らないからやっていない」 「できないからやっていない」 「知っていてやっていない」 事情はそれぞれあるのだろうが、 いまのまま放置されるべきでないのは確かだ。

（前回からの続き）いったいいつのまに、どうして、このような状況になってしまったのだろう？

技術者の無知

特に2000年前後のITバブル期の頃、Webというものが急速に普及した結果、 「にわかIT技術者」が急増した。 パスワードの取り扱いに関する従来のあるべき論を学ぶことも無く、 IDとパスワードで認証するタイプの会員制Webシステムの構築をいきなり任されるケースが多発した。

発注者の無理解

Webシステムの発注者、つまりWebサイトの運営者側は、 パスワードの取り扱いなどといった技術的な意味合いが強い （と思われている）話にはついていけない（ついていく気もない）ケースがままある。 パスワードがどのような形でデータベースに保存されているかなんてことには無頓着だ。 そんな状況で、システム構築業者が技術者としてのモラルを働かせ、 「パスワードは暗号化（ハッシュ化）して保存するようにしましょう」 と提案したところでクエスチョンマークな顔で怪訝にされるだけだ。 パスワードを忘れたユーザーに対する対処が生パスワードを見て教えるだけなのとは違い、 新たにパスワードを登録しなおしてそれを教えるという業務の増加があるということ (その2参照)まで話すと、 無理解な発注者は却下するだろう。 「担当者がデータベース上のパスワードを見てそれをそのまま教えればよかろう、 余計な仕組みも無駄な業務もいらない、そのぶん安く早くしろ」と。

必要とされるシステム自体の変質

WebやE-MAILが登場する以前は、システムはもっと小さかった。 ここで小さいというのは利用するユーザー数やネットワークの規模のことだ。 たとえば、中規模の不動産屋が自社で扱う不動産物件の情報を一元管理する データベースシステムにアクセスするのは、自社の社員だけだった。 それは多くてせいぜい数十人か数百人。 しかも社内のコンピュータからしか接続できない閉じたネットワークで、だ。 そこではユーザーIDとパスワードをさほど重要視する必要はなかった。

しいて言えば銀行のATM網は昔からユーザー数は非常に大きい。 しかし、やはり閉じたネットワークで、端末も特殊で、 アクセスするにはキャッシュカードという物理的な媒体も必要。 もともとが現金を扱うという超クリティカルな業務なので警戒も厳重。 これではパスワードの保存方法云々を議論するまでもなく不正は難しい。

万単位の不特定多数が、不特定な端末を使って、不特定なネットワークを経由して、 ひとつのコンピュータシステムにアクセスする。 そんなシステムはインターネット以前にはほとんど存在しなかったのだ。 10年ほど前のような小さく閉じたシステムに慣れた技術者（または発注者）であれば、 これまで述べたようなパスワード管理に関するあるべき論を知らない（重要視しない）、 のも無理は無い。もちろん本当はそれじゃいけないのだが。

低価格、短納期

とどめを刺すかように、やはりITバブル期以降、 システム構築の低価格化と短納期化が急速に進んでしまった。 システムを作る側としては、少しでもコストを抑え時間を稼ぐために パスワードの暗号化（ハッシュ化）保存処理などは 必要とわかっていても提案すらしないケースがあると思われる。 貴重なお客様と金と時間を前にすれば、技術者としてのモラルなど・・・。

SSL催眠術

「当社では個人情報保護のためにSSLを使用しています」 というSSL催眠術。これが一番やっかいだ。
http://ではなくhttps://ではじまるURLは通信内容がSSLという技術で暗号化される。 SSLの名誉のために言っておくと、簡単に破られるような暗号ではないし、 実際SSLを破ってなんらかの事件につながった例はほとんどない。 しかしSSLは通信の経路上で盗聴されることを防ぐためのものだ （暗号化により内容がわからなくなってるから盗聴しても意味が無いという理屈）。 したがって、

• SSLは内部犯行に対抗できない
  通信の経路上ではないところで起きること、 つまり、データベースに直接アクセスしてデータを抜き取るようなケース ＝内部犯行＝においてはSSLは無力である。

  ローソン、顧客情報流出事件の調査結果を発表 (CNET Japan 2003/08)
  −「委託先の開発用コンピュータから抜き取られた可能性が極めて高い」 −
  
  ファミリーマート、ネット会員18万人分の個人情報が流出 (itmedia 2003/11)
  − 従業員または委託先の従業員による内部犯行説が有力 −

  前回（その３）で書いた楽天での例も同じことである。
• SSLは単純ミスに対抗できない
  Webシステムの不具合や設定上の単純ミスで、本来表示されてはならないことが 表示できてしまうケース。これも通信の経路上で起きることが原因ではない。 したがってSSLを使っていたとしても全く意味を成さない。

  3万7000人の個人データ流出 エステサロンのTBC (Mainichi Interactive 2002/5)
  − アクセスにはパスワードなども設定していなかった −
  
  アマゾン書評、自作自演が発覚(cnn.co.jp 2004/2)
  − アマゾン・ドット・コムのカナダ版で 書評欄に書き込んだ人々の個人情報が表示されるシステム障害 −

このように、これまで起きた（＆今後起きるであろう） 個人情報漏洩事件の原因のほとんどはSSLの力が及ばないところにある。 にもかかわらず「SSLを使います」の一言を持ち出すだけで Webシステム発注者（＝Webサイト運営者）もその上司も末端のユーザーにも、 あらゆるセキュリティ問題は無くなると勘違いさせることができる。 IT業界特有の3文字アルファベット式催眠術の一種なのだ。

このSSL催眠術はほんとうに意外と強力だ。 「パスワードの暗号化（ハッシュ化）？なにそれ？SSLなら使ってるよ、それでも何か問題あるの？」 Web業界の技術とビジネスの両方に相当詳しい人間であっても、 そんな認識を平気で言う例を筆者は過去幾度と無く見ている。

さて、さんざん脅かして不安をあおるだけではなんなので、 現実問題としてWebシステムにおいてパスワードをどう取り扱うべきなのか、 ということについて述べてゆこう。 （次回に続く）

※SSLには通信の暗号化のほかに情報の出所確認という機能もあるのだが テーマと無関係なので省略。