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

CNET Japan ブログ

プロジェクトの情報リソースとしてwikiを使う

2008/10/13 13:49
  • このエントリーをはてなブックマークに追加

プロフィール

山田ひさのり

私がプロジェクトマネジメントを実践したり学習したりしていく中で、ためになった考え方やノウハウを紹介していこうと始めましたが、その後ケータイ/ソーシャルビジネスを中心の情報発信に変化しました。暫くの間更新が滞っていましたが、私の転職をきっかけにグロースハック/ハッカーの情報を発信するグログとして投稿を再開しました。
ブログ管理

最近のエントリー

今回からしばらく、私がプロジェクト管理で実践してきたボトムアップ・アプローチを紹介したいと思います。最初はプロジェクト規定のwikiでの共有化について紹介します。以後の文章で「プロジェクト」や「メンバー」と書いた場合は顧客を含めた表現であると理解して下さい。

私はプロジェクトにおける様々な規定を顧客と共有しているwikiにUPするように心がけています。プロジェクトの規定とは(顧客を含めて)プロジェクトを進行するに当たって定められた様々なルールとなる文章のことです。記述する内容としては(私の場合)以下が主です。

  • プロジェクト体制図
  • プロジェクト連絡フロー
  • プロジェクトの主なマイルストン
  • 製作物の要件・仕様
  • 製作物の非機能要求
  • 進捗管理表

運用系も含める場合は以下も追加します。

  • プロジェクト運用フロー
  • 定例MTG開催ルールなど
  • 不具合管理表
  • リリーススケジュール

※wikiの文章で表現できないものはPowerPointやExcelのファイルをwikiに添付します。

プロマネの経験がある人はわかると思いますが、上記はプロジェクト管理において用意される一般的な文章にすぎません。私はただその文章を顧客と共有されたwikiにUPしているだけです。ではこれの何が有効かというと、「そこを見れば情報が必ずある」という事実です。プロジェクト管理上のドキュメントは社内で厳格に管理され、顧客とメールベースで共有されているプロジェクトは世の中に多いと思います。管理上のドキュメントを作るところまでは私と同じなのですが、そのドキュメントをメール(もしくはメーリングリスト=ML)ベースで共有するという点に私は疑問を持っていました。

プロジェクト進行していると社内、社外にかかわらず人員の追加や入れ替えはよくある話ですが、私のプロジェクトではその度に「過去のメールを送ってくれ」という要望が来ていました。私の会社にはMLに投稿されたメールを検索・参照できるシステムが全社向けに用意されているため、これあ社内の場合はそこから必要なメールを検索してもらうことが可能なのですが、社外の場合はそうは行きません。特に顧客側の引継ぎがずさんな場合などは、新しい担当者から「過去のやり取りのメールを一式送ってくれませんか」などのよくわからない依頼があることもしばしばです。その場合、メールを探すのも一苦労だし各担当者が(原則禁止なのですが)私信のメールでやり取りをしていた場合はもうお手上げです。

そこで私はプロジェクトにおいて決定されたことを全てwikiにUPし、そのwikiを顧客と共有するようにしました。つまりプロジェクトにおける規定物のやり取りをwikiベースに変えたのです。規定物をwikiで共有するメリットは以下です。

  1. プロジェクトにおける人員の追加や入れ替えの時に掛かるコストを最小化できる
  2. 「wikiを見れば全てが載っている」という共通意識をプロジェクトメンバが持つようになる

実はメリットはこれだけです。細かいことを言い出すと他にもありますが突き詰めればこの程度だと思っています。しかしこれこそが重要で特に 2. の効果としてプロジェクトで最も信頼できる情報リソースとしてwikiが認知されます。つまり全ての営みがwikiを中心に行われえるようになるので、例えばプロジェクト運営において何か新しいルール発生したり、実装物の仕様が変更されると「wikiを変更しよう」という気持ちになり情報リソースの集約と更新性が保たれやすくなります。しかしこれがMLだとそうもいきません。情報リソースがMLである場合「情報の集約」という概念が希薄なため、「更新性を保とう」という発想に結びつき難いのです。wikiという誰もがいつでもどこでも見れる手段があるからこそ、情報の健全性を保つ努力を誘発するようです。

もちろんwikiでの共有化は私の1アイデアに過ぎず、情報の健全性を誘発する手段であれば何であっても構わないと思います。

最近はwikiの普及が一般化したので、もしかしたら社内でのプロジェクト情報の管理はwikiで行っている会社が少なくないかも知れません。私も以前は社内でやり取りされる情報についてはwikiを使って管理していましたが、ある時「これって顧客も巻き込んでしまえばいいのでは?」と思い立ちました。もちろん社内の守秘義務上顧客に見せることのできない情報もあるため、共有するwikiでは厳格なアクセスコントロールをするか、社内用と社外用の2つのwikiを用意するかを行う必要があります。

ちなみに弊社では後者を採用しています。前者が良いという意見もありましたが、前者の場合間違って社内用の情報を社外に公開してしまうリスクがあったため、社内用と社外用のwikiを明確に分離し、それぞれwikiのスキンを変えて誤記述を防ぐようにしています。

wikiの導入は私考えた以上に情報の集約を促進しました。もちろんプロジェクトメンバの追加や交代による引継ぎコストも0に近くなりました。「情報の集約先をMLからwikiに変えただけ」にも関わらずプロジェクト運営が健全化したため、かなり低いコストで高いメリットを享受できたと実感しています。

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

最新ブログエントリー