「頑張っているのに給料が上がらない」「評価されている実感がない」——こんな悩みを抱えるADHD（注意欠如・多動性障害）傾向のエンジニアは少なくありません。能力は高いのに、評価制度や評価者の期待を正しく読み取れないために、昇給・昇進の機会を逃してしまうことがあります。本記事では、評価制度の仕組みをわかりやすく解説し、ADHD特性を踏まえた実践的な対応策、自己アピールの方法、評価面談での伝え方、職場での合理的配慮の交渉までを丁寧にまとめます。

評価制度を「理解する」ことがなぜ重要か

評価制度は単に「良い/悪い」を決める機械ではなく、昇給・昇進・業務配分・キャリア開発の根拠になります。評価基準を理解していないと、どんなに仕事ができても「会社に重要とされる行動」を意図的に示すことができません。

ADHD傾向があると、以下のような特徴が評価とミスマッチを起こしやすくなります。

• 細かい実績の記録や報告が苦手で、成果が見えにくい
• 会議や日常のコミュニケーションでの印象形成が弱い
• 納期やプロセス遵守に多少の困難があり、それが評価にマイナスに働く
• 高い集中力で深い技術貢献をしても、それが「短期的なインパクト」と結びつかない

評価制度を理解し、評価者が「何を重視するか」を逆算することで、行動を戦略化できます。

評価制度の基本構造（評価対象・基準・プロセス）

まずは評価制度の共通要素を整理しましょう。どの会社でも次の3つが基本です。

1) 評価対象（What）

• 技術力（コード品質、設計能力、レビュー貢献）
• 生産性（タスク完了数、プロジェクト貢献度）
• 行動・態度（チームワーク、コミュニケーション、リーダーシップ）
• 影響力（プロジェクトの成功、後輩育成、プロダクトへの貢献度）

2) 評価基準（How）

• 定量指標：KPI、OKR、バグ件数、リードタイム、デプロイ回数など
• 定性指標：技術的判断の質、設計レビューの意見、チーム内の信頼度
• 等級・ラダー：ジュニア→シニア→リード、といった職位基準に沿った期待値（技術スキルと行動指標を組合せて定義されることが多い）

3) 評価プロセス（When/Who）

• 定期評価（四半期・半期・年次）
• 1on1や中間フィードバックの実施時期
• 評価者（直属上司、人事、ピアレビュー、ステークホルダー）の構成
• エビデンス提出（セルフレビュー、成果物一覧）

評価は単なる「点数」ではなく、評価者が持つ認知バイアスや組織の文化にも影響されます。だからこそ自分で「見える化」することが必要です。

ADHDと評価ギャップが生まれる典型的な理由

ADHDを持つエンジニアが評価で不利になりやすい要因を整理します。これらは「能力が低い」ことを意味しません。評価制度とのズレです。

• 成果の可視化不足
  • 高難度の課題に集中して取り組むが、進捗報告や小さなマイルストーンの提示が少ない。
• コミュニケーションの伝達不足
  • 口頭での報告が苦手で、非言語で貢献しても評価者が気づかない。
• プロセス重視の職場での減点
  • 柔軟な発想や高速なプロトタイピングが評価されにくく、ルール（チケット運用やドキュメント）を守らないとマイナスに。
• 一貫性の誤解
  • 波があるパフォーマンスは「信頼性が低い」と解釈されることがある。
• 自己主張の難しさ
  • 成果のアピールが控えめだと、他者の声が大きく評価される。

まずはこれらを認識し、意図的に埋める工夫を行いましょう。

自分の成果を評価基準に紐づける具体ステップ

ここからは実務レベルで使えるステップ。順に取り組むことで「評価に結びつく行動」を増やせます。

ステップ1：制度の全体像を入手して読み込む

• 人事または上司に評価制度・等級定義・評価スケジュールを文書で確認する。
• 具体的に「昇給/昇進に必要な行動」をピックアップする（例：レビューを月5件、オンコール対応回数、KPI達成率等）。

ステップ2：自分の成果と制度のマトリクスを作る

• 左列に評価項目、右列にあなたの具体的な成果（定量データやリンク）を並べる。
• 例：評価項目「コード品質向上」→ 実績「プロダクションバグを年20%削減、テストカバレッジを30%増加（PRリンク）」

ステップ3：記録と定期報告の習慣を作る

• 週次で「実績サマリ」をSlackやメールで共有（テンプレ：今週の完了タスク、影響、次週の予定）
• 面談直前には「セルフレビュー（1ページ）」を提出する習慣をつける

ステップ4：短期ゴールを設計して可視化する

• 大きなプロジェクトは短いマイルストーンに分割し、達成を周知する
• OKRやKPIに自分の貢献目標を紐づける（例：モジュールXのレスポンスタイムを30%削減 → 事業KPIに貢献）

ステップ5：フィードバックを積極的に求める

• 1on1で「今の評価で足りない点」は何かを聞く
• ピアレビューやStakeholderからの短いコメントを保存しておく

面談・フィードバックで使える実践フレーズとテンプレート

評価面談や1on1で使える短くて効果的なフレーズ、セルフレビューのテンプレートを紹介します。ADHDの方に合うよう「準備」と「要点化」を重視しています。

セルフレビュー（1ページ）テンプレート

• 氏名 / 期間 / 役割
• 今期の主要成果（箇条書き・定量データを必ず入れる）
  • 例：リリース遅延を2回から0回に削減（対応策：デプロイ前チェックリスト導入、CIの強化）
• 影響（事業/チーム/ユーザーに対するインパクト）
  • 例：サーバコストを月$300削減、ユーザーの平均応答時間を0.5秒短縮
• 次期の目標（SMARTで）
  • 例：次期はコードレビューを平均24時間以内に完了し、レビュー遅延率を20%以下にする
• 求めたいサポート（具体的）
  • 例：毎週の優先度確認/ドキュメントテンプレート提供/柔軟な休憩取り扱い

面談での伝え方（短いフレーズ）

• ポジティブな導入：「今期はこの3点でチームに貢献しました」
• 根拠を示す：「PR #123, #145参照。これによりXXを改善しました」
• 要望の提示：「次のステップとして、昇給に向けてどの評価基準を満たせば良いですか？」
• 具体的に聞く：「A等級に必要な技術的リーダーシップの具体例を教えてください」

ADHD向けの補助フレーズ（自己主張が苦手な方へ）

• 「客観的なデータで評価していただきたいので、私の成果を定量化する項目を一緒に決めてもらえますか？」
• 「プロセス遵守で注意される点があるので、短期的なチェックリストを作成して頂けると助かります」

日々の成果を証拠化するためのツールと習慣

成果の可視化は習慣化とツール活用で格段に楽になります。ADHDの方は「忘れやすさ」を前提にプロセスを自動化しましょう。

推奨ツール

• タスク管理：JIRA、Notion、Trello（チケットに必ず成果の「測定方法」を入れる）
• メモ・エビデンス保管：Notion/Obsidian（作業ログをテンプレ化）
• 自動レポート：GitHub ActionsやCIでのデプロイログを定期的にSlackに通知
• カレンダー：定期的な「成果ログ」タイムブロックを設定（週1回30分）

習慣（チェックリスト）

• 週次サマリを必ず1回発信する（Doneリスト＋インパクト）
• 完了したチケットには必ず「何が改善したか」をコメントで残す
• 重大な貢献はSlackで短いスレッドに残す（プロダクトマネージャーやPMにもCC）
• 1on1前にセルフレビューを完成させる（テンプレを保存しておく）

マネージャーに効果的に働きかけるコツ（合理的配慮の例）

評価制度における不利を減らすため、上司への働きかけや合理的配慮の交渉が有効です。ADHDは労働上の配慮対象となる場合があるため、職場環境を整える交渉は正当な手段です。

具体的な要望例

• 報告の頻度と形式の明文化：週次の短報告で評価に反映してもらう
• 柔軟な締切ルール：タスクを短いマイルストーンに分け、進捗で評価する
• ドキュメントテンプレートの提供：レビューやPRのフォーマットを用意してもらう
• 静かな作業時間の確保：1日2時間の集中ブロックを承認してもらう
• 定期的なフィードバック：月1回の短い中間評価を設けてもらう

交渉時のポイント

• 要望は「具体的で測定可能」にする（例：「週に2回、30分の1on1をお願いしたい」）
• 相手にとっての利点を示す（例：ドキュメントテンプレによるレビュー効率向上、バグ減少）
• 小さく試して効果を提示する（試験期間1か月→データで効果を示す）

会社の評価制度に対する戦略的アプローチ（長期計画）

短期の対処だけでなく、長期的に組織内で認められるための戦略も必要です。

ステップA：ロールとキャリアパスを明確化する

• 「今の職位で何が期待され、次の職位で何が期待されるか」を文書で明確にする
• 期待と自分の現状ギャップを定量化する（スキルマトリクスを作成）

ステップB：スキルの可視化と拡散

• 技術ブログ、社内勉強会、設計ドキュメントの公開で「影響力」を蓄積
• コードレビューの質を上げ、レビューコメントのログを残す

ステップC：ネットワークの強化（評判づくり）

• ピアからの推薦コメントを集める（短いSlackメッセージや360度フィードバック）
• ステークホルダー（PM、QA、カスタマー）と短期的成果を共有し、横展開される実績を増やす

ステップD：昇給/昇進のタイミングを狙う

• 評価サイクルに合わせてセルフレビューや実績を最も強調する時期を選ぶ
• 重要プロジェクトの成功タイミングを昇進の申請時期に合わせることを検討する

ケーススタディ：具体例で学ぶ（2パターン）

ケース1：技術的貢献は大きいが報告が少ないエンジニア（佐藤さん）

状況：複雑なパフォーマンス改善を一人で達成。だが週次の報告がなく、評価面談で「影響が不明」と指摘された。

対応：

• 週ごとに「改善前/改善後の数値・PRリンク」をテンプレで共有。
• 面談で「KPIに対する影響を一覧表で提示」して、上司にその資料を評価シートの一部として取り込んでもらう。
  結果：次の評価で「事業へのインパクト」が明確になり、昇給対象となった。

ケース2：アイデアは多いがルール違反で評価が下がるエンジニア（田中さん）

状況：素早く試作して成果は出すが、チケットやドキュメントの整備が雑でマイナス評価。

対応：

• PRテンプレートとデプロイ前チェックリストを作成して運用。
• 「素早いプロトタイプ」は評価項目に組み込み、短期マイルストーンで成果を出すように調整。
  結果：プロセス遵守が評価基準に達し、同時にプロトタイプの成果も評価されるようになった。

よくあるQ&A（短めに）

Q：自己主張が苦手でも昇給できますか？
A：できます。自己主張の代わりに「成果の見える化」「定量データ」「ピアからの評価」を用意することで、不足する主張を補えます。

Q：合理的配慮を会社に頼んで評価が下がることはありますか？
A：合理的配慮は労働環境改善の正当な要求です。求め方が「職務遂行を助け、成果を高める」ことを示せば、評価に結びつく場合が多いです。

Q：短期的にできることは？
A：週次サマリ、PRに「効果」を必ず書く、1on1の課題を明文化してもらう、の3つをすぐに始めてください。

まとめ：評価の「見える化」で給料アップにつなげる

ADHDエンジニアが給料や評価で不利になりやすい原因は「能力の見えにくさ」と「評価制度とのズレ」です。重要なのは以下の3点に集約されます。

• 評価制度をまず正確に理解する（何を・どう評価するかを把握する）
• 成果を定量化・可視化し、評価基準に紐づける（テンプレ・ツールで自動化）
• 上司やチームに対して、具体的で測定可能な支援を交渉する（合理的配慮・プロセス改善）

最も大切なのは「自分の貢献を評価制度の言葉に翻訳する力」です。ADHD傾向があっても、工夫と準備で評価される行動を増やせます。この記事のステップやテンプレートを参考に、まずは「今週のサマリ」を1つ作ってみてください。それが評価の流れを変える第一歩になります。

投稿 「なぜか給料が上がらない」ADHDエンジニアのための評価制度を理解する力 は ADHDエンジニア成長日記 ― 障害を抱えながらIT業界で活躍するためのブログ に最初に表示されました。