仕事の中で「認められたい」「褒められたい」と感じることは誰にでもある感情です。しかし、注意欠如・多動症（ADHD）を持つエンジニアは、その承認欲求が仕事の質や健康、人間関係に悪影響を及ぼす形で現れやすい傾向があります。本記事では、なぜその罠に落ちやすいのかを整理し、具体的で実践しやすい「安全に満たす」方法を豊富な例とともに紹介します。職場でのパフォーマンスを保ちつつ、自分を守るための実践ガイドとしてお使いください。

イントロダクション：なぜ「承認」が重要か

承認欲求は、人間の基本的な社会的欲求の一つです。特にエンジニアは成果が可視化されにくい作業（バグ修正、設計、リファクタリングなど）を行うことが多く、「評価されない」と感じやすい場面が多くあります。ADHDを持つ人は、以下の理由から承認を求める行動が強く出ることがあります。

• 即時のフィードバックを求める傾向（遅い評価がストレスになる）
• 自己肯定感が不安定で、外部の評価に依存しやすい
• 注意の変動により「短期的な達成感」を強く欲しがる

これらが重なると、過剰なアピールや過労、関係の摩擦など「罠」に陥るリスクが高まります。

ADHDエンジニアが「承認欲求の罠」に陥りやすい典型的なパターン

以下は職場でよく見られる典型パターンです。自分に当てはまるものがないかチェックしてみてください。

• 小さな成功でも人に逐一報告して反応を待つ
• 「よくやった」と言われるまで作業を終えられない（完了基準が他者の反応）
• SNSや社内チャットでリアクション数を成果の指標にしてしまう
• コードレビューで否定的なコメントを避けるために過剰な説明や作業の先延ばしをする
• 表彰や褒め言葉を求めて、無理な残業や複数プロジェクトの掛け持ちを引き受ける

これらは短期的には注目を集めたり褒められたりすることがあっても、長期では燃え尽き、評価の信頼性を損ない、チームに負担をかけることになります。

罠が引き起こす具体的な問題（例付き）

1. 過労・バーンアウト

例：リリース直前に「自分が残れば間に合う」と思い込み、徹夜でバグを潰し続けた結果、体調を崩して数週間休職。褒められたものの、長期の不在で評価や信頼を失う。

2. 生産性の低下

例：小さなタスクで頻繁にチームに報告してフィードバックを待つあまり、まとまった開発時間が取れず生産性が落ちる。

3. 人間関係の疲弊

例：毎回「助けて」と頼みすぎて同僚のリソースを消耗させ、徐々に距離を置かれるようになる。

4. 自己評価の不安定化

例：一度否定的なレビューを受けると落ち込み、以降は受け身に。承認がないと動けなくなる。

これらを避けるためには「承認を得ること自体が目的化」していないかを見直す必要があります。

安全に承認欲求を満たすための基本方針（4つ）

1. 内発的動機と外発的承認のバランスを作る
2. 小さな成功を意図的に設計し可視化する（外部承認を待たず自分で承認できる仕組み）
3. 他者からの承認を得る方法を「健全なフィードバックループ」に設計する
4. 自己ケアと境界設定を優先する

これらを具体化する方法を次で詳述します。

実践テクニック：すぐに使える方法

1) マイクロゴールと可視化（自分で承認する仕組み）

• 毎日のタスクリストを「完了」スタンプ付きで管理（例：Trello、Notion）
• 完了したチケットは自分で「レビュー」タグを付け、1日に1回まとめて振り返る
• 短い日誌（3行ログ）：何をしたか、今日の良かった点、明日の改善点を記録。小さな成功を意識化する

メリット：外部の反応を待たずに自己承認でき、達成感が安定する。

2) フィードバックの「粒度」をコントロールする

• 重要なレビューは「形式化」する：PRを出す際に「評価してほしいポイント」を3つだけ明示する（例：性能、設計、テストの網羅）
• コードレビューで必要以上に早い肯定を求めない。逆に早い評価が必要なら「暫定レビュー」を依頼し、最終版は別途まとめる

メリット：フィードバックが曖昧だと承認を無限に求めてしまうため、期待を明確にする。

3) 定期的な「ポジティブ・ルーチン」を作る

• 週1回の「良かったことミーティング」を自己開催：自身の勝ちパターンを3つ挙げる
• チームで「週のハイライト」を共有する文化があれば参加し、あらかじめ自分の小さな成果を組み込む

メリット：承認が自然なルーチンの一部になり、要求度が下がる。

4) 健全な境界設定の言語化（テンプレート例）

エンジニアリングの中でお願いや報告をする場面で使える短い言葉：

• 「この部分について短いレビューをお願いできますか？15分で見てほしいのはこの3点です。」
• 「今週はこのタスクに集中したいので、午後はミーティングを減らしていただけると助かります。」
• 「フィードバックは具体的な改善点を1つずついただけると対応しやすいです。」

境界を言語化することで、無駄な承認要求を減らすと同時に他者への配慮も示せます。

5) 代替の承認源を作る（多様化）

• コード以外のスキルで承認を得る：ドキュメント、テストカバレッジの改善、オンボーディング資料の作成
• 社外コミュニティでの小さな成果：OSSの小さなプルリク、勉強会での発表（反応が得やすい場所を選ぶ）
• メンターや信頼できる同僚との「定期的な承認時間」を確保（週に一度、短時間で良い）

メリット：承認の源を分散することで、1つの承認が得られない時のダメージを減らせます。

上司・チームに伝えるコツ（合理的な依頼の仕方）

ADHD当事者が職場で支援を受けるには、感情的でなく合理的に伝えることが有効です。以下のフォーマットを参考にしてください。

• 状況（Situation）：例えば「最近集中して作業する時間が短く、作業の中断でモチベーションが下がることがあります。」
• 影響（Impact）：例「途中でフィードバックをもらえると、方向性を確認できて安心して続けられます。」
• 具体的なお願い（Request）：例「週に1回、10分の短いチェックインを設けてもらえますか？」

このように構造化して伝えると、上司も支援策を検討しやすくなります。

セラピー・薬物療法・専門家の活用（注意点入り）

承認欲求の強さやその結果の問題が深刻な場合は、専門家への相談が有効です。治療オプションには認知行動療法（CBT）やADHDに特化したコーチング、必要に応じて薬物療法が含まれます。注意点：

• 専門家の診断と治療は個別化が重要。自己判断で薬を中断・開始しないこと。
• カウンセリングでは「承認の受け取り方」を技能として学べる。具体的なスキル（認知の再評価、セルフコンパッション訓練など）が得られる。

専門家は「治療」だけでなく、職場で使える実践テクニックやコミュニケーション戦略も提供できます。

実例：田中さんのケーススタディ

• 背景：田中さん（30代、ソフトウェアエンジニア、ADHD診断済み）は、PRを出すたびに同僚から褒められたいという思いが強く、レビューが来るまで待ち続けて作業が進まない。結果、残業や相談の多さでチームに負担がかかっていた。
• 問題点：
  • 完了の基準が他者の反応に依存している
  • フィードバック待ちが多く、ブロッキング時間が長い
• 介入と改善：
  1. マイクロゴール（30分単位）で作業を刻み、Trelloで「自分レビュー」カードを作成。
  2. PRテンプレートを導入し、「見て欲しい点3つ」を明記する習慣を作った。
  3. 週1回、上司と10分のチェックインを持つことを依頼。そこでポジティブなフィードバックを1つ伝えてもらうことにした（互いの承認文化の構築）。
  4. 週の終わりに「自己評価シート」を記入し、小さな成功を自分で認める練習を継続。
• 結果：レビュー待ち時間が短縮し、残業が減り、チーム内の摩擦が軽減。田中さん自身の自己肯定感も安定してきた。

このように小さな仕組みを導入するだけで大きな改善が期待できます。

SNSや社内チャットでの注意点

SNSやSlackでの「いいね」やリアクションは即時の満足感を与えますが、これに依存すると不安定になります。対策：

• 意図的に投稿の頻度を決める（例：業務関連の共有は週2回まで）
• 反応を成果の指標としない（リアクションは嬉しいが作業の質には直結しないと自分に言い聞かせる）
• 反応を求める投稿は、一文で「フィードバック目的」か「共有だけ」かを明記する

SNSの使用は適度に管理しましょう。

実践チェックリスト（今日から使える）

• [ ] タスクを30分単位で区切る
• [ ] 完了時に自分で「セルフレビュー」を行う（3行日誌）
• [ ] PRやタスクの依頼は「期待するフィードバック3点」を明記
• [ ] 週に1回、短い振り返りミーティングをスケジュール
• [ ] 無理な残業は月X時間までなど、明確な境界を設定
• [ ] 専門家に相談するかどうかを検討（ストレスが高ければ早めに）

1週間のサンプルプラン（テンプレ例）

• 月曜：今週のマイクロゴール設定（30分）。上司に短いステータス送信。
• 火曜：2時間のブロック作業（通知オフ）。終わりにセルフレビュー。
• 水曜：PR作成。テンプレに沿って「評価してほしい3点」を記載。
• 木曜：チームの「週ハイライト」投稿（自分の小さな成功を1つ共有）。
• 金曜：上司との10分チェックイン。週次の自己評価シート記入と翌週計画。

このようにルーチン化すると承認を待つ不安が軽減します。

よくある誤解とその反論

• 誤解：「承認欲求を抑えるべきだ」
  反論：承認欲求自体は自然で有用。問題は「承認が唯一の動機になる」こと。抑えるのではなく、安全に満たす仕組みを作る。
• 誤解：「自分で全てをコントロールすれば良い」
  反論：他者のフィードバックは重要。むしろ「誰から・どのように」承認を得るかを設計することが鍵。

まとめ（結論）

ADHDを持つエンジニアが承認欲求の罠に陥るのは珍しいことではありません。しかし、その罠を「知らずに放置する」のと、「仕組みで管理する」のとでは結果が大きく異なります。大事なのは以下の3つです。

• 小さな成功を自分で可視化し、自己承認できる仕組みを作ること
• フィードバックの期待値を明確にし、健全なフィードバックループを設計すること
• 境界設定と自己ケアを優先し、必要なら専門家の助けを求めること

これらを日常的に実践すれば、承認欲求を「破滅的な罠」から「モチベーションの資源」へと変えることができます。まずは1つ、小さなルーチンから始めてみてください。

もし具体的なテンプレート（PRテンプレ／自己評価シート／上司への依頼メール文など）が必要であれば、次にそれらを用意してお送りします。どの場面で一番困っているか教えてください。

投稿 ADHDエンジニアが陥りやすい「承認欲求の罠」とその安全な満たし方 は ADHDエンジニア成長日記 ― 障害を抱えながらIT業界で活躍するためのブログ に最初に表示されました。