考えるのは当然(私も考えた)。いうツッコミを待つばかりだが、このプロジェクトは2005/2末に試用停止と至ったとのこと。目のつけどころは悪くないのだが、結局は器と中身の鶏卵話に落ち着く。優れた技術・サービスであっても、乗っかるコンテンツが流行らなければ、電源のないパソコンと同じ。今の仕事の業務分析が先だろうと誰も言い出せないまま始めちゃったんだろうねッ。「ビジネスブログブック」とゆー本が出ているようだが、マンセー厨房が沢山いるamazonにもかかわらず低め評価。順に渦を回していくのが成功パターン。個人→グループへライブラリ情報をシェアしていくとか。一人で使ってもでも便利だし、使っていない人も便利になる仕組みがポイント。management」。プロジェクトマネジメントでブログを使う際、注意するべきことが書いてある。ブログを使うシチュエーションとして、そのプロジェクトの要求分析のフェーズでワークショップとして使う方法がある。プロジェクト・プロセスをキッチリ踏む仕事ではなく、ホントに起きていることを素早く共有するために使える。ホンネとタテマエを使い分ける必要がある場合、ホンネのやりとりに使う。各リーダーがプロジェクト全体へ影響がありそうな話題を振ったり共有するために使う。メールを使った一斉送信だとどうしても一方通行になりがち。単なる通達ならそれでも良いが、各グループ間で調整が必要となるネタだとメールでは不十分。「仕様変更におけるスコープ変更情報は、このサイトで一括周知・調整します」と宣言し、専用の場として扱う。正式な変更管理の業務フローに組み込む形でブログを使う。リスクと情報をつないでいけばよい。ここで初めてトラックバックが威力を発揮する。PMBOKでいう「あるフェーズのアウトプットは別のフェーズのインプット」がまさにこれだ。ブログ使うならスモール・スタートアップ。自分の小さな渦を広げてゆくつもりで。答えが見つからないときは、問題を変えてみよう。(哲学はなぜ間違うのか)本は読まなくても書評を書くことはできる。