プロジェクトアリストテレスは、Googleが社内の180チームを対象に「効果的なチームを成り立たせている条件は何か」を突き止めようとした調査の呼び名です。世界最高のチームを作るための研究として紹介されることもあり、結論として挙がった5つの要因は心理的安全性という言葉とともに日本でも広く引用されています。ただ、引用が広がる過程で、調査の規模や測り方、5要因に付いていた優先順位、そして設問文が何を測るものだったのかは落ちがちです。ここではre:Workの原文と、心理的安全性の原典であるEdmondsonの1999年論文までさかのぼって整理します。
まとめ：プロジェクトアリストテレスの結論と押さえるべき数字
調査の結論は、成果を左右するのはチームの構成メンバーではなく、メンバー同士の関わり方だという1点に集約されます。re:Workは「what really mattered was less about who is on the team, and more about how the team worked together」と書いています。優秀な人を集めることではなく、集まった人たちの間で何が起きているかが変数だという整理です。
数字は4つ押さえれば足ります。対象はエンジニアリング115チームと営業65チームの計180チーム、分析には35種類を超える統計モデル、チームの有効性は4通りの尺度で測定、抽出された成功要因は重要度順に5つ。5要因は心理的安全性、相互信頼、構造と明確さ、仕事の意味、インパクトの順で、この順序自体がre:Workの記述（In order of importance）に含まれます。以下では数字の中身、Googleがチームに配った自己診断サーベイの設問例、そして「影響しなかった8項目」まで見ていきます。
プロジェクトアリストテレスの概要と名称の由来
名称の由来「全体は部分の総和に勝る」の出典と、格言としての帰属
コードネームの由来について、re:Workは「a tribute to Aristotle’s quote, the whole is greater than the sum of its parts」（アリストテレスの言葉への敬意）と説明し、括弧書きで「as the Google researchers believed employees can do more working together than alone」（社員は単独で働くより一緒に働くほうが多くを成せると研究チームが考えたため）と補っています。日本語では「全体は部分の総和に勝る」「全体は部分の総和にあらず」などと訳される言葉です。
ただし、この一文をアリストテレス本人の言葉として断定するのは避けたほうが無難です。W.D.Ross訳の『形而上学』第8巻（1045a8-10）にあるのは「the whole is something besides the parts」で、総和より大きいという量の話ではなく、総和とは別のものだという質の話になっています。総和より大きいという言い回し自体は古くからの通説で、ゲシュタルト心理学者Kurt Koffkaは1935年の『Principles of Gestalt Psychology』で「It has been said: The whole is more than the sum of its parts. It is more correct to say that the whole is something else than the sum of its parts.（全体は部分の総和より大きい、と言われてきた。より正確には、全体は部分の総和とは別のものだと言うべきである）」と訂正しています。それでも今日まで広く流通しているのはgreater形のほうで、Koffkaのこの一文も greater 形へ誤引用され続けています。記事や研修資料で引くときは、Googleがこの格言に敬意を表して命名したという事実までを出典付きで書くのが安全です。
調査規模と時期：エンジニアリング115・営業65の計180チーム
re:Workの記述では、対象は「180 teams to study (115 project teams in engineering and 65 pods in sales)」で、高業績チームと低業績チームが混在するように選ばれました。対象チームの規模は3人から50人で、中央値は9人です。日本語の解説では「100以上のチーム」とまるめられがちですが、この範囲を押さえておくと、後述する「チームの人数は影響しなかった」という結論の射程も正しく読めます。
調査を担ったのはGoogleのPeople Operations（同社が人事部門をこう呼びます）です。The New York Times Magazineの報道によれば、着手は2012年で、People Analytics部門のマネージャーAbeer Dubey氏が主導しました。分析結果はPeople OperationsのアナリストJulia Rozovsky氏が「The five keys to a successful Google team」として2015年11月17日にre:Workブログで公表し、2年間で200件を超えるインタビューと250超の属性、180超のチームのデータを扱ったと記しています。
公表年については情報が割れています。re:Workのガイドは「Originally published 2015」と表示する一方、同じページのEditor’s Noteは「Project Oxygen and Project Aristotle, which were released in 2011 and 2016 respectively」としており、Google自身の記述が2015年と2016年に分かれます。さらに2016年2月25日のThe New York Times Magazine掲載記事（Charles Duhigg「What Google Learned From Its Quest to Build the Perfect Team」）で一般に広まったため、日本語の解説でも年次表記は割れたままです。一次情報の初出は2015年11月17日と押さえたうえで、2016年という表記も誤りと決めつけない、という扱いが実態に合います。
調査対象の線引き：組織図上の部署ではなく相互依存のあるチーム
調査の最初の作業は、そもそも何をチームと呼ぶかの定義でした。re:Workは「work group」を「characterized by the least amount of interdependence」（相互依存が最も少ない）集団とし、組織上の階層に基づいて情報共有のために定期的に集まるものと説明します。対する「team」は「highly interdependent」（相互依存が高い）で、特定のプロジェクトのために計画・問題解決・意思決定・進捗確認を行い、メンバーが互いを必要とする集団です。そのうえで「Organizational charts only tell part of the story」として、組織図ではなくチーム自身の申告で対象を選びました。自社で同じ枠組みを使うなら、部署単位に配るのではなく、実際に仕事が絡み合っている単位で測る必要があります。
調査手法：有効性の測り方と35超の統計モデル
客観指標の断念と、有効性を測る4つの尺度
最初の難所は、効果的なチームをどう測るかでした。研究チームはコード行数、修正したバグの数、顧客満足度などを検討しましたが、当初は客観指標を求めていた経営陣自身が、どの指標にも本質的な欠陥があると気づきます。re:Workの説明はこうです。コード行数は多ければよいものではなく、修正したバグが多いということは、そもそも作り込んだバグが多かったことを意味する。結果として採用されたのが、定性評価と定量指標を組み合わせた次の4尺度でした。
| 尺度 | 原文 | 性質 |
|---|---|---|
| 経営幹部による評価 | Executive evaluation of the team | 定性 |
| チームリーダーによる評価 | Team leader evaluation of the team | 定性 |
| チームメンバーによる評価 | Team member evaluation of the team | 定性 |
| 四半期ノルマに対する営業成績 | Sales performance against quarterly quota | 定量 |
定性評価を3視点に分けたのには理由があります。同じ尺度で採点させたうえで理由を説明させると、幹部は売上や製品ローンチといった結果を重視し、メンバーはチームの文化を最重要と答え、リーダーの認識はその両方にまたがりました。立場が変わると「良いチーム」の定義そのものが変わる。re:Workは定性評価に「had inherent subjectivity」と主観の混入を認めつつ、4つの組み合わせで包括的な定義に近づけたと整理しています。自社で生産性指標を1本に決めようとすると同じ壁に当たります。
属性から相互作用へ、分析の焦点が移った過程
分析には「over 35 different statistical models on hundreds of variables」（数百の変数に対する35種類を超える統計モデル）が投入されました。当初の仮説は、性格特性や学歴、社外での交流頻度といったメンバー属性の組み合わせに正解があるというものでした。Rozovsky氏は、ローズ奨学生1人と外向的な人2人とAngularJSに強いエンジニアと博士号保持者を集めれば理想のチームになるはずだったと当時の期待を書き、「We were dead wrong.（我々は完全に間違っていた）」と結んでいます。
焦点はチーム内の相互作用へ移ります。Anita Woolleyらの集合知研究では、成果を出したグループに共通する特徴として、会話の量がメンバー間でおおむね均等になること（equality in distribution of conversational turn-taking）と、声色や表情から相手の状態を読み取る力の平均値が高いこと（average social sensitivity）が観測されていました。Googleの研究チームはこの知見を参照し、心理的安全性という結論へ向かいます。チームの発達段階を扱う枠組みはタックマンモデルとは？チーム結成から解散までの組織発展プロセスを示す理論と活用メリット、集団の中で働く力学はグループダイナミクスとは？定義・クルト・レヴィンの理論から具体例・活用法まで解説（集団力学）で扱っています。
効果的なチームを支える5つの要因と自己診断サーベイの設問例
re:Workは5要因を重要度順（In order of importance）に提示しています。Rozovsky氏の表現はさらに明確で、「Psychological safety was far and away the most important of the five dynamics we found」（心理的安全性は5つの中で群を抜いて重要だった）に続けて「it’s the underpinning of the other four」（他の4つの土台である）と書かれています。
| 順位 | 要因 | 原語 |
|---|---|---|
| 1 | 心理的安全性 | Psychological safety |
| 2 | 相互信頼 | Dependability |
| 3 | 構造と明確さ | Structure and Clarity |
| 4 | 仕事の意味 | Meaning |
| 5 | インパクト | Impact |
以下の各項で引く英文は、研究で使われた測定尺度そのものではありません。研究結果を受けてGoogleがチーム自身に配った自己診断サーベイの設問例で、re:Workは「Survey items focused on the five effectiveness pillars and questions included」と前置きしたうえで各1文を挙げています。要因名だけを覚えるより、この言い回しのほうが自社での運用価値があります。
心理的安全性：ミスが不利益に直結しないという共有認識
設問例は「If I make a mistake on our team, it is not held against me.（このチームでミスをしても、それを理由に不利益を被らない）」です。居心地の良さや人間関係の親密さを一切聞いていません。問うているのは、失敗を表に出したときに何が起きるかという一点です。最上位に置かれた理由もここにあり、分からないと言えなければ役割の曖昧さは表面化せず、遅れそうだと言えなければ相互信頼も成立しません。職場での高め方は人事担当者・管理職必読：心理的安全性を理解する方法。安心して意見交換できる組織環境の意義と必要性を解説で詳しく扱っています。
相互信頼：宣言した仕事が期限内に完了する度合い
設問例は「When my teammates say they’ll do something, they follow through with it.（チームメイトがやると言ったことは、実際にやり遂げられる）」です。原語のDependabilityは信頼性とも訳されますが、測っているのは人柄への信頼ではなく、宣言と完了の一致率です。改善策も意識づけではなく、着手前に完了条件を言語化する、期限が危うくなった時点で報告する経路を用意するといった手続きの側に置くほうが効きます。
構造と明確さ：決め方が機能しているかという観点
設問例は「Our team has an effective decision-making process.（このチームには機能する意思決定プロセスがある）」です。目標や役割が明確かではなく、決め方が機能しているかを問う。ここが実務的です。目標と役割は文書化した時点で明確になったつもりになれますが、決め方は毎回の会議で試されます。誰が決めるのか、決まらなかったときにどこへ持ち上げるのかが定まっていないチームは、この設問で低い値が出る。目標設定の枠組みはMBO（目標管理制度）とは？目標例・評価への反映とOKRとの違いを参照してください。
仕事の意味：本人にとっての仕事の価値
設問例は「The work I do for our team is meaningful to me.（チームのために自分がしている仕事は、自分にとって意味がある）」です。主語が「自分にとって」である点が重要で、会社の掲げる理念に共感しているかを聞いてはいません。経済的な安定、家族を支えること、技能が伸びる実感など、意味の中身は人によって違ってよいという前提です。全社ビジョンの唱和で埋めようとすると、この設問が測る対象からはずれます。
インパクト：組織目標への貢献の見え方
設問例は「I understand how our team’s work contributes to the organization’s goals.（自分たちのチームの仕事が、組織の目標にどう貢献しているか理解している）」です。前項の「意味」が個人の内側を向くのに対し、こちらは組織との接続を向いています。意味は満たされているのにインパクトが分からない（やりがいはあるが何の役に立っているか不明）という状態も、その逆も起こり得るため、2つを1つの施策でまとめて解決しようとしない切り分けが要ります。
5要因を測ったあとの実測値：新しい規範1つで心理的安全性6%改善
Googleは調査結果を配って終わりにせず、5要因を10分で測るgTeams exerciseというツールを作り、結果の要約レポートと対面での議論、改善資料をセットで提供しました。Rozovsky氏の報告では、1年間で300チーム3,000人超が利用し、そのうち新しいグループ規範を1つ取り入れたチーム、たとえば毎回の会議の冒頭で先週取ったリスクを共有するようにしたチームでは、心理的安全性の評点が6%、構造と明確さの評点が10%改善しています。数字の大きさより施策の粒度に注目する価値があり、研修でも制度改定でもなく、会議の冒頭に手順を1つ足しただけです。
チームの成果に影響しなかった8項目
5要因と同じくらい実務で使えるのが、re:Workが「有効性と有意な関係が見られなかった」と明記した項目のリストです。次の8つが挙げられています。
- 同じオフィスに一緒に座っていること（Colocation of teammates）
- 合意形成型の意思決定（Consensus-driven decision making）
- メンバーの外向性（Extroversion of team members）
- メンバー個人の業績（Individual performance of team members）
- 仕事量の多さ（Workload size）
- 年功・職位の高さ（Seniority）
- チームの人数（Team size）
- 在籍年数（Tenure）
組織施策の議論で持ち出される定番が、ほぼそのまま並んでいます。全員出社に戻せば結束が高まる、全員一致で決めるほうが納得感がある、エース級を集めれば強くなる。こうした主張は、少なくともこの調査の範囲では有効性と結びつきませんでした。個人の業績が入っている点はとくに重く、人事評価の高い人を集めることとチームが機能することは別問題になります。
ただしre:Work自身が留保を付けています。Googleで有意でなかったからといって他所で重要でないという意味ではない、として、チーム人数については10人未満のほうがチームの成功に有利だとする研究群（Katzenbach & Smith, 1993／Moreland, Levine, & Wingert, 1996 ほか）を挙げています。前述のとおり調査対象は3人から50人、中央値9人でしたから、この範囲内では差が出なかったという読み方が妥当です。合意形成型の意思決定については、対立を避けること自体が目的化しやすい論点でもあるため、コンフリクトマネジメントとは何か：意味・定義をわかりやすく丁寧に解説し、実践に役立つ完全ガイド【入門編】で扱う健全な対立の考え方と併せて検討してください。
心理的安全性の原典と、日本でよく起きる誤読
Edmondson 1999年論文における定義と対人的リスクの中身
心理的安全性はプロジェクトアリストテレスが生んだ概念ではなく、Googleが既存の学術概念を借りたものです。原典はAmy Edmondsonの論文「Psychological Safety and Learning Behavior in Work Teams」（Administrative Science Quarterly, Vol.44, No.2, June 1999, pp.350-383）で、定義は次の一文になります。
「Team psychological safety is defined as a shared belief that the team is safe for interpersonal risk taking.（チームの心理的安全性とは、そのチームが対人的なリスクを取っても安全だという、メンバーに共有された信念である）」
定義の中心は対人的リスクを取れることです。無知だと思われる、無能だと思われる、邪魔だと思われる、否定的だと思われる。そう見られる危険を承知で、質問し、失敗を報告し、異議を唱えられる状態を指します。安心して働ける、雰囲気が良いといった訳語で流通した結果、この輪郭が日本ではかなり削れました。
結束との相違と、混同したときの逆効果
同じ論文には、混同を明確に否定する一文があります。「Team psychological safety is not the same as group cohesiveness, as research has shown that cohesiveness can reduce willingness to disagree and challenge others’ views, such as in the phenomenon of groupthink (Janis, 1982), implying a lack of interpersonal risk taking.（チームの心理的安全性は集団の結束と同じではない。結束は、集団思考の現象に見られるように、異議を唱え他者の見解に挑戦する意欲をむしろ低下させ得ることが研究で示されているからである）」
結束を高める打ち手が、心理的安全性を下げる方向に働き得るという指摘です。ここは断言してよい部分だと考えます。懇親会を増やす、チームの一体感を強調する、批判的な発言を場の空気を乱すものとして扱う。仲の良さは作れますが、Edmondsonの定義でいう異議を唱える意欲は削れていきます。心理的安全性の施策としては失敗パターンです。
ゆるさとの混同：成果水準の引き下げは定義の外
逆向きの誤読もあります。何を言っても許される状態と受け取り、成果基準を下げてしまうケースです。Edmondsonは1999年の同じ論文で「The term is meant to suggest neither a careless sense of permissiveness, nor an unrelentingly positive affect but, rather, a sense of confidence that the team will not embarrass, reject, or punish someone for speaking up.（この語は、不注意な放任も、際限なく前向きな感情も意味しない。発言したことでチームが恥をかかせたり、拒絶したり、罰したりしないという確信を指す）」と釘を刺しています。Googleのサーベイ設問に戻れば分かりやすく、聞いているのは「ミスをしても不利益を被らないか」であって、「ミスをしても問題にならないか」ではありませんでした。ミスの事実は問題として扱い、その人の立場は脅かさない。この線引きが実装すべき内容です。
日本企業がこの研究を導入するときに外しやすい3点
5要因の並列配布による着手順の誤り
re:Workは5つを重要度順に提示していますが、日本語の解説では並列の5項目として紹介されるのがほとんどです。実際、上位表示されている解説記事は5要因を横並びのリストとして並べており、心理的安全性が最も重要だとする記述はあっても、5つ全体が重要度順に並んでいること（In order of importance）に触れているものは見当たりません。並列で配ると、現場は着手しやすいものから手を付けます。多くの場合それは「構造と明確さ」で、目標と役割の文書化から始まる。ところが1位に置かれた心理的安全性が低いままだと、役割を明確にする作業自体が責任の押し付け合いとして受け取られます。順序には意味があるという前提で着手順を決めてください。
診断設問の過剰な翻案による測定対象のすり替え
前掲の5つの設問例は短く、抽象度も低く設計されています。これを社内サーベイに載せる際、丁寧に言い換えようとして「チームの雰囲気は良いと感じますか」「上司は話しやすいですか」といった文に置き換えると、測る対象が変わってしまいます。とくに心理的安全性の設問は、行動の結果（不利益を被るか）を問うており、感情や印象を問うてはいません。翻案するなら、主語を自分にする、結果を問う形にする。この2点は保ってください。
研究の射程を超えた一般化と「Googleがそう言っている」論法
この調査は、Googleが自社の180チームを対象に、自社の評価尺度で行った社内リサーチです。査読論文として発表されたものではなく、対象は職種も事業もGoogleの内部に限られます。日本の中小企業や、多重下請け構造を含む受託開発の現場にそのまま一般化できる保証はどこにもありません。妥当な使い方は、5要因を仮説として自社で測り直し、自社のデータで確かめることです。心理的安全性という言葉を持ち出す根拠としてGoogleの権威に寄りかかるより、Edmondsonの定義と自社の測定結果に寄りかかるほうが、社内の議論は前に進みます。
よくある質問
アリストテレスプロジェクトとは何ですか？
プロジェクトアリストテレスと同じ調査を指す別の呼び方です。日本語ではプロジェクト・アリストテレス、アリストテレスプロジェクト、チームアリストテレスといった表記も使われ、英語表記はProject Aristotleになります。いずれもGoogleが2012年に着手し、社内180チーム（エンジニアリング115・営業65）を分析した調査を指します。
プロジェクトアリストテレスの結論は何ですか？
チームの成果を左右するのは誰がメンバーかではなく、メンバー同士がどう関わるかである、という結論です。具体的な要因としては、心理的安全性、相互信頼、構造と明確さ、仕事の意味、インパクトの5つが重要度順に挙げられ、うち心理的安全性が他の4つの土台と位置づけられました。
プロジェクトアリストテレスの名前の由来は何ですか？
アリストテレスの言葉とされる「全体は部分の総和に勝る（the whole is greater than the sum of its parts）」に敬意を表した命名だと、re:Workが説明しています。社員は単独で働くより一緒に働くほうが多くを成せる、という研究チームの見立てを名前に込めたものです。
プロジェクトアリストテレスの論文はありますか？
査読付き学術論文としては公表されていません。一次情報にあたるのは、Googleが運営するre:Workのガイド「Understand team effectiveness」と、People OperationsのJulia Rozovsky氏が2015年11月17日に同ブログへ投稿した「The five keys to a successful Google team」です。ただし核となる心理的安全性については、Amy Edmondsonが1999年にAdministrative Science Quarterly誌（Vol.44, No.2, pp.350-383）へ発表した査読論文が原典として存在します。
心理的安全性が高いチームは仲の良いチームということですか？
違います。Edmondsonの1999年論文は、心理的安全性は集団の結束（group cohesiveness）と同じではないと明記し、結束はむしろ異議を唱える意欲を低下させ得ると指摘しています。測っているのは、ミスや反対意見を表に出したときに不利益を被らないかであって、人間関係の親密さではありません。
