プロジェクトマネジメントを行っていく上で、プロジェクトメンバーとの関わりは避けられないものであり、メンバーに適切に動いてもらわなければ、プロジェクトは上手く稼動していきません。
そういった意味で、マネージャーとメンバー同士がいかに連携をとってプロジェクトを進めていくかは大きな課題であり、そこを解決できれば、プロジェクトが順調に進む可能性も高くなります。
プロジェクトが上手くいかない場合の、本質的な要因は何なのかなども含めて、現場目線も交えながら、その具体例を紹介していきます。
頭では理解していても、なかなか取り組めないケースもあるかもしれませんが、本記事を参考に、改めてマネジメント手法を見つめ直していただくきっかけになれば幸いです。
目次
1.プロジェクトのトラブルの原因は対人関係にある
プロジェクトのトラブルにはさまざまな要因がありますが、対人関係に起因するものも少なくありません。
しかし、プロジェクト経験が浅いマネージャーの場合、このような実状を正確には把握できていないこともあります。
問題点や進捗状況を正しく理解するためにも、プロジェクトマネージャーはメンバーが自由に発言することができるように、開発チームの中に、一定程度はミスや間違いを許容するような雰囲気作りをすることが大切です。
(もちろんミスの程度にもよるので、すべて許容するということではありません)
また、プロジェクトメンバーの性格を見極めてマネジメントを行っていくことも大切です。
2.プロジェクトが赤字だった場合の本質的な要因を理解する
プロジェクトマネージャーの力量によって、プロジェクトの成功は左右されると言っても過言ではありません。
まず、マネージャーは、小さなトラブルほど慎重に対応することが大切です。
当然ですが、トラブルに適切に対応しなければ、プロジェクトは赤字となってしまいます。
IT企業の経営においては、プロジェクトの収支管理が難しい部分もあります。
プロジェクトの正確な収益は、プロジェクトが終了しないと分からないこともあります。
当然、プロジェクトマネージャーは、プロジェクトが黒字になるように、予算管理、進捗管理を行ってマネジメントします。
しかし、例えばシステムのテストレベルにおいて、基本的な設計に立ち戻るような手戻りが発生すると、納期の遅れを縮小するために、お金や人員をつぎ込むことになります。
そうなれば、プロジェクトは一気に赤字となってしまいます。
そうは言っても、大きな手戻りが必要なトラブルはそれほど多くはありません。
しかし、小さなトラブルはよくあります。
小さなトラブルの対応を適切に行わなければ、納期や品質に少しずつ影響が出てきて、最終的にプロジェクトが赤字になってしまいます。
プロジェクトが赤字になった要因をプロジェクト終了後に分析してみると、品質管理が十分ではなかった、見積もりが甘かった、などといった理由がいくつか出てきます。
しかし、このような理由が本質的なものではないことも往々にしてあります。
同じプロジェクトメンバーで似たような規模のプロジェクトであっても、優秀なプロジェクトマネージャーが行うと、きっちりと黒字になることもあります。
つまり、プロジェクトが上手くいかなかった原因が、対人関係に起因している部分があるという見方もできます。
見積もりが甘かった要因は、技術者と営業担当の対人関係の問題ということもあります。
品質管理が十分でなかった要因は、プロジェクトマネージャーと技術者の対人関係の問題ということもあります。
要因を技術的な問題として、わずらわしい対人関係の問題ではないとしているのは、先々に面倒な事象を発生させたくないためという考え方もできるでしょう。
そういった本質的な要因を理解することで、プロジェクトが上手く回らなくなった場合の対応策を変えていくことが大切です。
3.なぜ、プロジェクト終盤に問題が噴出するのか
2.の章でもご紹介したように、プロジェクトをスムーズに運営するためのポイントは、対人関係にあることが少なくありません。
対人関係を上手くマネジメントできるかどうかは、プロジェクトマネージャーの力量にかかっている部分が大きいでしょう。
プロジェクトマネージャー、メンバー、営業担当、顧客などが信頼関係を構築できているとプロジェクトが上手くいく可能性が高くなります。
信頼関係を構築するための一つのポイントとして、プロジェクトチームの中に、ミスや間違いを許容する雰囲気作りをすることが大切です。
そのためには、(時と場合によりますが)失敗したことを他のメンバーの前で注意しないことも一つのポイントとなります。
担当者の失敗を、他のメンバーの前で大きな声で注意しているようなマネージャーがいることもありますが、このようなことを積極的にお勧めすることはできません。
プロジェクトチームの中に、ミスや間違いが許容されないような雰囲気が出てくると、メンバーは消極的になって、プロジェクトマネージャーに対して状況が良くない報告が全く上がらなくなってくることがあります。
すると、想定していなかったバグが発生して、予定通りにテストが進んでいない場合でも、プロジェクトマネージャーに正直に報告すると怒られるため、テストは順調に進んでいると虚偽の報告をするようになってしまいます。
このような状況になれば、問題が溜まってきて納期が遅れていても、プロジェクトマネージャーのみが把握していないということになります。
最終的に、プロジェクト終盤に近づいた頃にさまざまな問題が噴出して、プロジェクトが大変な事態になります。
こういった状況にしないためにも、プロジェクトマネージャーを含めた日頃からの適切なコミュニケーションが重要と言えます。
4.プロジェクトメンバーの性格を把握することが重要
どのような人にでも、ミスはあるものです。
メンバーにミスが起きた場合は、ミスを叱るのではなく、なぜそのミスが発生したのかについて十分に話し合うことが必要です。
同じミスを担当者が再発しないようにすることと、ミスの要因を他のメンバーとも共有することで、似たようなミスの発生を未然に防ぐためです。
答えが分かっている場合でも、プロジェクトマネージャーは直接的にその答えを示す必要はありません。
メンバーにその答えを考えてもらわないと、本当の意味での人材育成はできないからです。
また、正解は一つではないので、多様な考え方を尊重するという点においても、メンバー自身に考えてもらうことが大切です。
また、マネージャー自身が若い頃に起こしたミスの事例を、さまざまな機会を通してメンバーに伝えることも大切です。
プロジェクト稼働中にミスがあった場合でも、そのミスについてポジティブな会話ができるような雰囲気を作ることが必要です。
もちろん、同じ要因で担当者が再度ミスを犯した場合は、厳しく注意する必要があります。
しかし、その場合でも、他のメンバーがいるところではなく、担当者と一対一で注意することが大切でしょう。
担当者の性格にもよりますが、他のメンバーの前で注意されて気分の良い人はほとんどいないためです。
また、なぜ注意するのかという理由について、しっかりと担当者へ伝える必要があります。
担当者の単純なミスでない場合には、ミスを犯した要因が本質的なものでない場合もあります。
注意する前には、その要因が本質的なものであったかについて再度検討した方が良いでしょう。
また、プロジェクトメンバーの性格や反応を把握しておくことも大切です。
メンバーの性格を理解するのは、非常に難しいことです。
最低限、メンバーの性格が楽観的であるか、それとも悲観的であるかということは、確認しておくべきでしょう。
プロジェクトマネージャーは、定期的にメンバーと個別面談を行って、進捗状況の報告を受ける機会を持つことが大切です。
極端な例ですが、メンバーが楽観的な性格の場合は、1割程度しかプログラムができていない場合でも「すぐに完成します」と回答し、悲観的な性格の場合には9割できている場合でも「まだ時間がかかります」と報告するかもしれません。
楽観的な性格のメンバーの場合には、「このプログラムにはこのような機能が必要だが、機能は作り込んでいるか」といったことを、悲観的な性格のメンバーの場合には「終わっていない機能はどれか」といったことを聞くことで、より精度の高い進捗状況を把握することができます。
テスト進行中のケースでは、テスト仕様書のどの部分が終了したのか仕様書に追加記述して提出してもらうことで、視覚的にも確認できる環境作りをすることが大切です。
5.プロジェクト開始前や稼動中のメンバー同士の交流の場を提供する
プロジェクト稼働中は日々の作業が長時間にわたることも多いため、メンバーの体調を把握・管理することも大切です。
近年は、うつ病も多くなっています。
特に、うつ病は仕事に真面目に黙々と取り組むような人に多いため、メンタル的に疲労しているような徴候がないか確認することも大切です。
メンバーが休職してしまうと、企業に多大な損失を与えるケースもあり、中心的なメンバーの場合にはプロジェクトの進捗に甚大な影響が出てきてしまいます。
そうならないためにも、日頃からちょっとしたコミュニケーションを取っておくことで未然に防げることもあるので、細かい気配りが大切になってきます。
プロジェクトを上手く稼動させるためには、プロジェクトマネージャー同士がお互いに良好な関係を築いていることも大切です。
プロジェクトマネージャー同士が良い関係で、お互いに切磋琢磨している姿を見せていれば、メンバーは安心して、チーム内にポジティブな空気が流れます。
プロジェクトのメンバー間で信頼関係を構築することも大切です。
数名のプロジェクトの場合には、メンバーは自社のみで構成されることもあります。
一方で人数が多い場合は、外注先のメンバーが加わるケースも往々にしてあります。
さまざまなバックグラウンドを持つメンバーでプロジェクトチームが構成されているため、お互いを理解するという点も含めて、プロジェクトをスタートする前にキックオフを行うことも大切です。
初めて出会うようなメンバーが多いため、これからお互いに協力して仕事をしていくために、良い雰囲気作りをする必要があります。
そのための手法としてアイスブレイクという方法があります。
アイスブレイクというのは、簡単に言うと自分を開示するために各自が行うものです。
自分のことを初対面の人に開示するのは、ある程度の勇気が必要なため、自分を開示する場を意図的に作り出すことも効果的でしょう。
例えば、各自が単に自己紹介をするようなものではなく、2人1組になって、まず1人が相手に自己紹介をして、その紹介を聞いていたもう1人が全員に他己紹介をするようなものでも良いでしょう。
そういった良好な雰囲気を作ってからスタートさせることが、プロジェクトのスタートダッシュにつなげるためのポイントとなります。
プロジェクト稼動中にも、メンバー同士が上手くいかないケースがあるかもしれませんが、定期的に懇親会を開くなどして、メンバーの息抜きや交流の場を提供し続けることが大切です。
まとめ
コンピュータプログラムを用いたシステム開発であっても、実際に開発を行うのは人なので、プロジェクトチーム内の人間関係を良好に保ちながらプロジェクトを進めていくことが重要なポイントと言えるでしょう。
そのためにはまず、プロジェクトマネージャー自身がメンバーに歩み寄り、積極的にコミュニケーションを取ることが大切です。
プロジェクトチームは良くも悪くも、マネージャーの考え・行動に左右されるので、マネージャーはそのことを踏まえて振舞うことが重要でしょう。
単なる仲良しチームではなく、良い意味での緊張感を持ちながら目標に向かって邁進できるチームを作れた時に、チームとしての結束力が出て、プロジェクトも良い方向に進んでいきます。
