1on1が苦痛な組織を変える評価制度｜エンジニアが納得する対話術

IT業向け

評価シートサンプルが無料でダウンロードができます。

ご入力いただいた個人情報の管理、利用については「プライバシーポリシー（個人情報保護方針）」の記載に基づき、適切に運用致します。
コンサルタントや専門士業など、同業・競合他社に該当する方のお申し込みはお断りしております。

どれほど緻密に設計された評価制度であっても、それが社員に伝わり、腹落ちしていなければ存在しないも同然です。多くの企業が等級定義や報酬テーブルといった制度の「器（ハードウェア）」を作ることに心血を注ぎますが、実際にそのシステムを動かす「OS（伝える技術）」を軽視している現状があります。

1. 評価制度は「作る」より「伝える」ほうが難しい

制度の意図が現場で「誤認」されるメカニズム

エンジニアという職種は、職業柄「定義」や「仕様」に極めて敏感です。プログラムの世界では、定義されていない変数はエラーを吐きます。同じように、人事評価においても言葉の定義が曖昧なまま運用が始まると、彼らは混乱し、やがて不信感を抱きます。

例えば、経営陣が「失敗を恐れず挑戦してほしい」という意図で作った加点主義の制度があったとします。しかし、現場のマネージャーがその意図を汲み取れず、面談の場で「今回の挑戦は失敗だったから、評価はステイだね」と伝えてしまったらどうなるでしょうか。

その瞬間、エンジニアの中でその制度は「リスクを冒すと損をする減点主義のシステム」として認識（コンパイル）されます。一度刻まれた認識を覆すのは容易ではありません。制度設計者と運用者（マネージャー）の間で、「この項目の真意は何か」「どんな行動を推奨したいのか」という解釈の同期（シンクロ）が取れていないことが、多くの組織崩壊の引き金となっています。

「評価イベント」から「成長支援」への意識変革

多くの現場において、半年に一度の査定面談は「憂鬱なイベント」になりがちです。それは、面談が「過去半年の罪状認否と判決の場」になっているからです。
エンジニアが求めているのは、変えられない過去に対する裁きではありません。「これからの半年、どうすれば自分の技術力が上がり、市場価値が高まるか」という未来への指針です。

1on1や評価面談を、「給与を決める手続き」から「未来のパフォーマンスを最大化するための作戦会議」へと再定義してください。

「今の君のコードはここが課題だ」ではなく、「君が目指すアーキテクトになるためには、次のプロジェクトでこの設計パターンを試してみるといい。そのために会社はこう支援する」という対話が行われるとき、評価制度は初めて「成長のエンジン」として機能し始めます。

信頼関係（ラポール）の土台がない場所にフィードバックは機能しない

テクニック以前の問題として、日常的な信頼関係（ラポール）の欠如があります。
「普段のプルリクエスト（PR）も見ていない」「Slackでの発言も追っていない」上司から、半年に一度だけ「もっと技術力を上げろ」と言われても、エンジニアの心には「お前に何がわかる」という反発しか生まれません。

心理学において、厳しいフィードバックが受け入れられる条件は「相手は自分の成長を心から願っている」という安全基地（Psychological Safety）がある場合のみです。

1on1は、制度上の義務として行うものではなく、日々のコードレビューや雑談を通じて積み上げた信頼を確認する場です。「あなたの仕事をちゃんと見ていますよ」というシグナルを日常的に発信し続けることが、評価運用における最大の準備作業となります。

2. IT現場で嫌われる「抽象的なフィードバック」の例

エンジニアは論理的であることを是とする生き物です。そのため、「頑張った」「元気が足りない」といった定性・抽象的な評価を「根拠がない（＝バグ）」と断じ、評価者への信頼を即座に失います。現場でよく聞かれる「ダメな言い回し」を解剖し、どのように改善すべきかを探ります。

「もっと主体性を持ってほしい」という言葉の罠

この表現はIT現場で最も嫌われる言葉の筆頭です。「主体性」という言葉の解像度が、人によって全く異なるからです。

上司の意図：「会議でもっと発言してほしい」
部下の解釈：「勝手に仕様を決めて実装していいということか？」

このズレが致命的な事故を生みます。エンジニアからすれば「具体的にどのプロジェクトの、どのフェーズで、どのようなアクションをとれば主体性があると判定されるのか」という受け入れ条件（Acceptance Criteria）が見えないタスクは、実行不可能です。

【改善案：行動事実への変換】
「主体性」という言葉を使わずに伝えます。
「今期のプロジェクトにおいて、設計上のボトルネックを見つけた際、PMからの指示を待つのではなく、自分から修正案をWikiにまとめてSlackで共有し、チームの合意を取り付ける動きを期待している」
これなら、エンジニアは何をすべきか明確に理解できます。

「技術力は高いが、コミュニケーションに課題がある」の不正確さ

「コミュ力」という言葉も、IT業界ではあまりに広義に使われすぎています。

要件定義でお客様の要望を引き出す力なのか？
チーム内での進捗アラートをあげるタイミングの早さなのか？
コードレビューでの言葉選び（言い回し）の配慮なのか？

これらを十把一絡げにして「コミュニケーションに課題」と伝えると、エンジニアは「自分は人格否定された」と感じてしまいます。

【改善案：場面の特定と代替案の提示】
「コードレビューの際、『このコードはダメ』と否定から入るのではなく、『この書き方だとメモリ効率が悪いので、こちらのライブラリを使ってはどうか』と代替案をセットで提示するようにしてほしい。そうすれば、後輩も萎縮せずに君の技術を吸収できる」
このように、「場面（Situation）」「行動（Behavior）」「影響（Impact）」をセットで伝えるSBIモデルを活用することで、フィードバックは納得感のあるものに変わります。

納得感を阻害する「他者との比較」による評価

「Aさんに比べて君は実装が遅い」といった比較は、百害あって一利なしです。エンジニアのプライドを傷つけるだけでなく、「じゃあAさんがいないプロジェクトに行きたい」という逃避行動や、チーム内の不必要な敵対関係を生みます。

評価はあくまで「本人が期初に立てた目標」や「グレード定義（等級基準）」との絶対評価であるべきです。
比較対象を「隣の誰か」ではなく、「半年前の自分（過去）」や「目指すべきグレード像（理想）」に置いてください。「半年前は単体テストで苦戦していたが、今は結合テストのシナリオまで書けるようになったね」という対話こそが、自己効力感を高めます。

3. 目標設定（OKR/KPI）をエンジニアの言語に翻訳する方法

多くのマネージャーが悩むのが、「会社の数字目標」と「個人の技術目標」の接続です。売上や利益といった経営数値を、そのままエンジニアの個人目標にブレイクダウンしても、彼らのモチベーションエンジンには点火しません。「翻訳」が必要です。

「売上目標」を「技術的な課題解決」に変換する

例えば「サービスの売上120%達成」という会社目標があるとします。これをエンジニアにそのまま渡しても「それは営業の仕事でしょ」となります。
ここでマネージャーの手腕が問われます。売上を上げるために技術ができることは何か？

ユーザー離脱を防ぐための「ページの表示速度改善（Core Web Vitals向上）」
新機能を高速で市場投入するための「CI/CDパイプラインの整備」
アクセス増に耐えるための「サーバーレスアーキテクチャへの移行」

このように、「ビジネス上の成功（売上）が、君の技術的関心（アーキテクチャ刷新など）をどう満たすのか」というストーリーを紐付けることが重要です。「君がこの技術的負債を解消してくれることが、結果として会社の売上目標を支える最大の柱になるんだ」という動機付けが、エンジニアの魂を揺さぶります。

OKR（目標と主要な結果）を用いた野心的な挑戦の奨励

一般的なMBO（目標管理）では、「達成率100%」が評価の基準になりがちです。すると、エンジニアは評価を下げるリスクを避けるため、「絶対に達成できる低い目標（置きに行った目標）」しか立てなくなります。これでは組織の進化が止まります。

そこで有効なのが、Googleやメルカリなども採用するOKR（Objectives and Key Results）の思想です。達成率60〜70%で「成功（Green）」と見なす「ムーンショット（ストレッチ目標）」を推奨します。「今の技術力では難しいが、達成できれば劇的なインパクトがある」という目標に挑むこと自体を評価（加点）する文化を作ってください。
これにより、新しい言語（RustやGoなど）の導入や、大規模なリファクタリングといった、リスクはあるが価値の高い業務に光が当たります。

計測可能な「主要な結果（Key Results）」の設定

目標の納得感を左右するのは「定量性」です。エンジニアは曖昧さを嫌います。

×「品質を向上させる」
○「単体テストのカバレッジを80%以上に引き上げる」「本番環境での障害発生件数を月1件以下にする」
×「レスポンスを速くする」
○「APIのP99レスポンスタイムを100ms以内にする」

このように、エンジニアが得意とする「数値の言語」で完了条件を定義することで、評価期間終了時の「やった・やってない」の水掛け論をゼロにできます。

4. 評価者のリテラシーを引き上げる「評価者トレーニング」の効果

1on1が盛り上がらない、評価に不満が出る。その最大の原因は、実は評価者（マネージャー）側が「正しい評価とフィードバックのやり方」を一度も体系的に学んでいないことにあります。
プレイヤーとして優秀だったエンジニアが、ある日突然マネージャーに任命され、武器（知識）を持たずに戦場に出されている。これが中小IT企業のリアルです。

評価エラー（バイアス）を自覚させる

人間には必ず認知の歪み（バイアス）があります。

ハロー効果： 「技術力が高いから、マネジメントもできているはずだ」と一点の特徴で全体を高く評価してしまう。
期末誤差（親近効果）： 半年前の大きな成果よりも、直近の小さなミスの方を強く覚えていて評価を下げてしまう。
類似性バイアス： 自分と同じ出身校、同じ技術スタックの部下を可愛がってしまう。

トレーニングを通じてこれらの心理的罠を自覚させ、「印象」ではなく「期間中のエビデンス」に基づいた評価を徹底する訓練を行うだけで、評価の公平性は格段に上がります。

コーチング・スキルの習得と実践

1on1は、上司が一方的にアドバイスをする場ではありません。それでは部下の思考停止を招きます。必要なのはコーチング（問いかけ）の技術です。

オープンクエスチョン： 「なぜ遅れたんだ？」ではなく「次はどうすれば防げると思う？」と問いかけ、思考を未来に向けさせる。
沈黙を待つ： エンジニアが考え込んでいる沈黙を、マネージャーが不安になって喋って埋めない。沈黙は「思考中」のサインです。
傾聴と承認： 「でも」と否定せず、「なるほど、君はそう感じたんだね」と一度受け止める。

こうしたコミュニケーションの型を学ぶことで、1on1は「詰められる場」から「自分の考えを整理できる場」へと変わります。

ロールプレイングによる「伝えにくい内容」のシミュレーション

座学だけでは不十分です。実際に「評価が低いことを伝える（Bad News）」「改善を促す」といった「心理的負荷の高い対話」を、コンサルタントや他部署のマネージャー相手にロールプレイングします。
「今の言い方は、攻められているように感じました」「もう少し事実ベースで話した方がいいです」といった客観的なフィードバックを受ける経験は、現場での失敗を未然に防ぐ強力なワクチンとなります。

コンサルタントの視点：制度は「生き物」であり、対話こそがその血流

評価制度を一度作って、あとはマニュアル通りに回せばいいと考えているなら、それは大きな間違いです。制度は「生き物」です。現場の状況、技術トレンド、会社のフェーズによって、常にチューニングが必要です。
そして、その制度という体に酸素や栄養を運ぶのが「1on1（対話）」という血流です。

どんなに立派な臓器（等級制度）があっても、血流（対話）が滞っていれば、組織は壊死します。逆に、制度が多少不完全でも、上司と部下の対話が健全に機能していれば、納得感は生まれ、組織は回ります。
「1on1が盛り上がらない」というのは、単なる会話不足ではなく、「組織の血流が滞っている」という危険なアラートです。これを放置すれば、優秀なエンジニアから静かに退職（サイレント・クイット）していきます。