« 2005年6月5日 - 2005年6月11日 | トップページ | 2005年6月19日 - 2005年6月25日 »

Wikiでプロジェクトマネジメントする4つの方法

「ブログでプロジェクトマネジメントする10の方法」への反応を見ていると、独り考え込むのでなくUPしてみるものだな、と思った。実務に適用している例や、Wikiでの試みがあることを知った。言及していただいた皆様、ありがとうございます。賛否ともども大変参考になり、中の人は感謝多謝することしきり。

  Wikiを発展させた開発支援コラボレーションツールMrkrgnao(via:marsのメモ

  Wikiを使った「Web向けLotus Notes」Jotspot(via:関心空間ラボ

  社内限定の非公開型ブログイントラブログ

さらに、「Wiki との優位性が見えない」「ストレージサービスでええやん」というコメントがあったが、そのとおりだと思う。実際、前のプロジェクトでは Wiki+CVSで「設計書+コード管理」してたし。時系列に情報を積み重ねるのがブログなら、Wikiは樹構造的な展開に向いている。各人のPCのディスクを圧迫している共有情報を吸い上げる装置がブログなら、ストレージは一定のまとまった情報(RFPや設計書)を最初から一括して保管しておくのに良いかと。

ま、大切なのは道具ではなくいかに使うか(使えるように仕向けるか)なんだろうが、ここではWikiでマネジメントする方法をご紹介。例によってネタ元はFour ways to use wikis for project managementであることは秘密だ。このブログはPMにオススメなのだが、中の人の自己紹介"Hire Us!"(雇ってください)を見るたびに「さきっちょの就職日記」を思い出してニヤリ

1.有機的なアジェンダ

事務局はアジェンダ(会議事項)の一覧までは作成するだろうが、個々の詳細はプレゼンする担当しか把握していないはず。どうするかというと、アジェンダ一覧をステークホルダー全員に送りつけて、「関連する担当は当日までに資料を作成しておいてください」と依頼するわけだ。

当然、会議当日まで、資料がどんな内容なのか「題名」以外は知る由もなし。よしんば事前配布だとしても、Excelやらのデカいファイルが「全員に」メールされるのだ(訂正される場合も、全員に同報される)。同じ資料が幾度も同報されるのを見ていると、全員のinboxを破裂させたいのかとウンザリ。

これをWikiで解決するなら、アジェンダのURLで周知。資料作成の担当はファイルをUPすればヨロシ。更新のたびに同報されるのはテキスト文のみ。事前に目を通しておきたいならご自由に。「更新が許されるのは会議前日まで」なら、その日に事務局がロックすればOK。

2.リアルタイム議事録

良いプロジェクトの条件として「会議は少なく短く」があるが、プロジェクトマネージャにとって必要不可欠なもの。「誰が何を発言し」「何がどう決まり」「次にどうするか」は会議が終わった直後に即座に共有したい情報だ…が、現実は議事録をシコシコ書いて→一斉同報→「ここが間違ってる(抜けてる)ぞゴルア!」とお叱りを受けて訂正→一斉同報を全員が飽きるまで繰り返す。

これは、1.のアジェンダに対し、それぞれの議題に対し議事録を書き込めるようにすれば解決する。議事録を受け持った人がドラフトを書いて、あとは出席者が好きに訂正すればよい。訂正内容は即座に全員の目に触れるため、「言った/言わない」も少なくなろうかと(願いたい)。Wikiの履歴を使えば、誰がどのように直したのかも追える。1.2.は少人数だとありがたみが薄いかもしれないが、デカい会議だとラクできる。

3.ブレーンストーミングツールとして

複数人でブレーンストーミングする際のプレゼンテーションツールとして使える。ネタ元は簡単にできるような口調で書いている…私はWikiの実力が分かっていないので、どれぐらい難しいのか(あるいは簡単なのか)は不明。そのまま紹介すると↓

共同でプレゼンの準備をするのは大変だ。特に複数で一つのコンテンツを同時にいじくろうとするとき、バージョン管理がやっかいとなる。
このとき、パワーポイントの代わりにWikiでやってみてはどうだろうか。Wikiなら追加も変更も簡単にできる。パワーポイント形式にエクスポートできるWikiのプラグインがある。レイアウトテンプレートを適用し、クリップアートを追加すればプレゼン準備は完了だ。
さらにパワーポイントを離れ、Wikiページそのものをプレゼンテーションにつかえないだろうか。その優れたページフォーマット機能を使えば、ブラウザからそのままプレゼンすることができる。

ステイツの方のプレゼンテーションを見る限り、確かに彼らのスライドは「メッセージ+黒い人の画像」が圧倒的(コンサルタント会社が作る美麗なやつは例外)。ネタ元の中の人はイギリスの方だが似たようなものだろう。だから↑のような使い方が可能。しかし、日本だと表やらグラフやらマンガ(しかもオリジナルなやつ)が一枚のスライドに盛りだくさんなので、向いていないカモ。

ブログと異なり、Wikiは「あとで直す」「誰かが直す」ことを想定しているため、時空間が隔たったメンバー同士のたたき台(というかたたき場所)として有効。アイディアを出し合う「しゃべり場」だね。具体的にはデルファイ法でスコープ、見積もり、リスクリストの洗い出しをするときに使える。

4.常に最新のドキュメントにする

共有ドライブにドキュメントを保存するのではなく、Wikiで管理する。バージョン管理機能を使えば定型的な変更管理はラクになる…が、ちゃん「お守り」をする人を充てておかないと風化する恐れが。なまじ簡単にはじめられるので、忘れ去られるのも簡単になる可能性が。Wiki によるマネジメントの成功パターンは、


  • プロジェクトマネージャが使う(絶対条件)
  • 入口はFrontpage限定(ただし全業務いきなり移すのはムリがある。まず進捗会議や仕様変更管理に限定する)
  • 「お守り役」が必要(全体責任は無責任)
  • 「共有情報を載せる」のであり「情報を載せて共有しようとする」のでない(via:swat_memo

渦は自分で起こせ。まずはスモールスタートで。

| | コメント (0) | トラックバック (5)

ブログでプロジェクトマネジメントする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
「ブログでビジネス」失敗と教訓

| | コメント (4) | トラックバック (6)

マッキンゼーITの本質

ここしばらく開発現場を離れ、「こんさるたんと」のお手伝いをしている。そこでマッキンゼーの中の人と仕事をしているのだが、奴らはスゴいの一言に尽きる。激務という言葉はまさに奴らのためにある。

たしかに、私も佳境に入ると夜討ち朝駆け徹夜仕事になる。システム屋は盆と正月こそ稼ぎ時だ(悲しいけどこれ現実)。しかし、奴らの場合はそれがデフォルトで、言葉どおり休みがない。「オレも休みなんてずいぶんもらっていないよ」と言いたい人は沢山いるだろうが、もう何年も一日たりとて休んだことないよという人はいないだろ。でも奴らはそれが普通。24時間戦えますか?(死語) もちろん、という連中

だから奴らは、通勤時間を惜しんで六本木や新宿にマンションを買っている(←激務に見合うだけ給料もハンパじゃないといっておく)。まぁマッキンゼーですら一つのステップで、激務の見返りにノウハウやパイプを吸えるだけ取って独立するつもりで身を粉にしているわけだし。

じゃぁその論文「マッキンゼーITの本質」もスゴいのかというと、そうでもない。とっぴなことは一切書いていない。膨大なデータを元に「仮説→検証→仮説→検証」の議論を反復した結果がこの本。サブタイトルの情報システムを活かした「業務改革」で利益を創出するうたい文句に偽りはないが、実行するには経営者の鉄の意思を要する。まさにマッキンゼーのやり方。

ITへの投資とリターンについて悩むエライ人が読むと、ああやっぱりな~と身につまされること請け合い。社畜が読んでもタメになるのは第1章。ITによる課題解決が何故うまくいかないのかと、その処方箋がまとめてある。自分のプログラムは完璧なのに、業務システムのレベルになるとどうして上手く実装されないかがよく分かる。

■IT課題解決を阻む5つの理由

1.ITの企画・推進に関するアカウンタビリティがない

CIOが具体的に何をする人で、何に対する責任を有するのかを明確化しないまま、CIOに命ぜられている。ぼんやりと「社内のITシステム全般について責任を有する役員」というあいまいなミッション定義のまま、IT便利屋の窓口になっている。
IT投資の企画における目標設定は誰が行うのか? 要件定義やプロジェクト管理はどの部門がどのように行うのか? 業務改革を含めた新システムの現場への定着はどの部門がどのような責任と権限で推進するのか? こうしたアカウンタビリティが存在しない。

2.目標がQCD(quality/cost/delivery)の面から定められていない

ITで業務を変えようとする際、最終的にどう変えたいのかが明確になっていないまま「システム改善」が着手されている。顧客満足度などの業務アウトプットの品質(quality)なのか、労働総量・残業代や不良在庫削減などのコストカット(cost)なのか、業務処理の時間短縮や顧客リクエストの迅速対応(delivery)なのかぼやけている。
いつまでに何を達成しなければならないのかが曖昧なままだと、それを「どう」達成するのか(=システムに何を求めるのか)は絶対に明らかにならない。

3.外来語をわからないまま受け入れる

オープン化、ERP、CRM、EA、SOAなど、何かいいことがありそうだが具体的に突き詰めてみるとよく分からないまま意思決定をしてしまう。その結果、ふたをあけてみれば「そんなつもりじゃなかった」という台詞が双方から聞かされることになる。
ITベンダーが提案するソリューションは、経営・業務の観点からするとただのツールでしかない。何のためにどのような道具が最も有効か、議論をつくす必要がある。

4.ベンダーとの協働がうまくできない

法律なら法律事務所、会計なら会計士事務所があるが、ITには背景に法・規制を伴ったルールが存在しない。さらにITエキスパートは開発業務を請け負うベンダーであることが多い。その結果、エキスパートといいながら仕事を請け負う立場としての遠慮から、顧客企業の指示や要望に従う下請けになりがち。

5.システムの完成が目的化し、成果や構築プロセスがなおざり

システム開発にまい進しているうちに、予定通りのカットオーバーが目的となってしまい、完成したシステムが実際に役立っているかを確認・検証する機会が忘れ去られている。ユーザ企業のIT投資・推進におけるPDCAサイクルが絶たれている。

■6つの処方箋

1.ITコストの可視化

自社がどれぐらいの資産を有し、どこにいくらのコストがかかっているかを可視化する。いわばITバランスシートを作成することで、どこに優先順位がつけるべきについて、現場担当レベルではなく、経営者が判断できるようになる。ITバランスシートは開発費、運用費だけでなく、ライセンスコストや稼働率も考慮して作る。

2.CIOをコアにした議論の場

システム単体を取り上げて事業への貢献を議論することは無意味。システムも含めた業務改善が事業にどれだけ貢献したかについて考えるべき。

3.PMOによるチェック

狭量になりがちな情報システム担当ではなく、PMOに第三者的なチェック視座を設けることで、システムの企画段階からIT投資・運用の効率性を経営者がチェックすることができる。

4.ユーザ部門のノウハウ集積

ファーストリテイリング(ユニクロ)の例。情報システム部ではなく、業務システム部を設け、主業務のプロセス担当者を置き、その担当者が業務改善を企画し、一環としてITの企画・導入・運用を行っている。

5.事業の本質に根ざしたIT戦略

全体最適されたIT投資を行うため、その目的・コンセプトを明確化する。次に、事業の生産性・収益性を向上する最大のレバー(梃子)は何か、その向上のために業務を、組織を、どう変えるべきかについて検証する。

6.ベンダーとのwin-win

仕様確定などベンダーとの共同作業を重視する。そこまで議論してきた業務フローなどの本質を理解できないままなら、いくら要件定義を緻密におこなっても似て非なる代物になるだけ。すべてをさらけだすつもりでベンダーを取り込むことで、システム改善の「肝」を腑に落ちてもらう。

なんてあたりまえな…という印象をもたれたかと思う。アタリマエなことがあたりまえにできていないことが問題なのだが、翻って私はどうかと。経営者の視点ではなくとも、分析の基本であるMECEやロジックツリーをやっているか? 否とよ。そこいらのHowTo本で分かった気になって、ちょっと使って上手くいかないとすぐに「MECEは現場離れしていて使えない」と断定。恥ずかしい限りだ。

一方、マッキンゼーの中の人は本当に使う。定石どおりに使うというよりもむしろ徹底的に使う。徹底的に使うとは、人が1時間考えるなら10時間考えてきている。だからプレゼン中に思いついただけの反論にもびくともしない。反論への反駁も準備万端(つまり客を不快にさせないように反駁するところまで考え抜いている)。

最後にネタばらし。マッキンゼーの中の人とはいっても、コンサルタントやプリンシパルだけがスゴいのではない。奴らの後ろにデータ解析屋がいて、パワーポイントの猛者がいる。彼らがスゴいのだ。莫大なデータをひたすらピボットテーブルしまくって傾向→対策を洗う解析屋。出てきたアウトプットを見栄えのいいストーリーに仕立て上げるパワーポイントマスター。彼らのおかげでコンサルタントはひたすらコンサルタントができる。マッキンゼーのプレゼン術なるHowTo本が書店にあるが、奴らのパワーポイントファイルを読んでみるだけでいい。そのスゴさ(あたりまえのことを徹底的に積み重ねること)が良く分かる。

| | コメント (3) | トラックバック (3)

« 2005年6月5日 - 2005年6月11日 | トップページ | 2005年6月19日 - 2005年6月25日 »