『Team Geek ―Googleのギークたちはいかにしてチームを作るのか』(Brian W. Fitzpatrick、Ben Collins-Sussman / オライリージャパン)は、エンジニアが人と上手くやっていくために必要なソーシャルスキルを著者らの経験に基づいた実践的なアドバイスでまとめあげた著作です。ソフトウェア・プロジェクトだけではなく、そのエッセンスは他産業にも応用することができます。それでは内容をご紹介します。
孤高のプログラミング職人はいない
この記事を書いている筆者は元エンジニアであるため、エンジニアがどのようなことを考えているかは知っているつもりです。彼らが共通して持っている願望の一つは「世の中から天才として認められたい」ということです。そのためエンジニアは、自分が実装しているプログラムが完成品するまでの過程を人に見られることを嫌います。なぜならその過程を見られてしまうと、多くの失敗や間違いを晒すことになり、「天才」ではないと思われるのではないかと不安になるからです。しかしながら、このようなエンジニアのマインドは「リスクが高い」と著者は指摘します。その理由は、
- 早い段階で設計ミスをしやすい
- 車輪の再発明をしやすい
- 他者からの強力を引き出せない
からです。ちなみに「車輪の再発明」とはざっくり言うと、すでに存在する技術や製品、方法を知らずに一からそれらを作り出してしまう無駄のことを意味しています。
隠れ家に1人でいたら、才能が開花することもない。秘密の発明をこっそり準備していたら、世界を変えることもできないし、数百万人のユーザーを喜ばせることもできない。誰かと一緒に仕事をしなければいけないんだ。ビジョンを共有しよう。仕事を分担しよう。他人から学ぼう。そして、素晴らしいチームを作るんだ。
本書によれば、エンジニアは完成品が出来上がる過程を隠すのではなく共有して「早い段階で、高速に、何度も失敗せよ」の精神を貫くことが良いとされています。実際、過去を振り返ってみても、世界を変えるような功績はチームの力によって生まれています。
“HRT(ハート)”がチーム作りの３本柱
著者は、優れたチームを作るためには「Humility(謙虚)」、「Respect(尊敬)」、「Trust(信頼)」の頭文字をとった”HRT(ハート)”を3本柱として仕事をすることが必要だと述べています。具体的にどのようなことが”HRT”を体現する上で重要なのか6つの方法が書かれています。
① エゴをなくす
自分の「エゴ」を押し付ける人には「謙虚」が欠けています。例えば、服装規定に違反するカジュアルな格好をすることを止めないと、人と会うたびにネガティブな印象からスタートしてしまうため結果的に持続的なコストを支払っています。個人の「エゴ」ではなくチームの誇りや文化など集団の「エゴ」について考えてみると良いでしょう。
② 批判の配分と対応を学ぶ
筆者は「成果に対する建設的な批判」と「性格に対する攻撃的な非難」を明確に区別するべきだと主張しています。これには他者への「尊敬」の精神が必要となります。また批判を受け取る側も「謙虚」と「信頼」を持って、相手の話に耳を傾ける姿勢が求められます。
③ 早い段階で失敗・反復・学習する
過去に失敗したことがなかったら、それは革新的ではないか、リスクをとっていない証拠である。失敗は次回のために学習して改善する絶好のチャンスだ。
新しいことへの挑戦には失敗は付き物です。そのためリスクをとるならなるべく早い段階で失敗しましょう。大事なことは、失敗から学んだことを「文書化」して見つけやすいように保存してチームの資産として残すことです。
④ 学習のための時間を残す
チームの中で一番知識があると教える立場になる機会が多くなります。確かに教育は重要ですし、本人にもやりがいがあるでしょう。しかし、チーム内で局所最適化してしまうと学習を止めてしまう傾向があります。それを避けるためには、教えることと同じくらい学習することに力を注ぐことが肝要です。
⑤ 忍耐を学ぶ
仕事の考え方や進め方が異なるチームメンバーと仕事をするのはタフな作業です。しかし”HRT”の心構えを忘れずに真摯に議論を重ねることで、本当の絆を築き上げることも可能です。
⑥ 影響を受けやすくする
影響を受けやすくなれば、それだけ影響を与えやすくなる。弱いところを見せれば、それだけ強い人だと思われる
この引用は逆説的に感じる方も多いと思います。なぜ、このようなことになるのでしょうか？その理由はまず、影響を受けやすいということは、メンバーの意見をしっかり聞いているという意思表示になるからです。次に、素直に過ちや間違いを認める「謙虚」を見せればメンバーは「信頼」と「尊敬」を抱くと考えられるからです。
チームを成功に導く「文化」について考える
本書によれば、チームの創設者たちが作り上げたチームの「文化」がプロジェクトを成功に導くといいます。そして強固な文化は自己選択的、すなわちその文化を継承する人材が集まってくる特性があります。例えば、シンプルで保守性の高いコードを書く文化を持つチームには、シンプルで保守性の高いコードを書く人材が惹きつけられてくるということです。それではチームの「文化」を根付かせるためにはどうすれば良いのでしょうか？それには5つのツールとノウハウを用いることが重要となります。
① ミッションステートメント
世の中の「ミッションステートメント」は綺麗事を並べた飾りのようなものが多いことは、みなさんもご存知でしょう。著者は、エンジニアリングチームには「チームの方向性の定義」と「プロダクトのスコープの制限」を含むことが大切だと述べています。例えば、著者らが関わったGoogle Web Toolkit(GWT)のミッションステートメントは次の通りです。
GWTのミッションは、開発者が既存のJavaツールを使ってAJAZを構築できるようにすることで、ユーザーのウェブ体験を劇的に改善することである。
このミッションステートメントには、方向性(ウェブ体験を改善)とスコープの制限(Javaツール)が具体的に述べられていることに注目です。ミッションステートメントを軽視するエンジニアも多いですが、これを明確にすることでチームの認識のズレを少なくすることができ、効果は高いです。
② 効率的なミーティング
ミーティングは非効率になる場合がしばしばあります。本書では、ミーティングを開く時の5つのルールが書かれています。
- 絶対に必要な人だけを呼ぶ
- アジェンダを作ってミーティング開始前に配布する
- ミーティングのゴールを達成したら時間前でも終了する
- ミーティングを順調に進める
- ミーティングの開始をお昼休みや終業時間の前に設定する
このルールを守っていれば、ミーティングを効率的に行うことが可能になるでしょう。
③ 設計文書
設計文書は、プロジェクトの未来を描いたハイレベルの青写真であり、すぐにコードを書き始めるのではなく、設計文書を作成してメンバーに共有してから開発をすることが好ましいです。設計文書は、永続的なものではなく必要に応じて後から変更することもできます。しかしながら、設計文書を書くことに過度な労力を費やすことは避けなければなりません。
④ メーリングリストとオンラインチャット
メーリングリストとオンラインチャットの利用は、チームに統一的な文化をもたらすために非常に便利です。メンバー間で共有しておくべきことは、これらのツールを用いて記録し、検索できるようにしておきましょう。
⑤ 課題管理ツール
課題が生まれたら、それを課題管理ツールにすぐに記載することで、その課題がオフィシャルに共有されたことになります。課題には優先順位をつけ、議論が膨らみそうな場合は、メーリングリストでのやり取りに移行するなど、柔軟に対応する必要があります。
優れた「リーダーシップ」を学ぶ
キャプテンのいない船は浮かんでいるだけだ。誰かが舵を手に取って、エンジンを始動しなければ、あてもなく漂流してしまう。ソフトウェアプロジェクトも同じだ。誰かが舵を取らなければ、何かが起きるのを座って待っているギークの集団にすぎない。
上の引用にあるように、チームを前に進めるためにはリーダーが必要です。しかし、多くのエンジニアはリーダーになりたがりません、どうしてでしょうか？それは彼らの大好きなコードを書く時間が奪われてしまうからです。とはいえ、リーダーになることにはメリットがあります。まず1つ目に自分自身をスケールして、1人でやる作業より多くの成果を残すことが可能になります。次に2つ目は、リーダーとして自分がやっていけるか試す良い機会になるからです。ここでは、リーダーシップの悪例と好例を解説します。
悪例：このようなリーダーにはなるべきではない
- 自分の言いなりになる人を採用する
- パフォーマンスの低い人を無視する
- 人間の問題を無視する
- みんなの友達になる
- 採用を妥協する
- チームを子どもとして扱う
1つ目に、リーダーは、自分の地位を脅かす優秀な存在を疎んで、自分にとってのイエスマンを採用したがる傾向があります。これでは、健全なチームワークを発揮できるとは思えません。2つ目に、リーダーは期待に沿えない働きをしているメンバーを放置してはいけません。優秀なメンバーの意欲を削ぐことになるからです。3つ目に、リーダーは技術者であったことが多いため、人間的な側面を軽視しがちです。それではメンバーの共感を得ることはできません。
4つ目に、友達関係と仕事関係を混同してはいけません。両者は互いに区別して適切な対応をする必要があります。5つ目に、よくある問題として「採用を妥協する」ことがあります。確かに人員確保は急務ですが、もし適当ではない人材を雇ってしまったらその代償は後から高くつきます。そのため、採用は基準を満たす人のみ行うべきです。6つ目に、チームメンバーを子どものように扱うことは止めましょう。メンバーに尊敬の態度を示さなければ、リーダーの求心力は落ちていきます。
好例：このようなリーダーを目指すべき
- エゴをなくす
- 懐疑的・批判的な態度は控える
- 触媒になる
- 先生やメンターになる
- 目標を明確にする
- 正直になる
- 幸せを追い求める
1つ目は、前述しましたがリーダー個人のエゴをなくすことが重要です。ただしチーム全体のエゴを持つことは推奨されます。2つ目は、懐疑的・批判的な態度を控えることです。そのような態度をとられて喜ぶメンバーはありません。前述した”HRT”を意識しながらメンバーとコミュニケーションをとるべきです。3つ目は、リーダーは合意形成をスムーズにする触媒として働くようにしましょう。
4つ目は、もし新人プログラマの仕事を自分なら10倍早く終わらせることができると思っても「ぐっ」と我慢して、見守る姿勢が必要です。部下の成長を第一に考えましょう。5つ目は、目標を明確にすることです。これは基本的に思えますが、なかなか実践されていません。チームの方向性は常に明確でなくてはなりません。6つ目は、正直になるということです。正直さが欠けるとメンバーの忠誠は損なわれてしまいます。7つ目は、チームの幸せを考えましょう。そのための定数的な指標を導入して、それを向上させるように取り組むことも大切です。
チームを心地よい環境へと変えるには
この記事を読んでいる皆さんの中で、自分のチームに不満を持っている方はどのくらいいるでしょうか？きっと、さまざまな形はあれど何らかの不満を抱えていることが多いと思います。チームの愚痴を同僚と話すことは楽しいですが、問題の解決にはなりません。ここでは、自分が居心地のいい環境をどのように作っていけばいいかについて紹介します。
① 許可を求めるより寛容を求める
自分のやりたいことの「許可」が下りるのを待つよりも、自分で「ここまでは大丈夫だろう」という範囲を見定めて、「寛容」を求める方が争いを避けることができます。ただし前提として、会社にとって正しいことをするということがあります。それを実現するために、同僚や友人の力を借りることは心強い味方となります。
② 道がないなら道を作る
もし現状に不満があるなら代案を出して草の根レベルでの広がりを狙うという方法もあります。多くの人にそのアイディアが使われているのであれば、官僚組織でも無視することは難しくなります。自分の道を自分で作りましょう。
③ 上司の管理方法を学ぶ
上司に自分が「上手く」やっていることを上手に伝える技術は重要です。しかしゴマスリのようなことはしたくないというメンバーも多いでしょう。ただ、上司によく思われていないと政治的な軋轢によって、最も力を注ぐべきであるプロダクトのローンチに集中することができないという問題が生まれます。不満があっても、現実的な妥協は必要になります。
④ 運と親切の経済
「運の良し悪し」はチャンスに気づくことができるかどうかで決まることが多いです。仕事をしている時に、もしも「これはチャンスでは？」と思うようなことがあれば積極的に力を注ぎましょう。また、会社に日頃から親切にしていると、それは蓄積され自分の元に戻ってくることはしばしば起こり得ます。まさに「情けは人のためならず」ですね。
⑤ 安全な地位まで昇進する
昇進はある種のゲームであり、戦略が求められます。昇進に無頓着でいると、いつまでたっても権限が大きく、自由度の高い地位に就くことが叶いません。そのためここはそれを割り切って、戦略的に昇進を目指すことも選択肢の一つになるでしょう。
⑥ 強力な友達を探す
社内における影響力が大きいキーパーソンに対しては、日頃からアピールをしておくと良いでしょう。それによって、自分のチーム内での立ち位置が左右されるということは可能性としてあります。社内の勢力図を把握しておくことが大事です。
⑦ 逃亡する
もし、上述したようなチームで居心地が良くなる努力をしても改善がまったく見られない場合は、そこから「逃亡する」という手段も十分に妥当性があります。「逃げる」という選択肢があるのだということは念頭に置いておく必要があります。
まとめ：Team Geak
ここまでエンジニアリングに精通したGEEKたちがどのように「人間」と関わり、対応していけばいいのかについて解説してきました。この本の特徴は、エンジニアにとっては気が進まないことも実行することを推奨していて非常に現実志向であることです。それ故に、アドバイスの一つ一つが明日からでもすぐに実行できるようになっています。この本の内容を忠実に行えば、エンジニアとして一つ上の次元に行くことができるでしょう。ぜひご一読くださいね。
