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

「ASD プログラマー」で検索すると、二種類の記事が並びます。細部の正確さが評価される仕事だから相性がいい、という記事と、実際にやってみたが向いていなかった、という体験談です。

どちらも本当のことを書いているのだと思います。というのも、プログラマーの仕事は一つの塊ではなく、性質のまったく違う作業が混ざっているからです。片方は正確さと一貫性で評価され、もう片方は曖昧なものを人とのやりとりで確定させることで進みます。求人票では両方まとめて「開発」と書かれます。

この記事では、その二つを分けたうえで、詰まりやすいのがどこなのかを具体で書きます。先に断っておくと、「ASDだからITが得意」とは書きません。診断名から職業適性を導く書き方はしません。書けるのは「こういう性質の作業では、こういう困りごとが起きにくい／起きやすい」というところまでです。

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

開発の仕事には、性質の違う二つの作業が混ざっている

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

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

同じ「バックエンドエンジニア」という肩書きでも、この二つの比率は職場によって大きく違います。一日の八割が一つ目という持ち場もあれば、半分以上が二つ目という持ち場もあります。相性の話をするなら、診断名ではなくこの比率を見たほうが当たります。

正確さと一貫性が効くのは、基準が文書になっている領域

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

ここで重要なのは、基準が外にあるから、指摘の正しさを人に依存せずに証明できるという点です。テストが落ちれば落ちた事実が残ります。仕様書と違えばどこが違うか指し示せます。「なんとなくこっちのほうがいい気がする」に付き合わなくて済むぶん、消耗が少ない。

ただし、これは職務の性質の話であって、ASDの診断がある人がこの作業を得意だという話ではありません。同じ診断でも個人差は大きく、細部を見るのが苦にならない人もいれば、そうでない人もいます。言えるのは、「基準が文書になっているかどうか」が、困りごとの起きやすさを左右する条件の一つだということです。

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

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

つまずきやすいのは、要件が口頭で変わるとき

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

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

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

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

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

補足として、書き戻しは「証拠を残す」ためというより、認識のずれを早く見つけるために効きます。二週間後の差し戻しがその日の返信一通に変わるので、手戻りの量が桁で違ってきます。この説明の仕方だと、チームにとっての利点として提案できます。

暗黙の優先順位という、書かれていないルール

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

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

これは、書かれた情報を正確に扱う人ほど不利になる構造です。書いてあるとおりに上から処理して、「なんで一番大事なやつを後回しにしたの」と言われる。

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

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

レビューでの言い方が、仕事の評価にすり替わる

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

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

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

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

個人の読解ではなくチームの記法なので、導入すれば全員の解釈が揃います。「自分のために」ではなく「レビューの往復が減るから」と提案できるのも利点です。

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

向いていなかった人に何が起きたか

体験談として上位に出てくる「向いていなかった」の中身を、起きた出来事のレベルで分けてみます。感想ではなく事象で見ると、原因が違うものが混ざっていることが分かります。

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

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

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

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

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

五つに共通しているのは、詰まっている場所がコードを書く工程の外側にあることです。要件が確定するまでの部分、決定が伝わる部分、評価される部分、環境の部分。だから「プログラミングが向いていない」と結論するのは早い、という言い方ができます。

大事なのは、次の判断に使える形まで分けておくことです。要件確定で詰まっていたのか、対人の合意形成で詰まっていたのか、刺激の量で詰まっていたのか。ここが一つに絞れていれば、次の職場で聞く質問が決まります。「全部だめだった」で終わると、同じ条件の職場をもう一度選ぶ可能性が残ります。

一方で、正直に書いておくと、この五つが全部そろっている職場は珍しくありません。合わない職場を避けようとすると、選べる求人はそれなりに減ります。減ったうえでまだ残る、というのが実際のところです。

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

だから「向いていなかった」という体験談を読むときは、その人が何をやめたのかを見ると参考になります。プログラミングをやめたのか、要件を人から聞き出す仕事をやめたのか。同じ言葉で語られていても、中身が違います。

AIは、曖昧さを翻訳する側で使う

生成AIがこの領域で役に立つのは、コードを書かせるところより、コードの前後です。

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

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

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

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

環境の話も一つ。IPAの「DX動向2025」（2025年6月26日公開、2026年8月27日確認）は、アジャイルや内製化を含む技術利活用の状況を日米独で比較しています。要件が動くことを前提にした進め方が広がるほど、曖昧さを扱う手順を職場が持っているかどうかの差が出やすくなります。手順がある職場とない職場の違いは、今後もっと分かれていくところだと思います。

職場を選び直すときに確認できること

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

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

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

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

最後に、職場側の状態がどれだけ効くかについて。障害者職業総合センターの調査研究報告書No.125（2015年3月）は、就業中の発達障害のある人の職業生活への満足度を因子分析し、「周囲の人たちの理解」「仕事のやりがい」「否定的な対応が少ない」の三つを満足度を構成する要素として抽出しています。三つとも本人の能力ではなく、まわりの状態を指しています。

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