参考URL:https://pixabay.com/
プロジェクトマネージャーの仕事は、クライアントとの打ち合わせ、工数や予算の提案、開発メンバーの工程、スケジュール管理、納品物の品質担保、などです。しかし、これらの業務を機械的に行えばプロジェクトマネージャーの仕事は完璧、というわけではありません。
プロジェクトマネージャーの下に付いているのはシステムエンジニアやプログラマーで、システムではなく人間です。たしかにプロジェクトマネージャーはExcelとにらめっこしたりWordで書類を作る作業が多いのですが、その先にいるのは人間で、特に開発メンバーへの配慮は不可欠と言えるでしょう。
システムエンジニアやプログラマーが相手にしているのはシステムなので機械的に割り切って作業することが重要ですが、プロジェクトマネージャーの場合そうはいかない、むしろ人と向き合っている意識がプロジェクト成功のカギを握っていると言っても過言ではないでしょう。
そこで今回は、プロジェクトマネージャーに求められるメンバーのケアスキルについて解説します。
まずはプロジェクトマネージャーの意識改善から
プロジェクトマネージャーの多くは、システムエンジニアやプログラマーから出世して今のポジションに付いています。そのため、ITスキルについてはエンジニアやプログラマーよりも高いケースが多く、当然業務に役立ちます。
しかし、実はここに落とし穴があるのです。プロジェクトマネージャーは管理能力だけでなくITスキルや業務知識も一定以上身に付いているため、個々のシステムエンジニアやプログラマーが理解できていないポイントを見落とすことが多いです。
悪気なく、「担当ではなくプロジェクトマネージャーである自分が把握しているのだから、システムエンジニアやプログラマーも自分の担当分は把握しているだろう。」と考えてしまうのです。
プロジェクトマネージャーがぱっと見で設計やソースコードを理解できても、システムエンジニアやプログラマーが同様に理解できるとは限りません。たしかにシステムエンジニアやプログラマーは自分の担当分を割り当てられて作業していますが、特に経験が浅いと自分の担当分を理解できていないケースがあるのです。
プロジェクトマネージャーの仕事はタスクやスケジュールの線を引いて終わりではないので、開発メンバー個々のスキルや状況を必ず把握する必要があります。把握自体は意識していればできるので、まずは意識改革からです。
自分がわかるのだから担当者はもっと理解しているだろう、という推測はNGです。
仕様やロジックはなるべくメンバーの口から説明してもらう
プロジェクトマネージャーはシステムの全体像はもちろん、個々のパーツについても担当者よりも深く理解しているケースが多いです。もちろん作業の進捗やバグの状況などは担当者本人にしかわからないのですが、そのパーツの役割やロジック、設計に関してはプロジェクトマネージャーの方が理解していると考えられます。
その結果、設計やソースコードを見てプロジェクトマネージャーが一方的に話してしまうことが多いのです。しかし、プロジェクトマネージャーが一方的に話すだけだとメンバーが理解できていない場合があり、よくわからないまま仕事を割り振ってしまうことがあります。
これは担当者自身にとっても辛いですしプロジェクトの進行にも悪影響なので、設計やロジックに関して共通認識を確認する場合等は、なるべくメンバーに説明してもらうようにしましょう。
そうすることでメンバーの理解確認になり、プロジェクトマネージャーとしても「このメンバーはどこがわかっていないのか」ということが一目瞭然になります。人に説明できない設計やコーディングを行うべきではありませんし、人に説明できれば設計もコーディングも半分できたようなものです。
なぜなら、日本語で話した内容を設計やプログラミング落とし込むだけだからです。いわゆるアルゴリズムをなるべく口頭で話してもらい、メンバーの理解を深めましょう。普段からこれをやっていると、いざメンバーが詰まったときにもプロジェクトメンバーに質問しやすくなります。
普段から説明の練習をしていないとうまくできませんし、メンバーの性格が内気だと尻込みしてしまうかもしれません。プロジェクトマネージャーとしてはなるべくメンバーが説明の練習をする機会を与え、その後自発的に相談しやすいコミュニケーション能力とメンタルを育んでもらいましょう。
メンバーが自発的にコミュニケーションできる土台を作ることは、強力なメンタルケアにもなります。チームで動いているのにコミュニケーションがうまく取れないと、当然働きにくくなります。
なので、メンバーが積極的に話せる能力と雰囲気を普段から作っておくと良いです。
仕事外のコミュニケーションを図る
参考URL:https://pixabay.com/
業務中はプロジェクトマネージャーと開発メンバーがコミュニケーションを取りますが、これはあくまでも仕事のためのコミュニケーションで、仲が深まるわけではありません。また、プロジェクトメンバーの方が立場が上なので、開発メンバーは多かれ少なかれ気を遣っていたり、場合によっては萎縮しています。
そのため、業務でのコミュニケーションを図るだけだとプロジェクトリーダーとメンバーの仲が深まらないのです。仲良くなる必要はないと考えるプロジェクトリーダーもいるかもしれませんが、ある程度仲が良い方がプロジェクトは円滑に進みます。
プロジェクト期間中はメンバー間やメンバーとプロジェクトリーダーの間で頻繁に業務連絡を行いますが、そのたびにメンバーが「プロジェクトリーダーは自分のことをどう思っているのだろうか。ムッとしていて怒っているのかもしれない。自分の説明の仕方が悪くてあきれているのではないか。」といったネガティブな感情を持っているかもしれません。
実際こういった事例は多く、感情がうまくかみ合わないままメンバーが無駄に心労を抱えている様子を外部から私は頻繁に見てきました。プロジェクトリーダーがプライベートな会話が苦手だったりメンバーが人見知り過ぎたりといったことはよくあるのですが、なるべくコミュニケーションを図った方が良いでしょう。
多少無理にでもランチに行ったりして、場合によっては飲み会なども開催した方が良いかもしれませんね。私自身プロジェクトマネージャーをやっていた頃には、「毎日仕事で会っているしわざわざ外に誘わなくてもいいかな。誘ったら予定を押してでも来る人が出てきて、迷惑になるかな。今の時代みんなプライベートを優先したいだろうし飲みにケーションなんて死語かな。ランチは弁当派の人もいるから外に食べに行く雰囲気を作ると苦痛に感じる人がいるかもしれない。」といったことを考えて、あまり誘わないこともありました。
しかし、思い切って誘ってみたところ何でも話しやすくなり、結果的にプロジェクトが円滑に進むようになったことがあるのです。夜空いている人や昼は弁当を持ってきていない人だけ参加する形で、強制もしないし、半強制のような雰囲気にもしない、という点には注意しましたが、自由に参加したい人だけ参加できる空気になりました。
プライベートの集まりは毎回強制ではなく各メンバーが気が向いたときに自由に楽しく参加できる雰囲気作りが重要で、それができればプロジェクト内が非常に良い雰囲気になることを私は体感しました。
私が普段そういった集まりを開催しなさそうなタイプだからギャップ効果が働いてうまくいったのかもしれませんが、適度にプライベートの交流を持つこともメンバーのケアとしては重要だと思います。
もちろん公私混同して仕事にメリハリがなくなるのは問題ですが、まったく交流しないのもプロジェクト内の雰囲気が良くならないので、適度にプライベートの交流も取り入れると良いですね。