エンジニアマネージャーのための称賛の技術
「褒める」のが苦手なのは、あなただけじゃない
「メンバーを褒めた方がいい」——頭ではわかっている。でも、いざ言葉にしようとすると、どこかぎこちなくなってしまう。
「お世辞みたいで嘘くさくならないか」 「そもそも何を褒めればいいのかわからない」 「技術的なことは評価できるけど、それ以外は...」
エンジニアからマネージャーになった方の多くが、この壁にぶつかります。コードレビューならいくらでもフィードバックできるのに、なぜ「称賛」だけがこんなに難しいのでしょうか。
Google社のre:Workプロジェクトの調査によると、**チームのパフォーマンスに最も影響を与える要因は「心理的安全性」**であり、その構築には日常的な称賛が不可欠とされています。しかし、エンジニア出身のマネージャーの約70%が「褒めることに苦手意識がある」という調査結果も存在します。
「論理的な自分には向いてない」という思い込み
「私は論理的な人間だから、感情的なコミュニケーションは苦手」 「エンジニアリングは客観的な評価ができるけど、褒めるのは主観的すぎる」 「下手に褒めて、逆にモチベーションを下げたらどうしよう」
こんな風に感じていませんか？実は、これらの不安を抱えているのはあなただけではありません。
技術の世界では「問題を見つけて指摘する」ことが価値とされてきました。バグを見つけ、パフォーマンスのボトルネックを指摘し、より良いアーキテクチャを提案する。私たちは「何が足りないか」を見つけるトレーニングを長年受けてきたのです。
だからこそ、「何がうまくいっているか」に目を向けることに違和感を覚えるのは、ある意味で自然なことです。
しかし、マネージャーになった今、求められるスキルセットは変わりました。そして朗報があります。**称賛は「才能」ではなく「技術」です。**エンジニアリングと同じように、学び、練習し、上達することができます。
称賛は「スキル」として習得できる
称賛の技術フレームワーク
称賛を「なんとなく感じのいいことを言う」と捉えていると、難しく感じます。しかし、エンジニアリング的に分解すれば、称賛は以下の要素で構成される「技術」であることがわかります。
称賛 = 観察（Observation）+ 具体性（Specificity）+ タイミング（Timing）+ 誠実さ（Sincerity）
この公式を覚えておけば、「何を」「いつ」「どう」褒めればいいか、迷わなくなります。
Googleのマネージャー育成プログラムでも、称賛は「学習可能なスキル」として位置づけられています。そして、このスキルを身につけたマネージャーのチームは、エンゲージメントスコアが平均40%向上し、離職率が25%低下したというデータもあります。
エンジニアマネージャーのための称賛テクニック5選
では、具体的にどのように称賛すればいいのでしょうか。エンジニア出身のマネージャーが実践しやすい、具体的なテクニックをご紹介します。
称賛テクニック5選
1. 「事実 + 影響」フォーマットを使う
曖昧な称賛は、むしろ逆効果になることがあります。「すごいね」「よくやったね」だけでは、何が良かったのか伝わりません。
代わりに、「事実 + 影響」のフォーマットを使いましょう。
NGパターン： 「いい仕事したね」
OKパターン： 「今回のAPIリファクタリングで、レスポンスタイムが30%改善された（事実）。おかげでユーザーからの問い合わせも減って、CSチームも助かっている（影響）」
このフォーマットなら、客観的な事実に基づいているため、「お世辞」に聞こえません。エンジニア特有の「具体的じゃないと気持ち悪い」という感覚を活かせます。
2. 「プロセス称賛」で成長を促す
結果だけでなく、プロセスを称賛することで、チームの心理的安全性は大きく向上します。
プロセス称賛の例：
- 「あのバグ、原因特定までのアプローチが論理的で良かった」
- 「わからないことを早めに質問してくれたのは正解だった」
- 「新しい技術をキャッチアップしようとしている姿勢、チームに良い刺激になってる」
特にエンジニアは「結果が出なかった＝失敗」と考えがちです。プロセスを称賛することで、「チャレンジすること自体が評価される」という組織風土を作ることができます。
3. 「1on1」を称賛の定期実行タイミングにする
称賛を「思いついたときにする」だと、忙しいときは後回しになりがちです。
1on1ミーティングに「称賛タイム」を組み込むことをお勧めします。
毎回の1on1の冒頭5分を「今週良かったこと」の共有に使いましょう。これにより、称賛が「やるべきタスク」として定期実行され、習慣化しやすくなります。
「事前に何を褒めるか考えておく」——これだけで、称賛のハードルは大きく下がります。
4. 「書いて残す」で称賛を可視化する
口頭での称賛は、言った側は覚えていても、言われた側は忘れてしまうことがあります。
テキストで残す称賛は、以下のメリットがあります。
- 後から読み返せる（モチベーションの貯金）
- 他のメンバーにも見える（良い行動の伝播）
- 評価面談の材料になる（具体的なエビデンス）
SlackやTeamsのパブリックチャンネルで称賛を送る、あるいはSeediaのようなありがとうを可視化するツールを活用することで、称賛文化を組織全体に広げることができます。
5. 「小さな称賛」を高頻度で行う
年に1回の「すごい称賛」より、週に複数回の「小さな称賛」の方が、心理的安全性の構築には効果的です。
日常的に称賛できるポイント：
- PR（Pull Request）をレビューしてくれたとき
- ミーティングで発言してくれたとき
- ドキュメントを更新してくれたとき
- 他のメンバーを助けていたとき
「当たり前」と思っていることこそ、称賛のチャンスです。小さな称賛の積み重ねが、チームの空気を変えていきます。
称賛がもたらす好循環
こんなエンジニアマネージャーにおすすめ
称賛の技術を身につけることで、特に以下のような課題を感じている方に効果があります。
- 技術力は高いが、マネジメントに苦手意識がある
- 1on1で何を話せばいいかわからない
- チームの雰囲気が硬く、発言が少ない
- 優秀なメンバーの離職が続いている
- 「怖い上司」と思われている気がする
エンジニアリングスキルを磨いてきたように、称賛スキルも磨くことができます。そして、このスキルはマネージャーとしてのキャリア全体を通じて、最もROIの高い投資になるでしょう。
組織風土は一人のマネージャーの行動から変わり始めます。あなたの「称賛」が、チームの心理的安全性を育て、エンゲージメントを高め、離職率を下げる第一歩になります。
まとめ：称賛は「技術」、今日から実装を始めよう
「褒めるのが苦手」は、変えられます。称賛は才能ではなく技術であり、エンジニアリングと同じように、学び、練習し、上達することができます。
今日から始める3つのステップ：
- 「事実 + 影響」フォーマットで、具体的な称賛を1つ書き出す
- 次の1on1で、冒頭5分を称賛タイムに設定する
- パブリックなチャンネルで、チームメンバーに感謝を伝える
コードを書くように、称賛も「まずは実装してみる」ことが大切です。最初は不完全でも構いません。リファクタリングしながら、少しずつ上達していけばいいのです。
あなたの「ありがとう」が、チームのパフォーマンスを最大化するきっかけになるかもしれません。今日から、称賛の実装を始めてみませんか？
