ブログでプロジェクトマネジメントする10の方法

マーケティングツールとしてのブログが流行らしいが、開発現場のマネジメントとしてブログを使えないかという提案。イントラネットに閉じたローカルブログ導入のヒントとして自分メモでもある。

1.ステークホルダーのコミュニケーションツールとして

進捗報告やマイルストーン毎のレポートなど、プロジェクトでやりとりする情報はかなりのものだが、それらを全て一斉同報メールで送るのは大変かも～というのであれば、ブログが有効かと。

日報、週報、月報のような定期レポートだけでなく、随時更新されるリスクマネジメントリストや、毎時参照されるトラブルレポートも対象となる。更新するタイミングでステークホルダーにお知らせメールを送るのも簡単だし、RSSリーダで読むようにすれば、それすらも要らぬ。その際、以下のルール決めをして浸透させておく必要がある。

• どのタイミングで
  
• 誰の責任において
  
• どのような情報が
  
• 公開されるのか（公開してもいいのか）
  

2.紙媒体の代わりに

定型書式を定めても、「その帳票の見た目が定型」であって、元のテンプレートとはかけ離れたレポートに出会ったことがある。極端な例は「一文字一セルのExcel報告書」で、定型書式が原稿用紙のようなマス目を埋める形式あったため、利便性を一切考えないトンデモ書式がまかり通っている。

それは極端だとしても、テンプレートや格納場所を系列化する作業を、作り手からシステムで受け持つことができるブログは、見えにくいトコロの効率化を図ることができる。

　　　　　　　a) メールでExcel形式の報告書を提出
　　　　　　　b) 受信者が紙に出してファイリング
　　　　　　　c) その紙を見ながら勤怠管理システムへ手入力

…ってしてない? a,b,cさんが別人だから視えにくいけれど、トータルで視るとかなりの労力をブログというテンプレートで巻き取ることができる。

3.議論の自動ログ化ツール

プロジェクトでおきる議論（問題・課題などのイシュー）は、通常、メーリングリスト、報告書での言及、それに特化した報告書など、バラバラな形で提示される。話題に対し、いわゆる「まとめ報告書」などを作ればよいのだが、よほど大きなものでない限り書かない。

これはトラックバックを使うことによってトレーサビリティが格段に向上する。議論の流れや話者により断ち切られること無く「結論→元の話題」や関連する話題を参照することが容易になる。また、コメント機能により結論や次のステップをオーソライズすることができる（曰く、○○マネジャーがOKとコメントしたから）。普及したら「過去ログを嫁」が一般化するかもしれない(w

4.情報の断片をつなげ合わせる

そのプロジェクト固有の「暗黙知」といった情報（共通パスワード、業務用語一覧、コードのお約束 etc）は、訊いてはじめて出てくるものでなかなか「まとめ」の形で存在しないのが普通。これらを掲示してもらうことで情報を共有することができる。皆の断片を持ち寄ってナレッジベースを作ることは、 Wiki の方が有効かも。ナレッジはテキストに限定されないため、googleデスクトップ検索と組み合わせるとさらに強力になるかと。

5.プロジェクト進捗をガラス張りにする

プロジェクトマネジャーにとって有効なのだが、「このプロジェクトに関するあらゆる情報がこのブログにある」というルールが守られている限り、「便りがないのは良い便り」といえる。問題があるなら新着情報が new ! であふれているだろう。

これを守ってもらうためには「良いことも悪いことも上げる」ことを徹底させる。システム開発に限らず、悪いニュースを知らせる人を悪者にする風潮があるため、問題はなかなか表面化しにくい。プロジェクトマネジャーかシニアマネジャーが最初にキッパリと言い切ること「悪いニュースを知らせてくれる人を重視します」

6.メールの呪縛を解く

仕事にメールは不可欠なのだが、「そのメール」は本当に不可欠かというとそうでもない。ミソもクソも一緒くたに inbox に入ってくる。アドレス振分けもできるが「話題」「重要度」で振り分けることはできない。開けて から分かるのだから。おまけに長いccリストを見ると、ブログに投稿すればずっと楽になるのに、と思わないでいられようか。

メールを読むという作業の大部分を占めているのは「重要度」「緊急度」「話題」を順位付けすることだろう。ここでいう「話題」とは、自分の作業との関連性ととらえてほしい。inboxの新しい順に頭から添付ファイルまでじっくり読んでいる人はまずいないだろう。ブログを巨大な inbox と考えて、話題は全部そこで共有し、題名やサマリで重要度や緊急度を判断する。取るべきアクションがあり、かつ指示する「人」が明確になって、初めてメールを送るようにするのだ。

7.要望を吸い上げる

ネタ元の"10 waysto use blogs for managing projects"には、顧客要望を集め、ディスカッションする場としてのブログが提案されている。はてなが典型だが、プロジェクトに閉じたブログで考えるならば「改善要望をディスカッションする」アイディアが浮かぶ。通常は発言者を明確化して投稿・コメントするルールだが、例外としてanonymous （名無しさん）を設ける。そこでプロジェクトの運営の仕方やルールの改善要求を上げてもらうということができる（これがメールだと非常にやりにくいし、掲示板だと一行コメント一行レスで終わりがち）

8.画像や文書ファイルとの連携

メールを「仕事用データベース」として使っていないだろうか? 添付ファイルが主でメール本文をプロパティのようにして、全てのデジタル情報をメーラーで管理。さらにメーラーの検索機能を使うことで、ToDoブラウザのように使っている人はいないだろうか?

しかし、同一プロジェクト内で全員が同じ情報を同じように「添付ファイルを保存」しているのなら、ディスクのムダ使いというもの。個々人はそうした意識が無くても、プロジェクトチーム全体からすると、同じ情報をそれぞれのPCで保存・管理していることは結構なムダになるかと。ブログなら記事＋参照先で共通化できる。PCを使って仕事をする人は、自分のPCのディスクの面倒見はいいくせに、全体としてムダがないかという視点が欠けていると指摘されたことがある。

9.プロジェクトの情報を最新に保つ

「このブログにはプロジェクトに関する情報の全部がある」「Frontpage には全ての最新情報が一覧化されている」とすれば、ステークホルダーは必ずチェックするようになる。また、全ての記事には投稿者が記名されているため、その情報を常に最新に保つように動機付けられる。

10.追跡調査に役立つ

問題が予め問題の姿をとって現れればよいが、必ずしもそうではない。最初はよくある話題（見解の相違、情報の行き違い）だったのが大きな問題となってたち現れてきたとき、その初期症状までたどることができる。さらに、「不具合発生→原因解析→対策実施→解消確認」の4ステップは、一つのトラブルで括りつけられているが、実はそれぞれのステップで「他にはないか?」という視線が抜けている場合が多い。それぞれのステップで過去ログを検索し、関連するものはトラックバックを打つことでより有機的な関連づけを行うことができる

最後に。もちろんここに書いたのは元記事に触発されたアイディアであり、ネタや願望がかなり混じっていることを白状しておく。また、「それってそんなに昔でない以前に流行したグループウェア（死語）じゃねーか！」というツッコミは予め自分で入れておく。

--
ネタ元
10 ways to use blogs for managing projects

関連
using wikis inproject management
「ブログでビジネス」失敗と教訓