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

3章船にはキャプテンが必要

母親の墓の前で宣言しても「マネージャー」にはなれない。でも、キャリアのどこかでリーダーの立場になってしまうときがある。本章では、こうしたときに何をすればいいかを説明しよう。

マネージャーのためのマネジメントの本はすでにたくさんある。本章はなんとなくリーダーになってしまったエンジニアのためのものだ。エンジニアはさまざまな理由からマネージャーになりたがらない。だけど、リーダーのいないチームは機能しない。別にマネージャーになれって言いたいわけじゃない（ぼくたちはエンジニアリングマネージャーだけどね！）。なぜチームにはリーダーが必要なのか、なぜエンジニアはマネージャーになりたがらないのか、なぜ優秀なリーダーは謙虚・尊敬・信頼の原則を使ってチームに貢献するのかを教えてあげたいと思う。そのあとは、リーダーシップのパターンとアンチパターン、それからモチベーションについて掘り下げていくことにしよう。

ソフトウェアの方向性に影響を与えるには、エンジニアリングリーダーシップを隅々まで理解しなければいけない。プロダクト開発に参加するだけでなく、舵取りをしたいと考えているのであれば、その操縦方法を学ぶ必要がある。あるいは、実際に浅瀬で試してみる必要がある。

3.1　自然は真空を嫌う

キャプテンのいない船は浮かんでいるだけだ。誰かが舵を手に取って、エンジンを始動しなければ、あてもなく漂流してしまう。ソフトウェアプロジェクトも同じだ。誰かが舵を取らなければ、何かが起きるのを座って待っているギークの集団にすぎない。

プロジェクトを進めるには、誰かが運転席に座らなければいけない。公式に任命されたかどうかは関係ない。おそらくやる気があって我慢のできないタイプが座るのだろう。もしかすると君かもしれない。すでにチームの衝突の解消・意思決定・人間関係の調整をしていないだろうか。こうしたことは常に頻繁に発生する。「リーダー」になろうと思っていないのに、なぜかリーダーになってしまう。こうした苦悩を「マネージャー炎症（manageritis）」と呼ぶ人もいる。 ...