この事例における問題点は、以下に集約されるであろう。
（１）現状分析を全く行わないで、理論的根拠のない納期だけを先に決定した。
（２）（１）を包含するが、根拠のない納期が重視された結果基本設計と上流設計がおろそかになっていた。
（３）開発マネージャが（責任のすべてを開発リーダに押し付けてことたれリとしていた（結果として、本質的な問題解決が先送りになった）。
（２）に関しては開発リーダにも責任はあると思われるが、（１）、（３）については開発マネージャに明らかに責任があると思われる。とくに（３）に関しては、責任転嫁、ないしは「職場内苛め」と取られても仕方ないであろう。
そもそも、この例に限らず開発マネージャが幹部社員、
開発リーダはその部下、すなわち、目標管理評価システムにおける評価者と被評価者の関係となっており、圧倒的に開発マネージャのほうが立場が強い。そうである以上、開発マネージャは権限に相応する責任を持つべきではないか？
なお、この事例においては、開発リーダが建設的な意見を出しても開発マネージャは否定的な発言で意見を切り捨てていると聞いている。ここから、恣意的な目標評価つまり低い評価をつけることを前提とした行為であることが考えられる。言い方を変えれば、事業部内のローカルな（し
かも社会的に容認できない）事情を優先するあまり、顧客に対して提供する製品の品質がおざなりになっているともいえる。Ｆ２の製品が顧客に受け入れられないとすればここに根本的な原因の一つがあるのではないか？
本当によいもの（顧客に受け入れられるもの）を作りたいのであれば、開発マネージャは以下に関して、リーダに責任を押し付けるだけでなく自身の責任も問うべきである。それができなければ、マネージャの座を降りるべきである。（当然のことながら、開発リーダを始めとする開発チームのメンバは、各自の責任を果たすべきであることは言うまでもない）
（１）基本設計の中で、製品がどのように使われるかを十分に検討した上で、製品設計の前提条件（同時利用者数や応答時間目標など）を決めること。
（２）基本設計の決定事項や開発チームの実力を元に現実的な納期（開発完了期限）が設定されること
（３）問題が発生しても、開発リーダ一人に責任を押し付けるのではなく、開発チーム全体が問題解決できる環境を整えること。製品が売れていない現状を打破するには、すべての開発マネージャに対して見直しをかけ、事業部のローカルな事情（たとえば派閥とか）にとらわれない大胆な入換が必要ではないか。（おわり）
|