第18回 スペシャリストはリーダーになれない？
野村隆（eLeader主催）
2006/9/20
| 将来に不安を感じないITエンジニアはいない。新しいハードウェアやソフトウェア、開発方法論、さらには管理職になるときなど――。さまざまな場面でエンジニアは悩む。それらに対して誰にも当てはまる絶対的な解はないかもしれない。本連載では、あるプロジェクトマネージャ個人の視点＝“私点”からそれらの悩みの背後にあるものに迫り、ＩＴエンジニアを続けるうえでのヒントや参考になればと願っている。 |
■リーダーシップトライアングルにおける位置付け
この連載では、システム開発プロジェクトにおけるリーダーシップを中心に、「私の視点＝私点」を皆さんにお届けしています。
今回の内容は、リーダーシップトライアングルのLove／Communication／Capabilityに関係します。Loveについては第10回「正しいことをし、行動力を発揮するココロ」を、Communicationについては第8回「コミュニケーションはリーダーシップの基礎」を、Capabilityについては第11回「信頼は河原の石のように」を、それぞれ参照いただければと思います。
 |
| 図1 リーダーシップトライアングル。今回は「Love」（ココロ）、「Communication」「Capability」に関連する内容について解説する |
■プロジェクト管理のスペシャリスト
この連載もすでに18回を数え、開始から約1年半が経過した計算となります。皆さまのご愛読に感謝いたします。今後ともよろしくお願い申し上げます。
1年半にわたってリーダーシップについての連載をしているためか、仕事で「野村さんは、プロジェクト管理のプロフェッショナルなのですよね」と声を掛けられることがあります。冷やかしやほめ殺しという場合もあるので、単純に喜ぶことはできません。しかし、個人的にはこのように声を掛けてもらえることを前向きに考え、期待を裏切らないよう頑張ろうと思うことにしています。
一方、声を掛けていただく中で「野村さんは、プロジェクト管理のスペシャリストなのですよね」という言葉をもらうことがあります。そのような場合、ちょっと意地悪なのですが次のように答えることにしています。
「いいえ、私はプロジェクト管理のスペシャリストではありません」
■スペシャリストの日本語訳は？
なぜこんな回答をするかは、スペシャリストという言葉の定義を考えればご理解いただけると思います。
スペシャリストを日本語に訳すと「専門家」です。専門家とは何か特定の事項について詳しく知っている人です。システム設計・開発プロジェクトにおいても、専門家、物知りである人材は非常に重要ですし、重宝されます。
しかし、プロジェクト、特に大規模プロジェクトを運営するリーダーとなるべき人は、プロジェクト管理のスペシャリストである必要はありません。むしろ、プロジェクト管理のスペシャリストでは、かえってプロジェクト管理ができなくなる局面があるのです。
このような考え方が根底にあるので、私は「プロジェクト管理のスペシャリスト」と評価されても、それを否定してしまうわけです。
なぜ、知識の豊富なプロジェクト管理のスペシャリストであるにもかかわらず、プロジェクト管理・運営ができない局面があるのでしょうか。その理由を具体的な例を用いてみていきましょう。
■プロジェクト管理ができないプロジェクト管理のスペシャリスト
私はIT業界で長い期間仕事をしているので、自称プロジェクトマネージャと何度となく仕事をしたことがあります。
例えば、私がかつて一緒に仕事をした、ある自称プロジェクトマネージャ（以下Aさん）の話です。Aさんは、いわゆるプロジェクト管理オフィス（PMO）のリーダーに配属されました。
当時、システムの要件定義の後半からシステム設計に着手するころでした。設計作業の本格化を迎えて、プロジェクトメンバーも増員され、プロジェクトの作業工数管理の仕組みを導入するという局面です。
ここでAさんは、Microsoft Project（MSプロジェクト）を使って作業工数管理をすることにしました。
AさんはPMOとして、作業工数管理のために以下の作業をプロジェクト全体に通達しました。
- 各チームの詳細作業項目をMSプロジェクトに登録
- チーム間の作業依存関係をMSプロジェクトで定義
- MSプロジェクトサーバを導入し、各チームメンバー全員が自分の実績作業時間をMSプロジェクトに入力可能とする
MSプロジェクトに詳細作業項目を登録し、細かい単位で作業工数を管理するという方法は、プロジェクト管理の教科書に書いてあります。この方法は、プロジェクト管理の視点から見ると良いことだといえます。
しかし、Aさんが通達をしたにもかかわらず、各チームとも詳細な作業項目を登録しません。チームのメンバーは作業時間をMSプロジェクトに入力していません。
作業時間が入力されない限り、実績作業時間は収集されないので、Aさんが考える本来あるべきプロジェクト管理ができません。作業項目ごとに予定作業時間と実績作業時間を突き合わせた予実管理は、プロジェクト管理の基本です。
各チームのメンバーが実績作業時間を入力せず、自分のチームの管理が思いどおりにできないと知って、Aさんはこういいました。
「私はやるだけのことはやった。MSプロジェクトを導入し、メンバーが作業時間を入力できるようにした。これはプロジェクト管理の基本として、プロジェクトメンバー全員が実施して当然のことだ。それにもかかわらず、各チームのメンバーが作業時間を入力しないのは、彼らの責任だ。私の理想とするプロジェクト管理ができないのは、各チームのチームメンバーのせいだ。私は何も悪くない。むしろ、MSプロジェクトを導入し、仕組みをつくった私の貢献を認めてほしい」
皆さんは、このような態度をどう思われますか？
自分の正当性を主張し、自分の仕事が遂行できない理由を他人のせいにする。これでは、プロジェクトを管理・運営する主体であるPMOのリーダーとして、Aさんは失格ですよね。Aさんのミッションであるプロジェクト管理・運営がうまくいかない責任を各チームのメンバーになすり付けて、何とかなるとでも思っているのでしょうか。
 |
| 今回のインデックス |
| ITエンジニアを続けるうえでのヒント（18） （1ページ） |
| ITエンジニアを続けるうえでのヒント（18） （2ページ） |
＠IT自分戦略研究所は2014年2月、＠ITのフォーラムになりました。
現在ご覧いただいている記事は、既掲載記事をアーカイブ化したものです。新着記事は、 新しくなったトップページよりご覧ください。
これからも、＠IT自分戦略研究所をよろしくお願いいたします。
