お使いのブラウザは最新版ではありません。最新のブラウザでご覧ください。

CNET Japan ブログ

社内ブログ導入記(2)

2005/07/08 18:10
  • このエントリーをはてなブックマークに追加

前回のつづき)

前回は、ブログ導入のそもそもの動機としてメーリングリストによるコミュニケーションの限界を見極めた、というお話をしました。

では、メーリングリストの問題はブログで改善されるのでしょうか。

結論から言うと、現在このノンスモーキングルームでは、メール中心のコミュニケーションにあった「閉鎖性」と「儀礼的沈黙」を破るという観点では大きな成果を上げつつあります。

たとえば毎日読んでいるニュースから面白かったものをクリップして同僚に送るなど、インフォーマルな情報伝達は「FYI (For Your Information)」と呼ばれていますが、時間とともに人数が増えたり関心の領域がずれてくると、いつかFYIメールを迷惑と感じる人が出てきます。経験的に、FYIメールがうまく機能するのは普段から緊密に仕事をしている4〜5名ぐらいが上限ではないかと感じています。これがブログの場合、読者のことをあれこれ考える前にひとまず自分用のメモとして書いてしまえばよく、メールと違って後から更新して文面をブラッシュアップすることもできるので、その仕上がりに満足して誰かに伝えたくなったら後で URL (Permalink) だけをメールで送ればよいのです。人間に限らず生物はフィードバックによって生きていますから、頭の中で考えていることを「声に出してみる」「書いてみる」というのは大切なことです。

また、パブリッシュ&サブスクライブ(発信と購読)型のコミュニケーションモデルの中でも、メーリングリストがPUSH型の「強いサブスクリプション」を要求するのに対し、ブログはPULL型の「弱いサブスクリプション」を可能にします。新聞や雑誌を読むのに、定期購読(PUSH)しかないというのはむしろ不自然です。たいていの人は定期購読する新聞はひとつで、他紙や雑誌は気が向いたときにふらりと立ち寄ったキヨスクで買うものです。ブログは、こういうアドホックな「キヨスク的購読」を可能にします。アンサブスクライブ(購読停止)に手続きなど必要なく、単にキヨスクに立ち寄るのをやめればよいのですから。

というわけで、前回のエントリへのトラックバックやコメントにもご指摘のあった通り、メールとブログ、あるいは掲示板のようなコミュニケーションツールは、それぞれに役割が異なるものです。

これを仮に緊急度という軸で切って図示してみました。これを「コミュニケーションのピラミッド・モデル」と呼ぶことにします。

20050708-3tierComModel.png

このピラミッドの各層は、潜在的な情報の量を表しています。メールは緊急度が高いことが期待されるため、最小限の情報を簡潔に伝えることが基本です。一方、ブログはメールで送るには押しつけがましくて遠慮してしまうような話題を気軽に書き込めることがメリットなので、メッセージとしての緊急度は低く、情報の総量は多くなります。

このピラミッドは「コミュニケーションにおいて情報量と緊急性が両立しない」ことを示す一般的なモデルですので、この3層にはメールや掲示板やブログ以外のものをあてはめても説明に使うことができるでしょう。

というわけで、上の「コミュニケーションのピラミッド・モデル」はレイヤーつきPNGになっています。Fireworksを使えば文字を差し替えできますのでご自由に再利用してください。(Fireworks以外で編集できるかどうかは詳しく調べていませんが、Photoshopではダメでした。。。)

さて、話を本筋に戻すと、ブログを導入するというのはメールや掲示板の不足を補うということであって、それらを置き換えるということではありません。あくまで、「会議室」ではなく「タバコ部屋」を、ピラミッドの最下層をつくりたかったのです。

ここからは、現在に至るまでの具体的な検討プロセスを書いてみましょう。

かなり事細かに書くと読むのに疲れるかも知れませんが、本気で社内ブログを導入しようと検討している人の参考資料になればと思い、文量を多めにしてみました。

■社内ブログの要諦は「認証」

まず、去年の8月から試験的にMovable Type (以下、MT) をインストールしたWebサーバをひそかに立て、開発部とマーケティング部を中心とした一部のメンバーで使っていました。メンバーのブログの更新情報はRNAを使ってアグリゲートし、新着順にポータルページに一覧表示していました。

業界標準のMovable Type一式だけに、これはこれで快適に使えていたのですが、いくつか不満点も出てきました。

  1. アクセス制御にクッキー認証を使えない(ベーシック認証のみ)
  2. 各自でテンプレートを変更する敷居が高い
  3. 必要に迫られて一部作り込みをしてしまったため諸々の変更やメンテナンスが面倒

特に、当初(1)は大した問題ではないと思っていましたが、実際使っていると心理的には結構大きな問題と感じました。

コミュニケーションツールとして使う以上、いつでもどこでも気が向いたときに気軽にアクセスできることは最低条件だったので、MTサーバは社外に置いていました。しかし社内の業務連絡もそこで行われる以上、そのコンテンツを誰でも見える場所に置くわけにはいきません。

ところが肝心の認証方式はというと、MTはインターネットでフルオープンにブログを公開することを前提に作られており、事実上コンテンツの閲覧制限をかける機能がありませんでした。このため、Webサーバのベーシック認証を使って、しかも全員で共通の閲覧用パスワードを共有するという方法で閲覧制御をするしかありませんでした。

一方、日常の業務連絡ではメールの方が主媒体であるため、みんながいつも互いにブログの新着記事をウォッチしているという状況はまず期待できませんし、そんなことを望んでもいません(上記ピラミッド図が示す通り、メールより情報量が多いですから、中毒症状が起きた場合は重症です)。従って、ブログはあくまで自分のためのメモ書きや思考の過程をスケッチするアイデアプールとして用い、アイデアがまとまってエントリに整理できたらその URL (Permalink) をメールで知らせる、というような使い方がベストプラクティスと考えています。

このとき、ベーシック認証を使っていると、そのメールを受け取った側では URL をクリックすると毎回ログインパネルに出くわし、ウルサくて不自然な印象を持ちます。「そんなの、ユーザ名・パスワードをブラウザに保存しておけば、クリック一回分の違いじゃん」という意見もあるでしょうが、たかがクリック1回、されどクリック1回。そこには、日々繰り返し使ってみるという形で体験してみなければ決して理解できないであろう、軽視できない精神的負荷がそこにはありました。とくに、大多数の人がメール中心の生活に慣れきっていて「ブログなんて、ケッ」と思っている初期はなおさらです。

たとえば、アマゾンにアクセスするたびに毎回ベーシック認証のパネルが出るなんてユーザビリティ的に考えられないと思いますが(アマゾンはトップページで「こんにちは、○○さん。」とやるために、同等のことをクッキー認証でやっているわけです)、つまりそういうことです。カーム・コンピューティング(「静かな」「目障りでない」をめざす設計思想)という言葉がありますが、ユーザーインターフェースを考える上ではこういう「クリック一回分の違い」を軽視しない姿勢は間違いなく重要度を増してきています。

こうして、クッキー認証以外には選択肢はない、という確信を深めつつあったのでした。(クッキー認証には別の問題点もあるのですが、これについては次回で)

ところで、社内ブログの要諦は認証であると言う以上、このあたりで言明しておかなければいけないことですが、私は「認証」や「アクセス制御」というものについて、独自の哲学を持っています。それは「社内の機密情報が漏れるのが怖いからセキュアにする」のではなくて「みんなにのびのびと自由に書いてもらうためにセキュアにする」という考え方です。結局、技術的には同じものを使って実現することになるのですが、その背景にある考え方は180度違うので、成否のカギを握る「運用ポリシー」に根深い影響をもたらします。ところが、この観点は常識的で立派な社会人であればあるほど非常〜に理解されにくい(つまり私自身も今回すごく苦労したということです)ので、次回きちんと論じます。

さてそんな頃、先々月に私のビザが下りてようやく渡米が正式に確定し、いよいよ日米間の情報共有チャネルをどうやって確保しようかと本格的に検討を始めたところ、とっとと社内ブログの公式リリースを急ぐのが一番よかろうということになり、私の6月中のタスクとして正式に積まれたのでした。

いつもながら唐突なジョブアサインですが、ここからが急展開でした。

■アクセス制御とVPN

さて、私自身がブログの導入から運用までを一括で請け負ったわけですが、最も重要なのはどのソフトウェアやサービスを使うかといったハード面よりも、どんな運営ポリシーにしてどういうモデレーションをするかといったソフト面に時間を多く割くことだという確信があったので、ハード面の採択の方向性はシンプルに絞り込みました。

  1. 社内外を問わずいつでもどこでもシームレスにアクセスできること
  2. 一方でユーザに目障りでない形で閲覧制限ができること
  3. TCOを抑えるため、可能ならサーバは購入せずレンタルサーバを使いたい
  4. Permalink が70文字以内(メールで行が折り返さない短さ)であること

(1)の社外からアクセスできるようにするという点は、賛否両論ありましたが、絶対に譲れないポイントでした。たとえば、会社に行かなければメールが出せないなんて、今時あり得ないでしょう。ブログはメール以上に気軽に書き込みができるべきであって、24時間いつでも気が向いたときに、その思考を妨げずメモ代わりに書き込めなくては不活性に終わるのが目に見えていたからです。(実際、ノンスモーキングルームは深夜のアクセスが一番多いのです)

そして、(1)と(2)を同時に実現するための別の選択肢としては、ブログサーバは社内LANに設置して認証そのものを行わない標準的なコンフィグレーションで運用し、社外から社内LANへはVPNを張ってアクセスするという案もありました。

しかし、個人的な経験からすればIPsecベースのVPNクライアントは使い勝手や運用の手間暇があまり芳しくなく(これはPKIモデル一般に言えることですが)、全社員に自発的にインストールしてもらうにはかなりハードルが高いと感じました。

そもそもブログのようなコミュニケーションツールは実際に使ってみるまで効果が出るかどうか誰も保証できず、従って全員が最初から納得済みで始めるのは難しいものです。ましてや、強制的に全員を参加させるというような押しつけがましい始め方では逆効果です。ちょっと使ってみて、「面白い!」と感じたメンバーが、ひとり、またひとりと自発的に楽しみ方を発見し、自ら伝道師となって広げてもらわなければうまくいかないのです。であるにもかかわらず、VPN経由でのアクセスを必須としてしまうと、その「ちょっと使ってみて面白さを発見する」ためのハードルが高くなってしまい、元も子もなくなるのです。

Windows XPやMacOS Xで標準となり、ユーザ名とパスワードだけでお手軽にセキュアセッションが張れるPPTPなら許容範囲か?とも思いましたが、そんなお手軽なPPTPでも社内のファイルサーバのNetBIOS名前解決やゲートウェイへのルーティングに問題があったりスピードが全体的に低下したりと、たかがブログへアクセスするためだけに新しい問題を抱え込んでしまいます。そうすると、カルチャー醸成などのソフト面で力を発揮してほしいライトユーザは面倒になってブログから遠ざかってしまうのが目に見えています。(ノンスモーキングルームの実績をみても、ムードメイカーはノン・テッキーな女性陣である、ということも添えておきます)

そんなわけで、VPN案は(全社員というレベルでは)まだ時期尚早ということでボツにしたのでした。

■「買う」より「借りる」

さて、次に検討したのが(3)の「自分でセットアップするよりレンタルサーバ」という点です。

私自身はPCを買ってきてサーバをセットアップするのは趣味でもありますし、技術的にはまったく問題ないのですが、それを業務で運用するというのはまったく別の話です。導入は興味と勢いで始められますが、運用には計画性と忍耐が必要です。自分でセットアップしたサーバは、自分が面倒をみるしかありません。たかがブログサーバとはいえ、パフォーマンスが低下したり原因不明のダウンが発生したら、調査に駆り出されるのは自分しかいないのです。趣味としてのセットアップの楽しさなんてあっという間に冷めてしまって後悔するのが見え見えだったので、自分でサーバを立てるのは避けたいなと思っていました。(余談ですが、実はプライベートで使っているメインのサーバも自宅ではなくて PROX のレンタルサーバを借りています。かれこれ6年以上使っていますが、非常に満足しています。自宅サーバに見切りをつけた「持たざる」の実践者としては早いほうではないかと自負しています。)

私個人のケースから一歩下がって一般論で考えても、社内ブログの導入を検討する立場の人というのは、ふつうバリバリのエンジニアではありません。つまり、PC・ネット・ケータイは趣味でパワーユーザーだけどLinuxのパッチを延々と当て続けるのが楽しいと思う種類の人間ではない、ということです。HTMLやCSSのテンプレートをいじるのは楽しいがPerlやPHPのレベルでハックしたいとは思わない人々、とも言い換えられるでしょう。

そういう人は、なるべく下の方のレイヤー(ハード、OS、プログラム)は誰かに面倒みて欲しく、自分は上の方のレイヤー(データそのものを扱う仕事)に集中したいものです。

それに、最初は社内ブログの導入を応援してくれる支援者も少ないですから、ブログ導入の成功によってその価値を証明できるまで、その人は自分一人であらゆる対応をきめ細やかに行っていかなくてはいけません。そういうときに技術的なトラブルで時間を取られていては本末転倒です。

ハイレベルな技術者がやれば技術的な問題は起きないかというとそういうわけでもなく、技術者は単に技術的な問題を解決するのが好きなのです。

一人の人間にやれることなんて限られてますから、注力したい&楽しみたいポイントを絞って欲張らないことが肝心です。技術面の満足と利用面の満足の両立は、往々にしてToo Muchなのです。

さて、この観点から、まず最初に調査したのはココログやライブドアのような一般向けブログサービスでしたが、当然ながらこれらは社内ブログ用に使えるセキュアな認証機能などはありませんでした。従って「のびのびと書けない」のでボツです。また、更新情報のアグリゲーションを行うトップページを簡単に作れないのも痛い点です。

次に調査したのは、MTをプリインストールしてあるレンタルサーバです。しかし、MT自体に認証機能がないという問題はやっぱり解決されません。

こうして次々と調査を進めていった結果、ふと、レンタルサーバ市場にはインターネットを前提としたWebやメールのサービスばかりで、イントラネット用の各種サーバをVPNで透過的に接続してアウトソースしますよ、というようなアプローチのサービスは全然ないことに気づきました。世の中、そんなに不特定多数のインターネットにつながっていたい人ばかりなのでしょうか?あくまで社内用途のマネージド・ホスティングという選択肢があってもよいと思うのですが。

これはビジネスチャンスか?と、一瞬、胸に野心の火が灯りましたが(笑)、とりいそぎ今の私に必要なのは仮想的に社内リソースとして使えるレンタルサーバです。

これだけブログが世の中で話題になっていても、社内システムとしてブログを使うという機運はまだまだ熟していないようで、色々とサービスやソフトウェアを探して検討したのですが、私の希望する(そして社内ブログ一般に要求されると思われる)要件にピッタリの選択肢はほとんどなかった、ということは特筆に値するでしょう。

というわけで、最終的に選択肢に残ったのが、候補リストの最後の方にあったダークホース「はてなグループ」だったのでした。

次回はいよいよ運用について。

(つづく)

♪ Prince / I Wanna Be Your Lover

※このエントリは CNET Japan ブロガーにより投稿されたものです。朝日インタラクティブ および CNET Japan 編集部の見解・意向を示すものではありません。
運営事務局に問題を報告

最新ブログエントリー