プログラミングの歴史 ― 計算機から創造の言語へ
私たちはいま、何気なくキーボードを打ち、プログラムを書いています。
print(‘Hello, world!’)
――それは、プログラマーを志す人が最初に出会う小さな魔法の言葉です。
しかし、この一行の背後には、70年以上にわたる人類の試行錯誤が積み重なっています。
プログラミングはもともと、計算を効率化するための機械のための言語でした。けれど、時代が進むにつれて、それは徐々に人間のための言語へと変化していきます。
数字を操る道具から、思想を表現する手段へ。
プログラムを書くという行為は、いつしか「機械を動かすこと」だけでなく、「世界をどう表現するか」という問いへと進化していきました。
この記事では、プログラミングの歴史を単なる技術史としてではなく、人類が “思考” をコードに託してきた軌跡として見ていきます。
原始の時代 ― 計算するための言語
プログラミングの始まりは、まだ「コンピュータ」という言葉すら珍しかった時代にあります。
1940年代、電子計算機は部屋いっぱいの大きさで、計算ひとつ行うにも機械のスイッチを直接操作する必要がありました。
この時代のプログラミングは、いわば “機械の言葉” でした。コードを書くというよりも、機械と直接 “対話する” ような作業だったのです。
たとえば「101010101」なんてコードを見て、「ああ、これで計算が動くね」なんて理解できる人は相当に限られていました。
やがて1950年代に入ると、コンピュータは少しずつ汎用化し、「より人間に理解しやすい形で命令を伝える」必要が生まれました。
ここで登場したのが、アセンブリ言語です。
アセンブリは、0と1の代わりに「MOV」「ADD」などの英単語で命令を書くことを可能にしました。
それでも、機械寄りであることに変わりはありません。
プログラマーはまるで機械の思考をなぞるように、細かい動作を一行ずつ積み重ねていきました。
このころのプログラミングは、まさに “職人の手仕事” そのものでした。
プログラマーは機械の中で何が起こるかをすべて理解し、メモリや演算装置を直接扱っていたのです。
人間の言葉で機械を動かす ― FORTRANとCOBOLの登場
1950年代後半、プログラミングは大きな転換期を迎えました。
それまでのプログラマーは、電気回路のような機械構造を直接意識しながら命令を書いていましたが、このころから「人間が理解しやすい言葉でプログラムを書けるようにしよう」という発想が生まれます。
この思想を最初に形にしたのが、FORTRAN（フォートラン） でした。
1957年、IBMのジョン・バッカスらによって開発されたFORTRANは、“Formula Translation”――つまり「数式の翻訳」という名の通り、数学的な式をそのままプログラムとして表現することを目指した言語でした。
これにより、研究者や技術者は、複雑な数値計算を人間の言葉に近い形でコンピュータに伝えられるようになったのです。
それまで「アセンブリの職人」でなければ書けなかったプログラムが、普通の科学者やエンジニアにも手の届くものになりました。
プログラミングが、専門職だけの技ではなく、“知的作業”としての入口を開いた瞬間だったと言えるでしょう。
数学から社会へ ― COBOLの思想
一方で、FORTRANが理系の世界を中心に発展していた同じ時期、もうひとつの潮流が誕生します。
それが、COBOL（コボル）です。
COBOLは1959年、グレース・ホッパーという女性プログラマーを中心に開発されました。
FORTRANが「科学者のための言語」だとすれば、COBOLは「ビジネスのための言語」でした。
その文法は、まるで英文のように書けるよう設計されています。
たとえば次のような命令文です：
ADD HOURS-WORKED TO TOTAL-HOURS.
つまり、「HOURS-WORKED を TOTAL-HOURS に加えよ」。
人間の読みやすさを第一に考えた設計思想は、当時としては画期的でした。
COBOLは、企業や行政の業務処理を支えるために生まれ、いまなお金融や公共機関のシステムで使われ続けています。
そこには、プログラムを「社会の運営を支える言葉」として捉えた思想が息づいています。
機械語から“言語”への進化
FORTRANとCOBOL――この二つの流れが象徴するのは、プログラミングが「技術」から「文化」へと変わり始めたことです。
FORTRANが科学技術を加速させ、COBOLが社会システムを自動化した。
どちらも、人間が機械を理解する時代から、機械が人間の言葉を理解する時代への橋渡しとなりました。
プログラミングは、もはや単なる命令の羅列ではなく、目的や文脈を持つ “表現” の一種になっていったのです。
この時期を境に、プログラマーは「計算する人」から「設計する人」へと進化していきました。
そして次の時代――1960年代から70年代にかけて、プログラミングの世界に新たな思想が芽生えます。
それが、「構造化」という発想です。
複雑さをいかに制御し、再利用可能な形に整理するか。
ここから、現代的なプログラミングの礎が築かれていくことになります。
抽象化の夜明け ― 構造化と制御構文の発明
1950年代までのプログラミングは、いわば “職人の手仕事” でした。
FORTRANやCOBOLによって多少人間に近づいたとはいえ、依然としてプログラマーは細かい処理の流れを自ら管理しなければなりませんでした。
複雑なプログラムになるほど、どこで何が行われているのかが分からなくなり、一度書いた自分のコードですら理解できなくなる――そんな混乱が頻発していたのです。
この状況に風穴を開けたのが、1960年代に登場した 構造化プログラミング（Structured Programming）という考え方でした。
「goto文」からの解放
当時のプログラムは「goto文」によって自由にジャンプし、条件やループを制御するのが一般的でした。
しかし、ジャンプを多用すると処理の流れが複雑に入り組み、プログラム全体が “スパゲッティコード” のように絡み合ってしまう問題がありました。
これに対して、オランダの計算機科学者 エドガー・ダイクストラ（Edsger Dijkstra） は、1968年に発表した論文『Go To Statement Considered Harmful（goto文は有害である）』で警鐘を鳴らします。
彼が提唱したのは、「プログラムは3つの構造 ― 順次・分岐・繰り返し ― のみで表現できる」という思想でした。
つまり、命令を上から下へ順に流し、分岐やループを明示的に構造化する。
この発想が、今日の「if文」や「while文」などの制御構文の原型になったのです。
ALGOLとPascal ― 構造を持つプログラムの誕生
この考え方を実際の言語に落とし込んだのが、ALGOL（アルゴル）と Pascal（パスカル）でした。
ALGOLは1958年にヨーロッパの研究者たちによって開発され、「Algorithmic Language（アルゴリズムのための言語）」という名の通り、数学的に整った文法と、明確な構造を持っていました。
ALGOLは直接的な商業的成功を収めたわけではありませんが、その設計思想は後に多くの言語に影響を与えます。
特にPascalやC言語、さらには後のJavaやPythonなどにもその影響は色濃く残っています。
Pascal（1970年）は、スイスの計算機科学者ニクラウス・ヴィルトによって設計されました。
教育目的で作られたPascalは、「正しい構造でプログラムを書く」ことを重視し、多くの大学や教育機関で教えられました。
Pascalの時代に、プログラミングは個人の感覚や勘に頼る作業から、論理的な設計行為へと変化していきます。
つまり、芸術的な職人仕事から、再現性を持つ工学へ――。
“構造化”は、プログラミングを科学へと押し上げた思想だったのです。
C言語の誕生 ― 現代プログラミングの原型
そして1972年、ベル研究所で生まれた C言語 が、構造化の思想を実用的な力へと変えます。
C言語は、ALGOL系の構造化文法を受け継ぎながら、ハードウェアを直接操作できるほどの柔軟性を併せ持っていました。
そのバランスの良さから、Cは「高水準言語」と「低水準言語」の橋渡し的存在となり、オペレーティングシステムや組み込み機器など、あらゆる分野で使われていきます。
Cの設計者デニス・リッチーとケン・トンプソンが開発したUNIXも、まさにこのC言語で書かれたものでした。
彼らは「小さな部品を組み合わせて大きなシステムを構築する」という設計哲学を体現し、
その後のソフトウェア文化の礎を築いたのです。
抽象化という人間の知恵
構造化プログラミングの登場によって、プログラミングは初めて「人間が理解できる構造」を持ちました。
機械の中で何が起こっているかを意識するだけでなく、コードを読む人・保守する人・拡張する人の存在を前提とした設計へと進化したのです。
抽象化――つまり、複雑なものをシンプルに整理して理解する力。
それはプログラミングに限らず、人間の知的活動そのものでもあります。
この「抽象化」の思想が、次の時代にさらなる飛躍をもたらします。
プログラマーたちは、次第にこう考え始めました。
「データや関数だけでなく、現実の世界そのものをプログラムの中に表現できないだろうか？」
そうして生まれたのが、オブジェクト指向という新たな時代の扉でした。
オブジェクト指向という思想の誕生
1970年代、構造化プログラミングによって、コードはようやく「理解できる形」を得ました。
しかし、それでもなお、人間が扱う現実世界の複雑さを表現するには限界がありました。
“手続き” や “データ” という抽象化は便利でしたが、それらはどこか機械的で、人間の思考の流れとは異なっていたのです。
そんななか、「プログラムの中に“登場人物”を置く」というまったく新しい発想が生まれました。
これが、オブジェクト指向（Object-Oriented Programming） の始まりでした。
Simula ― すべては“シミュレーション”から始まった
オブジェクト指向の源流は、1960年代にノルウェーで開発された言語 Simula（シミュラ） にあります。
もともとは「シミュレーションを行うための言語」として設計されたSimulaですが、開発者のオーレ＝ヨハン・ダールとクリステン・ニイガードは、現実世界の “もの” や “概念” をプログラムの中で表現するために、クラス（class） と オブジェクト（object） という概念を導入しました。
彼らは考えました。
「現実の世界は、独立した存在が互いに関係しながら動いている。
ならばプログラムも、そうあるべきではないか」と。
この発想によって、プログラムの世界は一変します。
手続き（手順）ではなく、“もの”を中心に考える。
命令ではなく、ふるまう存在としてソフトウェアを設計する――。
ここに、オブジェクト指向の哲学的な転換点があったのです。
Smalltalk ― 「すべてはオブジェクトである」
Simulaの考え方は、1970年代のアメリカでさらに発展します。その舞台となったのが、Xerox PARC（ゼロックス・パロアルト研究所）です。
ここで誕生した言語 Smalltalk（スモールトーク） は、“すべてがオブジェクトである” という純粋な世界観を打ち立てました。
ファイルも、文字列も、数字も、ウィンドウすらもオブジェクト。それらが互いにメッセージを送り合って動作する。
この「メッセージによるやりとり」という発想は、単なる技術仕様を超えて、ソフトウェアを生きた社会のように扱う考え方でした。
またSmalltalkの大きな特徴として、マウスを使って操作するグラフィカルユーザーインターフェース（GUI）の考え方を広めたことがあります。
今、私たちがパソコンの画面でクリックやドラッグを当たり前のように使っているのは、Smalltalkがルーツです。
Smalltalkの生みの親であるアラン・ケイ（Alan Kay）は、後にこう語っています。
「オブジェクト指向とは、データをカプセル化した小さなコンピュータたちが、
メッセージを送り合って協力する世界である。」
この思想は、後のすべてのオブジェクト指向言語の根幹となりました。
C++とJava ― オブジェクト指向の大衆化
1980年代に入ると、オブジェクト指向の概念は産業界へと広がっていきます。
そのきっかけとなったのが、C++ の登場です。
C++は、構造化言語であるCの文法をベースに、クラス・継承・多態性といったオブジェクト指向の要素を取り入れた言語でした。
つまり、“機械に強いC” と、“構造に強いOOP” の融合体だったのです。
これにより、企業の大規模システムやOS、アプリケーション開発にオブジェクト指向が実際に使われるようになります。
続いて1990年代、Java が登場します。
「一度書けば、どこでも動く（Write once, run anywhere）」を合言葉に、Javaはネットワーク時代の代表的言語となりました。
Javaは、C++よりも安全で、より純粋なオブジェクト指向を志向していました。
Web、企業システム、モバイル――ありとあらゆる場面で使われ、ついにオブジェクト指向は“プログラミングの標準思想”として定着したのです。
「登場人物で世界を描く」思想
オブジェクト指向の最大の特徴は、現実世界の構造をプログラムの中に映し出すことにあります。
現実では、車が走り、人が運転し、信号が変わる。
プログラムでも、「車クラス」「人クラス」「信号クラス」が互いに関係し、メッセージをやりとりする。
つまり、オブジェクト指向は “現実世界のメタファー” なのです。
そこではすべてのオブジェクトが責任を持ち、互いに協調しながら全体を構成しています。
これは単なるプログラミング手法ではなく、世界を理解するための思想でした。
命令中心から主体中心へ。
プログラムが「手段」から「表現」へと変わる――。
この発想の転換こそが、オブジェクト指向の本質です。
オブジェクト指向の登場によって、プログラムは単なる論理構造を超え、“生きた世界” を記述する手段へと進化しました。
しかし、同時にその柔軟さと抽象度の高さは、新たな複雑さを生み出すことにもなります。
次の章では、そんなオブジェクト指向の「功罪」――
つまりその思想がもたらした豊かさと矛盾について、少し批評的な視点から考えていきます。
オブジェクト指向の功罪 ― 豊かさと矛盾のあいだで
オブジェクト指向は、プログラミングの世界に確かな秩序をもたらしました。
複雑な現実を整理し、再利用可能な構造として組み立てる。
小さなオブジェクトたちが協力し合うことで、大きなシステムが機能する。
その発想は、まさに “構造的な美しさ” に満ちていました。
プログラマーは初めて、ソフトウェアを建築や都市設計のようにデザインできるようになったのです。
しかし同時に、オブジェクト指向の世界には、その美しさゆえの矛盾も潜んでいました。
豊かさ ― ソフトウェアを「構造的に」考える力
オブジェクト指向が登場したことで、プログラマーは初めて、複雑な問題を「責任の分担」で整理できるようになりました。
クラスごとに役割を定義し、それぞれの責任を明確にする。
データと振る舞いを一体化し、外部からは不要な情報を隠す。
この考え方によって、システムは部分ごとに理解できるようになり、大人数での開発や長期的な保守が可能になりました。
それは、まるで社会の分業構造にも似ています。
「一人がすべてを把握する必要はない。
それぞれが自分の仕事を正しく果たせば、全体が動く。」
オブジェクト指向は、協調するための仕組みをソフトウェアにもたらしたのです。
矛盾 ― 「設計が目的化する」罠
しかし、この “構造的な美しさ” が、やがて多くの人を縛るようになります。
オブジェクト指向は強力であるがゆえに、設計そのものが目的化してしまうのです。
「このクラスはどこまで責任を持つべきか」
「継承階層はどうあるべきか」
「抽象クラスとインターフェースのどちらを使うべきか」
こうした議論は本来、コードをより理解しやすくするための手段でした。
ところが次第に、正しい設計図を描くこと自体が目的になっていったのです。
その結果、システムは動いているのに、誰も全体を理解していない。
設計書だけが美しく、現実のコードは矛盾と継ぎ接ぎだらけ。
まるで、理想の都市計画に実際の人々の生活が追いつかないような光景です。
継承の呪い ― 階層が複雑さを生む
特に問題視されたのが、「継承」の乱用でした。
「共通部分をまとめる」という考え方は魅力的でしたが、現実の問題はそう単純ではありません。
親クラスを変更すれば、子クラスすべてに影響が及ぶ。
階層が増えるほど、どの振る舞いがどこで定義されているのか分からなくなる。
“再利用のための仕組み”が、いつの間にか“制約のための構造”に変わってしまう。
これは、オブジェクト指向が本来目指した「自由な協調」とは真逆の方向でした。
理想と現実 ― 世界はオブジェクトだけでは語れない
やがて、プログラマーたちは気づき始めます。
「世界は必ずしも、オブジェクトの関係として整理できるわけではない」ということに。
データ中心の処理、状態を持たない関数、並列計算――
現実の問題には、オブジェクト指向の枠に収まりきらないものが増えていきました。
たとえば、ゲーム開発や物理シミュレーションの分野では、“データを中心に処理を最適化する” 発想が求められました。
関数型プログラミングでは、「状態を持たない純粋な関数」が再評価されました。
こうしてオブジェクト指向は、ひとつの完璧な答えではなく、数ある視点のひとつとして再定義されていったのです。
それでも残る「思想」としての価値
それでも、オブジェクト指向が果たした役割は決して小さくありません。
それは単なる技術ではなく、「ソフトウェアとは何か」を問い直した思想でした。
責任の分担、カプセル化、再利用、協調――
それらは現代のあらゆる設計思想の中に、形を変えて生きています。
コンポーネント、マイクロサービス、モジュール、エンティティ。
呼び方は変わっても、根底にあるのは “現実を小さな単位に分け、それらを関係づける” というオブジェクト指向の哲学です。
オブジェクト指向は、もはや流行ではありません。
しかし、世界をどう整理し、どう関係づけるかという思考法として、今なお私たちのコードの奥に息づいています。
現代の位置づけ ― 多様化するプログラミング思想
2000年代に入ると、ソフトウェアの世界は再び大きな変化を迎えました。
インターネットが生活の中心となり、私たちは「ひとつのコンピュータの中」だけでなく、世界全体をつなぐシステムを相手にするようになったのです。
この変化に伴って、プログラミングの考え方もまた多様化していきました。
かつては「オブジェクト指向こそが正解」とされた時代もありましたが、現代ではもはや、ひとつの思想で世界を整理しきることは不可能になっています。
オブジェクト指向は成熟し、その周囲には関数型・データ指向・宣言的プログラミングなど、さまざまな “思想の分岐” が生まれました。
関数型プログラミング ― 状態を持たない世界の発想
関数型プログラミング（Functional Programming）は、もともと1950年代の数学的理論に由来する古い発想でした。
しかし2000年代以降、並列処理や分散システムが普及する中で再び注目を集めます。
関数型の核心は、「状態を持たない」ことです。
オブジェクト指向が “登場人物たちの関係” を表現するのに対し、関数型は “データの変換” という流れそのものを重視します。
たとえば、同じ入力があれば常に同じ出力を返す「純粋関数（pure function）」は、
副作用を持たないため安全で予測可能です。
これにより、並列実行やデータ処理を効率的に行うことができます。
代表的な言語としては Haskell, Scala, F#, そして関数型の要素を取り入れた JavaScript や Python などが挙げられます。
関数型の人気は、単なる性能の話ではなく、「複雑な状態を排除し、純粋な変化を表す」という思想への共感でもあります。
それは、オブジェクト指向の “世界を構築する” という考えとは対照的に、“世界の流れを観察する” 哲学なのです。
データ指向 ― 機械の現実を見据える思想
もう一つの潮流が、データ指向設計（Data-Oriented Design）です。
この考え方は、特にゲーム開発や高速処理が求められる分野で発展しました。
オブジェクト指向が「人間の理解しやすさ」を重視するのに対し、データ指向は「機械が効率的に扱える構造」を優先します。
コンピュータは、データを連続したメモリ上に並べて処理するのが得意です。
オブジェクトを複雑に分けすぎると、メモリのアクセスが非効率になり、パフォーマンスが低下します。
そこでデータ指向は、“データを中心に設計し、処理を後から考える” というアプローチをとります。
この思想は、いわばオブジェクト指向の “反転” とも言えるものです。
ゲームエンジンの内部設計やAI処理の最適化など、「スピードと現実性」を求める分野で広く採用されています。
コンポーネント志向とマイクロサービス ― 拡張と分離の思想
さらに現代では、システム全体の規模が拡大し、単一のプログラムだけで完結することがほとんどなくなりました。
Webアプリケーションは複数のサーバーやサービスを連携させて動き、それぞれが独立して更新・拡張できることが求められます。
この流れの中で生まれたのが、コンポーネント志向やマイクロサービスの考え方です。
これらはオブジェクト指向の「責任の分担」をさらに大きなスケールで実現したものです。
1つのシステムを、複数の “自己完結した部品” に分ける。
部品同士はAPIを介してやりとりする。
それぞれが独立しながら、全体として機能する――。
これは、まるでオブジェクトたちが社会を構成するように、サービスたちがネットワーク上で協調する社会のようなものです。
AI時代のプログラミング ― 「考えるコード」へ
そして今、私たちはもう一つの転換点に立っています。
AI、特に大規模言語モデル（LLM）の登場によって、プログラミングという行為そのものが再定義されつつあります。
これまで、プログラマーは“コードを書く人”でした。
しかしAIの支援によって、コードを書くよりも「どんな意図を持って設計するか」が重要になってきています。
AIがコードを生成し、人間がそれを設計・検証・方向づける。
これは、プログラミングが「手作業」から「創造的な対話」へと進化していることを意味します。
ここでも再び、オブジェクト指向が投げかけた問いが響いてきます。
“誰が、何を、どのように行うのか？”
AIが “登場人物” の一員となった今、プログラムは単なる命令の集まりではなく、人間と機械が共同で物語を紡ぐプロセスへと変わりつつあるのです。
思想の多様化がもたらす未来
今日のプログラミングは、もはやひとつの思想に依存していません。
オブジェクト指向も、関数型も、データ指向も――
それぞれが異なる世界の見方を提供しています。
重要なのは、「どれが正しいか」ではなく、「どの視点で世界を捉えるか」です。
プログラマーとは、道具を使う人ではなく、思想を選び、構造を設計する“思想家”でもあるのです。
プログラミングが教えてくれる“考える力”
プログラミングの歴史を振り返ると、それはまるで人類の思考の進化を映し出しているようです。
最初は機械を動かすための命令の羅列から始まり、
やがて、現実を整理するための構造を生み、
さらに、世界を表現するための抽象化へと進化していきました。
そして今、AIと共に考える時代を迎え、プログラミングは再び、“言葉とは何か” を問い直す段階に立っています。
コードは「思考の化石」である
プログラムを書くという行為は、単にコンピュータに仕事をさせるためのものではありません。
それは、自分の考えを構造化し、明確にし、他者にも理解できる形で表現することです。
コードとは、思考の化石のようなものです。
そこには、考え方、選択の理由、迷い、工夫――すべてが刻まれています。
過去のプログラマーたちがFORTRANやC、Smalltalkを設計したとき、彼らは単に新しい技術を作っていたのではありません。
彼らは「世界をどう説明すれば理解しやすいか」という、思考そのものの構造を探っていたのです。
だからこそ、プログラミングの歴史は “技術史” であると同時に、“哲学史” でもあるのです。
世界を整理する力、世界に寄り添う力
プログラミングが教えてくれるのは、“世界をどう整理するか”という知的な技術だけではありません。
もう一つ大切なのは、“世界にどう寄り添うか”という感性です。
構造化プログラミングが世界に秩序を与え、
オブジェクト指向が世界に登場人物を与え、
関数型が世界に純粋な流れを与えたように、
プログラミングはいつも現実との対話の中で進化してきました。
私たちがプログラムを書くとき、それはただの論理ではなく、人間の観察の延長線上にあります。
プログラマーは機械の操縦士であると同時に、世界の構造を見つめる観察者でもあるのです。
コードを書くとは、未来を設計すること
技術は移り変わり、言語は生まれては消えていきます。
けれども、その根底にある“考える力”は変わりません。
プログラミングとは、「いまの自分の理解で、未来の誰かが使う仕組みを作る」行為です。それは、未来に向かって橋を架けるようなものです。
自分の書いた一行が、まだ見ぬ誰かの手によって拡張され、修正され、使われていく。その連鎖の中に、人間の知性の継承が息づいています。
FORTRANからAIまで続く長い歴史の中で、プログラマーたちは常に「どうすればもっとわかりやすくなるか」を考えてきました。
その営みこそが、プログラミングという文化の本質なのです。
結びに ― “プログラマー”という哲学者たちへ
もしかすると、プログラマーとは、「世界をどう理解するか」を最も真剣に考えている人々なのかもしれません。
彼らは抽象と具体のあいだを往復し、理想と現実の境界を何度も行き来しながら、自分なりの“世界のモデル”を作り続けています。
それは科学者であり、設計者であり、哲学者でもある存在です。
プログラミングの歴史をたどることは、人類が「考えるとは何か」を問い続けた記録をたどることでもあります。
コードを書くことは、思考すること。
思考することは、生きること。
そして――
プログラムを書くとは、未来を設計することなのです。
コラム一覧に戻る
