とはいえ既存のページのワイヤーフレームを作るのも大変なもの。ただ、別に考える時に少しあれば良いのでそんなに手間をかけた細かいものでなくても良いわけです。

Volkside | Introducing Wirify: The web as wireframesで提供されているブックマークレットを使うと、簡単にワイヤーフレームが作れるようになります。リンク先の「Wirify by Volkside」のリンク先をブックマークに追加して、ワイヤーフレームを見たいページでブックマークを呼び出すだけです。

ちなみにこのブログのトップページをやってみたのが下記のイメージです。

ピクセルが正確には表現できていない点やプライバシーは保つもののURLをログとして記録をしているなど注意点もあるのでそのあたりは留意しながら使いましょう。ということでたまにはこんなネタでした。

ハイレベルサイトマップは解析とは関係ないようにも感じるかもしれませんが、自分はクライアントのサイトを分析する際は必ずといっていいほど作るものです。というかこれがないと分析の軸がブレやすくなってしまいます。

ただ、このハイレベルサイトマップは慣れていないとちょっと難しい部分もあるので、そもそも何よってところから、作り方まで触れていきたいと思います。

ハイレベルサイトマップとは？

そもそも、ハイレベルサイトマップって？について少し。ハイレベルサイトマップとは通常の詳細なサイトマップとは違い、サイト全体の大枠を知るために利用していきます。おおよそメリットは下記の感じです。

• サイトの概要、動線を俯瞰できるようになる。
• サイトの（マイクロ含む）コンバージョンの箇所が明確になる。
• フローの分析の手がかりになる。

サイトの概要、動線を俯瞰できるようにするためにサイトのポイントとなる部分だけを抜き出し、さらに主動線・辿ってほしい動線のみを記述するようにします。また、循環する部分をエリアとして明確にしておくと、全体の動線を想像しやすくなってきます。

さらにサイトのコンバージョンを色分けしておくことで、コンバージョンの箇所が明確になります。マイクロコンバージョン、最終コンバージョンを入れておくと良いです。（コンバージョンの分類については「コンバージョンは３つに分類しよう」に詳しく書いてます）

フロー分析の手がかりですが、上記２つの項目が明確になることはもちろんのこと、回遊部分、線形部分を把握できるようになることで分析のアプローチもしやすくなってきます。（回遊、線形については「サイト構造を考えながら解析しよう！」にも詳しく書いてます。）

また、流入チャネルやコンバージョン率などを記入していくことで、さらに色々と仮説検討のためのベースもできあがってきます。

ということでハイレベルサイトマップがなんとなくわかったら作ってみましょう！

Step１：おおよその型を知る

サイトの構造の種類は大きな視点で考えるとそれほど多くはありません。というかベースは３つです。実際にサイトマップを作るサイトがおおよそどのような構造にかるか、これらの型にあてはめ、そこからカスタマイズすると良いと思います。

コマース・新規獲得型

いわゆるコマースサイトですね。商品を選んで、カートに追加して、チェックアウトプロセスをとおって購入完了となるものです。

商品は複数の場合もあれば１つ選ぶ場合もありますが、おおよその構造は同じなので１つにまとめてしまって問題ありません。とうかハイレベルサイトマップ上はどちらも変わらないです。

また、新規獲得（リードジェネレーション）と呼ばれるいわゆる資料申込や無料体験といった箇所を最終コンバージョンとして提供している場合も構造自体はあまり変わらないのでここになります。

メディア型

メディア型の場合は、広告などを参照してもらう、そもそも記事を読んでもらうなど様々なな理由があれど、基本は記事をたくさん見てもらうことです。

ともあれ基本的に、回遊を中心とする場合はこのメディア型の構造になってきます。

機能提供型

会員へのサービスなどを提供しているものがここに入ってくることが多くなります。わかりやすいところでいけば金融系などはこの部分になってきますね。

オンラインバンキングなど機能を提供して利用してもらう部分などがこの機能提供型の特徴になる部分です。他にもSNSもこれに近い形になります。一見、メディア型に近い部分もあるのですが、会員に機能を提供しているという点ではこちらでも良いと思います。

Step２：自分のサイトに近づける

これらの型をベースに自分のサイトに近づけていきます。下記の要素を使いながら、肉付けをしていきます。

ここでのポイントはポイントとなる部分を大きくくくって考えること、メインの動線だけに線を引き、細かいリンクは気にしないことです。

さて要素ですが下記のようなものを入れていきます。
・　TOPページ
・　ランディングページ
・　商品一覧
・　商品詳細
・　ログイン
・　会員登録
・　会員機能
・　ツール（商品比較機能やシュミレーターなど）
・　サイト内検索
・　買い物かご
・　購入／資料請求プロセス
・　最終コンバージョン
・　特集・キャンペーン

あとはこれらをうまく組み合わせながら作っていくだけです。あと、細かいポイントをいくつか挙げておくと

• 商品検索などで検索方法（軸）が違う場合は別の要素として扱います。たとえば商品の条件で選ぶ場合と商品を写真から選ぶ機能がある場合などは別ものとして扱います。
• 主動線を意識すること。入口として大きくなる箇所、TOPページ、ランディングページ、キャンペーン、商品詳細ページなどから最終コンバージョンに至るための主動線（想定動線）で結んでいきます。
• 最終コンバージョンが複数存在する場合はそれぞれ別のものとして記載します。たとえば、システム的には同じページで処理をしていたとしても無料体験申し込みと資料請求はコンバージョンの種類が違います。こういった場合は別のものとして記述しておくようにします。

まとめ

上記を組み合わせていくことでおおよそハイレベルサイトマップが出来あがるとおもいます。ハイレベルサイトマップを作るときに最も重要なのは「動線を意識すること」と「細部にこだわりすぎない」ことです。

そして「誰でもサイトを俯瞰できるようにすること」が重要です。その上で上記の要素をうまく取り込んでいきます。俯瞰できることが重要なので、場合によっては粒度を荒くする、細かくするなどは行っても問題ありません。

ハイレベルサイトマップが出来たら次は下記のようなことをやってみると良いと思います。

• チーム内にシェアをする
• 解析ツールで分析して流入箇所が多い箇所にメモを入れる

ということでハイレベルサイトマップの作り方でした。

逆に言えば、アクションにつなげやすいサイトは、解析のしやすいサイトであり、それは結果としてサイト構造がしっかりしたものとも言えます。

ということで、サイトを作っていく上で＜解析視点から＞押さえておくと良いポイントをご紹介したいと思います。

USで起きている変化

まずは最初にUSで起きている変化について少し触れてみたいと思います。個々数年、USの上位に評価されているコマースサイトのTOPページなどを見ていくと、実際に＜解析しやすい＞が意識的に作られていると感じています。

下記のキャプチャはBest BuyのTOPページを現在と２００５年１月のものとで比較したものです。
（２００５年版はInternet Archive: Wayback Machineから取得しました）

基本構造は＜メニュー＞＜特集（メイン１つ、サブ２〜３）＞＜フリーワード検索＞の３つを軸にシンプルなものに変化しているのがわかると思います。

これは最低限の要素だけを残すことで、行動のニーズを把握しやすいようにして、サイトの改善はもとより、ターゲティングもしやすいようにしているんです。

日本は…運営社内での陣取り合戦が多いですね。圧縮陳列的になっているわけですね。

これはこれで選択肢を沢山用意しているということではあるものの、＜改善＞という観点から見ると非常に評価しにくい構造だったりします。この辺りが、現状のUSと日本では大きく違うと言えます。

どういう構造を作るのか？

それでは、実際のどような部分に気をつけて作っていくかを考えていきたいと思います。最近、自分の中で整理したポイントは下記です。

• １ページ（URL）＝１コンテンツ
• URL構造はきちんとした階層構造に
• ページ内リンクはメインナビとして利用しない
• ランディングページで動画系は利用しない
• ページ内は要素ごとに入れ替えやすいように

１ページ（URL）＝１コンテンツ

＜解析しやすい＞で最も重要なものと考えているのは１ページ＝１コンテンツに絞り込むことです。ページが見られたこと＝どんな情報が参照されたか？ということがわかれば飛躍的に改善のスピードがあがります。

ここは意外と見落としがちなのですが、これが実現できているかどうかで、改善アクションの検討やアクションの取り方が大きく変わってきます。

ランディングページなどでは、なるべく１ページで色々なコンテンツを見せたいということもあると思いますが、まずは、それぞれのコンテンツに分割することで、改善のアクションが取りやすくなります。

URL構造はきちんとした階層構造に

＜解析しやすい＞の2番目としてURL構造も重要です。ここでのURL構造とは、きちんと階層構造になっていて、かつ意味が推測できることを指しています。

この部分は、以前よりはよくなってきていると感じていますが、まだURL内が意味を全くなさない文字列で造られていることがたまにあったりします。

あと、きちんとしたURL構造を作ることは、コンテンツの階層構造を意識することでもあります。経験上、URL構造がきちんとしているサイトは、コンテンツの整理もきちんとされている傾向があるかなぁと思ってます。

ページ内リンクはナビとして使わない

ページ内リンクは、大量のコンテンツが１つのページに存在する場合は、ナビゲーションとして役立つこともあります。

先程触れたとおり、そもそもコンテンツ内に複数のコンテンツを推奨しないわけですが、ページ内リンクはWeb解析視点からみた場合にも致命的な欠点を抱えています。それは計測されないことです。

もちろん、別途実装等をすればリンククリックを計測することは出来るのですが、基本はページビューとしてカウント出来ないのです。つまり、訪問者がページ内リンクを多用していたとしても、それを解析面から見て取ることが難しいんです。

「ページの先頭に戻る」といったリンクはユーザビリティ的に有用だと思うので良いのですが、メインナビゲーションとしての利用はおすすめ出来ません。

ランディングページで動画系は利用しない

動画をプロモーションとして利用することが多くなってきましたが、ランディングにおいてしまうと、動画だけ見て満足して帰った訪問者は全て＜直帰＞扱いになってしまいます。

せっかく動画が効果をあげていたとしても、これでは評価しづらくなってしまいます。そのためWeb解析からの評価を考えた場合は、ランディングページでの動画はあまりおすすめできません。

Flashも同じで、裏側でリクエストを投げているなどをしていないFlashコンテンツをランディングにでかでかと持ってきてしまうと、解析ツール上はそれで遷移が終了、つまり直帰になってしまうのです。

きちんと効果を上げていることを数字に落とすためにも、こういった部分は制作時に少し意識しておく必要があったりします。

ページ内は要素ごとに入れ替えやすいように

テストを意識するということでいうと、テストできる要素を事前に意識できた作りになっているかも最適化アプローチの中では大きいです。

これは制作側で特に意識をする内容だと思っています。どの単位でテストされるのか？その単位でテストがしやすいか？などが意識できた作りになってると改善アプローチがしやすくなります。

ターゲットセグメントによって、ページ内の要素の位置を入れ替えるだけでもコンバージョンは変化します。セグメントによりコンテンツごとの優先度が違うのでこれをツールでコントロールするわけです。

テストツールは基本はソースの一部を出し分ける作りになっているので、デザインとして要素をある程度入れ替えても崩れないような組み方をしているとこういったテストもしやすくなるわけです。

まとめ

ということで、Web解析ツールを利用して分析を行うという視点から、サイトの作りについて少し触れてみました。サイトをより良くしていくためには、こういうちょこっとした部分ができてるかがポイントになってきます。

「次の改善アクションをどうするか？」と考える時に、手元のデータが使えないデータよりは、仮説が色々と組み立てられるデータのほうが良いですよね。

ということでサイトの構造と指標の味方について少し。あれ、同じような話を書いた気がする…と思ったら書いてたけど、そこから拡張版で書きますっ！（サイトマップ、頭に入ってますか？／　コマースサイトのサイトマップ）

まずはハイレベルサイトマップ

自分がお客様と何かしら分析について話す場合は、なるべくハイレベルサイトマップを作り、最初に確認する用にしています。通常、サイトマップというとサイトに用意しているような、サイト全体のリンク集みたいなものや細かいURLとディレクトリの位置を記述したものを想像される方も多いと思います。

ハイレベルサイトマップとは、そういった詳細なものではなく、もっと、ざっくりとしたサイトマップで、サイト内の主要動線構造や機能の箇所、コンバージョンへのルートを確認するためのものです。

これを整理すると、サイト全体でどのようなルートでユーザーがフローを辿るのかが見やすくなります。

これを整理することでのメリットは

• サイトを俯瞰できるようになる。
• サイトの（マイクロ含む）コンバージョンの箇所が明確になる。
• フローの分析の手がかりになる。

といったことになります。分析する際の勘所がつけやすくなります。そして、何よりサイト全体の理解をするには早いわけです。なんでも細かいところからやってはダメです。大きくいきましょう。

一般的なサイト構造

ハイレベルサイトマップを整理することで見えてくることが多いのですが、サイトのフロー構造はいくつかに分類され、それらの組み合わせによって成り立っています。

メディアサイトやコマースサイトでも商品を探す部分などは、リンク構造が複雑にからみ合ったウェブ・回遊型などと呼ばれるものや、IRサイトや情報系サイトでは多く見られるヒエラルキー（階層）型、予約・購入などのフローで見られるライナー（線形）型などがあります。

さきほどのハイレベルサイトマップを作ると、サイトのどこがサイト構造として成り立っているかを俯瞰することができるようになります。

そしてこのサイト構造の大枠を理解しておくことで、ウェブ解析ツールでさまざまな課題点の分析をしていく際の、評価のポイントが見えてきます。というか、評価を分けなきゃおかしい部分もあったりするわけですよ。

コマースサイトやリード獲得系サイトの場合、ウェブ・回遊型と線形（ライナー）型の組み合わせパターンがほとんどです。ウェブ型で色々な情報を見せ、購買意欲が高まった時点でフォームに流すわけです。そしてフォームについてはライナー型で一直線なフローになってくるわけです。

このような組み合わせを考えた場合に、わかりやすい違いの例でいくと滞在時間や平均ページビュー数があげられます。ウェブ型の部分は、どんどん回遊をして購買意欲を高めてもらいたいわけで、滞在時間や平均ページビュー数の伸びを期待します。

しかし、ライナー型のフォーム部分はその逆です。滞在時間、平均ページビュー数が伸びているということは、何かしら詰まっているわけですよ。入力に手間取っているかもしれないですし、エラーをだしまくりかもしれないわけです。

この場合のライナー型の部分については、滞在時間、平均ページビュー数はある程度ひくくなった方がユーザビリティが向上しているとも言えるわけです。

まとめ

ということで色々とざっくりと、それでいてしつこくなく、まったりとした形でサイト構造について書いてみました。

ウェブ解析ツールの結果として出てくるものは数字です。ただ、これだけ眺めていても答えや課題は見つかりにくいものです。

サイト構造を頭に入れておいたり、実際にサイトと数字を見比べながら分析を行っていくことで、本質的な課題が見つかることが多くあります。

ということで特にハイレベルサイトマップなどはぜひぜひ一度作って頂くと良いと思いますよ！

ということで、たまにはお薦めの書籍でもご紹介しようかと思います。つまり、雰囲気の便乗です。

しかし、普通のWeb解析系本の紹介だと、恐らくほかでも十分に紹介されている気がするのでちょっと路線を変え、Web解析周辺で役立つものをご紹介。

ちなみにタイトルを押下するとAmazonに飛びます。ほら、あれですよ、お年玉ください。

Website Optimization（洋書）

O’reilly本になりますが、SEM、Conversion（CRO：Conversion Rate Optimization）、Web Performance という３点の最適化に絞って記述がされている、少し面白い視点の本になります。

残念ながら日本語化はされていませんが、内容を読むと結構勉強になるところはああったりします。O’reilly本ということもあり、運営者向けというよりは、サイト運営に携わっている制作者向けといった本だと思います。

追記
コメントで日本語版の存在を教えて頂きました。t32kさんありがとうございます！日本語版はこちら＞オプティマイジングWebサイト ―SEO・サーバ・クライアントの最適化技術

Web Design for ROI（洋書）

これも洋書になってしまいますが、「ROIを意識したデザインをするには？」という視点で書かれた本になります。デザイン本なので、カラーで事例も豊富に掲載されています。

どんなところに気をつけてページデザインをすると良いのか？という視点を、得るにも非常に良い本です。インターフェース設計をされる方やデザイナー向けになると思います。

IA100 ユーザーエクスペリエンスデザインのための情報アーキテクチャ設計

コンセントの長谷川さんが書かれた本です。すごく良いです。IAに関する100個の項目について、丁寧に記載がされています。

デスクに置いておいて、リファレンスとして利用する形になりそうな本です。ちなみに、書籍発売記念でスペシャルサイトがコンセントのサイト内にあります。こちらも是非チェック。

Web情報アーキテクチャ

これまたO’reilly本になりますが、ここ数年、製作者の方には愛読されているかと思われる本です。もともと第１版では情報アーキテクチャについて書かれていたものですが、第２版でWebが付き厚みも倍になった本です。

いきなり読んでしまうとちょっとハードルが高くなってしまうのですが、長谷川さんの本と併読や読んだ後に読むと、理解がぐっと進むと思います。

消費者行動論

消費者行動論というと少し難しい学問的になってしまうことが多いのですが、この本は、ビジネス向けに記述されていることもあり、すごくわかりやすくまとまっています。

たまに何かを考える際にもフレームワークとしてリファレンスすることも多く、非常に重宝している本の１つです。

まとめ

ここでご紹介した本のほとんどは、ボリュームが多いのが多いこともあり、がっつりと読み込みというよりも、サーっと読んでおいてリファレンス的に参照するのが良いかもしれません。

ご参考になれば。

• Site-it!：DESIGN IT! w/LOVE
  コンセント長谷川さんが紹介／発案？されたページテンプレートを付箋にしたSite-it!。Web解析でもフローの話をすることは多いので、これはかなり有用な気がします。というより欲しい！
• link rel="canonical"によるURL正規化タグ——SEOにとって非常に重要な進歩（前編） | Web担当者Forum
  リスティング広告であったり、提携広告からの流入をトラッキングする方法の１つにそれぞれにパラメータを付けておく方法があるのですが、これがURLを複数生み出してしまう原因だったわけで、このcanonicalタグはかなり有用なものになりそうです。

全ての答えは４２である。まぁ、そんな明快な答えはWeb解析ツールは教えてくれないわけです。その行動の結果が４２であろうとしても、４２の意味は教えてはくれません。

Web解析ツールの一番の目的は俯瞰ツールと言っても良いのではないでしょうか。データを俯瞰しやすくするツール、Webサイトを俯瞰しやすくするツールなわけです。

• 時間軸による変化
• 他との比較による違い

この２つを見ていくことで問題点のおおよその場所を特定していくわけです。そして、重要度の高い部分から改善の対応をしていくわけです。

以前に「アクセス解析はユーザビリティの夢を見るか」というエントリーを書いたときに、そのプロセスについて触れました。

そのプロセスの最初にある「変化を調べる」という部分がデータの俯瞰により見えてくる部分です。そしてこの部分が解析ツールが最初に教えてくれる数字です。

後は、色々な問題点をもとに「その数字の裏」をとっていくわけです。それは解析ツールによる深堀かもしれませんし、ユーザビリティ的考慮かもしれないですし、IA的視点かもしれません。

まぁ、何より重要なのは「究極の問いに対する答えはWeb解析ツールは持っていませんよ」ということ。

４２の数字を与えられた時に、その４２をどう自分の行動に結びつけることができるか？それが解析ツールなわけです。

あなたのWebサイトが売れない理由は「なぜ？」（1/2） − ＠IT

個人的な見解として、アクセス解析を利用して改善を行っていくためには、ヒューリスティックな判断をしていく必要があると思っています。

そのときに知っておくと良いのが「ユーザビリティ」「 IA（情報アーキテクチャ）」「インタラクションデザイン」など。これらを理解しておくことで、よりディープにアクセス解析を活用できるようになるのではないかなぁと思っています。

もともとが４回連載の予定だったので、色々と詰め込んで書いてしまった部分もあるのですが、よろしければご参考くださいませ。

以前にリニューアルを担当した時に、担当の方から言われた一言です。これは何かというと、数ピクセルずつ広げることで、フッターにあった余白を無くしたんですよね。

何故、その余白を無くしたかったかというと、そこに別部署からの要望を受け付けられないようにするため。TOPページは大きな組織にとって、陣取り合戦なわけです。

組織であること

ある程度、落としどころが見えたデザインにとって、もう、マーケティングやらIAやらアクセス解析などは関係ないわけです。そこにあるのは組織内での調整。

ユーザー視点は重要だと思います。しかし、企業のサイトではそれだけでは済まない部分は多々あるわけです。

ユーザーにとってのメリットとともに、そこには企業の利益を追求すべき部分が必ずあるわけです。その両方のバランスをとっていかないと、企業サイトとしては意味がないわけです。

SONYのコーポレートサイト

先日、SONYのコーポレートサイトがリニューアルしたそうです。そこでTOPページにある「銀行・保険」というリンクをクリックすると画像のようなページに遷移します。

本来であれば、デザイナーさんやIAの方々の努力によって、もっと良い見せ方はあるはずだと思うのですが、これは恐らく組織の壁にやられたんだと思います。

でも、これも実は重要だったりするわけです。本当のことはわかりませんが、こういった見せ方をあえてしたことで、次のステップできちんとした統合を見せるということを考えられているかもしれません。ただ、単純に…というのも十分に考えられるわけですが。。

まとめ

特に大きな組織にとっては、こういったグループとしてのブランドの見せ方と、実際の業務がまだまだ壁が多いことは事実なわけで、組織である以上、サイトにも組織が反映されちゃうんですよね。

これって、運用に関わってないと結構見えないようで、制作の方でも以外と知らないことが多いようですね。ということを、先日のIA Cocktail Hour Tokyoに参加して思いましたという話。

昨日顔を出してきたIA Cocktail Hour Tokyoの主題です。これって結構難しいですよね。そして、やはりみなさんも苦労しているっぽい。

社内ブログや社内SNSはやはり、Postする人が限定されてしまうのはどこも同じらしい。いくつか出ていたのが「自分がどう書いていいかわからない」「この人に意見なんて出来ない」「自分のレベルが低いかもしれない…」など。

情報共有の目的

情報を共有することの目的としては、その状況に応じて様々なわけですが、プロジェクト内部の情報共有のような、進行具合や状況を把握するための情報共有と、こんなサイト知ってる？といった、参考情報の共有があるわけです。

どっちも難しいと言えば、難しいわけですが、状況の把握の場合、特にそれがプロジェクトなどであれば、仕事の中で必要なわけですし、受け取る側も受け取る意欲があるわけで、まぁ、なんとかなる場合も多いわけです。おそらく。

ということでこれは誰かにおまかせして、今回はもう１つの参考情報としての共有についてもう少し考えてみたいなぁと。

これって、直接的に業務に関係ない場合もあったりするので、実は状況把握としての情報共有よりはるかに難しい気がしています。

仕事に役に立つかもしれないし、役に立たないかもしれない。でも、それを知っておくことで、チームやグループの幅は広がるといったものです。

ある人から見れば、「無駄な情報」かもしれないし、他の人がみれば「のどから手が出るほどありがたい」情報かもしれないわけです。

情報を集める方法と知らせる方法

気にする部分は大きく２つ。「情報を集める方法」と「情報を知らせる方法」です。

情報を集める方法といっても、RSS使えとか新聞読めとかそういうことではなく、ピックアップされた情報を集約する方法です。

これは出来るだけ簡単な方が良いのかなぁと思ってます。それこそ、Bookmarkletなどを利用してPostしたりTamblooぐらいになってしまうとさらにうれしい。

つまり、いちいちテキストエリアを目の前にして何を書くか考えてしまうことでハードルがあがってしまうわけで、この際、もうそういった事すらやめてしまう。

あとは、誰かがそれを再編集していく。どこかで繋がるものもあるかもしれないし、そうでないものもある。ちょっと、違うものもあるかもしれないから、それは別にしてしまうか削除する。

これをやっておくと、だいぶ情報の質が高まるわけです。編集という作業であれば、自分の意見を書く訳ではないので、誰でもできるわけです。そして何より、編集という作業を通して、その情報について考えるし詳しくなれる。ということで、グループで仕事としてローテーションでも良いかと。

次に情報を知らせる方法ですが、これはRSSで配信しておくことは重要だと思います。ここである程度取捨選択ができますからね。

それと、ホワイトボード。オフィスなどのどこかに書かれたものがアップされてれば、もしかしたら目につくということにもなるかも。最近のはやりの企業だと、マインドマップとかを会社の廊下とかに用意してますよね。

これは月間ASCIIに載っていたのですが、株式会社内田洋行では、同社が提供しているパーフェクトプロジェクションアダプター（PPA）というのを利用して、会社の壁に並べた複数のディスプレイに、誰でも簡単に自分のPCから情報を掲示できるそうです。

これで集約した情報の新着を載せていたら面白いだろうなぁと。

まとめ

ということで、情報共有について少し考えてみました。偉そうな理想を並べましたが、結局は、メールで情報共有、リアルに顔を突き合わせてコミュニケーションが一番盛り上がったりするものです。

おぉ、そういえば情報共有で思い出したのですが、FrindFeedというサービスを利用して、はてなのアクセス解析タグとDeliciousのWebAnalyticsタグを１つのRSSになるようにしています（WebAnalytics – FriendFeed）。

一応、ニュースだったりブログのエントリーを中心にしているので、わたくしめが勝手に不要なリンクは削除したり、コメントを入れていたりもします。なので、パブリックというよりは、かなり偏った感じの情報ですが。ご興味があれば是非。これも情報共有。