![]() ![]() ![]() ![]() プロジェクトの進捗状況報告書は必要かこの記事のURLhttp://japan.internet.com/busnews/20070525/6.html
著者:Eric Spiegel
海外internet.com発の記事
邪悪な状況報告書
「彼は実にマイクロマネージャだ!」 チームのメンバーの一人から発せられた驚きの声は、社内中に人づてで伝わり、私は自分ではけっして意図していなかった種類のマネージャというレッテルを貼られた。何が間違っていたのだろう。私がマイクロマネージャ(細かいことをいちいちチェックするようなマネージャ)だなんて、絶対ありえない。私にはありえない。 私はチームメンバーにすべて任せているし、仕事に対して敬意を十分表している。いつも時間を取って仕事を課し、期待する目標を設定し、プロジェクトを成功させるのに必要な資料を何でもチームに提供している。その後、私が“マイクロマネージャ”と分類されたのは、各チームメンバーに週刊の状況報告書を提出するように求めた後だったことがわかった。 何か間違ったことをしたのだろうか。マネージャは誰だって、状況報告書を求めるものではないのか。成果を達成するまでどの程度進んで、皆がどのような働きをしているのかを、どのように知ればよかったのか。 私は必ずしも様子をチェックするのに状況報告書を使っていたのではなく、チームのメンバーが自分の仕事の進み具合を自慢する手段としてみていた。振り返ったときに、改善できたり、際立った成果を上げられた分野を簡単にみつけるために使うこともあった。しかし、誰もが同じように思うわけではなく、時間の無駄だと感じていたようだ。 簡潔に行う 企業で初めて状況報告書が必要になったのがいつかは定かでないが、初期の頃はおそらく口頭で、次に手書きで、次第にタイプライターを使って書くようになり、こうして少々時間のかかるものになっていったと推測する。しかし、時は経ち、標準の状況報告書を作るのに必要だった労力が、Eメールの出現で効率化された。マネージャは標準テンプレートを提供するだけ、チームメンバーは進行中の仕事、これからしなければいけない仕事、問題などを空欄に埋めればそれで終わり。状況報告書が次々に出来上がり、数分間で配られる。 短く簡潔にすれば、週刊の状況報告書はそれほど時間がかからずに有用なものになる。「予定通り仕事は進んでいる」といったよくあるコメントではなく、新たにリスクができたなどの例外に目を向ければいい。状況報告書は、すでに知っているはずのことをきちんと把握しているかどうかを確かめ、理解違いが起きないようにするために最低限使えばいいのだ。 またチームメンバーに、1週間何が起こったのかを腰を据えて考えてもらえるという利点がある。どんな活動をしたのか簡潔にまとめようと、集中して努力しない限り、適切な注意が向けられなかったかもしれない課題を表面化できる。 本当に達成できたものは何か 「状況報告書から何が本当にわかるのか」という疑問がまだあるだろう。マネージャとしてどんな問題が起こっているのかは、把握しているはずではないか。 第一線のマネージャとしては、もちろんチームと日常的にやり取りをし、把握しているはずだ。大きな問題を週の終わりに報告され、驚いたとしたら、プロジェクトで起こっている大事なことに通じていないことになる。 では遠隔の営業所にいるマネージャはどうなのか。複数のプロジェクトの予算や時間に影響を与えるような大きな問題について、CIO はどうやって知ることができるのか。またはプロジェクトの事業主は、どのように大きな問題を知り、予定通り進めろという要求を譲歩することができるのだろう。「大きな問題」という語を使ったことに注意してほしい。トップの IT マネージャやビジネスマネージャは、こまごましたことに首を突っ込む余裕などないのだから。 したがって、仕事の状況や大きな問題は、チームリーダーやマネージャが他の営業所に伝え共有すべきだ。プロジェクトのポータルを使って、注意が必要な仕事を緑、黄や赤でマークする、単純に重要な問題や新しいリスクに別のページを用意するなどすればよい。別の方法としては、プロジェクト管理ツールを使って非常に簡潔な報告書を作り、目標達成までどの程度進んでいるかを示したり、大きな問題のリストを作ったりするといい。 そうかもしれないし、そうではないかもしれない 一方、時代はおそらく変化し、状況報告書は企業の効率性の名の下に、過去の遺物となっているのかもしれない。現在のネット社会では、問題が起きたときにチームのメンバーが投稿できるよう、個人でプロジェクト Blog を立ち上げたり、プロジェクトポータルを使ったりというのが、代替策になるのだろう。企業というチェーン店の誰もが、中央の1か所で同じ“状況”を確認できるようにする。 この場合の問題点は、フィルターがないために、上層部が誤解して問題に過剰反応してしまう恐れがあるということだ。混乱と間違った意思決定を招くだけの不適切な(あるいは間違った)情報でごちゃ混ぜにならないように、コントロールときちんとしたプロセスが必要だと考える人もいた。 最初の質問に答えて締めくくりたい。プロジェクトチームのメンバーにとって、状況報告書は常に邪悪なのだろうか。私の結論は、マネージャとしてプロジェクトに責任があるということ。誰かが失敗したら、結局はマネージャの責任になり、だから、何が予定通り進んでいて何がそうでないのかをきちんと把握しておく必要がある。 したがって、Blog だろうが、口頭だろうが、文面だろうが、チームメンバーには仕事の状況をタイムリーに伝える責任がある。とんだびっくりに陥らないためには、口頭と書面の両方で常に状況報告を行う以外ないのだ。 どうか遠慮なく、形式ばらない方法でやってみるといい。だが、もしその方法ではっきりと伝わらない場合、おそらくある意味のマイクロマネージメントがふさわしいのだろう。私はこれを責任のあるマネージメントだと思うのだが。 これからスタッフの仕事の状況を確認してくるので失礼する。 |