FOSSプログラマーを統率する7つのヒント：マネジャーの教科書（3/4 ページ）

[Bruce-Byfield，Open Tech Press]

干渉を控えるべきときを知る

　プロダクトマネジャーになってすぐに、コードが出そろってコンパイルの準備が整ったばかりの商用プロダクトに大きなバグを発見したことがある。問題の解決を任されたわたしは、役員らにその状況を報告できるように、1時間ごとにコンパイルを行うようにチームに要請した。問題を解決した後になっても、自らのしたことに憤りを感じている自分に気づいた。当時、確かにチームのプログラマーたちはミーティングを敬遠していたが、原因はそれだけでなく、わたしは何か起こるたびに細かく問い詰めることで彼らの能力に疑問を持ち、彼らから責任を奪おうとしていた。危機的状況が現実のものになったときも、わたしは彼らに協力しようとせず、問題を解決しようとする彼らの活動を妨げていたのだ。

　こうした状況は必ずしも回避できるわけではないが、経験を積んだマネジャーなら、プログラミングチームのメンバー全員に、それぞれが確実に実力を発揮できる範囲内で自主的に行動させるだろう。そうした場合には、プログラマーと経営陣の要求との間のとりなしを行うだけでなく、どうしても必要なときにはそれぞれの部下の仕事スペースに姿を見せるにとどめるることにもなる。わたしの場合も、全員に召集をかけるのではなく、電子メールで仕事の依頼を送ったり、プログラマーにアポイントメントを取って進捗確認を行うべきであった。もっといいのは、チームには納期の順守を求め、その納期が来るまではチームの誰にも干渉せず、役員たちに対しては取り組みんでいる方法がうまく行きそうだ──どのみち彼らはそれが知りたいだけだ──と説明を続けることである。

ミーティングを最小限にする

　マネジャーにとって、ミーティングはときとして仕事を片付ける場になる。だがプログラマーにとっては、ミーティングへの出席といえば普通、仕事から離れる時間を意味する。特にプロジェクトが始動するときや危機に陥ったときには、ミーティングが避けられないこともあるが、プログラマーはミーティングを嫌がることが多く、会議室で1分が過ぎるごとに苛立ちをつのらせていく人々であることをマネジャーは認める必要がある。開発者たちにとっては、ミーティングの回数が少なく時間が短いほど受け入れやすくなるのだ。

プログラミング言語の一時的流行に注意する

　プログラマーは2、3年ごとに、Java、.NetとMono、Rubyのような新しいプログラミング言語にのめり込むことを繰り返す。プロジェクトに着手すると必ず、チームの何人かは流行りの新しい言語を用いるべきだと熱心に唱え出す。ときには、理にかなった主張であることもあるが、健全な設計の実践というより知的好奇心の現れであることがほとんどだ。

　たいていの場合、こうした主張はプロジェクトに混乱をもたらす。以前勤めていたある会社では、プロダクトスイートがあまりに多くの種類の言語で書かれていたため、各モジュール間のやり取りが困難になるばかりだった。何度かこのスイートを1つの言語で書き直そうと試みたものの完遂されることは一度もなく、かえって複雑さが増す始末だった。こうした罠は自らにプログラマーとしての経験があれば容易に回避できるだろうが、マネジャーたるもの、新たなプログラミング言語の追加には慎重になるべきである。