Googleニュース日本版の 登場以来、特に地方紙のアクセス数の伸びがすごいそうだ。 もちろん日経や朝日などの全国紙サイトのアクセスもGoogleニュース経由のアクセスが大きくなりつつある。 そのあたりのニュースソースのまとめが以下に。

GoogleMania: 開始まもない「Google ニュース日本版」の恩恵を受けた日経新聞と朝日 (2004/10)

さて、読売や産経などはいつまで「食わねど高楊枝」を決めこむつもりなのだろうか。 See also: 直リンク問題とGoogleニュース日本語版(2004/9)

（前回からの続き。2回目も同じ感じだっただったけど）
いやしかし、動的ページ使いまくりのアマゾンなのに日本のアマゾンだけで見ても140万ほどインデクスされていることはどう説明するんだ？ しかもアマゾンだってアクセスしてよく見るとURLの最後にセッションIDっぽい数字が自動追加されてるのに？？

Googleに140万ページがインデックスされている www.amazon.co.jp と 1700件の www.shopping.hp.com の違いはなんだろうか？ それは両者を何ページがサーフィンしてみるだけですぐにわかる。 amazon.co.jpのURLには記号はほとんど/(スラッシュ)だけで、たまに=(イコール)がある程度。 www.shopping.hp.comのURLは?(クエスチョン)や=や&が盛りだくさん。

そう。Googlebotは?や=や&があるURLを動的ページとみなしてクロールにブレーキをかける。 実は動的ページと静的ページの見分け方についてはGooglebotはそんなに頭が良いわけではない。 GooglebotはURLに?や=や&が多用されているとか、さらにその文字列に「session」といった単語があるとか、 そういったことだけでそれが動的ページであるかどうか判断している。 これはGooglebotだけじゃない。Yahoo!Slurpなどにおいても似たようなものだろう。

?や=や&はCGI(Common Gateway Interface)仕様のひとつであるQUERY STRINGと呼ばれる指定方法だ。 プログラムはこの記号に沿って指定された文字列をもとに、動的ページを生成して出力する。 文字列というのは例えばECサイトであれば商品番号だったりする。

ただし、このCGI仕様はあくまでもひとつの方法に過ぎない。 本来はファイルシステム上のディレクトリ(フォルダ)構造を示すために使われる/(スラッシュ)という記号だが、 ?や=や&といったCGI標準仕様の変わりに使ってはいけないわけではない。 1回目の記事で、YahooJapanのトップページが「index.html」なのにもかかわらず動的ページであり、 拡張子などは参考に過ぎないと書いた。 Googlebotだってその点ではそれほど優秀なわけではない。 「?や=や&を含むURLは動的ページである可能性が高いから注意せよ」というプログラミングに基づいているだけだ。

かくして、URLに?や=や&が盛りだくさんのwww.shopping.hp.comのページは ちっとも検索エンジン内に蓄積されてゆかない。

実はプログラムに引数を渡す手段は?や=や&だけではない。技術的な手段は何通りでもある。 そこでアマゾンでは、一般に使用される?や=や& の代わりに極力 /(スラッシュ) のみを使って動的ページのURLを表現することで URLだけで見ると「ちょっとディレクトリ構造が深くて独特だね」くらいにしか見えないようにしている。 もちろんこのスラッシュはWebサーバ内のディレクトリ構造を示しているわけではまったくないだろう。 ただしこれは筆者の推測なのだが、アマゾンのこうした工夫は検索エンジン対策というよりは以前の記事でも書いた対人間用の心理学的な配慮であり、 検索エンジン対策としても機能しているのは結果オーライなのかもしれないと考えている。

実はアマゾンはもうひと工夫している。例えば
http://www.amazon.co.jp/exec/obidos/ASIN/4093860726/
に普通のブラウザでアクセスしようとすると
http://www.amazon.co.jp/exec/obidos/ASIN/4093860726/xxx-xxxxx-xxxxx
というふうにURLの最後に個別のセッションIDが付加されたURLにリダイレクト (HTTPステータスコード302)されるが、 User-AgentヘッダがGooglebotの場合にはリダイレクト処理はされずにそのままコンテンツを返すようになっている。 また、そのコンテンツの中身自体も、普通のブラウザアクセスに対しては「123-45678-000999」のようなアマゾン独特のセッションIDが コンテンツ内全てのアンカーリンク内のURLに自動追加されるが、 Googlebotが相手の場合にはそれがなされないようになっている。 こうしたシステム的な工夫により、前回説明した、

一見異なっているようで実際は同じページにリンクしているURLをロボットが排除できず...

という現象を避けるようになっている。

いずれにせよ、セッション維持にURL埋め込み方式を取っているWebサイトなど少ない。 動的ページだらけのWebサイトであっても、URLに?や=を使わない方式にするだけで Googlebotはいくらでもクロールしてくれるようになることはアマゾンによって証明されているのだ。

しかし、言うは簡単というのが世の中のつらいところである。 一般に販売される「ECサイト構築ソフト」のようなものや、 システム開発会社が手でまともに設計するシステム、 あるいはシステム開発会社などで使われるWebサイト（というよりWebアプリケーション）を作るための 各種のAPサーバ製品やフレームワークなどは、 ほとんどがCGIの標準仕様のみにもとづいており、URLには当然ながら?や=や&が多用され、 それにあわせ request.getParameter(hogehoge) とか $_GET[hogehoge] といった記述が プログラム内のいたるところで使用されている。 それらを使ったところで 「高い金出して作ったWebサイトなのにGoogleやYahooではトップページくらいしかひっかからない！」 という事態が待っているのだ。

アマゾンのようにできるだけ/(スラッシュ)だけの形式で引数を渡すには 設計自体、ソフト自体、フレームワークそれ自体の大幅な改造が必要であり、現実的ではない。 仮にそのように改造したとしても、 もしも近い将来、検索エンジンのクローラーの方が進化してしまって?や=があるURLに対するクローリングにも 問題がなくなってしまったら、苦労と金は水の泡と消えるだろう。

データの管理画面はCGIやらの動的ページで行って、 実際にお客が見るページは静的なページを自動生成するようにすればいいんですよ、 と甘い言葉をささやく業者もいる。 それは間違ってはいないが「足して５になる数字は２と３ですよ」と言っているに過ぎない。 要は動的ページであってもURLだけは静的ページであるかのように見えるように作れば、 Googlebotはクロールしてくれる。 しかし残念ながら上で述べたようにそこまで考えている製品やプログラミングフレームワークは少ないし、 そこまで考えが至るエンジニア自体もまた少ない。

Apacheのmod_rewriteや、それに類するフィルタリング装置を使うとか、 QUERY_STRINGのかわりにPATH_INFO環境変数を使えばなんとかなるかもしれないが、 それなりのノウハウが必要だしアプリも無改造というわけはまずいかないだろう。 楽天市場の店舗の商品URLや2ch.netのURLのシンプルさには実は理由があるということに改めて気づき横目に見つつ、 ?や=や&を使いまくりの長い長いURLを持て余しているECサイトの運営者のみなさんの苦悩は続く。

See also:
yohei-y:weblog: 良い URI の設計 (2005/8)
URLを変えるな！(1) － 後悔しないためのWebデザイン (2006/10)
URLを変えるな！(2) － 後悔しないためのWebデザイン (2006/10)
URLを変えるな！(3) － 後悔しないためのWebデザイン (2006/10)

（前回からの続き）
アマゾンのほとんど全てのページが動的ページである。 しかしGoogleにはwww.amazon.co.jp配下のページが140万ほどインデクスされている。 おいおい、誰だ動的ページは検索エンジンにクロールされにくいとか言ってるのは？！

真相を調べるには当事者に聞いてみるのがもっとも手っ取り早い。

Google では、ダイナミックページもインデックスに登録できます。 ただし、クローラはダイナミックコンテンツのあるサイトに負担をかけてクラッシュさせる可能性もあるため・・・
(Web マスターのための Google 情報)

ダイナミックページとかダイナミックコンテンツとはもちろん動的ページのことだ。 動的ページはアクセスがあるたびにWebサーバ上のCGIプログラムないしその背後のAPサーバ上のプログラムが実行された結果がコンテンツとしてブラウザに返される。 ただそこにあるファイルの中身をそのまま返すだけの静的ページと違い、アクセスがある都度プログラムが実行されるためＣＰＵパワーと時間をかなり食ってしまう。 もしそのプログラムが背後のデータベースにでも検索に行くタイプのものならなおさらである。

ここからはやや筆者の推測が混ざるのだが、開発された初期のGoogleはまだクローラー（Googlebotのこと）は台数も性能もよくなかったので、標的のサイトに対しかなりの頻度(数秒おきとか)で繰り返しアクセスしていた。しかしそれでは、貧弱な性能のマシンなのに動的ページが多いようなWebサイトが相手だとGooglebotによる繰り返しアクセスでマシンがダウンしてしまうケースがあったのだろう。「負担をかけてクラッシュさせてしまう可能性・・・」とはこのことだ。で、Google帰れ！とWebマスターはカンカンになる。この教訓もあって、現在のGooglebotは1分間に2アクセス以上は絶対しないようになっている。

こんなのもある。

Q. Googlebot が私のサイトをクロールするスピードが速すぎます。どうしたらよいですか？
A. サイト名と問題の詳細を添えて、電子メールで googlebot@google.com までご連絡ください。Web ログで Google のアクセスを示す部分も添えていただければ、こちらでより早く問題を突き止められます。
(Web マスターのための FAQ)

現在もGoogleはこの問題にかなり気を使っていることがうかがえる。

Googleが動的ページを積極的にクロールしない理由はほかにもある。

セッション ID やサイト内のパスを追跡する引数がなくても、サーチ ロボットがサイトをクロールできるようにしてください。これらのテクニックは個々のユーザーの動きを追跡する場合に便利ですが、ロボットがアクセスするパターンとはまったく異なります。これらのテクニックを使用すると、一見異なっているようで実際は同じページにリンクしているURLをロボットが排除できず、そのサイトのインデックスが不完全なものになる可能性があります。
(Web マスターのためのガイドライン)

「セッションIDやサイト内のパスを追跡する引数」とはいったいなんのことだろう？ たとえば ヒューレットパッカード社の直販ショッピングサイトを例に説明しよう。 トップページからどこでもよいので適当に商品リンクをいくつかたどっていくと、URLにおかしな文字が入っていることに気づくだろう。

http://www.shopping.hp.com/...store_access.jsp?BV_SessionID=@@@@0644540149.1098543935@@@@&...

これがセッションIDである。これは何に使うかというのは上にあるとおり、 個々のユーザーの動きを追跡する＝サーバーサイドWebプログラミング専門用語で言うと「セッションを維持する」＝ためにURLに自動的に付加される。

一般的な「買い物カゴ」の機能もこうしたセッションという概念を利用している。セッション維持用の変数をユーザーに保持させるには通常はCookieを使う。しかしCookieを使用できない古いブラウザ＝PC用ブラウザでは今時あり得ないが携帯端末用ブラウザなどではいまだに使えない＝に対応するためだったり、欧米ではCookieの利用はプライバシーの侵害だとする動きが盛んなため（Cookie使用禁止の法律すらできかけたことがあったとか）こうしたセッション維持変数のURL埋め込み方式を使用するケースは珍しくない。

同じ商品のページにアクセスするとしても、人によって（もちろんクローラーも含め） セッションIDが個別に発行される。ページ上のアンカーリンクタグ内のURLには全てこのセッションIDが自動追加される。ということはURLが事実上無限に存在してしまう。検索エンジンはそんなのまでいちいち相手にしていたらキリが無い。ということで、こうしたタイプの動的ページもやはり積極的にインデクスに加えようとしない。「一見異なっているようで実際は同じページにリンクしているURLをロボットが排除できず・・・」というのはこのことだ。 ちなみに上で紹介したwww.shopping.hp.com のページはGoogleではたったの1700件しかインデックスされていない。あれほどの規模のサイトでこれだけのページしかないというのはありえないのに。

で、動的ページ使いまくりのアマゾンなのに日本のアマゾンだけで見ても140万ほどインデクスされていることはどう説明できるのだろう？ しかもアマゾンだってアクセスしてよく見るとURLの最後にセッションIDっぽい数字が自動追加されてるのに？？ という話をようやく書き始めようと思ったら長くなったので次回。

Webシステム＆デザインの世界では「動的ページ、静的ページ」といった言葉がよく使われる。 近年流行っているＳＥＯ＝Search Engine Optimization＝検索エンジン最適化＝において 動的、静的の違いによる影響が大きいことから、 最近ではエンジニアではない人の会話でもこの言葉が使われるようになってきた。

サーバーサイドWebプログラミングの心得があるたいていのプログラマーやＳＥなら 動的ページと静的ページの違いくらい十分理解している。 しかしそれ以外の人＝Webデザイナーや外注頼りのWebマスター＝は、 理解しきれていない人のほうが断然多い。 「Googlebotは動的ページをクロールできない」といったような誤解も見られる。 単なるJavaScriptによる見かけ上の動的ページと静的ページの区別がついていないことさえある。

結果、Webサイト構築のプロジェクトにおいて静的ページと動的ページの議論になると 話が微妙に噛み合わなかったりする。 そこで、動的ページと静的ページとはそれぞれ何ぞや？ それがＳＥＯにどう結びつくのか？ といった話を今後数回にわたって適当に書いていくことにする。

手始めにまず、この「ネタ帳」サイトのようにGoogleのアドセンス広告を表示している Blogサイトのwebページは動的、静的、どちらなのだろう？ アクセス毎に広告が変わるということは動的ページであると考えられなくも無いが正解は静的ページである。 動的に広告を見せているのはそのJavaScriptを通して実行される Google側のシステムだからだ。広告を載せる側のページでは 固定のJavaScriptコードが書き込まれているだけだ。

なお、この「ネタ帳」サイトは他の多くのblogサイトと同様、 MovableTypeというソフトで作られている。ちなみにniftyのココログをはじめとする商用blogサービスのいくつかもMovableTypeのカスタマイズ版であることが多い。 このソフトではperl言語によるCGIスクリプトが生成した動的ページがblogの管理画面として使用される。 しかし実際の記事自体は普通のHTML形式の単なるファイル（つまり静的ページ）の形に自動生成され、 Webサーバのファイルシステム上にたとえば /usr/local/apache/htdocs/mt/000001.html の ような感じで保存してくれる。トップページであるindex.htmlなども同様だ。 blogを訪れてくれるユーザーはこの静的ファイルにWebサーバを通してアクセスし、記事を読む。

ではヤフーはどうだろう？ヤフーのトップページは、 http://www.yahoo.co.jp/index.html である。 index.php でも index.jsp でも default.asp でもない。ではヤフーのトップページは静的なページなのだろうか？

もちろん答えはＮＯ。中央の特集(?)記事部分のHTMLはアクセス毎にアトランダムに変わっている。これはGoogleアドセンスのような固定されたJavascriptコードによる外部サイトのコンテンツの表示ではなく、includeするコンテンツをアトランダムに変えるという、 純粋なサーバーサイドWebプログラミングの手法である。 右上の個人ツール部分も「こんにちは、○○さん」のようにユーザーごとに違う（Yahoo!IDを持ってログインしていれば）。 こうしたことは動的ページでしかできない技だ。 つまり、それが動的か静的ページかどうかを判別する手段としてはファイルの拡張子などは参考程度にしかならないと考えたほうがいい。 yahooのトップページのindex.htmlは実在のファイルではなくて他の実行スクリプトへのエイリアスでしかない可能性すら高い。

amazon.co.jpのトップページに至ってはファイルの拡張子すらほとんど表に表示されない、というか WebサーバにHTMLファイルを置いてどうのこうのという一般的な概念すら用いていないシステム構成なのだろう。 http://amazon.co.jp/index.htmlなんて勿論存在しない。アマゾンのほとんど全てのページが動的ページである。（追記：perl言語で構築された動的ページである）　しかしGoogleにはwww.amazon.co.jp配下のページが140万ほどインデクスされている。 おいおい、誰だ動的ページは検索エンジンにクロールされにくいとか言ってるのは？！

ということで次回は検索エンジンと動的ページの関係について・・・。

普通のパソコン等から携帯電話のメールアドレスに対してうまくメールを送れない、というトラブルはよくある。 たいていは携帯電話側でドメイン指定受信制限などを設定している、 といったことが原因だが、こんなケースもある。

Exchange 2000 Server と Exchange Server 2003では @の直前にピリオドがある等、 RFC に準拠していないアドレスを含むメッセージを送受信できない。
(Microsoft 2004/6)

postfixなどのメールサーバでも同様の原因でメールの送受信ができない。 （sendmailはどうなのだろう？）

いま現在も、auやdocomoの携帯電話上ではメールアドレスの設定変更の画面において、 xxxx.@docomo.ne.jpのように設定しても通ってしまう。 結果、Exchangeやpostfixなどのメールサーバからこうしたメールアドレスに送信しようとするとエラーになる。 携帯キャリア(auやdocomoのこと)のエンジニアがメールアドレスのフォーマットにまつわるRFCを理解しきらずに メールアドレスの設定変更システムを作ったことが原因だ。

しかしながら、べつに携帯キャリアの弁護をするつもりはないのだが、 筆者自身がRFC 2821の原文を読んでみたもののそこから メールアドレスの@の直前にはピリオドは使ってはいけない ということを読み取ることが、恥ずかしながらできなかった。とにかく難解なのだ。 一般に技術仕様書というものは難解なもので、RFCもしかりである。 しかしそれでもちゃんと読んで理解しておかなければ、メールという、 世の中において重要さを増す一方の情報通信インフラがおかしくなってしまう。 それなりに責任重大だ。自戒も込めて。

See also:

• そのサイトを見るとルーターがクラッシュする
• DoCoMoの説明にある「RFCに準拠しています」はウソ
• みんなで渡れば怖くないの罪 － au by KDDI メールアドレスにRFC違反を故意に許すの巻
• ドコモもauもいいかげんにメールアドレス設定の仕様を直せ。 (2007/11)

いや別にどっちの肩を持つというつもりはないのですが。

ライブドアについては、同社のインターネット上からアダルトページに接続できる点に質問が集中。青少年の健全育成の視点から事業見直しを求める意見が出された。
Yahoo!スポーツ - ニュース - 毎日新聞(2004/10)

楽天もやってるよしかももっとコアな感じで。

See also:
オ・ト・ナの楽天って知ってました？
楽天の大人のブックスのその後

以前の記事 で紹介した、イーバンク銀行が実装したフィッシング詐欺対策機能はほぼ無意味であることが判明。 以降、産業総合研究所の高木氏による記事（2004/10） から引用。

問題点
------
ユーザがパスワードの前半をサイトに入力してボタンを押したとき、自分の登 録キーワードが画面に表示されたからといって、それが本物サイトであるとは 限らない。

なぜなら、同じ画面を偽サイト上に構築し、騙して入力させた前半のパスワー ドと口座番号を、偽サイトが本物サイトに送信すれば、偽サイトは本物の「登 録キーワード」を入手することができるのであるから、それを偽サイトの画面 上に表示できてしまう。

そのような偽サイトは、ブラウザからのアクセスの全部を本物サーバへと中継 し、本物サーバからの応答をそのままブラウザに中継して返すという、単純な プログラムで実現できてしまうのであり、高度な技術を要するものではなく、 そのようなケースを想定しなくてよいことにはならない。

・・・確かにそのとおり。なんで気づかんかったんだろう（→自分）。PHPでもJavaでもperlでもそういうことを実現できるモジュールはいくらでもある。本気でフィッシング詐欺をやろうという輩ならその程度の技術力は十分あるだろう。

アクセス先が本物かどうかは、ブラウザが備えている機能によってしか確認し 得ないのであって、サイト側の工夫だけで真正性を示すことは本来原理的にで きないのだと心得るとよい。

まったくそう。 素人がセキュリティ上の大発明なんてやってはいけない。

ある程度大きな企業になると、企業内のLAN(＝イントラネット）上に各部門毎のWebサイトを開設することがある。 人事部のWebサイトでは異動通知やら住所変更手続きのやり方がどうだとか。 開発部のWebサイトでは「こんなの開発したから営業さん売ってきてよ」と言うための製品紹介用資料だとか自部門のエンジニアのための技術関連サイト上の新着情報やリンク集だとか。営業部のWebサイトでは業界関係紙の記事の紹介だとか路線検索エンジンへのリンクだとか。 Webサイトではなくいまだにクラサバ型のLotus Notesでやってたりするところもあるかもしれないが載っている情報は似たようなものだろう。

それらの企業イントラネット上のWebサイト群のなかには、更新されていない≒ほとんど機能していないWebサイトが少なくない。インターネット上の多くのサイトがそうであるように。

「なんで更新されてないんだ？ 何も発信する情報は無いとでも言うのか？Webサイトの責任者はなにをやってるんだ!」と、その部署での会議などで問題視されて浮かび上がってくる実情は
「責任者はいるんだけど別な業務で忙しいんです」
「責任者は一応いるんだけどあんまりやる気無いんです」
「責任者が産休を取ってそれっきりなのでそもそも責任者がいないんです」
てなことだったりする。インターネット上の多くのサイトがそうであるように。

確かに、やる気の無い責任者に委ねられたWebサイトは不幸だし責任者不在は論外だ。 だからといって、インターネット上（＝外部に公開される）の自社サイトならともかく 各部署ごとのイントラネット上Webサイトごときのために貴重な人員を割くことはできない。 （その企業での業務システムに直結していてそれが無いと日々の仕事ができないというような種類のイントラサイトなら話は別だが） 往々にしてイントラネット上Webサイトの責任者は通常業務と合わせて「兼任」ということになる。 そんなことを繰り返すうちにまた更新が停滞しWebサイトとしてまるで機能しなくなってしまう。 インターネット上の多くのサイトがそうであるように。

一番の根本原因はあけてみれば単純。誰もこれ以上管理するものを増やしたくないし責任も取りたくないのだ。管理したり責任を感じたりするのは日々の自分の本業＝営業とか開発とか＝だけで沢山だ！ というのが組織に属する人間の感情というものである。 「なんとかして自分たちの部門のWebサイトをもっと活用していこうよ」という現場の思いも、その現場にいる張本人のこうした深層心理によって声に出す前に飲み込まれ、 結果としてやはりイントラネットWebサイトは放置され存在すら葬り去られる。 インターネット上の多くのサイトがそうであるように。

このように、実は心理的な要因のほうが大きい問題に対してそのことに気づかずに「ちゃんとした責任者を置いてどうの役割分担がどうの」といった組織力学的アプローチでせまろうとすればするほど結局はモチベーションゼロ状態の無限ループに陥ってしまう。

ならば、もっと心理的に受け入れられ易い別なアプローチを試してみるべきだろう。

そういう意味において、最近話題になっている「企業による社員ブログサイト」は実際使うユーザーの心理面で優位なアプローチと言える。 書き手は、好きなときに好きなように書く。ブログサイトの責任者（Webマスター）は、書き手に好きに書かせるだけ。「Webサイトを管理する」という肩肘張った「業務」というイメージはそこでは薄れる。

「好きに書かせたら無責任なことやどうでもいいこと書くやつもいるし、本業ほったらかしてブログにばかり時間をかけてしまう奴すらいるだろう」 と懸念する人もいるかもしれないが、たいていはそれを口に出した次の瞬間に 「そういえばWebじゃなくても普段の仕事でも無責任な仕事するやつやどうでもいい発言をするやつもいるし本業じゃないことに思わず力を入れちゃうことは自分でもあるなあ」という結論に至る。

業種業態にもよるが、一家言持ってる人はどの組織にも少なからず必ずいるものだ。 つまらないデメリットを気にしつつ閑古鳥サイトをもてあますよりもそういう人のアイデアを掘り起こすメリットを取るべきだろう。 極端な話、ことイントラネットであればそれこそ「昨日子供が生まれました」みたいな記事があってもかまわない。外部に公開されるサイトなわけじゃなし、コンテンツが何も更新されないよりはマシである。

（Sun Microsystems社の幹部が自ら書いて外部に公開しているブログにおいて） Sunに勤めているけれど、表明された意見はそれぞれ個人的なものであり、 事前にレビューされたものではないし、会社として彼らの意見に必ずしも同意しているわけではない、と記載されている。日本のIT企業も、こんなポリシーで、社員Bloggerが外に向かって自由に発言していくのを奨励してもらいたいものだと思う。
(CNET Japan Blog - 梅田望夫・英語で読むITトレンド： 公開企業の経営者もBlogが書きたい 2004/10 より)

ほんとにそう思う。こういうゆるやかなポリシーなら管理だの責任だのといった心理的負担は薄れる。

いきなりインターネット上でやる勇気も権限も無いそれができるのは社長クラスだけだ(笑)と言うのならそれはそれで、ひとまずイントラネット上のWebサイトでやってみるというのはどうだろう。

1. 既存コンテンツは最低限を残して潔く捨て去り(どうせ大したコンテンツは無いか書き直せばすむ程度)、
2. 代わりにMovableTypeなりNucleusなりをインストールし、
3. 上の引用にあるSunの幹部ブログにあるポリシーの「会社として」のところを「○○部として」に直しただけのポリシーをかかげた上で、
4. その部署内の社員に好きに使わせてみるところから始めてみる

というのは企業イントラネット内Webサイトのリニューアル手段としてあながち突飛なアイデアではない。

しかしその部門のトップ（40代以上の石頭上司）がそういうポリシーでのWebサイト運営というものを理解できるかどうかというハードルは依然残るわけだが。

その他参考記事：
企業のBlog利用6分類(eNatural.org 2004/8)

2004/10/13追記：
とかなんとかいっていたら、独立行政法人経済産業研究所とかいうところが blog形式でのサイトを公開したらしい。

IT@RIETI e-Life Blog
(最新記事へのリンクがあるアンテナはここ )

お役所にしては英断。

2004/11/10追記
See also:ビジネスブログの実例：社内（イントラブログ）＞コラボレーション型

打ち合わせ中に携帯がなる。やかましい。バイブにする。 まだ鳴る。打ち合わせ中だっつの。無視する。まだ鳴る。 切れる。今度は外線が鳴る。
「watanabeさん、お父様からお電話はいってますが。」
「は？」
どうやら俺がどこぞで車で事故ってることになってるらしい。 はいはいごくろうさん。いそがしいっつの。

＃最近つまらない四方山話でごめんなさい。週明けにまともな記事書く予定です。

なんの気もなしにウロウロしていたらこんなのを発見。

偏差値７０からの大学受験

壮絶としか言いようがない。