ADHDとプログラマー・エンジニア。向く職場と向かない職場を条件で分ける

「ADHDの人はプログラマーに向いている」という話は、検索するとすぐ出てきます。細かい差に気づく、興味のある対象なら長時間取り組める、論理を追うのが苦にならない——だいたいこういう説明が並びます。

ところが同じ検索結果のなかに、「実際に入ってみたら続かなかった」という話も混ざっています。同じ診断名の説明から、正反対の結論が出ている。

これは矛盾ではなく、たぶん見ている場所が違うだけです。分けているのは特性ではなく、その人が入った職場の条件のほうだと考えたほうが、話がきれいに通ります。この記事では、開発の仕事で起きる困りごとを、職場側の条件4つに分けて整理します。

先に立場を書いておきます。この記事は「ADHDだからエンジニアに向いている」とは書きません。診断名と職業適性を直結させる書き方はしません。書けるのは「こういう条件の職場では、こういう困りごとが起きにくい／起きやすい」というところまでです。

特性で適性を決めると、現場で外れる

診断名から仕事の向き不向きを導く説明が外れやすいのは、困りごとが本人の中だけで完結していないからです。同じ人が、A社では普通に働けて、B社では三か月で消耗する。このとき変わったのは本人ではなく、まわりの運用です。

参考になる調査があります。障害者職業総合センターの調査研究報告書No.125（2015年3月）は、就業中の発達障害のある人の職業生活への満足度を因子分析し、満足度を構成する要素として「周囲の人たちの理解」「仕事のやりがい」「否定的な対応が少ない」の三つを抽出しています（出典・確認日は記事末尾）。

三つとも、本人の能力を指していません。全部、職場の側の状態です。もちろんこの調査はIT職に限ったものではありませんが、「本人の特性より職場の条件を見たほうが説明がつく」という方向は、開発現場の話としても素直に受け取れます。

以下、開発の仕事に絞って条件を四つに分けます。

条件1：集中する対象を、自分の裁量で選べるか

エンジニア職は「集中できる仕事」と語られがちですが、実際には集中の対象を誰が決めるかで、まったく別の仕事になります。

朝にその日のタスクが割り当てられていて、着手する順番を自分で決めてよい職場があります。一方で、チャットに飛んできたものを飛んできた順に処理する職場もあります。書いているコードの種類は同じでも、後者では「次に何をやるか」の判断を一日に何十回も繰り返すことになります。

困りごととして表に出るのは、たいてい「取りかかれない」という形です。ただし、取りかかれない理由は仕事の内容ではなく、着手の判断が細かく分割されていることのほうにある場合があります。判断の回数が減る運用——チケットで管理されている、一日単位で担当が決まっている、着手順は本人に任されている——だと、この詰まりは起きにくくなります。

同じ「エンジニア職」でも、一日の形はここまで変わります。

片方は、朝会でその日のチケットを二枚受け取り、あとは夕方まで自分で順番を決めて進める。途中で誰かに呼ばれることはあるが、当番の人が一次対応を引き受けているので、自分のところまで上がってくるのは本当に必要なときだけ。もう片方は、常時開いているチャットに、顧客からの質問、社内からの依頼、障害の一報が混ざって流れてくる。どれも「すぐ見てほしい」と書いてある。何を先にやるかは自分で判断するしかないが、判断の材料は本文に書かれていない。

後者で消耗するのは、コードが難しいからではありません。一日の大半を、コードではなく順番を決めることに使っているからです。この違いは、職種名でも会社の規模でも表せません。運用の形の話なので、中に入っている人に聞かないと分かりません。

念のため書いておくと、これは「ADHDのある人は集中力が高い」という話ではありません。集中の対象を自分で決められる環境のほうが、着手までのコストが低い、というだけの話です。これは誰にでも当てはまることで、影響の出方に差があるだけです。

条件2：締切の粒度と、割り込みの入り方

締切があること自体より、締切が一本か、無数かのほうが効きます。

二週間後に一本だけ締切がある状態と、一日のなかに細かい期限が十個ある状態では、必要な段取りがまったく違います。前者は自分の中で組み立て直せますが、後者は組み立て直す暇がありません。

割り込みも同じで、量より入り方です。問い合わせの一次受け、障害対応、顧客からの緊急依頼。これらが当番制で回っているなら、「今日は自分の番ではない」という日が作れます。全員が常時受ける運用だと、まとまった時間が構造的に取れません。

受託開発か自社サービスか、という分け方がよく使われますが、これも本当に効いているのは会社の形ではなく、締切を決めているのが誰かという点です。自社サービスでも、リリース日が先に決まっていて中身が後から膨らむ運用なら、状況は受託と変わりません。

見積もりの扱いも、同じ条件の一部です。自分で見積もりを出して、その数字がそのまま予定になる職場では、遅れそうなときに早めに言えます。ところが営業側で工数が決まってから降りてくる職場では、最初から間に合わない数字を渡されることがあり、そこから先はずっと遅れている状態が続きます。常に遅れている状態は、締切が一本あるのとはまったく別の負荷です。「今日中に終わらせないと」が毎日続き、区切りが来ません。

割り込みについては、量だけでなく回復の時間も見ておくといいところです。一度中断したあと、元の作業の文脈を思い出すのにかかる時間は人によって差があります。一日に三回中断が入るだけで、実際に手が動く時間が半分になることもあります。ここは「割り込みが多い職場だから頑張る」で押し切れる部分ではないので、条件として先に確かめておく価値があります。

条件3：レビューが仕組みになっているか

書いたものを他人と機械が読む仕組みがあるかどうかは、かなり大きい条件です。

具体的には、プルリクエストのレビューが必須になっているか、自動テストとCIが通らないとマージできないか、静的解析やフォーマッタが入っているか。この辺りです。

抜けやケアレスミスは誰にでも出ます。問題は、それが仕組みで拾われるか、本人の注意不足として個人に返ってくるかです。CIが先に落ちる職場では、抜けはレビュー以前の段階で機械が見つけます。同じ抜けが、レビュー文化のない職場では口頭注意になり、繰り返されると人事評価の話になります。

起きている出来事は同じで、返ってくる形だけが違う。ここは求人票にほとんど書かれないので、面接で確かめる以外にありません。

もう一つ、レビューが仕組みになっている職場には副次的な利点があります。判断の根拠が文字で残ることです。「なぜこの実装にしたか」がプルリクエストのコメントに書かれていれば、三か月後に自分で読み返せます。口頭で決まって口頭で承認される職場では、決めた理由がどこにも残らないので、後から「あれはどういう意図だったか」と聞かれたときに答えられません。記憶に頼る量が減るという意味で、レビュー文化は締切の管理よりも地味に効いてきます。

逆に注意しておきたいのは、「レビューはあります」と言われても中身が形骸化している場合です。誰も読まずに承認だけ押している、指摘は出るが全部が「好みの問題」で判断基準が人によって違う、といった状態だと、仕組みとしては機能していません。ここを見分けるには、レビューの承認が何人必要か、CIに何が含まれているか、といった具体で聞くのが早いです。

条件4：新規開発か、保守運用か

通説では「新規開発のほうが向いている」と言われますが、そう単純でもありません。両方に、逆向きの条件が同居しているからです。

新規開発は裁量が大きく、まとまった時間を取りやすい一方で、仕様が固まっておらず、決め直しが多く、締切が読みにくい。保守運用は割り込みが多くて細切れになりやすい一方で、手順が文書化されていて判断の回数が少なく、当番制が敷かれていることも多い。

つまり見るべきなのは「新規か保守か」ではなく、裁量の大きさと割り込みの量が、その職場でどう組み合わさっているかです。裁量が大きくて割り込みが少ない持ち場が、いちばん条件がそろっています。それは新規開発かもしれないし、社内ツールの改善かもしれないし、テスト基盤の整備かもしれません。役職名ではなく持ち場で見たほうが精度が出ます。

見落とされやすい持ち場を挙げておきます。社内向けの業務ツール、データ集計の自動化、テストコードの整備、開発環境やビルドの改善、ドキュメントとコードの同期。どれも締切が外部の顧客ではなく社内の都合で決まるため、交渉できる幅が広い仕事です。派手さはありませんが、まとまった時間が取りやすく、成果が数字で示しやすい。求人としては「バックエンド」や「社内SE」という枠に埋もれていることが多いので、募集要項ではなく業務内容の記述を読むと見つかります。

逆に、新規開発でも条件が悪くなる典型があります。仕様が決まる前に開発を始めていて、途中で何度も方針が変わり、それでもリリース日だけは動かない、という進み方です。裁量があるように見えて、実際には決め直しに引きずられて自分の予定を組めません。「新規開発なら大丈夫」と考えて入ると、ここで外れます。

入る前に、この四つをどう確かめるか

求人票からは判断できないので、面接で聞くことになります。診断のことを話さなくても、普通の求職者として聞ける質問だけを挙げます。

最後の一問は、答えの内容よりも答えが即座に出てくるかどうかを見ています。記録する場所が決まっている職場なら、担当者はすぐに答えられます。

診断を開示するかどうかは、これとは別の判断です。開示して配慮を求める道を選ぶ場合、事業主には障害者雇用促進法にもとづく差別禁止と、障害者からの申し出に応じた合理的配慮の提供義務があります（過重な負担になる場合は除く。厚生労働省「事業主の方へ」）。ここで挙げた四条件は、「静かな席がほしい」といった漠然とした要望より、申し出の形にしやすい部類です。着手順の裁量、当番制、レビューの運用は、どれもチームの運用ルールの話だからです。

規模の話も一つだけ。令和6年6月1日時点で、民間企業に雇用されている障害者は677,461.5人、実雇用率は2.41%でした（厚生労働省「令和6年 障害者雇用状況の集計結果」、2026年8月27日確認）。この枠を使う働き方もありますが、開示すれば解決するという話ではありません。開示は、その職場の条件と合わせて決めるものです。

AIで軽くなるところと、軽くならないところ

生成AIが開発の仕事に入ってきたことで、軽くなった部分ははっきりあります。

軽くなりやすいのは、着手の手前です。「まず何を書けばいいか分からない」で止まっているとき、AIに最初の骨組みを出させると、そこから直す作業に切り替わります。ゼロから始めるのと、間違っているものを直すのとでは、必要な段取りが違います。ほかに、エラーメッセージの読み解き、他人が書いたコードの説明、テストの下書き、長い仕様書の要約なども、詰まりが減りやすい作業です。

使い方を一つだけ固定しておくと安定します。たとえば、作業を中断されたときに「いまやっていたこと、次にやること」を一行で書き残す先をAIとの会話にしてしまう。戻ってきたときに、その一行を読んで続きから再開できます。中断からの復帰にかかる時間は条件2で触れた負荷の中身そのものなので、ここを短くできると効き方が大きくなります。

軽くならないのは、条件2で書いた部分です。AIは割り込みの量を減らしません。締切の決まり方も変えません。むしろ、聞けば何か返ってくる相手が常時そばにいる状態は、脱線の入口が一つ増える面もあります。調べもののつもりで始めて、気づくと関係のない話題を掘っていた、というのは普通に起きます。

構造の話も添えておきます。IPAの資料では、日本企業の85.1%でDXを推進する人材が不足しているとされています（IPA「DX動向2025-AI時代のデジタル人材育成」2025年10月9日公開、2026年8月27日確認）。人が足りない現場ほど、割り込みは少数の人に集中します。AIが入っても、この構造は自動では変わりません。ツールの話と職場の条件の話は、分けて考えたほうがいいところです。

条件が合っていないと分かったとき

四つの条件のうち、変えやすいものと変えにくいものがあります。ここを分けておくと、次にやることが決まります。

比較的変えやすいのは、着手順の裁量、当番制の導入、レビューとCIの運用です。これらはチーム単位のルールなので、チームの中で交渉できる余地があります。合理的配慮の申し出として出す道もあれば、単に「この運用のほうがチーム全体の手戻りが減る」という提案として出す道もあります。

変えにくいのは、受託か自社か、顧客との距離、締切を誰が決めるか。会社の商売の形そのものなので、個人の申し出ではまず動きません。ここが原因なら、同じ会社の中で粘るより、条件の違う職場を探すほうが早い場合があります。

大事なのは、辞める・続けるを決める前に、四つのうちどれが効いていたのかを一つに絞ることです。「全部だめだった」で終わらせると、次の職場選びに何も使えません。「割り込みが常時入る運用だけが無理だった」まで絞れていれば、次の面接で聞く質問が決まります。

絞るための方法は、記憶をたどるより記録を取るほうが確実です。二週間だけ、詰まった瞬間にその場で一行だけ書き残します。時刻と、そのとき何が起きたか。「10:40 チャットで別件が来て中断」「14:20 どれから手をつけるか決められず三十分」といった粒度で十分です。二週間分を並べると、だいたい一つか二つの型に集中します。ここまで来れば、それが変えやすい条件なのか、会社の商売の形に由来するのかも判断できます。この記録は、配慮を申し出るときの材料としてもそのまま使えます。困っている実感を言葉で説明するより、いつ何が起きたかの一覧を見せるほうが、話が早く進むことが多いからです。

もう一点。うまくいかない理由が締切や割り込みではなく、「要件が口頭で変わる」「暗黙の優先順位が読めない」「レビューでの言い方で評価が下がる」といった、曖昧さと合意形成のほうに寄っている場合があります。詰まっている場所が違うと打ち手も変わるので、そちらはASDとプログラマーの記事で別に扱っています。

いまの職場でいきなり試すのが難しければ、訓練を受けながら条件を確かめられる場所もあります。就労移行支援のなかにはIT・データ分野に特化した事業所があり、実際の作業を通して、自分がどの条件で詰まるのかを見てから決められます。合わなければ断って構いません。判断の材料を増やすためのものです。