プロジェクトマネージャーのためのチームビルディングあれこれ

このエントリーをはてなブックマークに追加
Facebook にシェア
Pocket
LINEで送る

受託開発ビジネスでは、案件ごとにプロジェクトチームを組みます。

プロジェクトに関わる時間が長くなると、次第にチームワークもよくなってきます。それぞれに得手不得手がありますので、自ずとチーム内での役割分担も決まっていきます。チームメンバーだけではカバーできない領域があるとチームの外に支援を求めるなどしてチームが回るように動き出します。

こうやってチームとしてのワークスタイルがてきあがります。ベースとなるワークスタイルが強化改善され、良いサイクルがはじまりよりよいチームへと成長していきます。

と、こう書くとチームを組んで仕事すればいいことだらけ、と感じるかもしれません。

しかし、上記のような「良いサイクル」が生まれるまでが大変です。そこまでいきつかずにチームが活性化することなくプロジェクトが終わることもあります。そのときのチームの生産性とか雰囲気は大抵よくありません。

良いサイクルを生み出すためにはチームの初期段階でのチームビルディングが重要です。チームビルディングには情緒的な要素も含んでおりメンバーの人間的成熟度も大きく影響します。それらを考慮したときプロジェクトマネージャーが重要視するべき点が2つあると考えています。

チームビルディングの2つのポイント

1.これならやれると思える計画を共有すること

システム開発は納期との戦いと言っても過言ではありません。そんなムチャなと思えるような納期が設定されている場合もあります。

プロジェクトマネージャーだってできることなら納期を延ばしたいと考えることもあるでしょう。どう考えても納期を守れないのであれば、できるだけ早くそのことを伝えリスケに走るべきです。

しかし、考え抜いた結果、これならできる!と(本心から)思える計画を立案できたのなら、その計画で推進するべきです。

但し、メンバーへの説明と納得が必要です。短いスケジュールに対しては、どんなに考え抜いた計画を示してもメンバーからは拒否反応がでるのが普通です。

メンバーは計画を聞いた瞬間に自分自身が具体的に作業しているシーンをリアルに思い浮かべます。そして様々な「できない理由」を言ってきます。

ここがプロジェクトマネージャーかチームビルドする絶好の機会です。

「できない理由」をひとつひとつ聞き、どうすればできるかを探っていきます。

プロジェクトマネージャーが気づかなかったような計画の破綻しているところをついてくる場合もあれば、単にリスクを多く見積もっているだけの場合もあります。

計画が破綻している場合は、素直に聞き入れて対策を織り込んでいきます。リスクに関する指摘なら危惧しているリスクを低減する方法と、リスクが現実のものとなった場合の対処を考えます。そのなかにはユーザーに掛け合って機能削減する、という対処方法もあるかもしれません。

こうやって「できない理由」をすべて根気よく解消(論破ではない)していきます。

ここで出た対処方法はプロジェクトマネージャーとメンバーとの間の約束事です。プロジェクトマネージャーは約束事を守らなければなりません。この約束事を守ることによってメンバーとの間に信頼関係が構築されます。

2.メンバーが暇なときは遅くまでやり、忙しいときはさっさと帰る

先ほど書いたように、プロジェクトマネージャーはメンバーと「約束」をします。

この「約束」は、各開発工程の前準備として手当てすることがほとんどです。必然的に開発メンバーが仕事のピークに入る前はプロジェクトマネージャーは忙しくなりますし、開発メンバーがピークのときはプロジェクトマネージャーは比較的余裕ができます。

といいますか、そのようにならないといけないのです。開発メンバーがピークのときにマネージャーも一緒になってバタバタしていては何かあったときにだれがプロジェクトをフォローするのでしょうか。

開発メンバーが遅くまで働いており帰りづらいと思っても、プロジェクトマネージャーはさっさと帰るべきです。プロジェクトマネージャーが力をいれるタイミングは別にあります。

以上、プロジェクトマネージャーのためのチームビルディング2つのポイントでした。少しでも参考になれば幸いです。

このエントリーをはてなブックマークに追加
Facebook にシェア
Pocket
LINEで送る

カテゴリーIT