ASDとプログラマー。正確さが効く場面と、曖昧さで詰まる場面を分ける

「ASDの人はプログラマーに向いている」という説明と、「実際に働いたら向いていなかった」という体験談があります。開発の仕事には、書かれた基準に沿って正確さを確かめる作業と、曖昧な要件を人とのやりとりで決める作業が混ざっています。

診断名から職業適性は決められません。ここでは、二つの作業の比率と、実際に詰まりやすい場面を見ます。

なお、締切や割り込みの多さで詰まっているケースは、この記事とは別の軸です。そちらはADHDとプログラマー・エンジニアの記事で扱っています。

プログラマーの仕事は、大きく2つある

一つ目は、正しさの基準が自分の外に書いてある作業です。仕様書がある、テストがある、型がある、規約がある。合っているかどうかを、人に聞かなくても判定できます。

二つ目は、正しさの基準がまだ誰の頭の中にもない作業です。顧客が本当にほしいものが定まっていない、社内で意見が割れている、優先順位が言語化されていない。ここを進めるには、人に聞いて、すり合わせて、合意を作る必要があります。

同じ「バックエンドエンジニア」という肩書きでも、この二つの比率は職場によって違います。求人票の職種名だけでは、実際の一日は分かりません。

ルールが書いてある仕事は進めやすい

一つ目の作業では、細かい差に気づくことがそのまま成果になります。テストの網羅、データ移行での型と桁の突き合わせ、仕様書と実装の照合、命名規則の統一、リファクタリング、バッチ処理の境界条件。どれも「他の人が読み飛ばした差分」を見つけることに価値があります。

テストが落ちれば事実が残り、仕様書と違えば箇所を示せます。こうした基準が文書や仕組みとして用意されているかが、確認のしやすさを左右します。細部を見る作業が得意かどうかには個人差があります。

注意しておきたいのは、この利点が切れる境目です。基準が外にあるように見えて、実は人の頭の中にしかない、という場面が現場には混ざっています。仕様書に「適切にハンドリング（処理）すること」とだけ書いてある。設計内容の確認（レビュー）で「一般的にはこうする」と言われるが、その一般が何を指すのか誰も定義していない。こうなると、正確さで進めようとするほど確認の回数が増え、「細かい」と受け取られます。

そのため、基準が文書になっている職場かどうかは、文書の有無ではなく粒度で確かめたほうが正確です。仕様書は存在するがA4一枚で、残りは口頭で補われている職場と、境界条件まで書いてある職場とでは、同じ「仕様書あり」でも中身が別物です。

口頭で指示が変わると、つまずきやすい

二つ目の作業で最初に問題になるのは、決定が口頭で行われて、文書が更新されないことです。

典型的な流れはこうです。仕様書には「Aの場合はエラーにする」と書いてある。ところが会議のあと、顧客との立ち話で「Aも通していいことになった」と決まる。決めた人と、その場にいた数人だけが知っている。仕様書は書き換えられない。仕様書どおりに作った人が、二週間後のレビューで「これ違うよ」と言われる。

ここで起きているのは、理解力の問題ではありません。合意の記録が残っていないという運用の問題です。ただ、当事者からは自分の落ち度に見えます。同じことが三回続くと、多くの人が「自分の確認が足りない」と結論します。

対処としては、決定を書き戻すのが確実です。口頭で何かが決まったら、その場か直後に一通送る。「先ほど伺った内容を整理しました。Aは通す、Bは従来どおりエラー、という理解で進めます。違っていれば教えてください」。これは相手を責める文面ではないので、角が立ちません。返信が来なくても、送った記録は残ります。

これを個人の努力でやり続けるのは負担なので、チームの運用にできるとなおいい部分です。仕様変更をチケットに書く、決定事項を議事録の決まった場所に書く。この運用がある職場かどうかは、面接で聞けます。

書き戻す目的は、認識のずれを早く見つけることです。二週間後の差し戻しを、その日の確認に変えられます。

書かれていない優先順位に注意する

もう一つ詰まりやすいのが、優先順位が言語化されていない状況です。

チケットが五枚あって、全部「優先度：中」と書いてある。ところが実際には三番目が最優先で、それを全員が知っている。理由は「あの顧客が先週怒っていたから」で、どこにも書かれていません。書かれていない順位を読み取る作業が、いつのまにか評価の対象になっています。

対処は、順位を確認する行為を常設の手順にしてしまうことです。週の初めに「今週はこの順で進めます」と一覧を投げる。違っていれば直してもらう。毎回聞くのは気が引ける、という問題が、定型の運用にすると消えます。

チーム側で解決できる方法もあります。優先度を「中」ではなく一から五の数字にする、朝会で今日の一番を口に出す、といったやり方です。これは配慮というより、単に手戻りが減る運用なので、提案として出しやすい部類に入ります。

レビューの伝え方も評価される

コードレビューとは、他の人がコードの内容を確認する工程です。内容が正しいかどうかを見る場所のはずですが、実際にはコメントの書き方でも評価されています。

両方向に問題が起きます。こちらから出す側では、「このコードは間違っています」は事実として正しくても、受け手には人格への否定として読まれることがあります。指摘そのものは通ったのに、人事評価では「コミュニケーション」の項目だけが低い、という結果になりやすいのがこのパターンです。

受け取る側でも詰まります。「ここ、ちょっと気になりました」と書かれたとき、それが「直してほしい」なのか、単なる感想なのか判別できない。確認すると「そこまで言ってない」と言われ、直さないでいると「言ったよね」となる。

ここも運用で解決できます。レビューコメントの頭に強度の区分を付ける方法が、多くの現場で使われています。

チームの記法にすれば、コメントの強さを全員が同じように読めます。レビューの往復を減らす提案として出せます。

関連して、障害者職業総合センターの調査研究報告書No.101（2011年3月）は、企業によってルールからの逸脱に対する許容の幅が異なると指摘しています。同じ振る舞いが、職場によって問題になったりならなかったりする。言い方の摩擦も、絶対的な基準があるわけではなく、その職場の許容幅の中で判定されている、と考えたほうが実態に近いと思います。

合わない職場では何が起きるか

「向いていなかった」という言葉の中身を、起きた出来事で分けます。

仕様書どおりに作ったのに差し戻される、が繰り返された。 原因は口頭での仕様変更です。三か月続くと「自分の理解力の問題だ」と結論しがちですが、記録が残らない運用の問題であることが少なくありません。

見積もりが常に外れた。 要件が曖昧なまま見積もりを求められ、確定させてから出そうとすると「遅い」と言われ、仮で出すと後から超過を責められる。曖昧なものを曖昧なまま扱う手つきが求められている状況で、それは正確さで解決できません。

決定が会議の外で終わっていた。 会議に出ても、方針はすでに決まっている。決まった理由が分からないので、実装の判断ができない。質問すると「そこはいいから進めて」と返ってくる。

技術的な評価は高いのに、総合評価が上がらなかった。 レビューの指摘は採用されていて、不具合（バグ）も少ない。それでも評価面談で言われるのは伝え方の話ばかりで、何をどう直せばいいのかが示されない。

環境の刺激で、コードを読む時間が取れなかった。 常時鳴る通知、雑談が聞こえる席、割り込みのある打ち合わせ。集中して読む必要がある作業が、細切れの時間に押し込まれる。

五つとも、コードを書く工程の外側で起きています。要件確定、合意の記録、評価、作業環境のどこで詰まったかが分かれば、次の職場で確認する質問に変えられます。

「向いていなかった」あとの行き先も、実際には一つではありません。開発そのものをやめた人もいれば、同じ開発職のまま、要件確定を別の人が担う体制の職場へ移った人もいます。顧客と直接詰める受託から、仕様が社内で決まる自社サービスへ移る、あるいはテストや品質保証、データ処理といった、基準が文書として先に決まっている持ち場へ寄る。動かしたのは職種ではなく、二つ目の作業の比率です。

体験談を読むときも、プログラミング自体をやめたのか、要件を人から聞き出す役割を離れたのかを分けて見ます。

AIで曖昧な指示を整理する

生成AI（入力した指示に応じて文章やコードを作るAI）がこの領域で役に立つのは、コードを書かせるところより、コードの前後です。

曖昧な依頼を、確認質問の一覧に変える。 「この依頼文で決まっていないことを箇条書きにして」と投げると、自分では言語化しづらかった穴が形になります。そのまま相手に送れる質問リストになるので、確認の手間そのものが減ります。

自分の指摘の書き方だけを変える。 「この内容のまま、事実は変えずに、相手が受け取りやすい順番に直して」。内容を薄めるのではなく、結論と理由の順序や前置きの有無を調整させる使い方です。何がどう変わったかを見比べると、その職場で通りやすい書き方の型が見えてきます。

会議のメモから、決まったことと決まっていないことを分ける。 議事録をそのまま渡して、決定事項と未決事項に仕分けさせる。未決のまま進んでいる項目が、着手前に可視化されます。

できないこともはっきりしています。AIは、決めていない人に決めさせることはできません。確認は最終的に人に取る必要があります。AIができるのは、確認すべき点を漏れなく並べるところまでです。

IPAの「DX動向2025」（2025年6月26日公開、2026年8月27日確認）は、アジャイルや内製化を含む技術利活用の状況を日米独で比較しています。進め方の名称だけで判断せず、要件変更をどこへ記録するかを確認します。

職場を選ぶときに確認すること

面接で聞ける形にしておきます。診断のことを話さなくても、普通の求職者として聞ける質問です。

• 仕様が途中で変わったとき、その変更はどこに記録されますか？
• 優先順位は誰が、どのタイミングで決めますか？ チケットの優先度は運用されていますか？
• コードレビューのコメントに、必須と任意を区別する記法はありますか？
• 仕様を確定させる役割の人はいますか？ エンジニアが顧客と直接詰める形ですか？
• リモート勤務や、まとまった作業時間の確保はどう扱われていますか？

答えの内容と同じくらい、即答できるかどうかが情報になります。記録する場所が決まっている職場なら、担当者は迷わず答えます。

診断を開示して配慮を求める道を選ぶ場合、事業主には障害者雇用促進法にもとづく差別禁止と、障害者からの申し出に応じた合理的配慮の提供義務があります（過重な負担になる場合を除く。厚生労働省「事業主の方へ」）。この記事で挙げてきた項目は、申し出の形にしやすいほうです。「変更は文字で残してほしい」「優先順位を明示してほしい」は、抽象的な希望ではなく具体的な運用の話だからです。

障害者職業総合センターの調査研究報告書No.125（2015年3月）は、就業中の発達障害のある人の職業生活への満足度を因子分析し、「周囲の人たちの理解」「仕事のやりがい」「否定的な対応が少ない」の三つを構成要素として抽出しています。個人の適性を示す資料ではなく、職場側の状態も確認対象になると読めます。

いまの職場で試すのが難しければ、IT・データ分野を扱う就労移行支援で、実際の作業を通して確認する方法もあります。Neuro Diveの専用記事で学習内容と通所条件を見てから、説明会へ進むか判断できます。