評価面談で自分を正当に評価してもらうためのADHDエンジニアの記録術

結論：評価面談では「事実の可視化」と「評価基準との対応付け」が最も効きます。ADHDの特性に合わせた短く継続可能な記録フォーマットを作り、重要な成果・障壁・学びを定量と定性で残しておくと正当な評価につながります。

要点まとめ

評価面談で正当に評価されるための核は次の3つです。理由も簡潔に示します。

• 短時間で追える一行サマリ（成果・インパクト） — 面談で即提示できるから
• 障壁と自分の工夫の記録 — 困難を克服した証拠になるから
• 評価基準に紐づけたエビデンス（数値・ログ・PR・レビュー） — 客観性を担保するから

以降で、具体的なフォーマット、ツール、ADHD特性別の工夫、面談での提示方法まで実例を交えて解説します。

記録の原則：何を、どのくらい残すか

記録は「量」より「再現性」。毎日完璧に書く必要はありません。評価期間ごとに面談で出せる状態にすることが目的です。重要なのは事実（事実＝何をしたか・いつ・結果はどうだったか）と自分の貢献点です。

記録すべき項目を紹介します。これらを短く書く癖をつけると続けやすいです。

• 成果サマリ（1行）
• 具体的なアウトプット（PR番号、リリース日、エンドポイントなど）
• インパクト指標（バグ削減数、処理時間短縮％、ユーザー指標）
• 遭遇した障壁と自分の対処（いつ・何を・どうした）
• 学んだこと・次に活かす点

上の項目を1案件または週単位で書いておくと、面談前にまとめやすいです。

実例（エンジニア）：
ある週の記録例：「APIレスポンス遅延の原因特定：2025-03-18、原因はDBインデックス漏れ、対応でクエリ改善→平均レスポンスタイム40%短縮（prodログ参照）。PR #342。運用負荷減少でSREから感謝。」

実践フォーマットとツール（決め方と比較）

記録はツールよりフォーマットが重要です。シンプルで継続できることを優先します。選ぶ基準は「取り出しやすさ」「検索性」「継続負荷が少ないこと」です。

主要な選択肢と向き不向きの比較です。

• エバーノート/Notion — 検索と整理が強み。ただし初期設定とテンプレート作成が面倒な人は続きにくい。
• Git commit/PRテンプレート — 開発の流れで残せる。成果の証拠として使いやすいが、定性的な振り返りは別途必要。
• シンプルなMarkdown日報（リポジトリやGitHub Gist） — 軽量でコード寄りの人に向く。共有は別途工夫が必要。

選ぶ基準は次の3つです：容易さ（続けられる）、面談での提示のしやすさ、客観的証拠との結合。

実例（エンジニア）：
私はPRベースの記録をメインにし、月次でNotionに要約を貼る運用にしました。PRは証拠になり、Notionは面談資料になるのでトレードオフが少なかったです。

メリットとデメリットを整理します。短所も知っておくと対策が立てやすいです。

メリット

記録術を導入すると次の利点があります。

• 面談で自分の貢献を即提示できる
• 自分の工数や障壁が可視化され、過小評価を防げる
• 改善サイクルが回りやすくなる（次回評価で成長を示しやすくなる）

これらは交渉材料としても有効です。

デメリット

次の点は取り組む際の負担になります。

• 記録を続けるための時間が必要
• 最初は形式を整えるコストがかかる
• 過度に細かくすると面談での説明が冗長になる

負担を減らす工夫を後述します。

ADHD特性別の工夫（実行しやすさの工夫）

ADHDの特性に合った工夫がないと、記録が続きません。ここでは特性別に実務で使える対処法を示します。

衝動性への対処：短いテンプレを作る。書く項目を3つに絞り、作業間に2分で記録するルールを作ります。
実例（エンジニア）：コードレビュー後に「何を直したか／何を学んだか／次のTODO」を1行ずつ書いてPRに貼る習慣をつけました。衝動的に次作業に移っても記録は残ります。

ハイパーフォーカスの活用：集中できた時は詳細を残す。後で使える証拠が増えますが、過剰な詳細は要約で補います。
実行機能障害（計画・開始が苦手）：記録のトリガーを作る（例：デイスタンドの後に5分、CI成功後に記録）。トリガーと一緒に習慣化すると始めやすいです。

感覚過敏（通知が邪魔）：通知を制限し、記録時間を短いポモドーロに設定します。長時間の記録は避けましょう。

面談前のまとめ方と提示方法

記録をただ溜めるだけでは不十分です。面談で提示できる形に整える必要があります。ここでは面談30分前でも使える最短フローを示します。

まずは「エレベーターピッチ」を作る。1分で言える1行サマリ（成果とインパクト）を3つまで用意します。次に支援データ（PR、ログ、ユーザーメトリクス）をリンクでまとめます。最後に「課題」と「次のアクション」を示します。これで面談は事実に基づきスムーズになります。

実例（エンジニア）：私の1分サマリは「検索APIのキャッシュ導入でCTO依頼のレスポンス目標を達成。PR#410、平均レイテンシ35%低下、A/BでCTR横ばい。次はキャッシュ戦略のTTL最適化予定。」リンクをNotionの表に並べて提示しました。

提示時の決定基準：時間が短ければ1分サマリ、時間が長ければ成果→障壁→学び→次の計画の順で深掘りします。客観証拠は必ず提示してください。

評価基準とのつなぎ方（メトリクスと証拠）

評価表やOKR、職務記述書にどう紐づけるかが重要です。会社の評価項目を見て、自分の記録をマッピングしてください。評価者が求める言葉に変換することで理解が速くなります。

具体的なマッピング方法を示します。まず評価項目を列挙し、それぞれに該当する自分の記録（PR、数値、フィードバック）を1つずつ紐づけます。これで「この評価項目を満たしている」という主張がエビデンス付きでできるようになります。

実例（エンジニア）：評価項目に「チームへの貢献」がある場合、コードレビュー数やメンターした新人のオンボーディング完了日を記載し、レビューコメントやSlackの感謝メッセージをスクリーンショットで添えました。

チェックポイント

面談準備で最低限確認すべき事項を短くまとめます。これらを面談前チェックリストに入れておくと安心です。

• 1分サマリが3つあるか
• 各サマリに対応する証拠（PR、ログ、数値）がリンクされているか
• 遭遇した主な障壁と自分の対処が明記されているか
• 次の期間での具体的な改善案があるか

これらは面談を事実ベースに保つための最低条件です。

向いている人／向いていない人

運用スタイルを選ぶ判断材料です。自分が続けられるかの目安になります。

向いている人：日常的に短時間の記録が続けられる人。PRやCIを普段から使っている人。
向いていない人：記録に長時間をかけてしまう人（ただしテンプレを使えば改善可能）。

比較（短期運用 vs 定期まとめ）

記録の運用には二つの流儀があります。短期運用（その都度書く）と定期まとめ（月次で一気にまとめる）です。決定の基準は「集中の波」と「可視化の必要性」です。衝動的に忘れがちな人は短期運用、ハイパーフォーカスの波が大きい人は定期まとめ向きです。

実例（エンジニア）：私は週の中でハイパーフォーカスが来るため、週次まとめ方式にしていると最も楽に続けられました。

行動のポイント

実行に移すための最小ステップを示します。まずは1つだけ始めてください。

• テンプレートを1つ決める（例：1行サマリ＋証拠リンク＋学び）
• トリガーを設定する（PRマージ時、デイスタンドの後など）
• 1ヶ月運用して面談直前に3つに絞る習慣を作る

これで継続性が高まり、評価面談で自分を守れます。

結論と次の一手

ADHD特性があっても、評価面談で正当に評価されるには記録の設計と提示方法が鍵です。短く続けられるテンプレートを用意し、面談では1分サマリ＋証拠を最優先で提示してください。まずは今日、1つのPRかタスクを振り返って1行サマリを書いてみましょう。それが習慣になれば評価は確実に変わります。

よくある質問

Q. 記録はどれくらいの頻度でやるべきですか？

評価期間と自分のワークスタイルで決めてください。推奨は週1回のまとめ、重大なアウトプットは都度記録する運用です。週1回なら続けやすく、面談前の作業負荷も小さくなります。

Q. 数値が出せない業務（設計や調査）はどう記録する？

定性的なインパクト（設計が原因で防げた障害の事例、調査が省いた工数の見積り）を証拠とともに残します。関係者のコメントやレビュー履歴を添えると有効です。

Q. 面談で緊張してうまく説明できない場合は？

1分サマリを紙かNotionに貼っておき、そのまま読み上げる作戦が有効です。証拠リンクを提示すれば、評価者が自分で確認できます。

Q. 上司が評価基準を明確にしてくれない場合は？

まずは自分で職務記述書やOKRに項目を当てはめ、提示してください。評価軸を提示すると上司もコメントをしやすくなります。

Q. 記録が続かないときの対処法は？

テンプレをさらに短くするか、記録トリガー（PRマージ、会議終了）を増やしてください。習慣化が難しい場合は週次のリマインダーをカレンダーに入れるのが現実的です。

結論を再掲します。評価は主観になりがちですが、記録で事実を示せば正当に評価してもらえます。まずは「1分サマリ」を今日から作ることをおすすめします。

投稿 評価面談で自分を正当に評価してもらうためのADHDエンジニアの記録術 は ADHDエンジニア成長日記 ― 障害を抱えながらIT業界で活躍するためのブログ に最初に表示されました。