本当にあった怖い話
経理「マクロが動かなくなりました」
私「コードを書き換えましたか？」経理「英語ばかりで気持ち悪かったので全部日本語に翻訳しておきました」
私「プログラミング言語とは…」— ななな_エンジニア (@hima_engineer) April 17, 2026
■プログラミング言語を「日本語に翻訳」した経理担当者、その背後にある深層心理とITリテラシーの壁
SNSで「本当にあった怖い話」として投稿され、多くのエンジニアやIT関係者を驚愕させたエピソードがあります。あるエンジニアが、経理担当者から「マクロが動かなくなった」という相談を受け、原因を尋ねたところ、衝撃的な返答が返ってきたのです。「英語ばかりで気持ち悪かったので全部日本語に翻訳しておきました」と。この言葉は、プログラミング言語における「翻訳」という概念を根底から覆すものであり、多くの人々に困惑と共感、そしてある種の恐怖をもたらしました。
この出来事は、単なるITリテラシーの差として片付けるにはあまりにも興味深い事例です。なぜ経理担当者は、プログラムコードを「日本語に翻訳」するという、本来ありえない行動に至ったのでしょうか。そこには、人間の認知、学習、そしてコミュニケーションにおける様々な心理学的なメカニズムや、IT社会における情報格差といった経済学的な側面、さらにはその行動がもたらす結果の確率論的な側面が複雑に絡み合っていると考えられます。今回は、このエピソードを科学的見地から深く掘り下げ、その背景にあるものを解き明かしていきましょう。
●認知の歪みと「心地よさ」への希求：心理学からのアプローチ
まず、経理担当者の行動を心理学的に分析してみましょう。彼（彼女）は「英語ばかりで気持ち悪かった」と感じています。これは、人間が自身の「快適な認知空間」を維持しようとする心理、すなわち「認知的不協和」の解消メカニズムが働いた結果と捉えられます。
認知的不協和とは、自身の持つ信念、価値観、態度、そして行動の間に矛盾が生じたときに感じる心理的な不快感のことです。例えば、「自分は健康に気を使っている」という信念を持っている人が、喫煙してしまうと、この二つの間に不協和が生じます。この不快感を解消するために、喫煙者は「タバコはストレス解消になる」「遺伝的に長生きだから大丈夫」といった合理化を行ったり、喫煙という行動を止めたりします。
今回のケースでは、経理担当者にとって、日常的に接する文書や業務は日本語である可能性が高いでしょう。そこに、見慣れない、理解できない記号や文字列の羅列である英語のプログラムコードが「侵入」してきた。これは、彼（彼女）の「日本語で情報にアクセスし、理解する」という既存の認知パターンとの間に、強い不協和を生じさせたと考えられます。その不快感を解消するために、「この英語を日本語に置き換える」という行動に出たのです。これは、コードの機能や意味を理解しようとするのではなく、「見た目の心地よさ」を優先した結果と言えます。
さらに、これは「確証バイアス」や「利用可能性ヒューリスティック」といった認知バイアスとも関連してくるかもしれません。確証バイアスとは、自分が信じたい情報や、既存の信念に合致する情報を無意識に探し求め、それ以外の情報を軽視する傾向のことです。経理担当者は「英語は理解しにくい、日本語が理解しやすい」という信念を持っていたため、コードを日本語に置き換えることで、その信念を強化しようとした可能性があります。また、利用可能性ヒューリスティックとは、想起しやすい情報に基づいて判断を下す傾向のことで、日常的に日本語に触れているため、「日本語での理解」がより容易に、より「利用可能」な選択肢として想起されたのかもしれません。
「翻訳」という言葉を選んだ点も興味深いです。彼（彼女）はおそらく、「英語から日本語へ」という「翻訳」という言葉が持つ、意味を理解し、伝え直すというプロセスを、コードに対しても適用しようとしたのでしょう。しかし、プログラムコードの「翻訳」は、自然言語の翻訳とは全く異なる次元の話です。自然言語の翻訳は、意味の伝達が主眼ですが、プログラミング言語の「翻訳」は、コンピュータが理解できる命令セットへの変換であり、その命令の正確な実行が目的です。ここには、言語に対する根本的な理解の差が存在します。
●「価値」の認識と「非効率」の排除：経済学的な視点
経済学的な視点から見ると、このエピソードは「価値の認識」と「効率性」という観点から考察できます。
経理担当者にとって、そのプログラムコードは「業務を遂行するため」のツールであり、その「価値」は「業務が円滑に進むこと」にあります。しかし、コードが英語であるという「情報」そのものが、彼（彼女）にとって「非効率」で「不快」なものであった。その結果、コードの機能や本来の意図よりも、「不快である」という情報に高い価値を置いた、あるいは「不快である」という状態を排除することに高い価値を見出したと考えられます。
経済学では、意思決定は通常、効用（満足度）を最大化するように行われると仮定されます。この場合、経理担当者の効用関数には、「業務の正確性」だけでなく、「精神的な快適さ」という要素も強く含まれていたのでしょう。英語のコードは、その精神的な快適さを著しく損なうため、たとえ業務が滞るリスクを伴ったとしても、その「不快さ」を排除する行動（日本語への翻訳）を選ぶことで、全体的な効用を（彼（彼女）なりに）最大化しようとしたのです。
また、この行動は、情報非対称性という経済学の概念とも関連しています。エンジニアはコードの構造や意味を熟知していますが、経理担当者はそうではありません。この情報格差があるために、経理担当者はコードの「中身」ではなく、コードの「見た目」という表面的な情報に囚われてしまい、誤った行動をとってしまったとも言えます。
「翻訳」にかかった手間も考慮すべき点です。SNSのコメントにもありましたが、コードを「日本語に翻訳」するというのは、相当な労力と時間を要する作業です。経済学でいう「機会費用」の観点から見ると、その労力は本来、経理業務に費やされるべきものでした。しかし、彼（彼女）はその機会費用を、精神的な快適さという「見えない利益」のために支払った、と解釈できます。これは、経済合理性だけでは説明できない、人間の心理的な側面が意思決定に大きく影響していることを示唆しています。
●「予測可能性」の崩壊と「ランダム性」の増大：統計学からの洞察
統計学的な観点からは、このエピソードは「予測可能性」の崩壊と、システムに導入される「ランダム性」の増大という視点から捉えることができます。
プログラムコードは、厳密に定義された文法と意味論に基づいて書かれています。そのため、エンジニアにとっては、コードの動作は極めて「予測可能」です。しかし、経理担当者による「翻訳」によって、その予測可能性は完全に失われます。例えば、「for」というループ構造を「フォー」と日本語に置き換えたとしても、コンピュータはその「フォー」を命令として認識できません。しかし、もし「（もし） ～ （ならば）」のような、ある程度意味の近い単語に置き換えた場合、かろうじて「こういう処理をしたいのかもしれない」という意図が残る可能性もゼロではありません。それでも、元のコードの意図とは全く異なる結果を招く可能性が極めて高いでしょう。
統計学でいう「ノイズ」や「異常値」に例えることもできます。正常なデータの中に、全く意味をなさない、あるいは誤った情報が混入すると、全体の分析結果は大きく歪んでしまいます。経理担当者の行動は、まさにプログラムという「システム」に、意図しない「ノイズ」を大量に導入した状況と言えます。
さらに、この「翻訳」は、コードの「確率分布」を根本的に変えてしまいます。本来、特定の順序や構造で並んでいた英単語の列が、意味不明な日本語の単語の列に置き換わることで、その「情報量」や「構造」は破壊されます。これは、統計モデルを構築する上で、前提とするデータの特性が大きく変化してしまうようなものです。
SNSでの「いんｔ 現金＝０円 いｆ（現金≧９９）｛ 現金多い時の処理（現金、１０）；｝」といった創作コメントは、この「予測可能性の崩壊」をユーモラスに表現していると言えます。もし本当にこのようなコードが実行されたら、その結果は全く予測不能です。
●ITリテラシーの断絶と「もはやなでしこ」という希望
このエピソードは、現代社会における「ITリテラシーの断絶」を浮き彫りにしています。エンジニアにとっては当たり前の「プログラミング言語」が、ITに詳しくない人にとっては「意味不明な記号の羅列」に映る。そのギャップが、このような事態を引き起こしました。
「もはやなでしこ」というコメントは、この断絶を埋める可能性を示唆しています。日本語でプログラミングができる「なでしこ」のような言語は、ITリテラシーの差を埋め、より多くの人々がプログラミングに親しみやすくするための試みです。「なでしこ」は、自然言語に近い記述をすることで、プログラミングの学習コストを下げ、直感的な理解を助けます。経理担当者の行動も、ある意味では、このような「日本語で、より分かりやすく」という欲求の現れだったのかもしれません。
しかし、だからといって、既存のシステムを勝手に改変することが許されるわけではありません。多くのコメントにあったように、「わかってないのにいじんな」「日常業務壊すな」という意見は、専門知識のない者がシステムに与える予期せぬ影響への懸念であり、極めて正当なものです。システムは、その設計者の意図通りに、またその仕様通りに動くことが前提です。それを、個人の主観や感情で改変してしまうことは、プログラミング言語の文法や構造を無視するだけでなく、システム全体の安定性や信頼性を損なう行為です。
「コード書き換えられないのにどうやって変えたんって思ったけど、もともとのシートで指定が英語とかだったらそこ修正しただけでもおかしくなるからコード書き換えてなくてもおかしくなる要素十二分にあるか…」というコメントは、状況の複雑さを示唆しています。経理担当者が「コード」そのものを直接編集していなかったとしても、例えばExcelのマクロであれば、シート上のセルに入力された英語の文字列を日本語に変更しただけで、マクロが想定外の動作をする、あるいはエラーになるという可能性は十分にあります。これは、システムがどのように連携し、どのような情報に依存しているのか、という全体像を理解していないことによる悲劇と言えるでしょう。
●結び：コミュニケーションの重要性と「知る」ことの価値
この「マクロが動かなくなった」エピソードは、我々にいくつかの重要な教訓を与えてくれます。
第一に、コミュニケーションの重要性です。ITリテラシーの差がある者同士が、互いの知識や前提を理解せずにコミュニケーションをとると、このような深刻な誤解や問題が生じます。エンジニアは、専門用語を避け、分かりやすい言葉で説明する努力が必要です。一方、ITに詳しくない側も、分からないことは素直に質問し、安易にシステムに手を加えないという姿勢が求められます。
第二に、「知ること」の価値です。経理担当者の行動は、ある意味で「知りたい」という欲求の表れとも解釈できます。しかし、その「知りたい」という欲求が、誤った方法で発揮されてしまった。もし、彼（彼女）がプログラミング言語の基本的な概念や、コードを不用意に改変することのリスクについて「知っていた」ならば、このような事態は避けられたでしょう。
現代社会において、ITは生活のあらゆる場面に浸透しています。だからこそ、最低限のITリテラシーは、どのような職種であっても必要不可欠になってきていると言えるでしょう。このエピソードは、その必要性を、ユーモアを交えつつも、私たちに強く問いかけているのです。そして、このエンジニアが自身のアプリを宣伝していたように、このような話題が広がることで、ITリテラシーへの関心が高まり、より多くの人々が「知ること」の価値に気づくきっかけになることを願ってやみません。
