Googleの「Project Aristotle」から学ぶ、最強のエンジニアリングチームの作り方
現代のソフトウェア開発において、チームワークはますます重要になっています。シリコンバレーでもソフトウェアエンジニアが協力して働くことが強く推奨されていて、なぜならグループで取り組む方がイノベーションが早く、バグなどの間違いに早く気づき、より良い解決策を見つけられるという研究結果があるからです。
しかし、「完璧なチーム」はどうすれば作れるのでしょうか？優秀なエンジニアをただ集めれば良いのでしょうか？
本記事では、Googleが数百万ドルを投じて行った 「Project Aristotle（プロジェクト・アリストテレス）」 の調査結果をもとに、チームを成功に導く真の要因について解説します。
元記事
「誰」が集まるかではなく「どう」協力するかが重要
Googleは「完璧なチーム」を構築するため、2012年に「Project Aristotle」というプロジェクトを立ち上げました。彼らは、Employee performance optimization（従業員パフォーマンス最適化）——つまり「個人の生産性やスキルをデータで分析し、より速く・より優れた働き手へと改善すること」——だけでは不十分だと気づき、チームの力に注目しました。
研究チームは、180以上の社内チームを分析し、以下のような仮説を検証しました。
- チームメンバーが仕事外でもよく遊ぶ友人同士の方が良いのか？
- 全員が内向的、あるいは外向的であるべきか？
- 趣味や学歴が似ている方が良いのか？
しかし、どんなにデータを分析しても、チームの構成要素（誰がチームにいるか）がチームの成果に影響を与えるという証拠は見つかりませんでした。優秀なエンジニアばかりを集めても、共通の趣味があっても、それが成功を約束するわけではなかったのです。
そこで研究者たちが注目したのが、Group norms（グループ規範） です。
グループ規範とは、「チーム内での暗黙のルールや、『うちのチームはこういうやり方だよね』という行動基準」のことです。例えば、「意見の対立を全力で避ける」チームもあれば、「激しい議論を推奨し、グループシンク（集団浅慮）を嫌う」チームもあります。
優秀なチームに共通する「集団的知性」と2つの行動
心理学の研究では、個人ではなくチーム全体としての賢さや問題解決能力を Collective I.Q.（集団的知性） と呼びます。
研究によると、個々のメンバーの能力がずば抜けていなくても、チーム全体としての集団的知性が高いグループが存在することがわかりました。そのような「優れたチーム」には、共通して2つの行動が見られました。
1. Equality in distribution of conversational turn-taking（発言量の均等な分配）
これは、「みんなが同じくらい発言する機会があること。一部の声が大きい人だけが喋り続けるのではなく、全員が交代で意見を言える状態」を指します。誰か一人や少数の人間だけが発言を独占すると、集団的知性は低下してしまいます。
2. Average social sensitivity（平均的社会的感受性）
これは、「相手の表情や声のトーンなどの非言語的なサインから、『今、この人は困っているな』『意見を言いたそうだな』と空気を読む力」のことです。優れたチームのメンバーは、誰かが動揺していたり、疎外感を感じていることを直感的に察知する能力に長けていました。
チーム成功の最重要鍵：「心理的安全性」
発言の均等性と社会的感受性は、心理学において Psychological safety（心理的安全性） と呼ばれる概念を構成する要素です。
心理的安全性とは、ハーバード・ビジネス・スクールのエイミー・エドモンドソン教授の定義によれば、「対人関係においてリスクをとってもチームは安全だという、メンバー間で共有された信念」のことです。簡単に言えば、「このチームなら、バカなアイデアを言っても笑われないし、失敗しても責められず、ありのままの自分でいられるという安心感」です。
Project AristotleがGoogleのデータを分析した結果、他の何よりもこの「心理的安全性」が、チームを機能させるために極めて重要であることが判明しました。
エンジニアリングチームに心理的安全性を導入するには？
「話を均等にしよう」「相手の感情に敏感になろう」と言うのは簡単ですが、実践するのは困難です。特にGoogleで働くようなソフトウェアエンジニアの多くは、もともと「感情について話すのを避けたい」という理由でその職業を選んだ人も少なくありません。
では、どうすればチームに心理的安全性をもたらすことができるのでしょうか。Googleのあるマネージャー、Matt Sakaguchi氏のエピソードが大きなヒントになります。
Sakaguchi氏は、新たに担当したエンジニアチームのアンケート結果が悪く、メンバーが仕事への影響力などに不満を抱いていることに気づきました。そこで彼はオフサイト（社外）でのミーティングを開き、まず自分自身の極めてプライベートな秘密をチームに打ち明けました。「実は私は、ステージ4のガンを患っています」と。
この衝撃的な告白の後、他のメンバーも次々と自分の健康問題や、辛かった失恋の話などを打ち明け始めました。このように、自分の弱みや個人的な苦難を共有することで、チームの間に深い共感と絆が生まれ、仕事上の小さな摩擦や不満についても正直に話し合えるようになったのです。
チームのあるエンジニアはこう語っています。「仕事は私の人生そのものです。もし職場でオープンで正直になれないなら、本当に生きているとは言えません」。
誰もオフィスに着いたからといって、自分の性格や内面の一部を家に置いて、「仕事用の顔」だけを作りたいとは思っていません。本当の意味で心理的に安全であるためには、時には報復を恐れずに自分の怖いと思うことや、面倒で悲しいことについて話せる自由が必要です。
まとめ：データが感情の共有を後押しする
チームワークを向上させるために、「お互いの話を聞き、感情やニーズに敏感になる」というのは、昔から良いマネージャーが知っていた当たり前の結論かもしれません。
しかし、エンジニアのようにデータを重んじる人々にとって、共感や感受性といった曖昧な概念が「チャートやデータ報告書に数値として示されること」には大きな意味があります。データがあるからこそ、感情について話しやすくなるのです。
エンジニアチームをリードする皆さん、またはチームの一員として働く皆さんも、日々のコードレビューやシステム設計だけでなく、「メンバーが均等に発言できているか」「相手の感情を汲み取れているか」といった「心理的安全性」にぜひ目を向けてみてください。それが、最強のプロダクトを生み出す最強のチームを作るための第一歩となるはずです。
Discussion