
ADHDエンジニアがマネージャーになって成功するために捨てた3つの習慣
結論:ADHDのエンジニアがマネージャーで成果を出すために捨てるべき習慣は「全部自分でやろうとする」「衝動的に計画を破る」「自己集中だけに依存する」の3つです。これらを捨て、委任・仕組み化・環境調整を取り入れると、感情的な負担が減りチームの生産性が上がります。
導入:私は現場でコードを書いてきたエンジニアからマネージャーに転じたとき、自分のADHD特性がリーダーシップにどう影響するかを強く感じました。衝動的に手を動かしてしまう性向や、ハイパーフォーカスで長時間抜け出せなくなる癖は、マネジメントでは裏目になることが多いです。以下では私が実際に捨てて効果があった3つの習慣と、具体的な手順、判断基準、利点と注意点を述べます。
要点まとめ
次に挙げる3つは、私がマネージャーになって意識的にやめた習慣です。各項目はすぐ使える代替行動とともに説明します。
これらの習慣をやめる目的は、個人の作業量を減らしチームのスケーラビリティを高めることです。具体的な代替策と判断基準を示します。
- 全部自分でやる→割り切って委任とSOP(標準作業手順)を作る
- 衝動的に計画を破る→短いタイムボックスと意思決定のプロトコルを導入する
- 環境に頼らない自力集中→感覚的な調整と外部トリガーでワークフローを安定化する
上の3点を捨てると、決断の疲労(decision fatigue)が減り、フィードバックを循環させやすくなります。以下で各項目を詳述します。
1. 捨てた習慣1:全部自分でやる(「自分がやった方が早い」思考)
説明:エンジニア時代に「自分でやったほうが早い」と考え、設計レビュー・デプロイ・バグ修正まで手を出してしまう傾向がありました。マネージャーになっても同じ癖を続けると、個人の生産性がボトルネックになりチーム全体の成長を阻害します。
なぜADHDだと起きやすいか:衝動性や即効性を求める性質、他人の仕事を待つことへのストレスが背景にあります。また、指示を出すより自分でやった方が確実という感覚が強くなります。
判断基準(委任すべきか否か):作業が反復的・手順化できるか、知識共有によって他者に託しても品質が保てるか、緊急度に対して自分しか対応できない特殊スキルか、の3点で判断します。これらは現場の迅速な意思決定に使えます。
実践例(エンジニア例):ある日、プロダクションで頻発する小さなバグ対応を私がすべて引き受けていました。そこで「バグの優先度判定ルール」と「テンプレート付きのチケット」を作り、ジュニアエンジニアに割り振りました。最初は手戻りがあったものの、テンプレートにあるチェックリストを満たすことで再発率が下がり、私はアーキテクチャ判断に集中できるようになりました。
代替行動:委任テンプレート、SOP(手順書)、コードオーナーシップの明確化、ペアレビュー制度を導入します。最初はレビュー時間が増えますが、3ヶ月で私の作業時間が半分になり、オンコール対応の頻度が減りました。
メリット・デメリット:委任はスケールさせる効果が大きい一方、初期投資(教育・ドキュメント作成)が必要です。品質が一時的に落ちるリスクもありますが、トレードオフとしては長期的に見れば十分に回収できます。
2. 捨てた習慣2:衝動的に計画を破る(「今やらないと忘れる」思考)
説明:アイデアや問題を思いついた瞬間に「今やる」癖があり、アジェンダを乱したりスプリントの優先順位を壊してしまいました。マネージャーは複数の利害調整と長期のロードマップ管理が必要なので、衝動がチームの安定を壊します。
なぜADHDだと起きやすいか:衝動性とハイパーリアクティブな注意配分により、短期的な刺激を優先する傾向があります。また、実行前の計画作成が苦手(実行機能の問題)で、即行動で安心を得ようとします。
判断基準(割り込みを許可するか):影響範囲(ユーザーへの影響、セキュリティリスク)、解決の緊急度(デグレードを起こすか)、既存の優先順位との相対価値の3点で判断します。緊急かつ高影響なら割り込み、そうでなければバックログに追加します。
実践例(エンジニア例):ある朝、製品の小さなUI表示ズレを見つけ「すぐ直す」と言いかけた自分を止め、代わりに「10分ルール」を導入しました。10分で済むなら当日中に処理、10分以上かかるならチケット化して優先度評価を経るルールです。結果として優先度判断が安定し、スプリント目標への影響が減りました。
代替行動:短いタイムボックス(5–30分ルール)、割り込みガイドライン、チケット化とレビュー会議での優先度決定を導入します。また、思いついたタスクは瞬時に記録して戻れる仕組み(音声メモや簡易チケット)を作るとストレスが和らぎます。
メリット・デメリット:衝動を抑えるとロードマップが安定しやすくなりますが、過度に固定化すると機会損失を招くことがあります。重要度評価のルールをシンプルにし、緊急時のエスカレーション手順を明確にすることでバランスを取ります。
3. 捨てた習慣3:環境に頼らない自力集中(「自分の集中力が全て」思考)
説明:ノイズや雑談に弱い感覚過敏、ハイパーフォーカスで時間を忘れる傾向がありました。自分の集中力に頼るとスケジュールが読めず、会議や1on1を飛ばしたり遅延を生みます。マネージャーはチームとの約束を守ることが信頼につながるため、環境面の工夫が必須になります。
なぜADHDだと起きやすいか:感覚過敏や集中の波があると、安定したパフォーマンスを自分の意思だけで保つのが難しいからです。外部トリガーやルーチンに頼る方が合理的です。
判断基準(どの環境調整が必要か):会議の頻度と重要度、自分の生産性パターン(朝型/夜型、ハイパーフォーカス時間帯)、チームの働き方(リモート/オンサイト)を考慮します。会議は自分の集中のピーク時間に入れない、ドキュメント中心で非同期コミュニケーションを推奨、などが基準です。
実践例(エンジニア例):デイリースタンドアップが午前9時に設定されていましたが、私は午前中に最も集中が切れやすいため、代わりに「午後の短い非同期チェックイン」を導入しました。具体的にはSlackの定型フォーマットで「今日やること・ブロッカー・完了予定」を各自が投稿する運用です。結果として、私のハイパーフォーカス時間に深い設計判断ができ、会議時間も短縮されました。
代替行動:固定したルーチン、外部トリガー(アラーム、カレンダーの色分け)、ノイズキャンセル機器、会議の非同期化、短時間の集中ブロック設定(ポモドーロ系)を活用します。
メリット・デメリット:環境調整により安定したアウトプットが期待できますが、チームメンバーの習慣との調整が必要です。導入は段階的に行い、チームの合意を得ることが重要です。
メリット
説明:これらの習慣を捨てることで得られる主なメリットを説明します。
まず、精神的な負担が減ります。手順や委任が決まっていると、衝動的に飛びつくストレスが小さくなります。次に、チームのスループットが上がります。私の経験では、SOPと委任でリリースサイクルが短くなり、オンコール対応の平均時間が20%減少しました。最後に、自己管理のコストが下がります。外部トリガーに依存することで意思決定の消耗を避けられます。
デメリット
説明:取り組みの注意点と限界も明確にします。
最初の負担として「教育コスト」と「ドキュメント作成」が発生します。委任に伴うバグやリワークは短期的に増える可能性があります。また、柔軟性を求められる場面で過度にルール化すると機会損失を招きます。これらを回避するため、初期は段階的導入と頻繁なフィードバックループを設けるべきです。
向いている人
説明:この方法が特に効果的な人の特徴を述べます。
短期的な刺激に流されやすいが、チームの成果を出したいエンジニア出身のマネージャーに向いています。プロダクト開発で複数の利害関係者を調整する必要があり、再現性のあるプロセスを好む組織でも効果的です。
向いていない人
説明:逆に不向きなケースも示します。
極めて小規模で即応性が最優先(例:小さなスタートアップで立ち上げ期に全員が同時に即断即決する文化)のチームでは、過度のプロセス化が足かせになることがあります。その場合は最小限の取り組みに留め、状況に応じて柔軟に戻せるようにしておくとよいです。
比較:やめる前と後の違い(短めの指標)
説明:効果を把握するための比較指標を示します。数値は私の職場での観察に基づく目安です。
- ミーティング時間:週あたり合計が20%減少
- オンコール平均対応時間:20%減少
- 個人の集中可能時間(深い設計):1.5倍に増加
これらは組織やプロダクトによって変わりますが、傾向としてはプロセス化と環境調整が正の効果を持ちます。
チェックポイント
説明:導入の進捗を測るための短いセルフチェックです。週次で確認してください。
- 主要作業のうち、誰かに委任できるものが明確にドキュメント化されているか
- 割り込みルールがチームで合意され、適用されているか
- 自分の集中ピーク時間帯に重要な会議を入れていないか
チェック後は小さな調整(15分のプロセス改善)を必ず行い、1週間で効果を評価してください。
行動のポイント
説明:すぐに実行できる3つの短いアクションプランです。簡潔に実行して結果を観察してください。
- 今週中に「5分テンプレート」を作る:バグ報告や小改善の標準テンプレート(優先度、再現手順、期待値)を用意し、誰でもチケット化できるようにする
- 10分ルールを導入する:思いついた作業は10分以内なら実行、超える場合はチケット化して優先度を評価する
- 週2回の非同期チェックインを試す:短いフォーマットで状況共有を行い、会議を圧縮する
これらは小さく始められるため、抵抗感が少なく継続しやすいです。
結論と次のステップ
結論:ADHDの特性を抱えたエンジニアがマネージャーで成功するには、「全部自分で抱え込む」「衝動で計画を壊す」「自力の集中に頼りすぎる」という3つの習慣を意図的にやめ、代わりに委任・仕組み化・環境調整を取り入れることが有効です。短期的には教育コストや調整負荷がありますが、中長期では心的負担が減りチームの成果が上がります。
次のステップ:まずは「テンプレート作成」と「10分ルール」の導入から始めてください。1ヶ月後にチェックポイントを確認し、必要に応じて微調整を続けましょう。
よくある質問
Q. ADHDでもマネージャー向きになれますか?
はい。ADHDの特性はマネジメントに向かないと誤解されがちですが、適切な仕組みと環境を作れば強みになります。衝動性は迅速な意思決定に、ハイパーフォーカスは重要な技術課題の深掘りに生かせます。重要なのは「自分で全てやらない」ルールと外部トリガーを設けることです。
Q. 委任すると品質が落ちる不安がある場合はどうする?
短期的には教育とレビューでカバーします。具体的には、テンプレート+ペアレビュー+段階的権限委譲の組み合わせを使います。最初はペアで作業し、品質が安定したら独り立ちさせる流れが効果的です。
Q. 会議が多い組織でどうやって非同期化を進めればいいですか?
全会議を非同期にする必要はありません。まずは情報共有系の会議(ステータスや軽微な議題)を非同期に置き換え、意思決定や議論が必要な会議は短く集中させます。成功基準は「会議時間の削減」と「決定の遅延が発生しないこと」です。
Q. 衝動を完全に抑えられないときの対処法は?
抑えるのではなく「受け流す」仕組みを作ります。思いついたアイデアは即記録(音声メモや簡易チケット)して、後で評価する習慣をつけると衝動による業務妨害が減ります。
Q. 小さなスタートアップではどう適用すればいいですか?
過度なプロセスは避け、最小限のルールだけ導入します。例えば「10分ルール」と「バグテンプレート」のみ取り入れ、チームの合意を得たら徐々にルールを拡張してください。状況次第でいつでも緩められる柔軟さを残すことが重要です。
コメント