はじめに

「どうせ、またお前が原因だろ？」

27歳のとき、障害対応の会議で先輩にそう言われ、何も言い返せずうつむいた。ADHDである私は、タスクの抜け漏れや説明不足で「やらかし」を量産し、無能のレッテルを貼られていた。

鍵となったのは、仕事の実力を磨くと同時に、コミュニケーションで「印象資産」を貯めるという発想だ。

本稿では、私が現場で血と汗で編み出した具体的なテクニックを、体験談を交えながら共有する。

この記事が、かつての私と同じ壁にぶつかるITエンジニアの心を少しでも軽くできたら嬉しい。

仕事のできない僕らが「印象資産」を今すぐ貯めるべき理由

印象資産とは

人は他人の能力を「結果」よりも「振る舞い」で先に判断する。
そこで得たプラスの先入観を、この記事では「印象資産」と呼ぶ。

• ✅ 預け入れ : ポジティブな行動・言動で信頼を積み立てる

• ❌ 出金 : ミスや遅延で信頼を引き出してしまう

印象資産が潤沢なら、たとえバグを出しても「彼ならすぐにリカバリーできる」と周囲は信頼してくれる。
逆に枯渇していると、同じバグでも「やっぱり、あいつは駄目だ」とレッテルが強化される。

体験談： 作業タイムラインだけで依頼対応がスムーズになった話

昔の私は返信を考えるのに時間がかかり、印象資産をみすみす失っていた。

ある日から「確認します！」というメッセージを即レスで付けることだけを徹底し、考えていることをスレッドのツリーに連ねるという行動を始めた。

そうすると今まで返信を考えていた内容が可視化され、周囲から「ごめん。そのエラーが出ているところって自分が改修したところだ。自分がやるよ」や「こっちでも調査してみるね」といったサポートが受けられるようになり、チームとしての連携力も上がった。

何より上司や依頼者からの「リアルタイムで対応してもらっている」という信頼値を蓄積することができ、自分の印象資産を貯めて快適に仕事ができるようになった。

スキルアップと同時並行で、手元の行動で「利息」を稼ごう。

「やらかし報告」はスピード勝負

失敗を見つけたら3点セットで即報告

1. 事実 : 何が起きたか (時間があればスクリーンショット・ログなどを付ける)

2. 原因仮説 : 現時点での推測でOK

3. 第一アクション : とった対応またはこれからやること

自分のやらかした障害をリカバリーする

あるとき、本番デプロイ後に本番環境でエラーに気づいてしまった。
こういう時は嫌でも心拍数が上がる。
でも、私は「いつか自分はやらかす」と思っていたので、事前に用意しておいたテンプレで即報告した。

【障害報告】[気付いた時間] [発生した事実]
- 事実: 
- 原因仮説: 
- 第一アクション: 

結果、上司の第一声は怒号ではなく「助かる。続報を待つ」だった。
スピードは謝罪を超える最強の対応である。

「質問下手」を1日で克服するフレームワーク

「質問がうまい」と上司に褒められた瞬間

かつて私は「どこが分からないか分からない」無能の典型例だった。
上司に質問しても「何を言っているのか分からない」「で、何がしたいの？」と反応されるばかり。

しかし、背景や試したこと等をテンプレートとして強制的に併記することにしたら無駄なやり取りが減り、上司から「質問が分かりにくい」と言われることはゼロになった。

ある日、上司から1on1で「もっと、あなたのように質問をしてくれる人が増えれば良いんだけどね」と言われ、自分の能力を評価された。
「質問力」は仕事の能力そのものだと痛感した。

「もう少し具体的に」が口癖の上司を黙らせるプロトタイプ投下術

機能デモで口より手を動かす最短経路。

• Step 1: 既存のコードをコピペし簡易な機能デモを作成

• Step 2: デモを開発環境にデプロイ

• Step 3: デモのURLをSlackに貼り「簡単な叩き台ですが動くデモを作ってみました。自由にご意見をください🙇‍♂️」とメッセージ

言い争いゼロで要件定義が終わった奇跡

新規案件で仕様の調整で3週間かかり炎上気味。
私は黙って2時間で「デモアプリ」を作りURLを関係者のSlackに貼った。

それを叩き台にスレッド上で議論が行われ、1日で仕様が固まった。
目に見える叩き台は100枚のスライドに勝る。

「理解したフリ」が事故を招く。認識合わせの重要性。

仕事における最強ワードは「〜という認識でよろしいでしょうか？」だ。

自分の見てきた「仕事ができる人」で認識合わせをすることに文句を言ったり、嫌な顔をした人を見たことがない。

どうやら「仕事ができる人」というのは大幅な手戻りを発生させる「認識のズレ」を相当気にする傾向にあるようだ。

3段ステップで確認

1. 自分なりの言葉で要約 (結論→理由の順)

2. 「〜という認識でよろしいでしょうか？」で相手にYES/NOで答えてもらう

3. ズレがあれば即修正

仕様バグを未然に潰した「念押し」チャット

リリース2週間前、仕様書の記載に違和感を覚え、PMに要約を送り「念のための確認ですが、この仕様は〇〇という認識でよろしいでしょうか？」と確認したところ、仕様書が誤っていることが判明。

即座にコードを修正し、テストを実施しリリースに間に合わせた。

たった1行の確認で数百万の損害を防げ、PMからは感謝された。

最後に

この記事では、私流のADHDの仕事術について書かせてもらった。

ただ、私の方法論は完璧ではない。それでも共有したのは、試行錯誤の価値を信じているからだ。

ADHDである私は今後も「やらかし」をするであろう。それが生まれ持った特性なのだから。

しかし「やらかし」ごとに教訓を得て改善するなら、失敗はむしろチャンスとなり得る。

どうか、過去の私のように自分を一方的に責めたりせず、自分の「特性」を「得意」に変える人が一人でも多く増えることを祈る。