「天才だ」という褒め言葉がエースを潰す理由
「天才だ」のような能力中心の褒め言葉は、うれしい承認であると同時に、守らなければならないアイデンティティを生み出すことがあります。リーダーは人を評価するのではなく、観察した行動、判断、影響と、それを次に再現する方法を具体的に伝えるほうがよいでしょう。
「天才だ」という言葉は、成果ではなく人の固定的な能力を評価するため、失敗や助けを求めることの心理的コストを高める可能性があります。
褒める際は、観察した状況と行動、その行動がもたらした影響を具体的に結び付けることで、学びにつながる情報になります。
努力そのものを無条件に褒めるのではなく、効果的な戦略、修正のプロセス、協働や検証の行動を認める必要があります。
良い結果が出たときだけエースを褒めると、業務の集中、知識の独占、過労、チームの依存といったリスクが高まる可能性があります。
褒め言葉はできるだけ速やかに伝えつつ、公にするかどうかや表現方法については、本人の好みと組織の状況を考慮する必要があります。
称賛は人を動かす強力なシグナルだ。しかし、「最高だ」「さすがエースだ」「天才だ」のように、人の能力やアイデンティティを断定する言葉は、意図とは異なる結果を招くことがある。メンバーが仕事そのものよりも、「今回も有能だという評価を守らなければならない」というプレッシャーに意識を向ける可能性があるからだ。
だからといって、称賛をなくすべきだという意味ではない。重要なのは、人を格付けする称賛を減らし、再び活用できる行動や判断を伝える承認へと変えることだ。
「天才」は説明ではなくアイデンティティへの評価だ
「天才」という言葉は、複雑な成功のプロセスを一つの生まれ持った能力に集約する。何を観察し、どのような行動が効果的だったのかは伝えないまま、その人全体に高い評価を与える。
こうした表現を繰り返し聞いたメンバーは、次のようなプレッシャーを感じることがある。
· 簡単な課題はできて当然であり、難しい課題での失敗は能力不足の証拠になる。
· 分からないと言ったり助けを求めたりすると、エースという評判を失うように感じる。
· 試行錯誤が必要な課題より、成功する可能性が高い課題を選ぶようになる。
· 成果を生み出した協働や環境よりも、個人の才能を過大評価するようになる。
· 同僚もその人の判断を検証するより、「エースがうまくやってくれるだろう」と考えることがある。
創作物では、「天才」という設定だけで人物の非凡さを素早く伝えられる。現実の組織では、設定ではなく、観察可能な判断、行動、結果が必要だ。実際の行動によって裏付けられていない天才という評価は、本人にはプレッシャーとなり、同僚には不公平な特別扱いに見えることがある。
研究が示していることと、示していないこと
Carol DweckとClaudia Muellerの研究では、課題で成果を上げた後に知能を褒められた子どもは、努力を褒められた子どもよりも、自分の成果を証明しようとする目標を多く選び、失敗後の粘り強さやパフォーマンスにおいて不利な反応を示した。発表年は研究の原文で確認できる。この研究は、「頭がいい」のような能力への称賛が、挑戦を前にすると脆弱になる動機を生み出し得る根拠として広く引用されている。
ただし、この結果をすべての社会人やあらゆる称賛にそのまま当てはめてはならない。
· 代表的な実験の参加者は子どもだった。成人の業務環境を直接検証した実験ではない。
· 称賛の効果は、表現だけでなく、関係性、信頼、公開か非公開か、評価制度や報酬体系によって変わる。
· プロセスへの称賛も、曖昧だったり統制的に聞こえたりすれば役に立たない。
· 承認が実際の成果に及ぼす効果を調べた職場でのフィールド研究もあるが、特定の設計による結果をすべての組織に一般化することはできない。
称賛に関する研究を総合したレビュー論文では、称賛は常に内発的動機を高めたり下げたりする単純な刺激ではないと説明されている。受け手がその言葉を、有能さを伝える情報として解釈するのか、統制や評価として解釈するのか、真実だと信じるのかが重要だ。
承認、称賛、フィードバックはどう違うのか
この3つの表現は日常では混同して使われるが、機能は異なる。
区分 | 中心となる問い | 例 | 注意点
承認 | どのような貢献に気づいたか | 「会議前に論点を整理してくれたおかげで、意思決定が速くなりました。」 | 感謝だけを伝え、学びにつながる情報を欠くことがある。
称賛 | 何を肯定的に評価しているか | 「説明が明確でした。」 | 根拠がなければ、お世辞や格付けのように聞こえる。
フィードバック | 何を維持し、何を変えるべきか | 「比較表によって選択基準が分かりました。次回もコストとリスクを併記してください。」 | 過度に指示的だと、自律性を低下させることがある。
優れたリーダーの言葉は、3つの機能をつなげる。貢献に気づき、観察した根拠を示し、次の行動に活用できる情報を残す。
効果的な称賛の4つの原則
1. 人の特性より、観察した行動を伝える
「几帳面ですね」と言うより、何を見てそう判断したのかを説明する。
· 曖昧な表現:「さすが完璧です。」
· 具体的な表現:「リリース前に3種類のユーザー権限で再確認し、アクセスエラーを発見しました。」
具体的な称賛は、メンバーにどのような行動を繰り返すべきかを伝える。同僚にも成功から学ぶ手がかりを提供する。
2. 行動と影響を結びつける
行動だけを並べると、監視されているように感じさせることがある。その行動が顧客、チーム、品質、スケジュールにどのような影響を与えたのかを結びつける。
· 「顧客からの質問を種類別にまとめてくれたおかげで、サポートチームが同じ回答を繰り返し作成せずに済みました。」
· 「反対意見を先に尋ねたことで、会議で見落としかけていたリスクを発見できました。」
影響は誇張せず、確認可能な範囲で伝えるべきだ。売上増加のように因果関係を確認しにくい結果を、一人だけの功績だと断定してはならない。
3. 効果的なプロセスと判断を認める
プロセスへの称賛とは、単に「頑張った」と言うことではない。有効だった戦略や修正行動を具体的に指摘することだ。
· 仮説を立て、小さな実験で検証した行動
· エラーを隠さず、迅速に共有した行動
· 顧客の意見を反映して草案を修正したプロセス
· 同僚に情報を引き継ぎ、ボトルネックを減らした協働
· 失敗の原因を記録し、次の試みを変えた判断
効果のない方法を長く繰り返した人に「努力したからそれでいい」と言えば、期待の低さを伝えてしまうこともある。努力の量よりも、戦略の質、学びと修正を併せて見る必要がある。
4. できるだけ間を空けず、一貫した基準で伝える
行動と称賛の間隔が短ければ、メンバーはどの場面について話しているのか理解しやすい。四半期末の評価まで待つより、業務が終わった直後に簡潔に伝えるほうが有用だ。
ただし、「すぐに」が「衝動的に」という意味ではない。事実関係を確認する必要がある場合や、感情が高ぶっている状況では、整理してから伝えるべきだ。人前で褒められることを負担に感じる人には、個別メッセージや1対1の会話のほうが適していることもある。
一貫性とは、全員を同じ回数だけ褒めるという意味でもない。役職や親密さではなく、事前に共有された業務基準に基づいて貢献を認めることを意味する。
実務で使える称賛の文章構造
次の3つの要素を順番につなげれば、誇張せず具体的に伝えやすい。
観察した状況と行動 → 確認された影響 → 再利用または発展させる点
例は次のとおりだ。
· 「今日の報告で、不確実な数値を推定値だと明確に表示していました。そのおかげで、意思決定者が確定値と仮定を区別できました。次の報告書でも同じ表示方法を使ってください。」
· 「障害の原因を特定できていない段階でも、先に現状を共有しました。サポートチームが顧客に遅延状況を早めに案内できました。次回は初期点検項目も一緒に残してみましょう。」
· 「会議で新人メンバーの意見をもう一度尋ねました。既存案で見落としていたユーザビリティ上の問題を発見できました。次の企画会議でも、さまざまな役割の人の意見を確認してください。」
再現方法をリーダーが断定しにくい場合は、質問で締めくくることもできる。
· 「今回、最も効果的だった判断は何でしたか?」
· 「次のプロジェクトでも維持したい方法は何ですか?」
· 「チームでこの方法を共有するには、何を文書化するとよいでしょうか?」
結果がよくなかったときにも認められること
結果が失敗だったのに、成功したかのように褒めると信頼を失う。反対に、結果が悪いときに、すべてのプロセスまで無価値なものとして扱えば、メンバーはリスクを隠し、安全な課題だけを選ぶようになる。
失敗した状況では、結果、有効だった行動、改善点を分ける。
· 結果:「今回の提案は顧客に選ばれませんでした。」
· 承認:「決定直後に顧客へ理由を確認し、チームに共有した行動はよかったです。」
· 改善:「次回は価格だけでなく、導入に必要な社内人員も早い段階で確認してみましょう。」
「最善を尽くしたから大丈夫」で終わらせず、何を学び、次の試みで何を変えるのかを確認しなければならない。これが失敗を美化せず、心理的安全性を守る方法だ。
エースへの称賛がチームの構造的リスクになる瞬間
一人をエースとして繰り返し名指しする問題は、個人の動機だけにとどまらない。業務と意思決定権がその人に集中すれば、組織運営上のリスクへと拡大することがある。
リスク | 現れる可能性のある兆候 | リーダーがすべきこと
業務の過度な集中 | 難しい仕事と緊急業務が、いつも同じ人に割り当てられる。 | 業務量を確認し、責任と機会を分散する。
支援要請の回避 | エースが問題を一人で解決した後、遅れて報告する。 | 早期共有や助けを求める行動自体を肯定的に認める。
知識の独占 | 文書がなく、特定の人しか手順を知らない。 | 文書化、ペア作業、相互教育を貢献として評価する。
検証の弱体化 | 同僚がエースの判断に疑問を呈さない。 | 反論とレビューの役割を正式な手順にする。
特別扱いという認識 | 同様の貢献をした同僚が認められない。 | 称賛の基準を公開し、目に見えない支援業務も観察する。
アイデンティティの重圧 | ミスの隠蔽、完璧主義、休息の回避が現れる。 | 成果と個人の価値を切り分け、休息と代替要員を確保する。
本当のエースを守る方法は、より多くの仕事を集中させ、さらに大げさな修飾語を付けることではない。その人が生み出した判断や知識をチームの能力へと転換し、不在でも業務が機能するようにすることだ。
リーダーが避けるべき称賛
· 比較による称賛:「ほかのチームメンバーと違って、君は確かに頭がいい。」競争と上下関係だけを強めることがある。
· **誇張された称賛:**小さな修正に対して「会社史上最高の成果」と言えば、その後の承認に対する信頼性が低下する。
· 統制型の称賛:「よい社員なら、当然こうするべきだ。」承認のように見えるが、服従を求めている。
· **意図が混じった称賛:**褒めた直後に追加業務を任せるパターンが繰り返されると、承認が業務割り当てのシグナルとして解釈される。
· **功績を独占させる称賛:**複数人で生み出した結果を、目立つ一人の天才性によるものとして説明する。
· **人格と結果の結びつけ:**一度の成功を「君は成功する人だ」、一度の失敗を「やはり能力が足りない」と拡大解釈する。
称賛を組織の学習データにする方法
個人に好意的な言葉をかけるだけで終わらせず、成功を生み出した行動をチームの知識として残すことができる。これは、「一人の天才」への依存を減らすための別の運用手段だ。
· 称賛した行動を振り返りの記録に一文で残す。
· 成果を生み出した条件と協力者を併せて確認する。
· 繰り返し使える方法は、チェックリストや事例として整理する。
· 結果だけでなく、早期警告、文書化、検証、同僚への支援も承認項目に加える。
· 誰が頻繁に認められ、誰が抜け落ちているのかを定期的に確認し、偏りを点検する。
称賛の目的は、メンバーに「天才に見え続けなければならない」と要求することではない。自分が何をうまくできたのかを理解し、難しい問題に直面しても質問し、学び、その方法を同僚と共有できるようにすることだ。