失敗を恐れるADHD部下を育てる上司の行動とフィードバック

冒頭結論：失敗を恐れるADHDの部下には、「安全で予測可能な仕組み」と「プロセス重視のフィードバック」を組み合わせることが最も効果的です。短い区切りで成功体験を積ませ、具体的な手順と選択基準を与えると自己効力感が高まり、ミスが学びに変わります。

イントロダクション：私自身、エンジニアチームでADHD傾向のあるメンバーをマネジメントしてきました。衝動的なアイデア、突発的な集中（ハイパーフォーカス）、そして優先付けや開始が苦手という典型的な特性に直面しました。ここでは実務で効果があった具体的な行動とフィードバック方法を、感情面と実務面の両方から解説します。

要点まとめ

以下は本記事でおすすめする基本方針です。理由と実践例は以降で詳述します。

説明：「まず試すべき行動」をシンプルに示します。

• 仕事を小さな「明確で期限付きのタスク」に分解する
• 失敗を報告しやすい「心理的安全性」を作る
• 結果ではなく「プロセス」に対する具体的なフィードバックを行う
• 選択肢と判断基準を提示し、決断疲労を軽減する

上記は、短時間で実行しやすく効果が確認しやすい行動です。以下で具体例と根拠を示します。

ADHDの特性を理解する（定義と影響）

まず簡単に定義します。ADHDは注意欠如・多動性障害の略で、注意散漫、衝動性、実行機能の低下（優先付け・計画・作業開始の困難）などが見られます。これは「失敗を恐れる」行動と結び付きやすく、過去の批判的経験がトラウマとなることがあります。

職場での影響は「完璧主義が強くなりすぎて着手できない」「途中で別の仕事に飛び移り失敗が増える」「完了までの管理が難しい」などです。私の経験だと、あるバックエンドエンジニアは仕様変更を恐れてレビューに出せず、長時間かけて自己検証を繰り返して納期を遅らせていました。これを改善するために以下の対応を取りました（後述）。

上司が取るべき具体行動（計画と実行支援）

まず行動面です。ADHD部下には「構造」と「小さな成功の連続」が必要です。具体的には「タスク分割」「明確な優先順位」「時間管理支援」「進捗の可視化」を行います。

例：バグ修正の分割
あるエンジニアが大きな不具合に取り組む際、次のように分割しました。1) 再現手順の明文化（2時間）、2) 原因特定のためのログ収集（4時間）、3) 仮修正の作成（3時間）、4) 単体テストとコードレビュー（3時間）。各段階に具体的な完了条件とタイムボックスを設定し、レビュー時にはその段階での判断基準だけを評価しました。結果、取り掛かりの障壁が下がり、納期通りに完了しました。

なぜ効くのか：長い仕事は先延ばしと不安を生むため、短く明確な区切りで成功体験を積ませると不安が軽減します。タイムボックスはハイパーフォーカス時に時間を浪費するのを防ぎ、衝動的な方向転換を抑えます。

決定基準：タスク分割の粒度は「15分〜2日程度で完了可能」かつ「評価可能な成果物」が出ることを基準にしてください。粒度が細かすぎると管理コストが増え、大きすぎると効果が薄れます。

フィードバックの方法（感情と具体性のバランス）

フィードバックは「安心感のある言い方」と「具体的な改善指示」の二つを同時に行うことが重要です。感情に配慮しつつ、次に何をするかを明確に伝えると効果が高まります。

実務的なフィードバック例（コードレビュー）
私が使うテンプレートは「観察→影響→提案」の順です。例えば、「テストが不足しているように見えます（観察）。もしこのケースで失敗が本番で起きるとリリース後の修正コストが増えます（影響）。まずはユニットテストを1ケース追加して、その後に結合テストで再確認しましょう（提案）。もし時間が厳しければ、私がペアで30分付き合います。」この流れは評価ではなく協力を示すため、失敗を報告しやすくなります。

なぜ効くのか：ADHDの部下は失敗を個人的な欠陥と結びつけやすいため、フィードバックに「学びの道筋」を含めることで心理的負担を下げます。提案を複数提示すると選択疲労を防ぎます。

トレードオフ：詳細なフィードバックは時間がかかります。忙しいときは短い観察＋次の行動だけ示す（例：今週中にテスト1件追加）など優先順位を付けてください。

チーム文化と評価制度の調整

個人のサポートだけでなく、チームの文化や制度が失敗恐怖を強めている場合があります。ピアレビュー文化、事後分析、評価軸を見直すと良いです。

例：ブレームレスなインシデント対応
あるSREチームで、障害分析を「誰のミスか」ではなく「仕組みのどこが脆弱だったか」にフォーカスするように変えました。事後報告は事実と再発防止案を中心にし、個人名は出さない運用にしました。ADHD傾向のエンジニアは障害報告への抵抗が減り、自発的に問題解決に参加するようになりました。

導入の判断基準：チームの過去1年のインシデント報告で「個人責任に帰着する記述」が半分以上あるなら、まずはブレームレス文化導入を検討してください。利点は報告率の向上と学習速度、欠点は責任の所在が曖昧になるリスクなので、責任の所在は役割ベースで明確にしておきます。

メリット／デメリット

メリット：ADHD部下に合わせた運用は、短期的には生産性と士気が上がります。長期的には創造力や独自の問題解決力を引き出し、チーム全体の改善につながります。

デメリット：初期の導入には上司の時間投資が必要です。タスク細分化や頻繁なチェックは管理コストを増やす可能性があります。また、他のメンバーとの公平感に注意が必要です。

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

向いている人：具体的な作業で短時間の集中を繰り返せる業務、ペア作業やレビューが頻繁にあるチーム。エンジニアならクイックリリースやバグフィックス業務に向きます。

向いていない人：完全に独立して長期計画を一人で進め続ける業務（ただし分割や段階的レビューで適応可能）。高いドキュメント負荷や細かい事務作業が中心の仕事は苦手な傾向があります。

比較：従来型管理との違い

従来の一括タスク管理は「結果重視」で短期では効率的に見える反面、失敗恐怖のある人には不利です。一方、プロセス重視の管理は短期的に管理コストが上がりますが、長期的に信頼とスループットを高めます。選ぶ基準は「短期納期の厳しさ」と「チームのリテンション優先度」です。

チェックポイント

次の観点で現場を点検してください。点検の目的は改善の優先度決定です。

• タスクが1日以内で完了する粒度になっているか
• 失敗を報告したときの反応がチームで一貫しているか
• フィードバックが具体的な次の行動を示しているか

これらを定期的に振り返ると、何を改善すべきかが明確になります。

行動のポイント

ここで実行に移すための簡潔なチェックリストを示します。短時間で取り組める項目です。

説明：今週から試せる具体行動を並べます。

• 次のスプリントで、ADHDの部下担当タスクを「2〜8時間」単位で分割する
• 毎日のスタンドアップで「今日の完了条件」を必ず一つ宣言させる
• コードレビューでは「観察→影響→提案」の順でコメントする
• 月に1回、ブレームレスなインシデント振り返りを実施する

これらは少しのルール変更で実行可能です。効果が見えるまで3〜8週間を目安に評価してください。

結論と次のアクション

結論として、失敗を恐れるADHD部下には「予測可能な構造」と「学びにフォーカスしたフィードバック」が最も有効です。まずはタスク分割とフィードバックテンプレート（観察→影響→提案）を導入し、1か月間で効果を評価してください。改善が見られない場合は、業務配分や外部コーチの導入を検討する価値があります。

次のアクションの提案：

1. 今週、対象メンバーと15分のワンオンワンを設定し、「短期タスク」と「完了条件」を一緒に作る。
2. 次のコードレビューから「観察→影響→提案」テンプレートを試す。
3. 1か月後に進捗と心理的安全性の変化をレビューする（指標：レビュー回数、着手までの時間、本人の自己申告）。

よくある質問

Q. フィードバックはどの頻度が良いですか？

週1〜2回の短いフィードバック（10分前後）をお勧めします。頻度は「迷ったときに相談できる」バランスを目安にしてください。頻度が高すぎると監視の感覚を生むので、目的は支援であることを明確に伝えます。

Q. 失敗を許容しすぎると品質が下がりませんか？

許容とは「失敗を学びに変える仕組み」を意味します。品質を下げないためには、テスト、段階的リリース、コードレビューといった防御ラインを強化し、学習サイクルと品質管理を両立させます。

Q. 他のメンバーとの公平性はどう保つべきですか？

支援を個別の優遇と見なされないよう、目的と基準を公開します。例えば「誰にとっても有用なタスク分割ルール」として全員に適用することで公平性を担保できます。

Q. どの程度の粒度でタスクを分割すべきですか？

目安は「15分〜2日」で完了し、達成基準が明確なレベルです。短すぎるとオーバーヘッドが増えるので、チームの文化に合わせて調整してください。

Q. 外部支援（医療やコーチ）を勧めるタイミングは？

業務上の支援を行っても改善が見られず、本人が強いストレスを感じている場合は早めに提案してください。医療やコーチは本人の選択ですが、上司として情報提供と相談窓口の案内を行うと良いです。

投稿 失敗を恐れるADHD部下の育成法：上司が取る行動とフィードバック例 は ADHDエンジニア成長日記 ― 障害を抱えながらIT業界で活躍するためのブログ に最初に表示されました。