読者です 読者をやめる 読者になる 読者になる

戦力を見抜く技術

プロジェクトをやっているとプロジェクトメンバのパフォーマンスはとても気になるものです。気にならないプロジェクトマネージャがいたらおかしいですよね。だって計画どおりに成果が出なくても困らないってことですから。

じゃあ、どうすればメンバのパフォーマンスを把握すればいいのでしょうか。

初めて一緒にチームになるメンバ

プロジェクトはいつも言っているとおり、同じプロジェクトは世の中に存在しません。いつも何かが違います。スコープ、リソース。そう考えるとメンバは人的リソースですからプロジェクトを左右する一つのファクターだ、と捉えることができますし、そう言った目線で見なければなりません。

何度か一緒にチーミングしたメンバなら気心も知れているし、どのくらいのパフォーマンスかを想定することができますが、初めてチームを組むメンバはそうはいきません。なぜなら、そのメンバのパフォーマンスに関する情報を持っていないからです。

計画の前提を明示的にする

チームのメンバには期待する成果を求めます。プロジェクトですからプロジェクトの達成すべき目的があって、定量的な目標があるものです。

それを達成するための、いつ、何を、どのタイミングで、アウトプットするか、が計画に記載されていなければなりません。

計画はプロジェクトの目的を実現するためのシナリオに当たるものですが、別の側面があります。それは、実績が計画どおりに出ているかを比較し、過不足している場合にはその原因を検証し、プロジェクトの目的を達成するために計画を変更する必要があるからです。

つまり、メンバのパフォーマンスをベンチマークする基準になります。

新メンバのパフォーマンスを計測する理由

初めてチームを組むメンバにはどれだけパフォーマンスが出るのかをプロジェクトに参画するタイミングで計測する必要があります。プロジェクトの参画のタイミングを逃すと、そのメンバのパフォーマンスが期待以下の場合に退場させるタイミングが作りづらくなります。

プロジェクトマネージャの仕事の一つの観点で言えば、パフォーマンスの出ないメンバはプロジェクトにいる存在価値はありませんし、そんなコストはお金をドブに捨てているようなものですから、さっさと止血しなければなりません。

あと、これを放置してしまうと、他のメンバに足らないパフォーマンスをカバーさせたり、別のメンバを入れたりする対策を打たなければなりません。なぜなら、パフォーマンスの出ないメンバを見ている他のメンバのチームへの貢献に悪い影響が出てしまうからです。

先行タスクでテストする

ということで、メンバに対して期待するパフォーマンスが得られるかを計測する必要があります。ここでどれだけやってもらえるかが把握できるかどうかで今後のプロジェクトの行き先が左右されるので大事に検証したいところです。

先行タスクでテストをしますが、テストは1ストライクアウトにしてしまうと他のメンバも同じ扱いをされると萎縮してしまわないようにすることと、テストする側の誤計測の観点から複数回した方が良いでしょう。よっぽどのことがない限りは。

テストするには基準が必要で、それと比較することがポイントです。決して雰囲気にごまかされたりしないように。テスト中のプロセスでのコミュニケーションや期待するアウトプットが得られているかを客観的に評価します。

極論を言えば、プロジェクトマネージャ的にはプロジェクトの目的のアウトプットが制約条件や前提条件上で得られればいいのです。とは言え、プロジェクトというチームで人がコミュニケーションをとりながら業務を遂行しなければならないため、プロセス上の問題がないかも目を配らなければなりません。

結論は、戦力かどうかは自分の目で何かしらの確証を持たなければ見抜くことはできません。ただ、キャリアシートなどの書きっぷりと質疑で当たりはつけられますけれど、確証を得るまでは安心はできないのがプロジェクトマネージャという生き物なのですよね。