リーダーとはいったい何か？ - 感想:Team Geek

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

本書には「サーバーントリーダー」という言葉が繰り返し出てきます。言葉の通り、リーダーはメンバーのために働き、メンバーが仕事をすることを助ける、という考え方のようです。メンバーが仕事を進める上での障害の排除、環境の整備、合意形成の場のファシリテーションなどなど。

私が考えていたあるべきリーダー像とは、「強いリーダー」でした。なので、サーバントリーダーという考え方は考えさせられました。「強いリーダー」とはすなわち、アーキテクチャやプロジェクトの進め方など全方位に渡り決定を下し、メンバーに指示を出し、プロジェクトを推進する、というイメージです。

ただ一方で、このやり方にも限界があるなとは最近感じていました。一人のリーダーが全方位に渡り適切な決定を下せるのか、下したとして全責任をリーダーが負うことに無理があるのでは無いか、メンバーが指示待ちになりリーダーの独り相撲みたいな盛り上がりのないプロジェクトになってる、というような課題を悶々と感じていました。

特に、最後のメンバーが指示待ちになる、については痛い目にもあっていたりもします。実体験で、あるメンバーは開発～テストを担当していたのですが、だれがどう見ても仕様バグだと分かる箇所についても、設計書に書いてあるからという理由でそのまま実装されたことがありました。いや、まぁ、指示の通り作っているので、その人を責めることはできないんですが、さすがに参りました。

こういう現象を起こす遠因が「強いリーダー」なのかもしれないと、本書を読んで強く感じました。つまり、メンバー一人一人に当事者意識というか、プロジェクトに対する興味というか、考えてもらい、サーバントリーダーはそれをサポートする。理想は確かにそうだと思いました。

一方で、メンバーの立場になると、技術的に興味がわかないとか、途中で開発だけに突っ込まれたのでそもそものお客様とかできあがる物の効果とか評判とかに全く興味がないとか、結構ありがちで難しい。本書は、Googleでの体験がベースにかいてあり、長めに一つのプロジェクトに携われるんだろうから、そういう悩みは少ないんだろうなーと思いました。逆に私の所属しているところは、短いプロジェクトが多いので、なかなか興味が持てない、モチベーションを膨らませられないことも多いんですよね、自分自身含め。

TEDでは、こんな参考になりそうなプレゼンが。

whyかー。理屈はよく分かりますが、短いプロジェクト、一期一会のお客様に why を求めるのも難しいなと思いました。

 理想を追求するのは難しい。。。