みんなのプロジェクトマネジメント

メンバーが、リーダーが、マネージャーが、プロジェクトマネジメントを使いこなす。

スケジュールの遅れ

プロジェクトの実行中、しばしば発生する「スケジュール遅れ」。

スケジュール表上で、完了日と現在の日付を比較して、
完了日を過ぎているのに、完了となっていないと出る、「遅れ」の文字。

管理者がそれを見つけて、
「遅れているじゃないか、何をやってるんだ!」
「早く挽回しろ!」とのハッパ。

それでもうまく行かないと、
「新しく作業者を3人入れるから、これで何とか納期までに終わらせろ」
という対策が取られ、
作業者にうまく作業が振れず、現場は大混乱。
結局、納期までに終わらず…

こんなマネジメントを、よく見かけないでしょうか。


スケジュールに遅れの兆候が見られた場合、
最初にすべきことは「原因の判別」です。

なぜ、遅れているのか?
「時間が取れず、予定の作業がこなせなかった」
といった、遅れの原因を判別します。

次に、上記の遅れの原因が、今後も発生するかを検討します。
時間がとれなかったのが、1回きりの突発対応のためであれば、
今後、挽回の見込みがあります。
PJ作業に加え、上司が次々と作業を出してくるような状況であれば、
今後も発生する可能性があります。
このままでは、挽回は難しいかもしれません。

今後も発生するようであれば、その原因を取り除かなくてはいけません
上司から振られる作業が多いようであれば、それを止めさせ、
その上で、遅れている作業を挽回するように、
人を投入する、残業体制を敷くなどの対応を行う必要があります。

遅れに対して、遅れ分の工数をあてがうだけでは不十分です。
(「3人入れるから大丈夫だろう」、という感じ)
遅れの根本原因を取り除かないと、繰り返し遅れが発生してしまいます。
原因を取り除いた上で、確実に終わるような計画を立てる必要があります。

また、要員の追加などの対策が取られると、
遅れを作った張本人が安心し、作業の手を緩めることもあります。
遅れを出している作業者は、遅れていることを自覚し、
早く遅れを挽回するよう、意識づけをすることも重要です。

作業者としては、とにかく予定通りに進めることが重要です。
終わらない場合、その原因をしっかり上位者に報告してください。

管理者としては、遅れを発見したとき、どういう対策をとるかで、
プロジェクトの成否が大きく変わってきます。
まずは上例の通り、原因の判別を実施してください。
もしかすると、真の原因が自分にあるかもしれません。

生産性

「スケジュールの作成方法」にて、スケジュールの作成に、生産性を用いることを紹介しました。
生産性とは、「単位時間当たりにできる作業量」のことです。

…簡単にこう言ってしまっていますが、自分のやっている作業について、
生産性がどれくらいか、把握しているでしょうか?
そもそも、プロジェクトは新規性があるものであり、
メンバの経験や求められる品質なども、プロジェクトごとに差異があります。
ですので、一律、これでいい、という値は存在しないことになります。
とは言え、何も計画無しで進めるわけにも行かないので、
類似プロジェクトの結果を参考にしたり、プロジェクトの特性から補正したりして、
目標値を定めていることが多いです。

でも、参考にするものが無い場合は、どうしたら良いのでしょうか?
その場合はズバリ、「測定してみる」のが良いです。
実測値ですから、信ぴょう性もかなり高いです。

例えば…10ページの設計書を元にコーディングを行ったら、
5時間かけて、300ラインのコードが作成した、という値を測定しておきます。
この場合は、300÷5=60(ライン/時)という生産性が得られます。
さらに、10÷5=2(ページ/時)という生産性も得られます。

この値を持っておくと、次に30ページの設計書をもらったとき、
およそ900ラインのコードができ、およそ15時間かかる、ということが推測できます。

これ以外にも、テスト100項目消化するのに10時間かかった、など、
成果と時間をセットにして測定することで、生産性は簡単に求めることができます。

難易度や状況につき、ばらつきはつきものですが、
複数回、継続して収集していくと、精度の高いものができてきます。

さらに…まだ経験の浅い後輩に作業を振るときは、
持っている生産性に0.8かけて算出する、などにも使えます。

目標のない状態で作業すると、時間が増大しがちです。
とにかく、まずは基準となる値を持つことが、非常に重要です。

生産性は、プロジェクトという大きなくくりでなくても、
もっと身近な、日々の作業で使えるものです。
ぜひ意識して、測定し、活用して欲しいと思います。

チーム・ビルディングのゴールと成果

人を集めただけでは、チームとしてうまく機能しない、というのは想像がつきやすいし、経験のある人も多いでしょう。
1+1が「1」とか「1.2」とかになっている場合です。コストは2人分かかっているのですが…

メンバーをチームとして機能させるためには、チーム・ビルディングを行うことが必要です。
チームビルディングのゴール、および成果としては、以下のようなものがあげられます。

・メンバーが、相互補完関係にある。
 →同じタイプばかりで固めず、それぞれが得意な領域を持ち、補い合う状態。
・プロジェクトのゴールや目標が共有されている。
 →メンバーが、プロジェクトの成功に向かって作業している状態。
・メンバーは、協力して働くことを理解している。
 →他のメンバーが困っていたら、自主的に助けることが根付いている状態。
・適度なレベルの競争と、利害対立がある。
 →基本的には協力の姿勢であるが、ただの仲良し集団ではダメ。高いパフォーマンスを出すために、時には厳しいことも言えるような状態。

プロジェクトを開始してから、なるべく早くこういう状態を作り上げることが、プロジェクトリーダには求められます。

個人の成果・進捗ばかりを重視してばかりいると、チームとしての結びつきは弱くなっていきます。
自分の仕事だけ終わればよいと考え(もしくは、自分のだけで精いっぱい)、遅れているメンバーを気にしなくなってしまいます。
こうならないようにするには…「協力しなさい」というだけでは不足です。
ずばり、「フォロー用の工数を与えておく」というのが有効です。
1日のうちの数時間を、フォローするために使いなさい、と決めてしまうのです。
この時間で、遅れているメンバーを助けたり、他のチームの課題を解決したりするのです。
こういう活動を通じ、協力する姿勢や、プロジェクトの成功に向けて一丸となることを根付かせていくのです。
また、フォロー活動は、できればプロジェクトリーダではなく、メンバーが担う方が効果的です。
その方が、チームとしての推進力があがり、一体感を生むからです。

どんなチームができあがるかで、プロジェクトの成功は大きく変わってきます。
チームビルディングを重要な要素として、プロジェクト計画に組み込んでいきましょう。

マクレランドの欲求理論

動機づけ理論からもう一つ、「マクレランドの欲求理論」を紹介します。
これは、作業者が欲する欲求(動機)には、以下の3つがあるという理論です。

・達成欲求…作業を効率よく達成したい、問題を解決したい、複雑なタスクをやり遂げたい
・親和欲求…暖かで友好的な対人関係を確立、維持したい
・権威欲求…自分でコントロールしたい、他人から尊敬されたい

各作業者に、このような欲求があると理解し、この欲求を満たすような作業を当てはめることが、人的資源マネジメントでの活用方法となります。

具体的には…
・達成欲求
 →適度な難易度の作業を与える。
  結果に対してフィードバックを行い、進め方をさらに工夫してもらい、さらに高い難易度の作業を実施させる。
  本人のスキルが向上していることを実感させることが重要。
・親和欲求
 →協同で仕事をする環境を与える。
  チーム内でサポートを行うポジションで、たくさんの作業をこなしてもらう。
  役に立っている、と実感させることが重要。
  自らリーダになることはあまり望んでいない?
・権威欲求
 →人を管理して、チームとして結果を出す機会を与える。
  目標を達成するための手段を考えさせ、結果を出してもらう。
  ゴールまでの道のりを考えさせ、計画させることが重要。これにより出した結果が、本人の欲求を満たすこととなる。

いずれについても、「この人はこれだから、これを任せておけばOK!」と当てはまるとは限りません。
その人の成長段階により、複数の要因が混ざっている場合も多いです。
これもやはり、決めつけではなく本人としっかり話をした上で、どのような作業を振ればよいか、適切な計画を立てていく必要があります。

マズローの欲求5段階説

自チームのメンバーに、どんな作業を任せるべきか?どんな教育を与えるべきか?
に悩むこともあるかと思います。
特効薬ではありませんが、方針を立てるための知識として、
動機づけ理論のひとつ、マズローの欲求5段階説」を紹介します。

マズローの欲求5段階説
 個人が叶えたいと思う欲求は、大きく以下の5段階に大別されます。
 
  5:自己実現の欲求 …自己を成長させたい。実現させたい。
  4:尊重の欲求   …他者から認められたい。
  3:社会的欲求   …他者との関係。集団への帰属。
  2:安全の欲求   …生命や収入の危険から身を守りたい。
  1:生理学的欲求  …生存に必要な、衣食住が欲しい。
 
 数字の大きいものが上位の欲求で、下位の欲求が満たされると、上位の欲求を満たそうとする、というのがマズローの欲求5段階説です。

これを、システム開発チームに当てはめてみると…
「1:生理学的欲求」「2:安全の欲求」については、会社務めをしている場合、既に満たされている場合が多いと思います。
(例外も思いつきますが、、ここでは記載しないことにします。。)

まず、「3:社会的欲求」ですが、これは主に新入社員や、新しくチームに加わった人が該当すると思います。
この段階では、まずはチームの一員として働くことができるようになること、戦力になりたい、ということを考えていることが多いと思われます。
ですので、一人で基本的な作業が行えるような教育や、比較的簡単な作業を振るべきです。
時には手取り足取りで、しっかりついていてあげることも必要です。実はそれ自体が、集団への帰属を満たす方法でもあります。しっかりケアしてあげましょう。

次に、「4:尊重の欲求」です。この段階に来る頃は、作業を一通り覚え、一人である程度できるようになっています。
そうなると湧いてくるのが、もっとスキルを向上させたい、能力があると認められたい、という欲求になります。
この段階では、徐々に難易度の高い作業を与えていくことが重要です。本人のスキルを高めるとともに、難しいことをやり遂げたことで、あいつはこんなことができるようになった、と認めさせる材料になります。
ただし、まだまだ成長途中です。やり遂げるためのアドバイスをしっかり行いましょう。

最後に、「5:自己実現の欲求」です。この段階では、能力が十分につき、周囲からもそれを認められています。
そうなると、いつまでも言われたことをこなすのではなく、自分の考えた方法で進めたい、実現させたい、という欲求ができてきます。
この段階に来たら、思い切って作業を任せてみることです。明確なゴールのみを与え、そこまでの道のりを考え、進めてもらうようにします。
ただし、投げっぱなしではいけません。要所で確認を行い、ゴールへの道筋が正しいかを見ていきます。
…が、過度に手出しをしてはダメです。どこがいけないかを考え、修正してもらうようにします。
こういった経験を積むことで、判断力や応用力を養い、リーダーとして独り立ちしていく、という流れになります。

以上のように、欲求が順次変わっていくことを理解し、対象者がいまどのフェーズにいるのかを見極めた上で、適切な教育や作業を与える必要があります。
対象者のフェーズの見極めはとても難しいです。フェーズの間にいる人もいるでしょう。一番確実なのは、本人に聞き取りを行うことです。どんなことをやりたいか、どんな時に楽しいと感じるか、を聞き取り、育成に役立てていきましょう。