日本IT技術者の職業意識史 ――「機械設計への劣等感」から、「抽象層さんぽ」の時代へ

The Professional Consciousness of Japanese IT Engineers — From Reverence for Mechanical Design to the Age of the Abstraction-Layer Stroll

著：霧星礼知（min.k）｜mncc.info / Author: Reichi Kirihoshi (mncc.info)

この文章は、技術そのものの歴史ではない。日本のIT技術者が、自分たちの仕事を何だと思い、何を「設計」と呼び、どこに権威や引け目を感じてきたのか。その職業意識の変化を追う試みである。

ひとつ断っておく。以下には、資料で確かめられる歴史的事実、既存研究から借りる理論的な補助線、筆者の経験から立てた仮説の三つが混じる。とりわけ中心の見立て――機械設計への劣等感、それが安全装置として働いたという話、そして「抽象層さんぽ」――は、実証済みの事実ではなく筆者の仮説だ。どれがどの層の話かは、文中でその都度ことわる。

1. ITおじさんは、なぜ「地面の基礎」を見ていたのか

いまのIT現場には、抽象的な言葉が大量に流通している。クラウドネイティブ、可用性、疎結合、自動化、エージェント化。どれも便利な言葉だ。問題は言葉そのものではなく、その言葉が、実際にはどの機械で動き、どの経路を通り、障害時に何が壊れ、誰が復旧し、どれだけの運用負荷を生むのか――というところまで降りていかないまま、仕事として完結してしまう場面が増えたことにある。本来、運用や障害対応、復旧までを含めてシステムのライフサイクル全体で捉えるのが、標準的な設計観である^[1]。ここで欠けているのは、たいてい知識ではなく、そこまで降りていく往復のほうだ。

この状態を、本稿ではやや俗な言い方で「抽象層さんぽ（Abstraction-Layer Stroll）」と呼ぶ。筆者の造語である。抽象化が悪いのではない。抽象と実装のあいだを往復せず、抽象語の中だけを移動して一日の仕事が終わってしまうこと。それを指している。

ここで、ひとつ問いを置いておきたい。なぜ、以前のIT技術者には、抽象から物理や実装へ降りていく感覚が、比較的強く残っていたように見えるのか。これは印象論から始まる問いであって、まだ何も証明していない。だが、この印象の裏に何があるのかを掘ってみたい。

2. 情報系学部が整う前の「人材の入口」

まず、比較的確かに言える事実の層から始める。

日本で情報工学やコンピュータサイエンスが、いまのように独立した教育ルートとして整理されるのは、意外に新しい。それ以前、この分野の人材は、別の理工系領域から流れ込んでいた。

大学の制度史を見ると、情報系はしばしば既存の学部の内側から立ち上がっている。静岡大学では、機械・電気・工業化学の三学科で発足した工学部に、電子工学科や化学工学科が加わり、そして一九七一年に情報工学科が増設された^[2]。情報工学が、独立の器としてではなく、既存工学の学科群にあとから加わる形で始まったことがよくわかる。九州大学では、平成の初めごろまで、情報系の教員は工学部情報工学科や電気・電子工学の講座、理学部附属の基礎情報学研究施設など、複数の場所に分散して所属していた^[3]。情報が、まだひとつの独立した箱に収まっていなかったのである。

独立した器が整うのは、もっとあとだ。東北大学大学院情報科学研究科は一九九三年、同大学で最初の独立研究科の一つとして創設された^[4]。東京大学大学院情報理工学系研究科にいたっては、理学系の情報科学専攻と工学系の複数専攻を統合して、二〇〇一年に五専攻で発足している^[5]。基幹大学でも、情報理工の独立研究科が整うのは二一世紀に入ってからだった。同じ一九九三年には、会津大学が「日本初のコンピュータ理工学専門大学」を掲げて開学している^[6]。抽象化されたソフトウェアや計算機科学そのものから入る教育ルートが、制度として姿を現した時期だと言ってよい。

では、器が整う前の人材はどこから来たのか。ここも人物史の資料である程度たどれる。初期コンピュータのパイオニアには、電気・通信・物理といった既存分野の出身者が目立つ。たとえば相磯秀夫は、慶應義塾大学工学部電気工学科を出てから、電子技術の世界を経て計算機へ進んでいる^[7]。回路や実装に手で触れる領域を通ってから、計算機へ越境した経路である。

ここで慎重になっておきたい。こうした事例から言えるのは、「電気・通信・物理・応用物理など、既存の理工系から多様な人材が流入していた」ということまでだ。「機械系が多数派だった」とは言えない。一つの人物例や一つの大学の沿革から、日本全体の傾向を断定するのは無理がある。確かなのは、情報がまだ独立していなかったこと、そして人はいろいろな工学・理学から横断的に入ってきたこと。ここまでである。

3. 「本物の設計」としての機械設計

ここからは、事実の層に、筆者の見立てが少し混じり始める。

戦後日本において、機械工学とものづくりが技術者文化のなかで大きな重みを持っていたこと自体は、制度史からうかがえる。機械工学は、長い制度的伝統を持つ専門職共同体を築いてきた。日本機械学会は一八九七年（明治三〇年）に創立され、いまも会員三万人規模の、国内でも最大級の学会のひとつである^[8]。学会自身の記述によれば、その創立を提唱した真野文二は、英国で機械技術者の団体に触れ、そこでは会員であることが大学の学位にも劣らない敬意を集めていた実情に驚いて帰国したという^[8:1]。技術者という職能そのものに社会的な敬意が向けられる素地は、それだけ古くから育っていたわけだ。製造業もまた、長く日本の経済と雇用の中心にあった。ここまでは背景として言える。

ただし、「機械設計こそが工学部の花形だった」と一般化するのは危うい。時代によっても、大学によっても、産業分野によっても、威信の感じられ方は違う。ここは「少なくとも高度成長期から製造業中心の社会にかけて、機械設計は本流的・中核的な工学実践の一つとして参照されやすかった」という程度に、意識して弱めておきたい。

そのうえで、なぜ機械設計が「本物の設計」に見えやすかったのかは、内容から説明がつく。機械設計は、現実の制約に直接さらされる。寸法を決め、材料を選び、荷重を計算し、安全率を見込み、故障モードを想定し、製造できるかどうかまで担保する。設計が間違っていれば、物は壊れる。動かない。事故が起きる。作れない。直せない。だから、「設計」と呼ぶための厳しさが、目に見える形で存在した。

一方、当時の情報通信やコンピュータは、まだ新興の分野だった。ソフトウェアにいたっては、方法論そのものが不安定な出発点を持っていた。一九六八年のNATO会議で「ソフトウェア危機」という言葉が使われ、大規模開発の失敗・遅延・品質の不確かさへの応答として、ソフトウェアを工学化しようという志向が明示されたのは有名な話である^[9]。裏を返せば、それ以前のソフトウェアは、機械設計のように初めから設計方法論を備えた分野ではなかった、ということだ。

こうした落差のなかで、既存工学から情報へ移った人の一部が、機械設計への尊敬と、自分の仕事への半信半疑とを同時に抱えていたのではないか――ここから先は、筆者の見立てである。

4. 劣等感は「安全装置」だったのではないか（という仮説）

本稿の中心にある仮説を、ここではっきり出しておく。

**初期IT技術者の一部が持っていた「機械設計への劣等感」は、実務上はむしろ安全装置として働いたのではないか。**これは資料で立証された事実ではない。筆者の経験と観察から立てた見立てにすぎない。だから断定はしない。

仮説の中身はこうだ。彼らは、自分たちの仕事を無条件には信用していなかった。だから、次のような問いが手元に残り続けた。これは本当に設計と呼べるのか。現物として成立しているのか。壊れたらどうなるのか。誰が保守するのか。この仕様は本当に実装できるのか。運用まで含めて回るのか。言葉だけで済ませていないか。つまり、自分の専門領域を、少しだけ疑っていた。

この自己懐疑が、ITを神秘化しない態度、新技術への過信を抑える態度、実装を確かめに行く態度、物理層へ接地しに行く態度、レビューで具体を問う態度、保守や運用まで設計に含める態度――そういうものを、結果として支えていたのではないか。強調したいのは、これは古い技術に詳しかったという知識の話ではないということだ。知識ではなく、自分の専門に対する距離の取り方の話である。

ここで、既存研究を「証明」としてではなく、あくまで理論的な補助線として引いておきたい。高信頼性組織の研究は、失敗の小さな兆候にこだわり、単純化に抵抗し、自分たちの知識が不完全であることを前提に動く文化が、安全に寄与しうると論じてきた^[10]。心理学の側からは、知的謙虚さ――自分が間違っているかもしれないと引き受ける態度――が、判断の正確さの向上や、過大評価の少なさと関連することを示す研究がある^[11]。

念のため繰り返すが、これらの研究は「劣等感」そのものを扱ってはいないし、日本のIT技術者の職業文化を対象にしたものでもない。あくまで、「自分たちの知識を無条件には信用しない構えが、慎重さや精度に資しうる」という一般論に、もっともらしさを与えてくれるだけだ。筆者の仮説を裏づける証拠ではなく、仮説が荒唐無稽ではないと言える程度の補助線である。この区別は保っておきたい。

言い換えれば、こうも言える。昔は劣等感が安全装置になりえた。いまは自信が暴走装置になることがある。これも、証明ではなく、ひとつの見立てだ。

5. 抽象化は、「出発点」ではなかった

初期に既存工学から入った人にとって、抽象化は最初から世界にあったものではなかった――これも仮説寄りの話だが、経路としては説明がつく。

彼らはまず、機械、配線、電源、制御、記録媒体、通信、故障、保守を知っていた。その複雑な現実を扱いやすくするために、あとから抽象化を手に入れた。順序で言えば、物理・実装が先で、抽象化が後だ。抽象化は、現実を忘れるための道具ではなく、現実を扱うための道具だった。

この順序で学んだ人は、抽象化されたサービスを見ても、裏で何が動いているのか、何に依存しているのか、どこで壊れるのか、誰が直すのか、という問いを自然に持ちやすい。逆に言えば、抽象から入った人がその問いを持ちにくいとしても、それは能力の問題ではなく、入口の問題だ。ここは若い世代や情報系出身者を責める話ではまったくない。むしろ、入口が変わったという構造の話である。

なお、システム設計を「実装前の概念図」で終わらせず、運用・支援・廃棄まで含めてライフサイクル全体で捉えるという発想は、いまでは標準的なシステムズエンジニアリングの中核でもある^[1:1]。「抽象を実装へ降ろし、保守や運用まで含めて考える」という構えは、懐古趣味ではなく、現代の規範のなかにも書き込まれているものだ。

6. 「人材の入口が変わった」という事実

情報工学、コンピュータサイエンス、ソフトウェア工学が独立した教育ルートとして整理されていったこと自体は、当然の発展であり、良いことだ。ここに異論はない。

変わったのは、人材の入口である。以前は、物理や工学から情報へ入ることが多かった。いまは、最初から情報・ソフトウェア・Web・アプリケーション・クラウドから入ることが可能になった。前節で触れた大学史――静岡大の情報工学科、東北大や東大の独立研究科、会津大の専門大学――は、この「入口の独立」が段階的に進んだことを示している^{[2:1][4:1][5:1][6:1]}。ただし、これらは各大学の個別の再編であって、全国が同時に足並みをそろえて動いたわけではない。年表を一本にまとめて断定するのは避けたい。

結果として、ITを「現実の機械を制御するもの」「情報を物理媒体へ記録するもの」「通信線の上でデータを運ぶもの」としてではなく、API・GUI・オブジェクト・サービス・フレームワーク・プラットフォームとして最初に理解する人が増えた。ここで起きたのは、知識の低下ではない。認識の入口の変化である。この二つを混同してはいけない。

7. クラウドは、物理を消したのではなく、「見えなくした」

クラウドについては、はっきり言える部分と、慎重にすべき部分がある。

はっきり言えるのは、クラウドが物理を「消した」わけではない、ということだ。クラウドの標準的な定義そのものが、ネットワーク越しに共有された資源プールへオンデマンドにアクセスするモデル――つまり本質的に物理資源の抽象化――として書かれている^[12]。物理は消えていない。裏側で存続している。利用者がサーバを買わず、ラックを見ず、ディスクを交換せず、電源や空調を考えずに大規模システムを組めるのは、巨大な進歩だ。この利便は率直に認めたい。

だが本来は、物理が見えなくなった分だけ、責任分界、障害範囲、可用性、データ耐久性、復旧時間、ベンダー依存、運用負荷を、より厳密に考える必要があった。実際、クラウドの障害のなかには、電源や無停電電源装置、冷却といった物理設備の不具合に起因すると報告されたものもある。仮想化の層のさらに下には、依然として電気と熱の世界がある^[13]。

問題は、実務で「見えないものは、考えなくてよいもの」として扱われる場面が増えたことだ――これは筆者の観察であって、統計ではない。ただ、抽象の層から入った人にとって、見えない物理は「最初から存在しないもの」に近くなりやすい、とは言えるだろう。ここでも、「クラウド利用者は必ず物理を忘れる」といった全面化はしたくない。忘れやすくなる構造がある、という程度にとどめる。

8. 「抽象層さんぽ」の職業化

ここからしばらくは、筆者の現場での体験と観察が中心になる。証明ではない。

現代のIT現場では、抽象の層を移動すること自体が、独立した職務として成立するようになった。企画を作る。方針を語る。構成図の箱を並べる。会議を回す。将来像を描く。「クラウドネイティブ」「AI活用」「セキュアな基盤」「拡張性がある」と書く。ここまでで一つの仕事になる。

ちなみに、アーキテクチャの記述そのものは、複数のビューポイントと、記述と対象システムとの対応（整合性）のルールを備えるべきものとして国際的に標準化されている^[14]。つまり「構成図を並べる」ことは、本来は実システムとの対応づけを伴う専門的な営みだ。本稿が問題にしたいのは、その対応づけの確認が抜け落ち、記述だけが一人歩きしてしまう場合のほうである。

一方で、実装できるかを検証し、通信経路を確かめ、権限を設計し、障害時の挙動を確認し、運用担当を決め、復旧手順を作り、工数を見積もる――こうした部分は、別の人に委託される。そして実装側が「この要件では作れない」「この通信は成立しない」「この運用は回らない」「この日程では間に合わない」と指摘すると、抽象側からは「どうすればできるのか」という問いだけが返ってくる。

ここでは、抽象化は設計のための道具ではない。実装の責任を他者へ移すための空間になっている。これは特定の誰かを責めたいのではなく、そういう職務の傾きが生まれやすくなっている、という話だ。

9. 抽象層さんぽでは、「レビュー」が成立しにくい

レビューとは、本来、抽象化された要件や設計を実装へ降ろし、実装の制約を抽象側へ戻し、その往復のなかで矛盾を見つける行為である。実際、アーキテクチャや設計と実装のあいだの整合性をどう保つかは、ソフトウェア工学でも実務上の難所として繰り返し論じられてきた主題だ^[15]。だから本当のレビューには、具体的な問いが要る。その冗長化はどの障害まで耐えるのか。その経路は本当に通るのか。その権限で実装できるのか。その削除処理は運用で回るのか。復旧に誰が何分かかるのか。要件と設定は矛盾していないか。責任の境界はどこか。

抽象の層だけを移動する人が行うレビューは、「方針は合っている」「構成は妥当そう」「一般的には問題なさそう」「ベストプラクティスに沿っている」という、抽象語への抽象語返しになりやすい。悪意の話ではない。往復の足場がないと、そうならざるをえないのだ。

したがって、抽象と実装を往復できないと、厳密な意味での成立性レビューは難しくなる。「できない」と断ずるより、「成立性のレビューが難しくなる」と言うほうが正確だろう。

10. AIによって、「砂の城」はさらに高くなる

AIについても、利点と留保の両方を置く。

まず利点。生成AIが開発の速度を上げうることは、実証研究でも示されている^[16]。これは事実として認めるべきだ。AIを頭ごなしに否定する記事にするつもりはない。

だが同時に、留保すべき研究もある。AIアシスタントを使った利用者のコードが、より不安全になりやすく、しかも当人はむしろ安全だと信じやすい――そういう傾向を報告した研究がある^[17]。生成コードの相当な割合に脆弱性が含まれていたという報告もある^[18]。人が自動化を過信し、注意を手放してしまう傾向（自動化への慢心・偏り）は、AI以前から人間工学の分野で指摘されてきたものだ^[19]。これらは、AIの検証を人が引き受けなければならない理由になる。

クラウドによって、物理を見なくても仕事ができるようになった。そこへAIが加わることで、今度は実装そのものを見なくても、「作れる」「自動化できる」「数分でできる」「エージェント化できる」と語れるようになった。物理を知らず、実装を確かめず、生成物を検証せず、成立条件を詰めず、運用責任を持たないまま、構想だけが巨大化していく。筆者はこれを、夢の上で夢を語る状態と呼んでいる。砂の上に城を建てるというより、砂の上へホログラムで増築しているようなものだ。この比喩は、あくまで比喩である。

だからAI時代に必要なのは、AIを使える人「だけ」ではない。AIの出力を実装へ落とせる人、実装をシステム全体へ戻せる人、抽象と具体を往復できる人、現実の成立条件を確かめられる人が要る。

11. 失われつつあるのは、「ハードウェアの知識」ではない

ここまでを、「昔の人はハードに強かった」という結論に着地させたくない。それは話を矮小化する。

失われつつあるのは――そしてこれも「失われた」と断ずるより「失われつつある可能性がある」と言うべきだが――単なる知識ではない。自分の専門を少し疑う姿勢、現実へ照合しに行く姿勢、設計を成立性で測る姿勢、保守や運用まで含めて考える姿勢、抽象化の下に現物があると考える姿勢。そういう知的態度のほうだ。

初期IT技術者の一部は、情報通信を完全には信用していなかった。その半信半疑が、結果として技術的な慎重さを生んでいた――これは第4節で述べた仮説の再掲であって、証明ではない。逆に現在は、ITやAIが社会の花形になったことで、自分たちの専門領域そのものを疑う圧力が弱まった。この非対称は、知的謙虚さと過信をめぐる研究の含意とも、ゆるやかに響き合う^[11:1][10:1]。ただし、響き合うことと証明されることは違う。

12. いま必要なのは、抽象と実装を「往復する」技術者

筆者自身は、ITに抽象から入っていない。機械、記録媒体、ネットワーク、サーバ、ストレージ、OS、実装、運用の感覚を持ったまま、あとからシステム全体を抽象化する必要に辿り着いた。順序としては、下から上へ登った。

仕事で難所にぶつかるなかで、こう理解した。実装だけを深掘っても、システム全体は成立しない。抽象だけを語っても、実装は成立しない。必要なのは、システム全体を抽象化して見る視点と、実装レベルで成立性を見る視点の、往復である。抽象側で見つけた矛盾を実装で検証し、実装側で見つけた制約を抽象モデルへ戻す。この往復そのものが、設計であり、レビューだ。

そしてこれは、筆者の個人的な感慨にとどまらない。要求・設計・実装・検証のあいだの追跡可能性（トレーサビリティ）や、アーキテクチャ記述と実装の整合性が、システムの保守性に関わることは、システムズエンジニアリングの標準や研究が繰り返し述べてきたことでもある^[1:2]。往復は、規範として要請されている。

13. 「見えすぎる」と言われる技術者

物理から実装、運用、責任までを一度に見てしまう技術者は、周囲から「見えすぎる」と言われることがある。これは褒め言葉であると同時に、警告でもある。ここは体験知として読んでほしい。

見える人は、成立条件、依存関係、責任の空白、運用負荷、将来の破綻を、早い段階で見つけてしまう。だが、組織にそれを受け止める仕組みがないと、見える人がすべてを回収する羽目になる。エンジニアが、自律性の高い現場で燃え尽きるほど自発的に労働へ没入していく――そうした傾向は、日本のソフトウェア開発現場を対象にした社会学の研究でも観察されている^[20]（ここでも、証明ではなく、傾向の補助線としてだが）。設計も、実装も、調整も、進行管理も、顧客説明も、リスク処理も、一人で背負うことになる。

だから、これからの技術者に必要なのは、見抜く能力だけではない。可視化する能力、担当者へ返す能力、そして――見えることと背負うことを分ける能力である。見えてしまうことと、抱え込んでしまうことは、別だ。ここは実証の薄い、筆者の実感に近い話なので、一般化はしないでおく。

14. 結論

事実の層で言えるのは、こうだ。日本の情報系教育は当初から独立していたのではなく、電気・通信・物理・応用物理・数学といった既存の理工系から段階的に分化してきた^{[2:2][3:1][4:2][5:2][6:2][7:1]}。初期の担い手には、そうした既存分野の出身者が多様に含まれていた。ソフトウェアは、方法論的に不安定な出発点を持ち、危機意識のなかで工学化されていった^[9:1]。クラウドは物理を消したのではなく抽象化したのであり、物理は裏側で存続している^[12:1][13:1]。AIは開発を速めうると同時に、不安全なコードや過信の問題も抱える^{[16:1][17:1][18:1][19:1]}。ここまでは、資料に支えられている。

理論の層で言えるのは、自分たちの知識を無条件には信用しない構えが、安全や判断精度に資しうる、という一般的な補助線が存在することだ^{[10:2][11:2][19:2]}。

そして仮説の層で言いたいのは、こうだ。初期IT技術者の一部が抱いた、機械設計への尊敬と情報通信への劣等感は、実務上の弱さではなく、むしろ安全装置として働いていたのではないか。情報系教育の独立、クラウド化、AI化によって、ITは抽象の層から入る職業へと変わり、抽象化は高度になった一方で、抽象と現実を往復する力は弱まりつつあるのではないか。これらは証明ではない。筆者の見立てだ。

必要なのは、昔へ戻ることではない。物理から抽象へ登り、抽象から実装へ降りる道を、もう一度、意識的に作り直すこと。それだけである。劣等感を取り戻せという話ではない。自分の仕事を少しだけ疑う余白を、制度と文化のなかに残しておこう、という話だ。

☕️よかったらコーヒー一杯。
https://buymeacoffee.com/mink_obs

著：霧星礼知(min.k) / リサーチ・構造支援：Claude Opus 4.8、ChatGPT、Perplexity / AI-assisted / Structure observation

脚注

参考文献一覧（本文で実際に使用したもの）

一次資料・公的資料・大学史

• 静岡大学工学部「工学部の歴史」公式ウェブサイト。https://www.eng.shizuoka.ac.jp/outline/history/
• 九州大学理学部物理学科情報理学コース「沿革」公式ウェブサイト。https://jolly.i.kyushu-u.ac.jp/about/history/
• 東北大学大学院情報科学研究科「概要」公式ウェブサイト。https://www.is.tohoku.ac.jp/jp/introduction/outline.html
• 東京大学大学院情報理工学系研究科「沿革」公式ウェブサイト。https://www.i.u-tokyo.ac.jp/history.shtml
• 会津大学「沿革」公式ウェブサイト。https://u-aizu.ac.jp/intro/outline/history/
• 情報処理学会 コンピュータ博物館「日本のコンピュータパイオニア：相磯秀夫」https://museum.ipsj.or.jp/pioneer/aiso.html
• 一般社団法人日本機械学会「日本機械学会の活動と未来」https://www.jsme.or.jp/about/about-jsme/activity-and-feature/ ／「法人概況」https://www.jsme.or.jp/about/about-jsme/corporate-overview/
• Peter Mell and Timothy Grance, The NIST Definition of Cloud Computing, NIST SP 800-145, NIST, 2011. DOI: 10.6028/NIST.SP.800-145.

技術標準

• ISO/IEC/IEEE 15288:2023, Systems and software engineering — System life cycle processes, ISO, 2023.
• ISO/IEC/IEEE 42010:2022, Software, systems and enterprise — Architecture description, ISO, 2022.

書籍・会議報告

• Karl E. Weick and Kathleen M. Sutcliffe, Managing the Unexpected, 3rd ed., Wiley, 2015. DOI: 10.1002/9781119175834.
• P. Naur and B. Randell (eds.), Software Engineering: Report of a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7th–11th October 1968, NATO Scientific Affairs Division, 1969.

学術論文

• Shauna M. Bowes, Anna Ringwood, and Arber Tasimi, "Is intellectual humility related to more accuracy and less overconfidence?" The Journal of Positive Psychology, 19(3), 2024, pp. 538–553. DOI: 10.1080/17439760.2023.2208100.
• Raja Parasuraman and Dietrich H. Manzey, "Complacency and Bias in Human Use of Automation: An Attentional Integration," Human Factors, 52(3), 2010, pp. 381–410. DOI: 10.1177/0018720810376055.
• Sida Peng, Eirini Kalliamvakou, Peter Cihon, and Mert Demirer, "The Impact of AI on Developer Productivity: Evidence from GitHub Copilot," arXiv:2302.06590, 2023.
• Neil Perry, Megha Srivastava, Deepak Kumar, and Dan Boneh, "Do Users Write More Insecure Code with AI Assistants?" Proc. ACM CCS 2023. DOI: 10.1145/3576915.3623157.
• Hammond Pearce et al., "Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions," arXiv:2108.09293, 2021.
• Lakmal de Silva, Danny Weyns, and Hans Giese, "Architecture consistency: State of the practice, challenges and requirements," Empirical Software Engineering, 22, 2017. DOI: 10.1007/s10664-017-9515-3.
• 宮地弘子「ソフトウェア開発現場における自発的・没入的労働の相互行為論的考察」『社会学評論』第63巻第2号、2012年、pp. 220–238。DOI: 10.4057/jsr.63.220。

For international readers

This essay traces the shifting professional self-image of Japan's IT engineers rather than the history of the technology itself. Its central claim is offered as the author's own hypothesis, not as established fact: that many early engineers—recruited from established fields such as electrical, communications, and physics—held a quiet reverence for mechanical design and a matching self-doubt about information technology, and that this self-doubt worked as a kind of safety device, keeping them grounded in physical reality, implementation, failure, and maintenance. As information science became an independent educational path and as cloud and AI rendered the physical and implementation layers invisible, IT increasingly became a profession entered from the abstract layer—what the author calls the "abstraction-layer stroll." Research on high-reliability organizations, intellectual humility, and automation bias is used only as loose theoretical support, never as proof. The piece ends not with nostalgia but with a call to deliberately rebuild the round trip between abstraction and implementation.

Keywords

Japanese IT engineers, professional consciousness, mechanical design, software crisis, cloud computing, generative AI, abstraction and implementation, systems engineering, intellectual humility, abstraction-layer stroll