「ブログでビジネス」失敗と教訓

興味本位で始めたブログも、楽しさ・便利さに魅了されるとこいつを仕事で使えないだろうか? と考えるのは当然（私も考えた）。

思いつくのは、日報や課題管理をブログ化してグループで情報共有… いわゆるコミュニケーションマネジメントのツールなのだが、似たようなことを考える人はやっぱりいた→社内限定の非公開型ブログ「イントラブログ」（イントラネット+ブログ）

グループウェアとどこが違うの? ASPってもう死んでるよね? というツッコミを待つばかりだが、このプロジェクトは2005/2末に試用停止と至ったとのこと。目のつけどころは悪くないのだが、結局は器と中身の鶏卵話に落ち着く。いかに優れた技術・サービスであっても、乗っかるコンテンツが流行らなければ、電源のないパソコンと同じ。まず今の仕事の業務分析が先だろうと誰も言い出せないまま始めちゃったんだろうねッ。「ビジネスブログブック」とゆー本が出ているようだが、マンセー厨房が沢山いるamazonにもかかわらず低め評価。

いきなり導入ではなく、個人 > チーム > コミュニティ の順に渦を回していくのが成功パターン。 PukiWiki で個人→グループへライブラリ情報をシェアしていくとか。一人で使ってもでも便利だし、使っていない人も便利になる仕組みがポイント。

一方、海外でも似たような考えがある→「Using blogs for project management」。プロジェクトマネジメントでブログを使う際、注意するべきことが書いてある。

　ブログを使うシチュエーションとして、そのプロジェクトの要求分析のフェーズでワークショップとして使う方法がある。プロジェクト・プロセスをキッチリ踏む仕事ではなく、ホントに起きていることを素早く共有するために使える。ホンネとタテマエを使い分ける必要がある場合、ホンネのやりとりに使う。

　もうひとつのシチュエーションは、プロジェクトの各リーダーが使う。営業、設計、開発製造、試験など、各リーダーがプロジェクト全体へ影響がありそうな話題を振ったり共有するために使う。メールを使った一斉送信だとどうしても一方通行になりがち。単なる通達ならそれでも良いが、各グループ間で調整
が必要となるネタだとメールでは不十分。

例えば「仕様変更におけるスコープ変更情報は、このサイトで一括周知・調整します」と宣言し、専用の場として扱う。正式な変更管理の業務フローに組み込む形でブログを使う。うまく回るようなら、

　　スコープ　→　スケジュール
　　スコープ　→　コスト
　　スコープ　→　リスク

と情報をつないでいけばよい。ここで初めてトラックバックが威力を発揮する。PMBOKでいう「あるフェーズのアウトプットは別のフェーズのインプット」がまさにこれだ。ブログ使うならスモール・スタートアップ。自分の小さな渦を広げてゆくつもりで。