この記事のポイント
- 「発達特性があるからプログラミングに向いている」は安易な一般化であり、そのまま信じると判断を誤る
- ASD傾向の「ルールベース思考」とADHD傾向の「過集中・新奇追求」が、コーディングと構造的に噛み合う理由がある
- ただし相性が良いのはプログラミングの全工程ではなく、特定の条件がそろった場合に限られる
- チーム開発のコミュニケーション負荷や保守運用の単調さなど、相性が悪い条件も正直に知る必要がある
- 「向いてる/向いてない」の二択ではなく「自分で触って確かめる」のが最も確実
もーやん「ADHDはプログラマーに向いてる」って記事をよく見るんだけど、あれって本当なの？
かりぶー半分本当で、半分は雑すぎる話かな。「向いてる」には条件がある。
もーやん条件？ 「集中力があるから」とかじゃなくて？
かりぶーそれだけだと説明として足りないんだよね。なぜ相性がいいのかの構造を見てみよう。あと、向いてない条件もセットで。
この記事では、「発達特性×プログラミングは本当に相性がいいのか」を、認知特性の構造から整理します。ASD傾向とADHD傾向で相性の理由が異なること、プログラミングの「どのフェーズ」と噛み合うのか、そして相性が悪い条件まで含めて、当事者としての体験を交えながら解説します。
この記事が向いている人・向いていない人
この記事がどういう方に向いているかを先に整理しておきます。
向いていない人に当てはまる場合は、リンク先の記事から読むとスムーズです。
「発達特性×プログラミング＝相性がいい」は本当か
「発達障害だからプログラミングが向いている」という言い方は安易な一般化であり、そのまま信じると期待と現実のギャップに苦しむ可能性があります。
ネット上には「ADHDの人はプログラマーに向いています」「ASDの人はIT系と相性が抜群」といった記事が多くあります。就労移行支援の集客記事やプログラミングスクールの広告記事が典型で、そこでは「集中力がある」「細かい作業が得意」程度の理由で「向いている」と結論づけられています。
しかし、実際にはもう少し複雑です。
プログラミングという作業は、設計・実装・テスト・保守といった複数のフェーズで成り立っています。発達特性との相性は、フェーズごとにまったく異なります。「プログラミングが向いてる」ではなく「プログラミングのどの部分と、自分のどの特性が噛み合うか」を見る必要があります。
ここからは、ASD傾向とADHD傾向に分けて、プログラミングとの相性の構造を見ていきます。
ASD傾向とプログラミングの相性｜ルールベース思考が噛み合う理由
ASD傾向に見られる「入力→操作→出力のルールを見つけ出す力」は、プログラミングの論理構造と構造的に噛み合いやすい特性です。
「ASDの人はIT向き」という話はよく聞きますが、その説明が「几帳面だから」「こだわりが強いから」で終わっている記事が多いです。もう少し踏み込んで、なぜ噛み合うのかの構造を見てみます。
システム化能力とプログラミング
認知科学者のBaron-Cohenが提唱したシステム化理論では、ASD傾向のある人は「システム化指数（SQ）」が高い傾向があるとされています。システム化とは、「入力→操作→出力」のルールを抽出し、そのルールに基づいてシステムの振る舞いを予測する能力のことです。
プログラミングは、まさにこの「ルールに基づいてシステムを構築する」作業です。変数に値を入れ、条件分岐で処理を振り分け、結果を出力する。この一連の流れは「入力→操作→出力」のルールそのものであり、システム化能力が高い人にとっては「自然に頭が動く」領域になりやすいと考えられます。
実際に、IT業界で働く人は一般集団よりもAQ（自閉症スペクトラム指数）が高い傾向があるという研究報告もあります。ただしこれは「ASD＝IT向き」という意味ではなく、IT業界の仕事構造がシステム化能力の高い人に合いやすいという環境側の要因も大きいと解釈されています。
パターン認識とデバッグの相性
ASD傾向に見られるもう1つの特性が、パターンの細部に対する高い注意力です。コードのデバッグ（バグ探し）では、大量のコードの中から「ここだけ他と違う」箇所を見つける必要があります。
全体をざっくり見るのではなく、一行ずつ規則に照らし合わせて確認していく作業は、パターン認識の強さが活きやすい場面です。
ただし、後述するようにこの「パターン認識が活きる場面」はプログラミングの一部であり、プログラミングのすべてではありません。
HTML/CSSを触って「これは合う」と感じた ― エピソード
実際に自分が経験した場面を紹介します。
本業はUXデザインで、Webサイトのプロトタイプを作るのにHTML/CSSを触り始めた。デザインカンプをそのまま画面に再現する作業。
最初はコピペばっかりで何やってるかわからなかった。でも3日くらいで「このプロパティを変えるとここが動く」っていう規則が見えてきた。
そこからが早かった。気づいたら4時間経ってた。昼ごはん食べてない。隣の席の人に「まだやってるの？」って言われて時計を見た。
デザインの仕事だと、クライアントのフィードバックが「もうちょっと柔らかく」とか抽象的で、何を直せばいいかわからないことが多い。コードは違った。書いたら書いたぶんだけ結果が出る。
正解があるのがこんなに楽だとは思わなかった。
「規則が見えてきた瞬間に加速する」というのは、システム化能力が高い人に起こりやすい感覚です。ルールが見えた途端に「あとは当てはめるだけ」になるから、一気にスピードが上がります。
もーやんなるほど、「ルールに基づいてシステムを作る」のが得意ってことか。
かりぶーそう。ただ、プログラミングの全部がルールベースというわけでもなくて、チーム開発のコミュニケーションとか、曖昧な仕様をどう解釈するかとか、ルールがない部分もけっこうある。その話はあとで。
ADHD傾向とプログラミングの相性｜過集中と新奇追求が活きる場面
ADHD傾向に見られる「過集中」と「新奇追求」は、コーディングの特定の場面で強みとして機能しやすい特性です。
ASD傾向とは別の角度で、ADHD傾向もプログラミングと相性がいい面があります。ただし、こちらも「常に相性がいい」わけではなく、特定の条件が揃ったときに強みになるという話です。
過集中とコーディングの関係
ADHD研究において、過集中（hyperfocus）は中核的な特性の1つとして注目されています。研究では、過集中とは「興味関心のある活動に対して、通常を超える長時間の集中状態に入ること」と整理されています。
コーディングは、この過集中を引き出しやすい活動の1つです。理由はいくつかあります。
- 即時フィードバックがある
コードを書く→実行する→結果が画面に出る。このサイクルが短いため、報酬系が刺激されやすい - 問題解決の連鎖がある
1つのバグを直すと次の課題が見え、次の課題を直すとさらに次が見える。この連鎖が「止められなくなる」構造を作る - 自分のペースで進められる
会議のように他人のペースに合わせる必要がなく、自分の集中リズムで作業しやすい
ただし、過集中には「自分でコントロールしにくい」という側面もあります。興味が湧かないコードには一切集中できなかったり、集中しすぎて他のタスクを忘れたりすることもあります。過集中の活かし方と制御方法については 過集中がやめられないのは意志の問題じゃない｜ADHDの「没頭しすぎ」を仕組みで止める5つの方法 で詳しく整理しています。
新奇追求と技術領域の広さ
ある研究では、ADHD成人は「拡散的思考」のスコアが高く、新奇追求（novelty-seeking）の傾向が創造的な問題解決と関連しているとされています。
プログラミングの世界は、新しい言語、新しいフレームワーク、新しいツールが次々に出てきます。「新しいもの好き」の傾向がある人にとって、この技術領域の広さは飽きにくい環境になり得ます。
一方で、1つの技術を深く習熟する前に次の新しい技術に飛びつきたくなるという裏面もあります。エンジニアとしてキャリアを積む場合、ある程度の深さは必要になるため、ここは意識しておく必要があります。
JavaScriptの条件分岐にハマった夜 ― エピソード
実際に自分が経験した場面を紹介します。
HTML/CSSに慣れてきて、JavaScriptを触り始めた。if文を初めて書いた日のことは覚えてる。
「もしAならBを実行、そうでなければCを実行」。それだけの話なんだけど、自分の頭の中にあるルールをそのまま文字にできる感覚があった。
昼間、後輩に「この資料、もう少しわかりやすくしてもらえますか？」って言ったら全然違う方向に直されて、何回もやり直しになった。でもコードは書いたとおりに動く。期待を裏切らない。
その夜、気づいたら朝の5時だった。翌日の会議でぼんやりしてて、上司に「大丈夫？」って聞かれた。
「ちょっと寝不足で」とだけ答えた。
「コードは期待を裏切らない」という感覚は、過集中を引き出す重要な要素です。人間関係での「予測の外れ」にストレスを感じやすい人にとって、コードの「書いたとおりに動く」確実性は心理的な安心感につながります。
相性が悪い条件も正直に｜プログラミングの「ここがキツい」
プログラミングと発達特性の相性には「良い条件」と「悪い条件」の両方があり、悪い条件を知らないまま飛び込むと挫折しやすくなります。
ここまで「なぜ相性がいいのか」を見てきましたが、プログラミングを仕事にする場合、相性がいい部分だけではやっていけません。実際の仕事には、発達特性と相性が悪い場面がかなりあります。
チーム開発のコミュニケーション負荷
プログラミングの勉強をしている間は一人で完結しますが、仕事にすると「チーム開発」が基本になります。Slackでのやりとり、プルリクエスト（コードの変更内容を他のメンバーに確認してもらう仕組み）のレビュー、設計の合意形成。これらはすべてコミュニケーションであり、コードを書く力とは別のスキルが求められます。
特に以下の場面は、ASD傾向やADHD傾向のある人にとってストレスが大きくなりやすいです。
- コードレビューの指摘が何を求めているかわからない
技術的な指摘なのかスタイルの好みなのか区別がつきにくい - 曖昧な仕様を「良い感じに」実装してほしいと言われる
「良い感じに」の基準がわからず手が止まる - テキストコミュニケーションのニュアンスが読み取れない
Slackの一言返事が怒っているのか了解しているのかわからない
「プログラミングは一人でやるもの」と思って入ると、この部分でギャップを感じることがあります。
保守運用の単調さ
新しいシステムをゼロから作る仕事と、既存のシステムを維持する仕事では、必要な特性がまったく異なります。保守運用は、他人が書いたコードを読み、バグを修正し、小さな機能追加を繰り返す仕事です。新しいものを作る興奮がほとんどありません。
ADHD傾向の「新奇追求」が強い人にとって、この単調さは非常にキツい環境になり得ます。
チーム開発で壁にぶつかった ― エピソード
実際に経験した場面を紹介します。
個人で勉強してるうちは楽しかった。でもオンラインのチーム開発イベントに参加したら、全然違った。
Slackでのやりとりが苦手だった。「ここのロジック、もう少し整理してもらえますか？」って言われて、「整理って何をどうすれば？」がわからなかった。聞き返すのも気が引けて、自分なりに直したら「違う、そうじゃなくて」と返ってきた。
コードレビューの指摘も、技術的な話なのかスタイルの好みなのか区別がつかなかった。
「プログラミングは一人でやるもの」と思ってたけど、仕事にすると人との調整がけっこうある。そこは正直しんどかった。
チーム開発が苦手だからプログラミングに向いていない、ということではありません。ただ、「コードが書ける」と「エンジニアとして働ける」の間にはギャップがあるということは知っておいた方がいいです。
保守運用で飽きた ― エピソード
もう1つ、「相性が悪い条件」の体験です。
知り合いのスタートアップで、既存サービスの保守を手伝うことになった。バグの修正と、ちょっとした機能追加。
最初の1週間で飽きた。他人が書いたコードを読むのがまず苦痛。なぜこう書いたのかわからない箇所が多い。自分で一から書き直したくなる。
バグ修正は「間違い探し」みたいなもので、新しいことが何もない。2週間くらいで「これは自分に合ってないかも」と思った。
新しいものを作るのは好きだけど、維持するのは別の話だった。
「プログラミング」と一口に言っても、新規開発と保守運用では求められるものが大きく違います。自分がどちらに相性がいいかは、実際にやってみないとわかりません。
プログラミングの工程別・相性マップ
プログラミングの各工程と発達特性との相性を整理しておきます。
| 工程 | 内容 | ASD傾向との相性 | ADHD傾向との相性 |
|---|---|---|---|
| 要件定義 | クライアントの要望を聞き取り、仕様に落とす | 曖昧な要望の解釈が難しい場合がある | ヒアリングの集中維持が難しい場合がある |
| 設計 | 全体構造を考え、データの流れを決める | ルールベース思考が活きやすい | 全体の俯瞰とゼロからの発想で強みが出る場合がある |
| 実装（コーディング） | 実際にコードを書く | パターン認識・ルール適用が活きやすい | 過集中が発動しやすく没頭できる |
| テスト・デバッグ | バグを探して修正する | 細部への注意力が活きやすい | 単調さで集中が切れやすい場合がある |
| 保守運用 | 既存システムの維持・改修 | ルーティンが合う人もいる | 新奇性がなく飽きやすい |
| チーム開発 | レビュー・合意形成・Slackやりとり | コミュニケーション負荷が高い | 複数の会話スレッドの管理が難しい場合がある |
この表は傾向であり、個人差が大きい領域です。同じADHD傾向でも保守運用が苦にならない人もいますし、ASD傾向でもチーム開発が得意な人もいます。あくまで「注意すべきポイント」として見てください。
もーやんなるほど、実装は相性がよさそうだけど、チーム開発とか保守運用は別の話なんだ。
かりぶーそう。だから「プログラミングが向いてる」じゃなくて「プログラミングのこの部分が自分のこの特性と合ってる」まで分解して考えた方がいいと思う。
プログラミングとの相性を試す現実的な方法
「向いてるか向いてないか」は理論で判断するよりも、小さく触ってみて確かめるのが最も確実です。
ここまで構造的な話をしてきましたが、結局のところ「自分に合うかどうか」は実際にやってみないとわかりません。ここでは、リスクを最小限にしながらプログラミングとの相性を確かめる方法を整理します。
ステップ1：無料の学習サービスで触ってみる
最初のステップは、お金をかけずにコードに触れてみることです。以下のような方法があります。
- Progate・ドットインストール
ブラウザ上でコードを書いて結果を確認できる。HTML/CSS/JavaScript/Pythonなどの基礎を無料で学べる - YouTube・Udemyの入門講座
動画を見ながら手を動かすスタイル。自分のペースで進められる - ChatGPTやCopilotにコードの意味を質問しながら進める
「この行は何をしているの？」を都度聞ける環境を作ると、独学の壁が下がる
ポイントは「勉強する」感覚ではなく、「触ってみて、自分の反応を観察する」という姿勢です。2〜3時間触って「もっとやりたい」と感じるか、「もういいかな」と感じるか。その初期反応はわりと正直です。
ステップ2：小さな成果物を作ってみる
基礎を触って面白かった場合、次は何かを「作ってみる」ステップです。
自分で使うちょっとしたツール（タスク管理のメモアプリ、家計計算ツール、ポートフォリオサイト等）を作ってみると、「学ぶ楽しさ」と「作る楽しさ」が自分にとって同じかどうかがわかります。学ぶのは好きだけど作るのは面倒、というパターンもあります。
ステップ3：体系的に学びたくなったらスクールを検討する
独学で触ってみて「もっと体系的に学びたい」「独学だと行き詰まる」と感じた場合、プログラミングスクールを検討する段階になります。
この段階で大事なのは、いきなり高額なコースに申し込まないことです。まず無料カウンセリングや無料体験で「自分のレベルに合ったカリキュラムかどうか」「質問しやすい環境かどうか」を確認してください。
プログラミングスクールの詳しい比較は DMM WEBCAMPの口コミ・評判｜グレーゾーンでも使える？料金・転職保証・給付金を当事者目線で検証 で整理していますので、気になる場合はそちらもあわせてご覧ください。
マルチタスク的な仕事を避ける方法
相性を確認したうえでエンジニアを目指す場合、仕事選びの段階で「自分の特性と合わない条件を避ける」工夫ができます。
- 自社開発の企業を選ぶ
SES（客先に常駐して開発を行う働き方）より自社開発の方が、環境を自分でコントロールしやすい - リモートワーク可の企業を選ぶ
感覚過敏やコミュニケーション負荷を自分で調整しやすい - 小規模チームの環境を探す
大規模チームよりコミュニケーションの経路が少なく、把握しやすい
完璧な環境を見つけるのは難しいですが、「この条件は自分にとって必須」という優先順位を持っておくと、選択肢を絞りやすくなります。エンジニア転職を含めたグレーゾーンの転職戦略については グレーゾーンの転職戦略 でも整理しています。
FAQ
発達特性×プログラミングについて、読者からよく寄せられる疑問をまとめました。
Q. ADHDだとプログラマーに「向いている」と断言できますか？
断言はできません。ADHD傾向の過集中や新奇追求がコーディングと相性がいい面はありますが、チーム開発の負荷や保守運用の単調さなど、相性が悪い場面もあります。「ADHDだから向いている」ではなく「自分の特性のどの部分が、プログラミングのどの工程と噛み合うか」を具体的に確認する必要があります。
Q. プログラミング未経験でも始められますか？年齢制限はありますか？
プログラミング自体に年齢制限はありません。Progateやドットインストール等の無料サービスで、未経験からでもすぐに始められます。ただし、エンジニアとして転職する場合は年齢や職歴によって難易度が変わるため、スクールの無料カウンセリング等で現実的なルートを確認するのがおすすめです。
Q. ASD傾向が強い場合、チーム開発は無理ですか？
「無理」ということはありません。チーム開発のコミュニケーションに苦手意識がある場合でも、「質問テンプレートを用意する」「テキストで確認を取る習慣をつける」等の工夫で対応している当事者は多くいます。また、チームの規模や文化によって負荷は大きく異なるため、環境選びも重要な要素です。
Q. 独学とスクール、どちらがおすすめですか？
まず無料サービスで独学を試してみて、「もっと体系的に学びたい」「独学だと行き詰まる」と感じたらスクールを検討するのが現実的です。独学で進められる人は独学で十分ですし、質問できる環境や学習ペースの管理が必要な人はスクールの方が効率がいい場合もあります。
Q. プログラミングを仕事にしなくても、趣味として学ぶ価値はありますか？
あります。プログラミングのスキルは、本業がエンジニアでなくても業務効率化や個人プロジェクトに活かせます。エクセルの自動化、Webサイトの簡単な修正、データの集計など、「ちょっとコードが書ける」だけで選択肢が広がる場面は多いです。
まとめ
もーやん「向いてる」って一言で片付く話じゃないんだな。
かりぶーうん。「自分の特性のどの部分が、プログラミングのどのフェーズと相性がいいか」を具体的に見ないとわからない。
もーやんまずは小さく触ってみるのが現実的か。
かりぶーそう思う。合うか合わないかは理論じゃなくて、実際に触って確かめるのが一番早い。2〜3時間触って「もっとやりたい」と感じたら、それが一番信頼できる手がかりだと思う。
この記事では、「発達特性×プログラミングは本当に相性がいいのか」を、ASD傾向のシステム化能力・ADHD傾向の過集中と新奇追求という構造から整理しました。
「向いている」と言い切れるほど単純ではないけれど、相性がいい条件は確かにあります。同時に、チーム開発やコミュニケーション負荷、保守運用の単調さなど、相性が悪い条件も存在します。
大事なのは、ネットの「向いてる/向いてない」論に振り回されるのではなく、自分で触って、自分の反応を確かめること。理論は参考にしつつ、最終的な判断は自分の体験に基づいて行ってください。
未経験から3年かけてITエンジニアを目指すルートは 未経験からITエンジニアになる現実的なルート（30代向け） で、実務経験3年以降のハイクラス転職は TechGoの口コミ・評判（IT特化ハイクラス転職） で整理しています。
参考文献
- Baron-Cohen, S. (2009) “Autism and the Empathizing-Systemizing (E-S) Theory” — PMC
- White, H. A. & Shah, P. (2011) “Creative Style and Achievement in Adults with Attention-Deficit/Hyperactivity Disorder” — PubMed
- Ashinoff, B. K. & Abu-Akel, A. (2021) “Hyperfocus: the forgotten frontier of attention” — PMC
本記事の情報は公開時点のものです。発達障害の診断基準や支援制度は変更される場合があります。
本記事は医療上のアドバイスを提供するものではありません。具体的な診断や治療については医療機関にご相談ください。
