前のブログで、プロジェクトマネージャーの類型として
(1)トップダウン型
(2)ミドルアップダウン型
(3)丸投げ型
とあげました。そして、丸投げ型について、 仕事を丸投げして、マネージメントしやすいもの、しにくいもの のなかで、
(あ)やることが決まっている場合、丸なげしやすい
(い)やることに、少しずつ違いがある場合、丸なげしにくい
と書きました。
さらにいうと、丸投げ以外については、
(1)のトップダウン型の場合、(あ)の、「やることが決まっている場合」は、マネージメントしやすいです。
(い)の、「やることに、少しずつ違いがある場合」は、「ミドルアップダウン型」のほうが、現場の状況とかを判断して、マネージメントできるので、やりやすいです。
で、(1)のトップダウン型の場合は、やることがきまっているので、それをマニュアル化すれば、大規模に仕事ができます。
しかし、(2)のミドルアップダウン型の場合には、ミドルのマネージャーに、ある一定の技術になってもらわないといけないので、すぐには、規模が大きくなりません。
ところが、この矛盾を背負ってしまったのが、ソフト業界です。
ソフトウエア開発は、美容師などと同じく、仕事の内容に、少しずつ違いがあります。
業務が同じでも、新しいハードにするとか。。。
したがって、ミドルアップダウン型にしないと、いけないんです。
でも無理やり、大規模にやったら、どうなるか。。。
人だけそろえても、ミドルでマネージメントするだけの判断ができないので、結局、そこの人たちの仕事は、失敗する可能性が高いです。
で、ソフト開発の仕事は、成功する場合、利益は、限定的なのですが、失敗すると、かかる費用(=損失)は、プライスレスです。
そのうえ、その失敗したプロジェクトに人をさかれます。
ということで、9個成功しても、1個失敗すると、結局損失ってなことになります。
で、やるプロジェクトの数が増えれば、ただでさえ、失敗する危険性も増えますから。。。
規模を大きくするということは、ソフト開発会社にとって、危険です。
でも、規格化すればいいんじゃないの。。。という考えには、またこんど。
ちなみに、、 仕事を丸投げして、マネージメントしやすいもの、しにくいもの がキャバクラの話になるので、あとは、放送大学大学院の話がのこってます。
そこで、規格化の問題を書きます。
(1)トップダウン型
(2)ミドルアップダウン型
(3)丸投げ型
とあげました。そして、丸投げ型について、 仕事を丸投げして、マネージメントしやすいもの、しにくいもの のなかで、
(あ)やることが決まっている場合、丸なげしやすい
(い)やることに、少しずつ違いがある場合、丸なげしにくい
と書きました。
さらにいうと、丸投げ以外については、
(1)のトップダウン型の場合、(あ)の、「やることが決まっている場合」は、マネージメントしやすいです。
(い)の、「やることに、少しずつ違いがある場合」は、「ミドルアップダウン型」のほうが、現場の状況とかを判断して、マネージメントできるので、やりやすいです。
で、(1)のトップダウン型の場合は、やることがきまっているので、それをマニュアル化すれば、大規模に仕事ができます。
しかし、(2)のミドルアップダウン型の場合には、ミドルのマネージャーに、ある一定の技術になってもらわないといけないので、すぐには、規模が大きくなりません。
ところが、この矛盾を背負ってしまったのが、ソフト業界です。
ソフトウエア開発は、美容師などと同じく、仕事の内容に、少しずつ違いがあります。
業務が同じでも、新しいハードにするとか。。。
したがって、ミドルアップダウン型にしないと、いけないんです。
でも無理やり、大規模にやったら、どうなるか。。。
人だけそろえても、ミドルでマネージメントするだけの判断ができないので、結局、そこの人たちの仕事は、失敗する可能性が高いです。
で、ソフト開発の仕事は、成功する場合、利益は、限定的なのですが、失敗すると、かかる費用(=損失)は、プライスレスです。
そのうえ、その失敗したプロジェクトに人をさかれます。
ということで、9個成功しても、1個失敗すると、結局損失ってなことになります。
で、やるプロジェクトの数が増えれば、ただでさえ、失敗する危険性も増えますから。。。
規模を大きくするということは、ソフト開発会社にとって、危険です。
でも、規格化すればいいんじゃないの。。。という考えには、またこんど。
ちなみに、、 仕事を丸投げして、マネージメントしやすいもの、しにくいもの がキャバクラの話になるので、あとは、放送大学大学院の話がのこってます。
そこで、規格化の問題を書きます。