「エラー文読め猿」と「翻訳レイヤー不足エンジニア」の衝突
IT系の職場やSNSでは、たまにこういう空気が流れる。
「エラーメッセージに答えが書いてあるじゃん」 「俺は英文和訳ソフトなの？」 「それくらい読んでから聞いてくれ」 「何も試さずに聞いてくるな」
言いたい気持ちは、かなり分かる。
エラー文には、原因や手がかりが書いてあることが多い。 検索すれば似た事例が出ることもある。 少なくとも、質問する前に「何を試したか」「どこで詰まったか」「何を期待して、実際にどうなったか」くらいは出してほしい。
しかし、それをそのまま口に出すと、かなり攻撃的に見える。
ここで起きているのは、単なる性格の悪さではない。 もちろん性格が悪い人もいる。 でも構造として見ると、IT現場にはかなり衝突しやすい条件がそろっている。
ITには「対人よりシステムが楽」な人も集まりやすい
IT職は、人間関係がいらない仕事ではない。
むしろ実際には、
- 要件を聞く
- 仕様を確認する
- バグ報告を受ける
- 非エンジニアに説明する
- 相手の理解度に合わせて言い換える
- 「何が分からないか分からない人」から情報を引き出す
という、かなり高度な対人能力が必要になる。
ただし、入口のイメージとしては、
「人よりパソコン相手の方が楽そう」 「営業や接客よりは対人が少なそう」 「仕様やログやコードの方が、人間の感情より分かりやすい」
と感じてITに来る人もいる。
ここにズレがある。
ITは、人間から逃げられる仕事ではなく、 人間の曖昧な要望を、機械が理解できる形に翻訳する仕事でもある。
だから、対人が苦手な人がITに来ると、あとでこうなる。
「話が曖昧すぎる」 「何を聞かれているか分からない」 「エラー文を読めば分かるのに、なぜ読まない」 「俺は翻訳機ではない」
気持ちは分かる。 しかし職場では、その翻訳機能も仕事の一部になりがちである。
質問する側にも問題はある
もちろん、質問する側にも問題はある。
ITの質問で一番しんどいのは、情報が足りない質問だ。
たとえば、
「なんか動きません」 「エラー出ました」 「さっきまで動いてました」 「急にできなくなりました」 「これ直してください」
だけで来られると、受ける側はほぼ占いになる。
本来、最低限ほしい情報はこれである。
- エラー文
- 何をした時に起きたか
- 期待した動き
- 実際の動き
- 試したこと
- 再現手順
- OS、ブラウザ、アプリのバージョン
- いつから起きたか
- 急ぎ度
これがないと、回答者は「原因調査」ではなく「聞き取り」から始めることになる。
だから、エンジニア側がイラつく理由はある。
問題は、イラつくことではない。 イラついた感情を、そのまま相手に投げることである。
「正しいことを言う」と「職場で通る言い方」は別
「エラー文に書いてあるじゃん」は、内容としては正しいことがある。
でも、職場でそのまま言うと、
「馬鹿にされた」 「聞いたら怒られる」 「もう相談しにくい」 「この人には質問したくない」
という空気を作る。
これは本人にとっても損である。
なぜなら、質問者が委縮すると、次から早めに相談しなくなる。 その結果、問題が大きくなってから出てくる。 そして、結局エンジニア側の火消しが増える。
つまり、攻撃的な物言いは、短期的には気持ちいいが、長期的には自分の仕事を増やす。
これはIT現場でよくある。
ログは読めるのに、人間ログを読まない問題である。
心理的安全性は「ぬるさ」ではない
ここで大事なのが、心理的安全性である。
心理的安全性というと、たまに「何でも優しくしろ」「指摘するな」「ぬるい職場にしろ」と誤解される。
でも本質はそうではない。
Googleのre:Workでは、効果的なチームの重要要素として心理的安全性を挙げている。心理的安全性があるチームでは、メンバーがリスクを取ったり、疑問を出したり、間違いを認めたりしやすい。 参考: https://rework.withgoogle.com/intl/jp/guides/understanding-team-effectiveness
つまり、心理的安全性とは、 ミスや分からないことを早めに出せる状態である。
IT現場ではこれが重要になる。
なぜなら、バグ・障害・設定ミス・仕様齟齬は、早く出てきた方が安いからだ。
質問者を殴って黙らせると、問題が地下に潜る。 地下に潜った問題は、だいたい後で爆発する。
だから、強いIT職場は「優しいだけの職場」ではない。
強いIT職場は、
- 分からないことを出せる
- ただし情報不足の質問は改善させる
- エラー文を読む習慣を育てる
- 聞き方の型を共有する
- 回答者も刺す言い方を避ける
- 属人化せず、FAQやドキュメントに逃がす
という形になっている。
ACMの倫理規範でも「害を避ける」「尊重する」は基本
IT職は技術職であると同時に、専門職でもある。
ACMのCode of Ethics and Professional Conductでも、コンピューティング専門家は害を避けること、人を尊重すること、品質の高いプロセスと成果を目指すことなどを求められている。 参考: https://www.acm.org/code-of-ethics
これは、単に「コードを書ければいい」という話ではない。
技術の仕事でも、周囲とのコミュニケーションや説明責任は含まれる。
「読めば分かるだろ」と言いたくなる場面はある。 しかし、職場での専門性とは、読めない人を罵倒することではなく、読める状態に近づける仕組みを作ることでもある。
とはいえ、何でもエンジニアに投げる側も悪い
ここは両方見る必要がある。
回答者が攻撃的なのはよくない。 でも、質問者が何も読まず、何も試さず、何も整理せずに丸投げするのもよくない。
これは、IT職を「無料の英文和訳ソフト」「便利な修理屋」「何でも直す人」として扱っている状態である。
そうなると、エンジニア側は消耗する。
だから、質問する側にも最低限の作法は必要だ。
良い質問の型
やりたいこと： 〇〇をしたいです。
起きていること： △△というエラーが出ています。
エラー文： XXXXXX
試したこと：
- 再起動しました
- 設定Aを確認しました
- 公式ヘルプのこのページを見ました
期待する状態： □□になってほしいです。
補足： OSはWindows 11、ブラウザはChromeです。
これだけで、受ける側の負担はかなり減る。
回答者側の安全な言い換え
内心ではこう思っていてもいい。
「エラー文読めや」 「俺は英文和訳ソフトなの？」 「せめて試したこと書け」 「何回同じこと聞くんだ」
でも、職場でそのまま出すと事故る。
外に出す時は、こう変換した方がいい。
刺さる言い方
エラー文に原因がかなり出ているので、まずここを一緒に見ましょう。 次回からは、エラー文・試したこと・期待した動きの3点を送ってもらえると助かります。
もう少し強め
この内容だけだと原因を絞れないので、次からはエラー文と再現手順もセットで送ってください。 その方が早く対応できます。
繰り返し同じ質問をされる場合
同じ内容が何度か出ているので、手順をまとめます。 次回からはこの手順を確認して、それでも解決しない場合に声をかけてください。
これなら、相手を殴らずにルール化できる。
IT現場は「翻訳レイヤー」を置けるかで荒れ方が変わる
IT現場で本当に重要なのは、翻訳レイヤーである。
非エンジニアの曖昧な言葉を、技術者に伝わる形にする。 技術者の専門的な言葉を、非エンジニアに伝わる形にする。 エラー文を、次の行動に変換する。 質問の仕方を、組織の型にする。
これがない職場では、技術者と質問者が直接ぶつかる。
すると、
質問者「なんか動きません」 技術者「エラー文読め」 質問者「攻撃的で怖い」 技術者「何も読まずに聞くな」
という地獄になる。
つまり、問題は個人の性格だけではない。
翻訳レイヤーがない職場では、人間同士が直接例外処理になる。
ラベル：エラー文読め猿 vs 翻訳レイヤー不足エンジニア
この構造にラベルをつけるなら、
エラー文読め猿 vs 翻訳レイヤー不足エンジニア
である。
質問者側には、読まない・調べない・整理しない問題がある。 回答者側には、正しさをそのまま棍棒にする問題がある。 職場側には、聞き方の型・FAQ・ドキュメント・教育・翻訳役を用意していない問題がある。
だから、ITに攻撃的な物言いが多く見える理由は、単に「ITの人は性格が悪い」ではない。
- 対人よりシステムが楽な人が集まりやすい
- でも実際のIT仕事は人間対応が多い
- 質問者が情報不足で投げがち
- 回答者は同じ聞き取りで消耗する
- 正しい指摘を攻撃的に出してしまう
- 職場に翻訳レイヤーがない
この合体である。
結論：ログは読めても、人間ログが読めないと荒れる
IT職に必要なのは、コードを読む力だけではない。
エラー文を読む力。 仕様を読む力。 相手の困り方を読む力。 相手が何を分かっていないかを読む力。 自分のイラつきを、そのまま出さずに変換する力。
これが必要になる。
もちろん、質問者側も「何も読まずに聞く」はやめた方がいい。 エラー文、試したこと、期待した動きくらいは出すべきである。
でも、回答者側も「正しいことを言っているから刺していい」にはならない。
IT現場は、機械と人間の境界にある。 機械には正確な命令が必要で、人間には感情と文脈がある。
その両方を扱うから、ITは難しい。
「俺は英文和訳ソフトなの？」と思う日はある。 でも、職場ではその言葉をそのまま出さず、仕組みに変換した方がいい。
怒りを投げるより、質問テンプレを置く。 罵倒するより、FAQに逃がす。 毎回説明するより、ドキュメント化する。
それができると、IT現場はかなり平和になる。
できないと、今日もどこかでこうなる。
「エラー文読めや」 「攻撃的で怖いです」 「いや、読めば分かるだろ」 「もう聞けません」
そして障害は地下に潜る。
だから結論はこれである。
IT現場で本当に必要なのは、エラー文を読む力だけではない。 人間ログを読む力と、翻訳レイヤーを作る力である。