FOSSプログラマを統率する7つのヒント
私は、自分自身も含めて数十名のマネージャが両者の対立関係に立ち会い、それぞれに程度の差こそあれ成功を収めるのを見てきた。ここで述べる知見は、プログラマのマネジメントに携わるためにマネージャが知っておくべきだと私が考える基本的な事実をまとめたものである。対象とするプログラマの種別は問わないが、とりわけフリーおよびオープンソースソフトウェア（FOSS）のプログラマによく当てはまるのは、彼らの多くが通常のプログラマよりも極端な態度をとるためである。プログラマという人種を熟知している人々には自明に思われる点もあるだろうが、門外漢である人々にとっては自分たちの思い違いに何らかの示唆が含まれている限りはそうした点を強調しておく必要があると言えよう。
実力主義に従って自分の力量を示す
マネジメントの権威たちは通常、有能なリーダーの特徴に注目し、どうすればそうした特徴を模倣できるかに重きを置いて研究を進めている。そして野心的なマネージャたちに剣豪や極地探検家、あるいはヘンリー5世のような英雄的な自己イメージを抱かせる。しかし、そうした検討結果もイメージもギーク系開発者のマネジメントでは役に立たない。彼らが関心を寄せるのは物事の結果であり、本物であれ作られたものであれカリスマ的資質には関心を示さないからだ。ギークたちのグループをうまく統率できるようになるには、彼らに自分の実力を示さなければならない。彼らの専門分野で自らの腕前を披露してもよいし、彼らが持っていない有益な知識を授けてもよい。本当に効果的にことを運ぶためには、さらに踏み込んで、自らの専門的技量がグループと各メンバーの目標達成に役立つこと、また少なくとも他の誰よりも深い知見があることを証明する必要がある。
実力を示すまでは、たとえ元プログラマだったとしても、力量を問われていると思っておくとよい。細々とした点まで試されるのは腹立たしいだろうが、好ましいのは、有能さを示せばすぐに認めてもらえる可能性がある点だ。前に勤めていたある会社の最高技術責任者（CTO）は、何年もプログラミングから遠ざかっていたとはいえ優れた知識を身に付けていた。開発者たちはいつも彼の決定に異議を唱えていたが、彼が開発者のコードに厳しいながらも的確な批判を与えるようになって状況は変わった。それ以来、開発者からの反論はぴたりと治まったのだ。
地位の高さは優秀さの証ではない
仕事以外の時間を家族や友人とどのように過ごしているかを観察すれば、その人が格式ばらない関係をどの程度好んでいるかすぐにわかる。似たような選択肢がどのように与えられようとも、特に階層の底辺近くにいる人々はそうした格式ばった階層的組織から離れることを好むものだ。階層的組織は効率の面で優れているかもしれないが、ある部門の代表者になると自然と反感を向けられる対象になってしまう。
こうした自然発生的な反権威主義は、とりわけ開発者の間に強く現れる。少し考えれば、実力主義には、誰が何を新たに成し遂げたかによって地位が絶えず変化するという意味が含まれていることがわかる。この政治的な不安定さが立場の相違や不当な評価から生じるさまざまな感情と結びつくことで、リーダーに対する反感がさらに強まるのだ。そのうえ、FOSSの場合は、依然として地位がプログラマの功績に対する主たる報酬の1つであるため、こうした態度が極端に現れる可能性がある。
権威的な地位でも年齢の高さでも ― 多くの場合、マネージャにはこうした要素があるが ― IT部門の部下から自発的な尊敬を得ることはできない。地位には知性や熱意といった優秀さが反映されているのだと自分では思い込んでいても、IT部門の開発チームはおそらくそうは思わないだろう。経営コンサルタントのTim Bryceは、ほとんどのプログラマは頭の良さという点では他のどんな職種とも変わらないのだが彼ら自身はそうは思っていない、と主張している。
それが自然に生まれたものにせよ組織的に作られたものにせよ、どんな権威に頼るよりも、ITマネージャは自らを調整役または問題解決役とみなし、IT部門の文化に逆らわず、できる限りその文化のなかで活動を進める必要がある。まだ誰もその因果関係を示してはいないが、企業の組織がフラット化された時期とそれに重なるようにIT産業が繁栄したことの間にはおそらく何らかの関係があるはずだ。コンピュータ産業の経済的な影響力の大きさから、この産業の重要性は他の業界にも波及しつつある。
自らの動機付けが部下にも当てはまるとは限らない
1つのマネジメントスタイルでは全員に対応できないことを強調したマネジメント書は、Beverly L. KayeとSharon Jordan-Evansによる『Love ‘Em or Lose ‘Em』など、わずかである。しかし、この分野の多くの権威や彼らの教えに従うマネージャは相変わらず、昇進、給与、特別手当といった自分たちを動機付けるものがプログラマの動機付けにもなる、と思い込んでいる。そうしたプログラマの文化を知らない人々は、自分たちの考え方が間違っていることをなかなか理解できないかもしれない。
キャリア専門家のTag Gouletは次のように述べている。「優れたプログラマは優秀な社員の大半とは異なっている。ある新興企業における以前の仕事の1つで、私は開発担当の副社長として3人のプログラマからなるチームを率いていた。その1人はデスクの周りにDilbertという漫画の絵を貼り付けていた。それも主人公のDilbertがとんがりヘアの上司をからかっている場面で、たぶん私への当てつけだったのだろう。たくさんの企業を見てきたが、職場でそんな漫画を見かけたことはなかった。それどころか、いつも皆、自分がチームプレイを尊重する人物であることを意図的に示す小物を置くように注意を払っていたものだ」。事実、精神を鼓舞するコーポレートアートを風刺する通俗的なDemotivatorのポスターのような印刷物は、大半のマネージャが当然と考える価値に対して多くのプログラマが懐疑的、または否定的でさえあることを示す最初の徴候であることが多い。
厄介なのは、たいていのマネージャがビジネスやマーケティングの経歴を持ち、他の人々と一緒に働くことを好む外向的な人物であることだ。対照的に、ほとんどのプログラマはビジネスの世界でも学究的であり、自己の内面に目を向け、無機的な対象に取り組むことを好む。FOSS指向のプログラマであれば、企業への敵対意識を強く示すこともあるかもしれない。報酬を辞退するようなことはないにしても、プログラマは、仕事に対する満足をより大きな挑戦と責任、そして特にFOSS関係者の場合は功績に見合う称賛から得る傾向が高い。
営業員やマーケティング担当者なら場当たり的な仕事にでも意欲的に取り組んでくれるかもしれないが、プログラマの場合は、自分が疎外されたと感じてとんでもない軽率な行動に出る可能性さえある。毎週のようにピザパーティを開いたり、ナイトクラブでプロジェクトの完了を祝ったりすれば、人事部門のチームは満足するかもしれないが、IT部門のプログラマは職場から連れ去られるのに抵抗するか、あるいはコーディングの山場を抜けたばかりであれば家族と過ごす時間を奪われることに腹を立てるかのどちらかだろう。彼らにとっては待ち遠しいイベントどころか、ありがた迷惑な拘束としか映らないのだ。
こうした決まりきったやり方でプログラマのやる気を高めようとするのではなく、本当に彼らに意味のあるものを与えられる本質的な褒賞の実現を検討すべきである。たとえば納期を守ることができた者には、その責任を全うできる範囲内で、プロジェクト内での自主性を高めたり、プロジェクトリーダーの役割や在宅勤務の権利を与えたりすることで報いるのだ。FOSSの開発者の場合は、納期に間に合わせることができたらフリープロジェクトで活動する時間を与えるとよい。たとえそのプロジェクトが会社にとってすぐに使えるものでなくても、後で役立つかもしれないし、そうした協力の実施によって、将来的に入社の可能性がある人々の間で会社の評判が上がることにもなる。
やる気を与えるために最も重要なのは功績を認めることだが、FOSS開発者の場合は特に、文化的な違いを忘れてはならない。ほとんどの開発者は、ミーティングの場で褒められたり月間最優秀社員賞に選ばれたりしても困惑するだけだろう。むしろ、功績をきちんと認めていることや社内の他の場所で称賛を耳にしたことを部下たちに伝えるべきである。
干渉を控えるべきときを知る
プロダクトマネージャになってすぐに、コードが出揃ってコンパイルの準備が整ったばかりの商用プロダクトに大きなバグを発見したことがある。問題の解決を任された私は、役員らにその状況を報告できるように、1時間ごとにコンパイルを行うようにチームに要請した。問題を解決した後になっても、自らのしたことに憤りを感じている自分に気付いた。当時、確かにチームのプログラマたちはミーティングを敬遠していたが、原因はそれだけでなく、私は何か起こるたびに細かく問い詰めることで彼らの能力に疑問を持ち、彼らから責任を奪おうとしていた。危機的状況が現実のものになったときも、私は彼らに協力しようとせず、問題を解決しようとする彼らの活動を妨げていたのだ。
こうした状況は必ずしも回避できるわけではないが、経験を積んだマネージャなら、プログラミングチームのメンバー全員に、それぞれが確実に実力を発揮できる範囲内で自主的に行動させるだろう。そうした場合には、プログラマと経営陣の要求との間のとりなしを行うだけでなく、どうしても必要なときにはそれぞれの部下の仕事スペースに姿を見せるに留めることにもなる。私の場合も、全員に召集をかけるのではなく、電子メールで仕事の依頼を送ったり、プログラマにアポイントメントを取って進捗確認を行うべきであった。もっといいのは、チームには納期の遵守を求め、その納期が来るまではチームの誰にも干渉せず、役員たちに対しては取り組んでいる方法がうまく行きそうだ ― どのみち彼らはそれが知りたいだけだ ― と説明を続けることである。
ミーティングを最小限にする
マネージャにとって、ミーティングはときとして仕事を片付ける場になる。だがプログラマにとっては、ミーティングへの出席といえば普通、仕事から離れる時間を意味する。特にプロジェクトが始動するときや危機に陥ったときには、ミーティングが避けられないこともあるが、プログラマはミーティングを嫌がることが多く、会議室で1分が過ぎるごとに苛立ちをつのらせていく人々であることをマネージャは認める必要がある。開発者たちにとっては、ミーティングの回数が少なく時間が短いほど受け入れやすくなるのだ。
プログラミング言語の一時的流行に注意する
プログラマは2、3年ごとに、Java、.NetとMono、Rubyのような新しいプログラミング言語にのめり込むことを繰り返す。プロジェクトに着手すると必ず、チームの何人かは流行りの新しい言語を用いるべきだと熱心に唱え出す。ときには、理にかなった主張であることもあるが、健全な設計の実践というより知的好奇心の現れであることがほとんどだ。
たいていの場合、こうした主張はプロジェクトに混乱をもたらす。以前勤めていたある会社では、プロダクトスイートがあまりに多くの種類の言語で書かれていたため、各モジュール間のやりとりが困難になるばかりだった。何度かこのスイートを1つの言語で書き直そうと試みたものの完遂されることは一度もなく、かえって複雑さが増す始末だった。こうした罠は自らにプログラマとしての経験があれば容易に回避できるだろうが、マネージャたるもの、新たなプログラミング言語の追加には慎重になるべきである。
ギークの価値観よりも会社の価値観を優先すべき場合を学ぶ
ビジネスには興味がないためか、多くの開発者は納期など必要不可欠なものを疎かにしがちである。彼らにはそうした不可欠な要素をうやむやにしてしまう術を身に付けている者が多い。問題は、大半の開発者が自ら責任を持って仕事をするとは信じてもらえなくなることではなく、むしろ、彼らであればスケジュールの許す限りだらだらと時間をつぶすのが当然だと思われかねないことである。そうした場合は、ギークたちの巧みなマネジメントとは彼らの文化の理解を意味することだとは言うものの、企業の目標達成に重点を移すべき時期を見極めることのほうが重要になる。ときには、たとえ彼らから反感を買うことになっても、理解を示すことよりも差し迫った要件を優先させる必要があるのだ。熟練したマネージャは、部下との衝突を最小限に抑えながらも、ある程度の衝突は避けられないことをよく心得ている。
まとめ
プログラマ、とりわけFOSSプログラマのマネジメントは、すべてのマネージャが挑まなければならない究極の綱渡りのようなものだ。マネージャはIT部門の風土や部下たちとの仕事の進め方を理解する一方で、彼らのやり方と会社の方針との仲介役も果たさなければならない。こうした目標の両立は、マネジメントに対する自らの考え方を自部門に合わせて調整することを意味する。その調整は、あるときはプログラマの意見をプログラマ以外の人々にわかりやすく伝えることであったり、全社目標を達成するために経営陣の誤解からプログラマを守ることであったりする。またあるときには、もっと上位の全社目標をプログラマたちに意識させることであったりもする。落ち着いて取り組むのは難しい仕事だが、その立場に就いたときにどんなことが予想されるかを知っておけば、自らの失敗の後始末やチームからの協力不足に悩まされることなく、発生する難題により多くの時間を割くことができるだろう。
Bruce Byfield氏はセミナーのデザイナ兼インストラクタで、NewsForge、Linux.com、IT Manager’s Journalに定期的に寄稿しているコンピュータジャーナリストでもある。
NewsForge.com 原文
