プログラマはいつからアセンブリ言語を読めなくてもよくなった？コンパイラの歴史と「プロならアセンブラ必須」の変化

現在のWeb、業務システム、スマートフォンアプリなどの開発では、プログラマが日常的にアセンブリ言語を読み書きする機会は多くありません。一方、コンピュータの黎明期には機械語やアセンブリ言語に近いところでプログラムを書くことが一般的でした。

では「プロのプログラマならアセンブリ言語を理解して当然」という時代から、「分野によっては読めなくても仕事ができる」という現在の状況へ、いつ変化したのでしょうか。

結論からいえば、ある年を境に一斉に変わったわけではありません。1950年代後半からFORTRANなどの高水準言語が実用化され、1960～70年代に適用範囲が拡大し、1980～90年代にはPC・ワークステーションや高度なコンパイラの普及とともに、多くのアプリケーション開発者にとってアセンブリ言語が日常業務の必須技能ではなくなっていったと捉えるのが実態に近いでしょう。

初期のコンピュータでは機械語・アセンブリ言語が身近だった

初期のコンピュータでは、現在のように豊富なプログラミング言語や開発環境が最初から用意されていたわけではありません。プログラマはハードウェアに非常に近い形でプログラムを作成していました。

機械語を直接扱う負担を減らしたものの一つがアセンブリ言語です。数値で表された命令を、ADDやMOVのような人間が扱いやすい記号で記述し、アセンブラによって機械語へ変換します。

この時代のプログラマにとって、レジスタ、メモリアドレス、命令セットといった概念は現在よりはるかに日常的でした。したがって「低水準の動作を理解できること」が職業上重要だった分野が多かったのは事実です。

1950年代には「高水準言語では性能が出ない」という大きな壁があった

高水準言語の歴史で重要なのがFORTRANです。IBMのJohn Backusらが開発し、1957年にIBM 704向けのFORTRANコンパイラが提供されました。IBMはFORTRANについて、プログラマが機械語の細部ではなく数学的な問題へ集中できるようにしたものとして紹介しています。[参照] IBM「FORTRAN」

しかし、高水準言語を普及させるには大きな課題がありました。当時、プログラマが手作業で作ったコードに比べ、コンパイラが生成するプログラムは非効率になるのではないかという懸念があったからです。

FORTRAN開発を率いたBackus自身も後年の講演で、FORTRANプロジェクトについて、プログラミングやデバッグを容易にすること以上に、手書きコードと同等に近い効率のプログラムを生成することが重要だった趣旨を述べています。初期FORTRANコンパイラでは、生成コードの性能が高水準言語の実用性を左右する重要問題だったことが分かります。[参照] John Backus「The History of FORTRAN I, II, and III」

「コンパイラは信用できないから全部アセンブラで書くべき」だったのか

ここは少し慎重に考える必要があります。初期にはコンパイラが生成するコードの効率に対する強い懐疑がありましたが、だからといって全業界で「プロならコンパイラを信用してはいけない」「生成されたアセンブリを必ず全行検査する」という統一された職業倫理が存在したわけではありません。

むしろFORTRANが重要だった理由の一つは、コンパイラが十分に高品質なコードを生成することを示し、高水準言語を実務で使えるようにした点にあります。高水準言語によって開発時間を短縮できるメリットが大きければ、すべてを手作業のアセンブリ言語で書く合理性は低下します。

したがって歴史を「昔のプロは全員アセンブリを読み、コンパイラ出力を必ず検査していた」と単純化するのは適切ではありません。コンピュータの用途、機種、企業、時代、要求性能によって事情は大きく異なりました。

1960～70年代には高水準言語が急速に広がった

FORTRANだけでなく、1950年代末から1960年代にはCOBOL、ALGOL、Lispなど、用途の異なる高水準言語が登場します。これによって「プログラムを書くには対象CPUの命令セットを直接操作しなければならない」という状況が徐々に変わっていきました。

特にCOBOLは事務処理分野で大きな役割を果たしました。米国NISTはCOBOLについて、1959年にCODASYLによって開発され、ビジネスデータ処理向けに設計された言語として説明しています。[参照] NIST「COBOL 60」

企業の給与計算や在庫管理などを作るプログラマにとって重要なのは、CPUの個々の命令を巧みに使うことより、複雑な業務ロジックを正しく、保守しやすく記述することへ徐々に移っていきました。

1970年代でもアセンブリ言語が不要になったわけではない

高水準言語が普及しても、OS、デバイス制御、組み込みシステム、性能が極端に重要な処理などではアセンブリ言語が重要でした。また、初期のマイクロコンピュータではメモリやCPU性能が非常に限られていたため、アセンブリ言語を使う利点が大きく残っていました。

1970年代に登場したC言語は、この境界を変えた代表的な存在です。Dennis RitchieによるC言語の歴史では、CがUnixの開発と密接に結びつき、1973年ごろまでにUnixカーネルの大部分がCで書き直されたことが説明されています。[参照] Dennis Ritchie「The Development of the C Language」

これは重要な転換点です。OSのような低水準ソフトウェアでさえ、「必要な部分だけ機械に近い処理を残し、大部分は高水準言語で書く」という方向へ進めることを示したからです。

1980年代は「アセンブラを知っている人」と「必須の人」が分かれ始めた時代

1980年代にはパーソナルコンピュータが普及し、BASIC、Pascal、Cなどによる開発が広がりました。ただし当時のPCは現在と比較するとメモリもCPU性能も限られており、ゲーム、グラフィックス、デバイス制御などではアセンブリ言語を使うことが珍しくありませんでした。

例えばゲームのメイン部分をCで書き、描画やサウンドなど性能が重要な部分だけアセンブリ言語で最適化する、といった構成が合理的でした。この時代は「アセンブリ言語を知らなくてもプログラムは作れる」一方、「分野によっては知らないと厳しい」という過渡期として理解すると分かりやすいでしょう。

つまり、1980年代に突然アセンブリ言語が消えたのではありません。高水準言語で十分な領域が増えるにつれて、必要性が職種ごとに分化していったのです。

1990年代以降はアプリ開発で「必須ではない」がさらに一般化

1990年代になるとCPU性能とメモリ容量が大幅に向上し、コンパイラの最適化技術も成熟していきます。さらにWindowsなどのGUI OS、豊富なAPI、ライブラリ、開発環境が普及し、アプリケーションプログラマがハードウェアを直接操作する必要は減っていきました。

Javaのように仮想マシン上で動く言語も普及し、さらに後にはC#、JavaScript、Pythonなど、特定CPUの命令セットをほとんど意識せずに開発する仕事が大幅に増えます。

現在に近い「一般的なアプリケーションプログラマならアセンブリ言語を読み書きできなくても珍しくない」という状況が広く定着した時期を大まかに求めるなら、1980年代から1990年代にかけての変化が一つの目安といえます。ただし企業向けシステムなどでは、それ以前から高水準言語中心の仕事が多数存在していました。

なぜコンパイラの出力を毎回チェックしなくなったのか

現在でもCやC++を最適化するときに、コンパイラが生成したアセンブリコードを確認することがあります。しかし、一般的なプログラムですべての生成コードを人間が検査することは通常行われません。

理由の一つは規模です。現代のソフトウェアには膨大なコードが含まれ、ライブラリ、OS、ランタイムなど多くの層に依存しています。コンパイラ出力を全行目視するより、ソースコードレビュー、自動テスト、静的解析、動的解析、プロファイリングなどを組み合わせるほうが現実的です。

さらに現代の最適化コンパイラは非常に複雑です。インライン展開、ベクトル化、命令スケジューリング、不要コード除去などを行うため、単純に「自分でアセンブリを書いたほうが必ず速い」とはいえません。

「昔はアセンブラを書けないと技術者として信用されなかった」は本当？

これは職種と時代を分けて考える必要があります。初期コンピュータ、OS、組み込み、ゲーム、デバイスドライバなどハードウェアに近い分野では、アセンブリ言語やCPUアーキテクチャを理解できることが重要な技能でした。その環境なら、アセンブリ言語を全く理解できない技術者が担当できる仕事は限られていたでしょう。

一方、高水準言語が普及すると、業務アプリケーション、科学技術計算、データ処理など、アセンブリ言語を直接書くことが主業務ではないプログラマも増えます。その人たちまで一律に「アセンブリを書けないからプロではない」と扱われていた、と一般化する根拠はありません。

現在でも同じで、技術力は職種によって評価軸が異なります。Webバックエンドの専門家にCPU命令の暗記を求めるより、データベース設計、分散システム、セキュリティなどを評価するほうが仕事に直結する場合があります。

「アセンブラ」と「アセンブリ言語」は厳密には違う

日常会話では「アセンブラを書く」「アセンブラが読める」という言い方も広く通じますが、用語を厳密に分けると少し違います。

アセンブリ言語（assembly language）はMOVやADDなどを使って記述するプログラミング言語で、アセンブラ（assembler）はそのソースコードを機械語へ変換するプログラムです。

したがって厳密には「アセンブリ言語を書く」「アセンブリコードを読む」「アセンブラでアセンブルする」と表現できます。ただし日本の技術者同士の会話では「アセンブラが書ける」という表現も昔から使われているため、文脈から意味を判断すれば問題ありません。

現在でもアセンブリ言語を読めると強い分野

一般的なプログラマ全員に必須ではなくなったとはいえ、アセンブリ言語が過去の技術になったわけではありません。現在でも次のような分野では非常に有用です。

また、普段はPythonやJavaなどを使う人でも、アセンブリ言語を少し学ぶと「関数呼び出しとは何か」「スタックとは何か」「ポインタが実際には何を指しているのか」といったコンピュータ内部の理解が深まります。

現代でも生成アセンブリを確認する場面はある

「コンパイラ出力を確認する」という文化そのものが消えたわけでもありません。性能を追求するC・C++・Rustなどのコードでは、特定のソースがどのような命令列へコンパイルされたか確認することがあります。

例えばCompiler Explorer（Godbolt）では、C++やRustなどのコードを入力し、各種コンパイラが生成するアセンブリをブラウザ上で比較できます。[参照] Compiler Explorer

ただし目的は「コンパイラを一切信用してはいけないから全コードを監査する」ことではなく、「このループはベクトル化されたか」「余計なコピーが発生していないか」「抽象化が最適化で消えているか」といった特定の疑問を検証することが中心です。

歴史を年代で整理するとどうなる？

アセンブリ言語の必要性の変化を大まかに整理すると、次のようになります。もちろん分野によって数十年単位の差があるため、厳密な境界線ではありません。

この流れを見ると、「アセンブリ言語が不要になった瞬間」があるのではなく、コンパイラ、高水準言語、ハードウェア、OS、ライブラリという抽象化層が発達するにつれて、必要とするプログラマの割合が徐々に減ったと理解できます。

まとめ：転換は1950年代から始まり、1980～90年代には職種依存の技能になった

プログラマがアセンブリ言語を読めなくてもよいという状況は、特定の年に突然生まれたものではありません。1950年代後半のFORTRANをはじめとする高水準言語の実用化から、数十年かけて進んだ変化です。

初期の高水準言語には「生成コードの性能は大丈夫なのか」という強い懸念があり、FORTRAN開発でも手書きコードに近い性能を出すことが重要な目標でした。しかし高水準言語とコンパイラの有用性が実証されるにつれ、すべてをアセンブリ言語で書く必要性は低下していきました。

1970年代にはUnixの大部分がCで書かれるようになり、1980～90年代には一般的なアプリケーション開発でアセンブリ言語を直接扱わないプログラマがますます普通になります。したがって、「一般のプログラマにアセンブリ言語が必須ではない」という現在に近い感覚は1980～90年代にはかなり定着したものの、その始まりは1950～60年代の高水準言語普及まで遡るというのが妥当な整理です。

一方、OS、組み込み、コンパイラ、性能最適化、セキュリティ、リバースエンジニアリングなどでは現在もアセンブリ言語の理解が強力な武器になります。「プロなら全員必須」から「専門分野によって必要性が大きく異なる技能」へ変化した、と考えるのが最も実態に近いでしょう。