|
||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||
| 進捗管理では進捗を管理できない? | ||||||||||
|
プロジェクトマネジメントを実際にやってみるとすぐわかるのが、科学的で合理的といわれる方法論が本当の問題解決の一歩手前までで終わってしまうということです。進捗管理を例にとって考えてみます。 進捗管理の目的はなんでしょうか? 「そんなことはわかりきっている。進捗を確認し、遅れていれば何らかの対策を打ち、プロジェクトの納期を守るためのものだ」という声が聞こえてくるようです。 確かにそれはまぎれもない進捗管理の目的であり、間違ってはいません。しかし現実の世界をみてみると、そう簡単にことを片づけるわけにはいきません。 進捗管理によって進捗の状況を確認することはできますし、遅延を発見することもできます。つまり進捗管理は「何に手を打たなければならないのかを適切なタイミングで把握する」という面では、実に有効に機能します。しかし「そこでどのような手を打てば遅延を回復できるのか」という最も重要な関心事については、その効果は曖昧なものになってしまいます。 例えば、時間をかけてWBSを作成し、慎重にチームを作り、適切な報告スパンを設定し、プロジェクトをコントロールしているつもりでしたが、ある進捗報告会で遅延が発見されたとします。発見した遅延は、回復しなければなりません。しかし一般的な進捗管理の知識は、ここから先の具体的な回復策を提示しきれていないのが実情です。それも当然のことかもしれません。具体的な遅延の原因は、実に様々です。またどのような対策なら効果があるのかも、いろいろな理由で変わってきます。 |
||||||||||
| 管理における「見える化」の難しさ | ||||||||||
|
チームには様々な経験を持つメンバーが集まっています。遅延を顧客とのスコープ調整で乗り切った経験を持つメンバー、残業と休日出勤で乗り切った経験を持つメンバー、プロセスの省略と現場のコミュニケーションで乗り切った経験を持つメンバーなど、様々です。経験が様々であれば、価値観も様々です。 皆がプロジェクトマネージャーと同じ考えを持っていれば、あるいはマネージャーの対応方針が説得力のあるものであれば、チームが一致団結して遅延に対応していくことも可能です。しかし常にそううまくいくとは限りません。 仮にマネージャーの対応策に疑問をもちつつも渋々それに従うようなことが起こると、チーム内に不協和音が流れはじめる危険性があります。こうなると、本当は有効に働く可能性があった策でも、新たに発生したチーム内の問題によってその効果が相殺されてしまいます。 なぜ、このような違いが起こるのでしょうか? それは問題解決のイメージがチーム内で共有できていないからです。いい換えると「見える化」が不十分だからです。 長く一緒にやっているチームであれば、多くを語らなくてもそれが具体的にどのようなことかを伝えることができます。しかし、システム開発プロジェクトはシステムを開発するときに必要なメンバーが集められ、また顧客もそれぞれに違っています。こうした、多くの関係者が全員で共通のイメージを持てない状態で定石のような手を打っても効果は上がらないのです。 |
||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||

