フリーエンジニアのためのプロジェクトマネジメント教室 〜【第4回】開発現場のメンバーが意識すべきこと 〜

それぞれの立場で意識すべき点が異なる

ITプロジェクトは大まかにいって、ユーザ側(発注側)のプロジェクト、ベンダ側(受注側)のプロジェクトの2つに分かれ、ユーザ側はシステム側、業務側に分かれ、またベンダ側はマネジメント層と開発現場に分かれているのが一般的です。


それぞれの立場でプロジェクトマネジメントに対して意識すること、具体的にはスケジュールに対して、コストに対して、人的資源に対して、品質に対して等々、意識する点が異なります。
第4回からは少し視点を変えそれぞれの立場でどのようにITプロジェクトをやりくりしていかないといけないのかを説明したいと思います。
まずは開発現場のメンバーが意識すべきことです。

進捗の遅れ

例えば10日で完成するタスクがあり5日目終了時点で30%しか完成していなかったとします。
本来なら50%に達していないといけませんから20%、2日分の遅れが生じているということになります。

いろいろな原因が考えられますが、例えば先行する作業が2日遅れたため、着手も2日遅れてしまった場合は、どのように考えましょう?
この場合は3日で3日分の作業をこなしているので作業効率は問題ないですね。
ということはこのままいくと2日遅れることになります。
これは途中で別のタスクが割り込んでしまった場合も同じです。

次に着手は予定通りなのに進捗が30%の場合、2つ原因が考えられます。
一つはそもそも量が多い、あるいはあなたの効率が悪いかです。
これについては5日目で2日遅れということは10日目には4日遅れるということになります。

まとめると進捗の遅れは

(1)着手が遅れた、別の作業が割り込んだ
(2)そもそも量が多い
(3)担当者の作業効率が悪い
ということになります。

いずれの原因にせよ、その遅れがどのような影響があるかを考える必要があります。
これを一般にクリティカルパス法といいます。

遅延しそうなタスクがクリティカルパス上にある場合

タスクの遅れというのは日常茶飯事ですので、すべての遅れに目くじらを立てていては無駄なエネルギー消費をしてしまいます。
そのタスクが納期に対して重要かどうかを見極めて重要なタスクに対してエネルギーを注ぐ必要があります。
そのタスクがクリティカルパス上にある場合はタスクの遅れは納期の遅れにつながります。
つまり重要なタスクなのです。
その場合はチーム一丸となって対処する必要があります。

前述の(1)の場合は2日遅れでしたね、もし1日遅れ程度なら毎日1.6時間の残業でリカバリできそうなので、なんとかなるかもしれませんが2日となるとリソースの追加を考えた方がいいでしょう。
ここで残業時間について述べたいと思います。
私の経験的では、1日の作業時間が9時間半というのが最も「生産高」が高くなると思っています。
「生産性」をいっているわけではありません、「生産高」です。
というのは、9時間半を超えたあたりから「時間当たりの生産量 < 時間当たりの失敗量」という状態になってきます。

1日の終わり、「ああ今日も頑張ったなぁ」と自分で自分を褒めてあげても、残業が多い人は翌日以降に色々な「ミス」が発覚します。
つまり残業すればするほどミスが多くなりそのリカバリーを翌日以降に対応しなければいけなくなります。
そうすると翌日以降、突如そのリカバリ作業を対応しなければならないので、本来予定していた作業に着手できるのは午後あたりから・・・なんてこと皆さんも一度や二度あるはずです。
ですので、上記のケースでは2日遅れであるなら残業ではカバーできないと考えたほうがいいと思います。
1日の勤務時間は9時間半までと思ったほうがいいです。

前述の(2)のケースはどうでしょう?そもそも量が多く、予定では4日遅れになる。
もちろん残業ではカバーできませんね。
リソースを1名追加した方がいいですのですぐにマネージャに相談しましょう。

前述の(3)の場合はどうでしょうか?スキルが足りないのであれば、すぐに相談してスキルの高い人をつけてもらう方がいいでしょう。
この場合はスキルを教えてもらいながら遅れもリカバリしていくという作戦です。
また体調が悪いため作業効率が落ちている場合は、いうまでもなく要員の交代+増員という手段になります。

遅延しそうなタスクがクリティカルパス上にない場合

クリティカルパス上にない場合は、どの程度余裕があるのかを把握する必要があります。
そのタスクが2日遅れてもプロジェクトには影響がない場合、無理矢理期間内におさめて逆に品質を下げてしまうリスクを抱えるのであれば、遅れを受容することも必要です。

また4日遅れてしまうと納期が1日遅れるというのであれば、何とかして1日分を短縮するということを考えた方がいいですね。
この場合だと増員よりも残業でカバーする方が適切でしょう。
またリソースについても目を向ける必要があります。
現在担当しているタスクがクリティカルパス上にないとしても、その人の「次のタスク」がクリティカルパス上にある場合は、現在のタスクの遅れは、次のタスクの着手が遅れるということになるので注意が必要です。
その場合は次のタスクの担当を変更するといった方法もありますが、それができない場合は現在のタスクをフォローする作戦が必要です。

次回は現場からクリティカルパスに影響を与える遅れが出た場合、あるいはそのような事態が発生しないようにするにはという視点でベンダ側のプロジェクトマネージャが意識することを述べたいと思います。

  • この記事を書いた人
この記事を書いた人

高崎敦史 氏

年齢:50代 エンジニア歴:21年
大学卒業後、外資系銀行・コンサルティング会社・ネット企業での勤務を経て、2006年からフリーランスのエンジニアとして始動。
09年にPMP取得した後はプロジェクト・マネジメントの専門家という立場で、多くのIT系プロジェクトを成功に導いている。



人気のコラム記事