　計画（P）は難しく、計画どおりプロジェクトは進まず（D）、確認（C）をするがそれも非常に難しい……。ここまでPDCAサイクルのうち、3つのフェイズの点検をしてきましたが、サイクルをうまく回せない問題点が分かってきました。勇気を振り絞って、対策段階（A）の状況も点検してみましょう、対策段階にもさらなる問題が潜んでいます。ここでの問題の多くは「人間と組織」から発生します。

1. プロジェクトリーダーの実態

　プロジェクトリーダーは、文字通りプロジェクトのリーダーとして、状況を把握し問題があれば素早く対応しなければなりません。しかし、実際のプロジェクトリーダーはほとんど権限がなく実行できる対策は限られたものなのです。

　図3のように、多くの企業の開発組織ではマトリクス組織と呼ばれる組織形態を採用しています。メカ設計や電気設計、ソフトウェア開発といった機能別、専門分野別に組織を作り（ライン型組織）、必要に応じて各プロジェクトに人員を割り振る仕組みです。この組織はいうなれば、1人のエンジニアに対して2人の上司がいるようなマトリクス型となり、プロジェクトリーダーもライン組織のどこかに所属し、ライン長（GL）の「部下」となっていたり、自らがライン長を「兼務」したりします。

図3　マトリクス組織

　プロジェクトの遅れを取り戻すためには、遅れを発生させているタスクに適切な対策をタイムリーに実施する必要があります。しかし、実際のところ人員の追加権限はライン長にあります。部品購入は購買部門、仕様に関する権限は商品企画部門がそれぞれの権限を握っており、プロジェクトリーダーに権限はありません。できるのはただただ各部門へ「お願い」するだけという笑えない状況だったりします。

2. ライン長のジレンマ

　とはいっても、ライン長の状況も似たようなもので、決して楽をしているわけではありません。ライン長は人の割り振りに関する権限を持っているので、プロジェクトリーダーから増員の「お願い」を受ける立場にあります。しかし「お願い」されたからといって、振り向けられる人員は非常に限られたものでしかないのです。

　開発テーマをどんどん増やし商品開発を加速させるのは会社方針ですから、プロジェクト数が多過ぎるのではないかと思っても、声を大にしていうことは許されません。本当に緊急対応するためには、いくつかのプロジェクトを中断して人を出さなければならないと思っても、そのような判断を自分1人で決められるわけもないのです。

　結局ライン長もジレンマの中で、人を出してくれと「お願い」されても、「ムリ」と答えるしかないというのが状況なのです。

3. 開発部長の悲哀

　年々大規模化、複雑化している開発プロジェクト環境で、開発部門のトップはどう感じているのでしょうか。これまで検討してきたように、現状のプロジェクト管理体制の仕組みでは、組織の中で何が起きているかを把握するのは非常に困難です。何とかしたいと思い組織を変更して、プロジェクトリーダーの権限を強化しようとしても、限られた人員では結局プロジェクトリーダーとライン長は兼務せざるを得ず、組織の絵は書き換えられても、内情は結局大きく変わることはないのです。

　ここまで開発現場の実態を、PDCAサイクルのそれぞれの段階に当てはめて見てきました。少し誇張して書いていますが、皆さんの会社でも似たような状況にあるのではないでしょうか。実際のところ、開発の現場では現場の願望とは反対に、PDCAのマネジメントサイクルはほとんど回すことができず、なおかつ有効な手立ても講じられていません。その原因はこれまで見てきたように、開発現場の常識と実際の管理方法があまりに実態と乖離（かいり）していることに起因します。

◇

　第1回では瓢箪（ひょうたん）型の年齢構成でミドルマネージャーが圧迫されている現状を説明しましたが、開発マネジメントを機能させるカギはミドルマネジメントをどう機能させるかにかかっているのです。次回では複雑な開発をマネジメントするシンプルな方法「TOCによるプロジェクトマネジメント」について検討していきましょう。

前のページへ 1|2|3 　　　　　　