今回はプロジェクト・リーダーのメンバーに対する責務について考える。システム開発という極めて知的な仕事においては、単に指示し、統制するだけではいい結果は出ないからだ。
 |
ソフトやシステムの開発部門が“知的職場”である以上、開発者のヤル気を引き出し、モラルを維持することが、優れた設計を生み出す最低限の条件である。にもかかわらず、“作業現場”的発想でチームやプロジェクトをルールと統制で動かそうとするのは問題だ。
開発職場のプロジェクト・リーダーは、開発方針はもちろん、具体的設計の大枠についても自ら先導して考え、メンバーに提案し、彼らにも考えさせるくらいのリーダーシップを発揮できなければ、システムはまとまらない。
リーダーはその名の通り、管理統制は緩やかでも、チームの知的活動をリード、先導してこそ存在意義があることを強く認識しなければならない。知的職場である以上、「緩やか統制、しっかり舵取り」が大事である。
 |
部下への仕事の指示は、その内容と期限をはっきり設定することは当然だが、「何のためにその仕事をやる必要があるのか」という仕事の目的を明示することが大切である。巨大プロジェクトでは、担当者はとかく与えられた作業をこなすことに専念しがちなだけに、この仕事、この開発が何のために必要なのかを丁寧に教えることが、メンバーのモラル向上に極めて大切だ。
目的が明確であれば、仮に作業指示に不明確なところがあっても、担当者は積極的に質問するだろうから、やるべき仕事をしっかり理解でき、むだな作業も減るはずである。さらに、担当させる部分が周辺とどういう関係を持ち、周辺から何を期待されているか、どういうリスクがあるか、などを教えておけば、インタフェース・ミスの防止にも役立つであろう。
 |
プロジェクト・リーダーの主たる仕事は、具体的な作業をメンバーにやらせ全体を方向付けるとともに、プロジェクトの進行状況を監視し、問題があれば適切な指示によって解決に当たることである。だが、全く新しいシステムや業務に対しては、どう指示し、どう指導したらいいかを判断することがかなり難しい。にもかかわらず、細かなことはすべて部下に任せることが管理者の威厳を維持する道だと考えているリーダーを時に見かける。これでは維持しているつもりの威厳もやがて怪しくなり部下はついてこなくなる。
自分でもよく分らないときは空威張りなどせずに、部下とともに汗をかき、一緒に考え悩み、一緒に対策に当たる姿勢で臨むことが、プロジェクトの本質をつかむためにも、部下の信頼を得るためにも大事である。
 |
「上三年にして下を知り、下三日にして上を知る」というように、上長は部下のことをよく分からないのに、部下を評価し、部下の仕事を決める権限と責任がある。逆に部下は、上長の長所・欠点がすぐ分かるのに、自分の上司を選ぶ権限がない。こうした本質的矛盾の中で仕事せざるを得ないことが、組織の辛さでありおかしさだ。この矛盾は永遠に解決できない問題だから、矛盾が生む悲劇を極力減らす努力が組織の管理者には求められる。
よく「あいつのことはよく分かっている」と自信満々に言う管理者がいるが、そう単純に分かるわけがない。むしろ「きっと自分は部下のことを見誤っているところがあるに違いない」という謙虚な気持ちで部下を見るべきだ。部下の評価や配置については、将来の成長や幸せを祈る気持で対処しなければならないし、時には心の痛みを感じながら決断する必要がある。
