2025年8月06日·1 分
ジョン・バッカスとFORTRAN：ソフトウェアをスケールさせた言語
ジョン・バッカスはIBMでFORTRANを率い、高水準言語でも高速に動作できることを示した――生産性を高め、ソフトウェアを本当の産業へと成長させた。
ジョン・バッカスはIBMでFORTRANを率い、高水準言語でも高速に動作できることを示した――生産性を高め、ソフトウェアを本当の産業へと成長させた。
1950年代初頭、コンピュータは政府や大学、大企業が使う希少で高価な機械でした。当時の計算機は当時としては強力でしたが、プログラミングは非常に遅く、苦痛を伴う作業でした。多くのプログラムは機械語やアセンブリで直接書かれ、命令はハードウェアの限られた語彙に合わせる必要がありました。式の小さな変更が長いコードの書き直しを意味し、1つのミスが数時間待った後の実行全体をクラッシュさせることもありました。
ジョン・バッカスはIBMの技術者で、低レベルのコーディングに費やされる時間の大きさを実感していました。彼は小さなチームを率いて大胆な試みを行いました：数学中心の指示を、問題を考えるときの表現に近い形で書かせ、コンパイラがそれを高速な機械語に翻訳する、というアイデアです。
このプロジェクトがFORTRAN（"Formula Translation"の略）になり、対象は主に数値計算を行うIBMの科学顧客でした。約束は単純でした：コードを少なく書き、バグを減らし、IBM 704のような機械上で効率よく動かすこと。
当時、多くのプログラマは高水準言語を贅沢品だと見なしていました。何か「英語らしい」表現は、丹念に手で最適化されたアセンブリよりずっと遅くなるはずだと考えられていたのです。コンピュータが高額で計算時間が厳しく配分されている状況では、性能は単なる“欲しいもの”ではなく、全てでした。
だからFORTRANは単なる新しい文法ではありませんでした。専門家の技能に匹敵する自動化：コンパイラが熟練プログラマに匹敵するコードを生成できるか、という賭けでもありました。
FORTRANの物語は技術的突破と文化的転換が混ざったものです。次に、低水準言語以前のプログラミングの実情、バッカスのチームがどのようにして手書きコードと競えるコンパイラを作ったか、そしてその成功がソフトウェアの経済学をどう変えたかを見ていきます。これは現代のチームが今でも頼るパターンを作りました。
FORTRAN以前、"プログラミング"は通常、コンピュータ自身の語彙、あるいはそれにわずかに人間向けのレイヤを加えたものを直接書くことを意味していました。
初期のコンピュータは機械語（数値のオペコードとメモリアドレス）を実行しました。これを管理するのはほぼ不可能に近く、プログラマは短いニーモニックに置き換えるアセンブリ言語を使いました。それでもアセンブリはハードウェアに非常に近い薄い抽象化に過ぎません。あなたは数学的に「何をしたいか」を記述するのではなく、「どのように」ステップごとにレジスタやアドレスを操作してそれを実行するかを書いたのです。
科学計算では、ループやメモリ配置、中間値の手動管理が必要でした。式の小さな変更でも、多数のプログラム箇所を書き換えねばならず、全体がアドレスやジャンプで密に結びついていました。
アセンブリプログラミングは遅く壊れやすい作業でした。一般的な問題例：
科学者や技術者は単に1回計算するだけではなく、モデルを洗練し、シミュレーションを繰り返して“もしも”を調べます。更新ごとに数日や数週間の書き換えとテストが必要なら、実験は著しく遅れます。
ここで見えてくる新しいコストはプログラマの時間でした。ハードウェアは高価でしたが、熟練者の時間も高価でした。1950年代半ばまでに、ボトルネックは必ずしも機械の速度ではなく、人間が有用な仕事を機械にさせるまでの時間になりつつありました。
ジョン・バッカスは最初からコンピュータの“先駆者”を目指していたわけではありません。落ち着きのない初期の経歴と陸軍での経験を経て、1950年代初めにIBMに入社しました。彼は退屈な作業に対する実務的な嫌悪と、大規模な技術的努力を組織する才能で早く頭角を現しました。
IBMには問題と機会が一台の機械に詰まっていました：IBM 704です。数学処理（浮動小数点演算など）に関して当時は強力でしたが、技術・科学の顧客はアセンブリを書くのに膨大な時間を費やしていました。もしプログラミングがそのまま遅いままなら、優れた機械も十分には活用されないのです。
IBMの賭けは単純に言えるが実行は危険でした：速度を犠牲にせずに704をプログラムしやすくすること。
バッカスは、FORTRANを二つに不可分なプロジェクトとして扱うチームを率いました：人が書ける言語そのものと、それを高速な機械語に翻訳できるコンパイラ。後者が真の賭けでした。当時多くの専門家は“自動プログラミング”は常に非効率で、手書きアセンブリに勝てないと考えていました。
高水準言語は単なる「親切な構文」ではありませんでした。問題の数学や論理に近い形で式やループ、構造化された命令を書き、コンパイラがそれを熟練プログラマが手で作るのに匹敵するコードに変換することを意味していました。その信頼をIBMとバッカスは勝ち取りたかったのです。
FORTRANの核心的な約束は単純で急進的でした：機械に対して細かい手順を一つずつ指示する代わりに、あなたは数学に近い形の文を記述でき、コンパイラがそれを効率的な機械語に変換する。
技術者は「多くの値についてこの式を計算する」と書けるようになり、アセンブリで必要だった読み込み・加算・保存・ジャンプの列挙を手動で書く必要がなくなりました。目標は、プログラミングがアイデアを表現する行為に近づき、配線盤を言葉で組むような作業から離れることでした。
FORTRANはそのまま機械上で動きません。別のプログラム――コンパイラ――がFORTRANのソースコードを機械の低レベル命令に変換します。
これを技術会議の熟練通訳者になぞらえることができます：あなたは高水準の文で話し、聴衆は低レベルの語彙しか理解しない。拙い通訳は意味を伝えても冗長で間抜けかもしれない。優れた通訳は意味と効率を保ち、聴衆が即座に行動できる形で伝えるのです。
バッカスのチームは稀な組合せを目指しました：
特に最後の点が重要でした。FORTRANは万人向けを目指したわけではなく、現実的な計算を少ないミスで終わらせることに主眼を置いていました。
懐疑は強烈でした。多くのプログラマは性能には絶対的な制御が必要だと信じており、“自動”変換は無駄が多いと考えていました。さらにデバッグへの懸念もありました：コンパイラが最終命令を生成するなら、機械が実際に何をしているかはどうやって知るのか？
FORTRANの最初のユーザは技術者や科学者でした――方程式を走らせ、モデルを検証し、結果を出す人々。彼らにとって約束は新奇さではなく、時間の節約、転記ミスの減少、そして少数のアセンブリ専門家ではない人々でも保守できるプログラムでした。
FORTRANは単に新しい書き方ではなく、新しい翻訳の方法を要求しました。その翻訳はコンパイラの仕事であり、その成功がFORTRANを革命にするか注釈にするかを決めました。
コンパイラは高度な専門会議の熟練通訳者のようなものです。あなたは高水準の一文（「この方程式を各値について計算せよ」）を話しますが、聴衆は厳密な低レベル語彙しか理解しません。下手な通訳は正しく翻訳しても回りくどく、時間がかかり、無駄が多い。優れた通訳は意味と効率を両立させます。
FORTRANはその優れた通訳が必要でした。
初期のプログラマは美しさや快適さのためではなく、家賃を稼げるかどうかでFORTRANを選びます：コードを書きやすくなることで工数が減り、実行時にペナルティがなければ導入に値する。IBM 704のような高価な機械では、無駄なCPU時間は文字どおりお金の無駄であり、科学的な仕事では遅いコードは結果が出るのが遅くなるという深刻な問題を引き起こします。
だから実際の製品は言語仕様ではなく、コンパイラが生み出す成果物だったのです。コンパイルされたプログラムが手書きアセンブリに近ければ切り替えは正当化され、そうでなければどれだけ見かけが良くてもFORTRANは見捨てられたでしょう。
FORTRANの売りである「数学をそのまま書く」という点は、コンパイルを難しくします。コンパイラは次を行う必要がありました：
多くのエンジニアは高水準コードが定義上遅いはずだと考えていました。バッカスのチームは、その仮定を証拠で覆す必要がありました：競争力があり予測可能で信頼できるコンパイル済みプログラムを示すこと。性能の信用がなければ、FORTRANは学術的な便利さにすぎないと見なされるだけだったのです。
FORTRANの大きな約束は、コードの作成が速くなるだけでなく、コンパイル後のプログラムも速く動く、という点にありました。採用初期のユーザは趣味のプログラマではなく、機械時間や結果を重視する科学者や技術者だったため、これが決定的でした。
最適化はコンパイラが余分に働くことで、プログラマが手間をかけずに済むようにすることです。あなたが数学的に書いた文を、コンパイラが命令数やメモリアクセスを減らす形に書き換え、IBM 704上での実行時間を短くします。
重要なのは“賢さ”を追求することではなく、予測可能に効率的であること――だから人々はFORTRANで書くことに不利益を感じないのです。
FORTRANコンパイラが適用した改善は直感に合うものです：
これらはいずれも、プログラマが命令時間やメモリ配置を気にしなくても、アセンブリで重要視していた点を補ってくれるものでした。
アセンブリ派の強力な主張は「手で書けば常に速くできる」というものでした。初期の懐疑論者は高水準言語は肥大で無駄が多いと考えていました。
バッカスのチームはその懐疑を製品要件として扱い、最適化は"おまけ"ではなく、抽象化が性能放棄を意味しないことを証明する手段でした。
FORTRANプログラムが多くの実用ワークロードで手書きアセンブリと競えることが広まると、採用が加速しました。コンパイラは信頼できる仲間のようになったのです：意図を明確に書き、詳細はコンパイラに任せてもハードウェアを尊重する結果が得られる、と。
FORTRANは単に「見た目が良い」だけではありませんでした。科学者や技術者の日常業務に直結する実用的な構成要素を提供しました：繰り返し計算、再利用可能な手続き、大量の数値データを扱う仕組みです。
科学プログラムは“これをN回繰り返す”という処理で満ちています。合計、時間ステップの進行、反復解法、データポイント全体への式適用などです。アセンブリでは繰り返しは手書きのジャンプロジックになりがちで、誤りを起こしやすく読みづらいものでした。
FORTRANのDOループは意図を明確にしました：
SUM = 0.0
DO 10 I = 1, 100
SUM = SUM + X(I)
10 CONTINUE
複数のジャンプやカウンタの手動管理の代わりに、範囲を指定して式に集中できます。
エンジニアリングの仕事は繰り返しが多い：行列乗算、単位変換、多項式の評価、標準データ形式の読み取りなど。サブルーチンにより、信頼できるルーチンを一度書いて複数箇所から呼び出せるようになり、コピーペーストによるバグ拡散を減らしました。
同時に、サブルーチンは大きなプログラムを小さな部品に分割し、個別にレビューやテスト、改良が可能になることを奨励しました。
測定値、ベクトル、表、グリッド、行列は科学計算の中心です。配列はそれらを直接表現する手段を提供し、多数の個別変数や手動のアドレス計算を避けられます。
アセンブリ中心の制御フローは大量の条件・無条件ジャンプに依存します。ラベルの誤りが結果を静かに壊すことがあります。FORTRANはループや名前付きサブルーチンといった構造化された構成を提供し、絡み合ったジャンプロジックの必要を減らして、変更に強いコードにしました。
FORTRANはラボの巧妙なアイデアに留まらず、時間や予算がかかる実問題を解く現場で繰り返し使われたから広まりました。言語は賞賛されても日常業務を変えないことがありますが、FORTRANは実際の締め切りと予算をかけて賭けるに足る信頼を得られたため、日常業務を変えました。
初期採用者は計算に命運をかける分野のグループでした：航空宇宙、物理学研究所、気象・気候、構造や電気の計算を行う工学部門など。これらはおもちゃの例題ではなく、ほんの少しの生産性向上がより多くの実験や設計反復、手作業の隠れたミスを減らすことにつながります。
FORTRANは配列やループ、サブルーチンといった機能が問題の形にマッチしていたため特に適していました。
アセンブリは特定機種に結びつき、他者が読み書きするのが難しかったため、共有が困難でした。FORTRANは即座に移植性を与えたわけではありませんが、プログラムをより理解しやすくしました。これにより組織内、さらに組織間でコードを回覧しやすくなり、元の作成者がすべての詳細を“翻訳”し直さなくても済むようになりました。
高水準で計算を表現できるようになると、信頼できるルーチンのライブラリを保つ意味が出てきました。チームは数値手法や入出力パターン、ドメイン固有の計算を再利用しやすくなり、コードを資産として維持・改善する投資が合理的になりました。この変化は、プログラミングを一回限りの工芸から繰り返し可能な仕事へと押し上げました。
FORTRANは単に一台の機械を使いやすくしただけではありません。言語が何をすべきか、コンパイラが何をできるかという期待を確立しました。当時はこれらの考えがまだ論争的だった時期です。
FORTRANの成功から得られた重要な教訓は、言語設計とコンパイラ設計は切り離せない、ということです。初期の批判者は単に「英語らしい」コードに懐疑的だっただけでなく、コンパイラがそれを効率的な命令に翻訳できるか疑っていました。FORTRANチームの答えは、コンパイルと最適化に大きく投資することでした。これは後の多くの言語プロジェクトに影響を与えています。
この考え方は、より安全な抽象化、明快な構文、生産性の向上をコンパイラ技術で支えるという長期的な信念につながりました。
FORTRANはコンパイラが競争力のあるコードを生成するべきだという考えを一般化しました。すべての後続言語が同じ目標を追ったわけではありませんが、基準は変わりました：「高水準＝遅い」は必ずしも真ではない、と。
これによりコンパイラ研究と実践は、ループ解析、計算の再編成、レジスタ管理などの最適化技術に力を入れる方向へ進み、数十年にわたって標準的な話題となりました。
初期のFORTRANはIBMハードウェアに密接に結びついており、最初から移植性が主目的だったわけではありません。しかし、FORTRANが広まるにつれ、科学コードを別機種へ書き直すコストが明白になり、業界を言語標準化へと押し進める力になりました。
結果は即座ではなく完璧でもありませんでしたが、単一ベンダーや機械世代を超えて生き残る言語には安定した定義が必要だという前例を作りました。
FORTRANは複雑な計算を書きやすくしましたが、プログラミングを「簡単」にしたわけではありません。高水準言語はある種の頭痛を取り除く一方で、新たな問題を露呈させました。
FORTRANの速度に対する評判は、コードの書き方にトレードオフを生みました。しばしばプログラムはコンパイラが最適化しやすい形に合わせて分割や並べ替えが行われ、結果として新しい読み手には分かりにくいコードになることがありました。
FORTRANはプログラムの再利用コストを減らしましたが、初期は“移植可能”にも注釈が付きました。語長や数値の振る舞い、入出力デバイスの違いにより、同一の数学でも機種ごとに別の取り扱いが必要だったことがありました。
FORTRANは科学計算に特化しており、後の言語が提供するような大規模コードベースを整理する強力な道具はありませんでした。デバッグは依然として遅くフラストレーションを伴い、初期のコンパイラは暗号めいたエラーを出すことがありました。
FORTRANは「最高速を優先するべきか、より明瞭な抽象化を優先するべきか」という議論を触発しました。この問いは当時と同様に現代のチームにも該当します。FORTRANは抽象化が有益であり得ることを示しましたが、どのトレードオフを受け入れるかは状況次第です。
FORTRANが成功した理由は、開発者の時間を希少資源として扱った点にあります。バッカスとIBMは単に見た目の良い構文を作ったのではなく、ツールへの投資がどのようにソフトウェアのクラスを解き放つかを証明しました。
FORTRANの主張は簡単でした：行数を減らし、より正しいプログラムを出す。現代のチームもこれを何度も学び直します。安全なAPIや明確なモジュール境界、煩雑なワークフローを自動化するスクリプトへの1週間の投資は、ホットループから3%を削るよりも大きな価値を返すことが多いのです。
人々は抽象化を「制御を放棄すること」と見なして疑いました。コンパイラは手書きアセンブリに近い速度を提供することでその不信を払拭しました。
現代の類推はフレームワークやマネージドランタイム、クラウドサービスへの信頼です。しかしその信頼は当然与えられるものではありません。抽象化が破綻するとチームは手作業に戻ります。解決策は1957年と同じです：性能の測定、挙動の透明性、故障時の予測可能性。
FORTRANは単なる言語ではなく、高水準プログラミングを大規模に実現したコンパイラの努力でした。今日の同等物は：
また、新しいツール群は元のFORTRANの賭けに似たことを行っています。たとえばKoder.aiのようなVibe-codingプラットフォームは、チャットで望みを記述するとエージェントベースのシステムがアプリケーションを生成・反復するというアイデアを推進します（例：WebのReact、バックエンドのGo＋PostgreSQL、モバイルのFlutterなど）。プランニングモード、スナップショット、ロールバック機能は、FORTRANが証明したのと同じことを目指しています：高水準の意図を表現しても運用上の制御を失わないこと。
良いツールはバグを防ぐだけでなく、野心を拡げます。小さなチームでより大きなシステムを作れるようにするのです。
バッカスの残した重要な影響は、言語・コンパイラ・実務慣行といった「コードを取り巻くシステム」が人々の作業を速めて自信を与えるとき、ソフトウェアはスケールする、という考えです。それは現代のエンジニアリングチームにとっても変わらない基本戦略です。
FORTRANは、プログラミングの「人間側のコスト」を大幅に下げながら、実行時のペナルティを小さく抑えられた点で重要でした。
コンパイラは、人間が書いたソースコードを特定の機械が実行できる低レベル命令に変換するプログラムです。
FORTRANの場合、コンパイラは二つの仕事を高いレベルでこなす必要がありました：
当時の高水準言語に対する主な反論は「遅いだろう」という点でした。もしFORTRANのコンパイル後コードがアセンブリより大幅に遅ければ、科学者やエンジニアは利便性のために性能を犠牲にできません。
FORTRANの採用は、コンパイラが競争力のある機械語を生成できるかどうかにかかっていました。単に“動く”だけでは不十分だったのです。
典型的な最適化は次のような実用的で機械的な改善でした：
これらは、アセンブリプログラマが手作業で行っていたトリックと同じ種類のものを自動化したものです。
FORTRANは日々の数値計算パターンを容易に表現できるようにしました：
DOループは範囲にわたる繰り返し計算を直接表す。これらにより、複雑なジャンプや手動のアドレス計算が減り、バグも減りました。
すぐには、また完全には移植性が提供されたわけではありません。初期のFORTRANは読みやすさや書き換えコストを下げましたが、実際の移植性は次の要因で制限されました：
時間が経つにつれて、科学コードを別機種へ移すコストが明白になり、標準化への圧力が高まりました。
経済性を変えました：
つまり、FORTRANはプログラミングを「一度きりの職人仕事」から「繰り返し可能な産業活動」へと押し上げました。
いくつかのトレードオフが実際に現れました：
大きなボトルネックは取り除かれましたが、複雑さそのものは消えませんでした。
核となる教訓は「ツールへの投資がスケールを生む」という点です。
実践的な要点：
これらは現代のチームにも通じる教訓です。
FORTRANは今日でも科学技術計算の分野で広く使われています。特に、成熟した検証済みライブラリや長期にわたるコードベースが重要な場合に現役です。
学ぶときのポイント：