自分は天才か無能か？ADHDエンジニアが自分の能力を冷静に評価する方法

結論：ADHDの特性は一方で創造力や集中の爆発（ハイパーフォーカス）をもたらし、他方で実行力や継続的なパフォーマンスを阻害します。冷静な評価は「成果（アウトプット）」「プロセス（働き方）」「環境（職場・ツール）」の三つを分けて観察し、定量と定性の両方で記録を取ることです。これにより「天才的瞬間」と「無能に見える瞬間」を分解して理解できます。

要点まとめ

まず重要なポイントを簡潔にまとめます。短時間で判断基準を掴むためです。

• 評価軸は「成果」「プロセス」「環境」の三つに分けること
• 数値（コミット数、PRのマージ率、バグ率など）と行動ログ（作業時間帯、気分、注意の切れ方）を組み合わせること
• 短期的な自己認識（衝動的評価）を避け、4〜8週間のデータで傾向を見ること

上の三点を実践すると、感情的な自己評価（今日はダメだ）と実際の能力（平均して何ができているか）を切り分けられます。

自己評価の原則（ADHDエンジニア向け）

自己評価の際にはいくつかのルールを自分に課すとブレを減らせます。特にADHDの衝動性や感情の波があると主観評価がぶれやすいからです。

まず「短期感情を切る」こと。日ごとの浮き沈みで自分を全否定しないために、評価期間は少なくとも4週間に設定します。次に「状況依存性を把握」すること。自分が良い成果を出す条件（静かな環境、締切直前のハイパーフォーカスなど）と悪い条件を明確に書き出します。

例：あるエンジニアは、朝の2時間にコードレビューとデバッグを集中して終わらせ、午後はミーティングとドキュメント作業に回すことでミスが激減しました。条件を記録するだけで再現性が高まりました。

測るべき具体指標（成果・プロセス・環境）

何を測るか決めると評価が客観的になります。以下はエンジニアが実務で使える指標です。目的は「能力の全体像」と「パターンの検出」です。

• 成果（アウトプット）：マージされたPR数、リリースした機能数、顧客のバグ報告件数
• プロセス：平均PRレビュー時間、タスク着手までの遅延（日数）、ハイパーフォーカス継続時間
• 環境：作業中のノイズレベル、リモートかオフィスか、同期／非同期コミュニケーション比率

これらを週次で記録し、4週間の平均と標準偏差を出すと、波の大きさ（安定性）とピーク（才能の発揮）が見えます。

例：週に3件マージされるが、バグ再発率が高い場合、短期のアウトプットはあるが品質管理プロセスの改善が必要とわかります。

方法1：実績の定量化 — 具体的ステップ

実績を数値化する手順はシンプルです。まず測定項目を決め、ツールで自動収集できるものは自動化します。手動で記録するものは簡潔に続けられるフォーマットにします。

手順の例（エンジニア向け）：

1. 3つの主要指標を決定（例：週のマージ数、重大バグ数、平均PR滞留時間）。
2. GitやIssue管理ツールから週次レポートを自動取得する。
3. 手動で「作業開始時刻」「作業終了時刻」「集中度（1-5）」を一言日報で残す。
4. 4週間分のデータを可視化し、傾向を判断する。

利点は客観性、欠点は初期設定と継続の手間です。自動化できる範囲は積極的にAPIで取得すると負担が少なくなります。

例：CI/CDの成功率やデプロイ頻度を週次ダッシュボードに表示して、自分の影響範囲を数値で把握したエンジニアが、モチベーションを維持できたケースがあります。

方法2：プロセス観察と自己モニタリング

数値だけではADHD特有の波を見落とします。自分の「どうやって働いたか」を観察することが重要です。日々の気づきを簡潔に記録し、トリガー（騒音、長時間ミーティングなど）を特定します。

記録の例：作業開始前に「気分/集中度/外的ノイズ」を3項目で記録し、作業後に「何が邪魔したか/ハイパーになった時間帯」をメモします。これを4週間続ければ、パターン（夜に強い、締め切り前に急に伸びるなど）が見つかります。

利点は原因究明、欠点は記録の手間と認知負荷です。認知負荷を下げるために「音声メモ」や短いテンプレートを使うと続けやすくなります。

例：あるエンジニアは、朝のSlack通知を切るだけでレビュー速度が向上し、集中時間が1時間増えたと記録しました。

環境が能力を左右する—職場での調整例

ADHDは環境依存性が高いです。職場の音・照明・コミュニケーションスタイルが生産性に直結します。環境調整は評価の一部として考えるべきです。

代表的な調整案と判断基準は以下です。適用前に「試験期間」を設け、指標の変化を見ます。

• ノイズ対策（ヘッドフォン、静音ルームの確保） — 集中時間が増えるかで判断
• 非同期コミュニケーションの推進（メール・チケット中心） — ミーティング時間の減少で生産性が上がるかを測る
• 時間ブロック制度（午前はコーディング、午後はミーティング） — 細切れ時間の減少が成果に結びつくか確認

利点は即効性と再現性、欠点はチームとの調整コストです。チームに提案する際は、自分の短期テスト結果を提示すると説得力が出ます。

例：週に一度の「静音コーディングデー」を導入して成果が20%向上したチームがあります。数値を出して継続承認を得ることが大事です。

メリット

ADHD的な特性がプラスに働く場面は多くあります。創造的な設計、抜本的なリファクタリング、短時間での集中した問題解決などです。これらは「天才」に見える瞬間を生みます。

例：短時間で複雑なバグを発見して深い修正を行い、トラフィックが安定したケースは、ハイパーフォーカスの強みが出た典型です。

デメリット

一方で継続的なタスク管理、ドキュメントの維持、長期的なプロジェクトマネジメントは苦手になりがちです。これが「無能に見える」原因になります。

例：締切を逃す、仕様変更で作業が中断されると再開に時間がかかる、という現場での不具合はよく起きます。

向いている人 / 向いていない人

短く基準を示します。自分に当てはまるか判断する材料として使ってください。

向いている人

短期集中で創造的な仕事が多いプロジェクト、裁量が大きく自己管理できる環境、頻繁に新しい技術に触れられる職場に向いています。

例：プロトタイプ開発や機能のPoC（概念実証）に強みを発揮するエンジニアが多いです。

向いていない人

厳密な手順・高いドキュメント品質が不可欠な運用業務や、細かい反復タスクだけを長時間続けるポジションは苦手になりやすいです。

例：24/7のインシデント対応で同じルーチンを黙々と回す業務は負担になることがあります。

チェックポイント

自己評価の最後に、簡易チェックを行ってください。これで今の状態で改善が必要か、配置換えや役割変更を考えるか判断できます。

以下は評価時に確認する主要項目です。該当数が多いほど現状のズレが大きい可能性があります。

• 過去4週間で締切を守れなかった週が2週以上ある
• バグの再発率が高く、コードレビューで指摘が多い
• 自分の作業パターンが環境に強く依存している（静かでないと作業できない等）
• ハイパーフォーカスで短期的に高い成果を出すが、その後燃え尽きることが多い
• 日常的に決定疲労や優先順位付けが苦手でタスクが滞る

チェック後は、優先度の高い1〜2項目に集中して改善策を試すことをお勧めします。

行動のポイント

実行に移すための短期的な行動指針です。どれも1〜2週間で効果が分かる施策です。選ぶ基準は「変更のコストが低く、効果が観測しやすいこと」です。

• まずは4週間の簡易ログを始める（自動取得できる指標＋1分日報）
• 職場での「試験的環境変更」を提案し、2週間のA/Bで効果を測る
• タスク分解と時間ブロッキングを組み合わせ、1日のうち”集中ウィンドウ”を固定する

これらを始めると客観データが手に入り、自己評価が格段に正確になります。

結論と次のステップ：まず4週間のデータ収集を開始してください。データがあれば「自分は天才か無能か」という二択を超えて、長所を伸ばし短所を補う具体的なプランが立てられます。

よくある質問

Q. ADHDである自分に客観的な評価は可能ですか？

可能です。感情的評価を避け、4〜8週間の定量データと簡潔な行動ログを組み合わせれば、かなり客観的に傾向が掴めます。

Q. 評価に使うツールは何がおすすめですか？

Gitのメトリクス、Issue管理（Jira/GitHub Issues）の週次レポート、簡易的な日報は最もコストパフォーマンスが良いです。音声メモやタイムトラッキング（Togglなど）も有用です。

Q. ハイパーフォーカスが不規則で困っています。どう評価すればいいですか？

ハイパーフォーカス自体を評価指標に入れてください。持続時間と成果（何を完了したか）をセットで記録すると、その価値が数値化できます。

Q. チームに環境変更を提案するときのコツは？

短期の試験（2週間）と測定指標を提示することです。「これを試して成果がX%改善すれば継続」と明確にすると承認が得やすくなります。

Q. 自己改善が続かないのですが、どうすれば継続できますか？

変更は小さく、1つずつ。自動化できるものは自動化し、成功体験を週ごとに確認すると習慣化しやすくなります。

結論：ADHDは「能力の二面性」を生みます。自己評価を体系化すれば、自分がどの場面で“天才”になり、どの場面で“無能”に見えるかを明確にできます。まずは短期のデータ収集から始め、改善サイクルを回してください。