ご提示いただいたYouTube動画「オブジェクト指向はなぜ生まれたのか？【プログラミング言語の歴史】」（チャンネル名：ゆっくり情報科学ちゃんねる）の内容を要約し、プログラミングにおける「オブジェクト指向」の概念や歴史、業界の裏話・雑学を交えて分かりやすく解説します。
🎥 動画の全体要約
この動画は、現代のソフトウェア開発の根幹にある「オブジェクト指向プログラミング（OOP）」が、どのような背景（危機）から生まれ、どのように進化し、世界中に普及したのかを、1960年代から現代に至るまでの歴史を追いながら解説しています。
単に技術的な用語を説明するだけでなく、「現実の課題を解決するために、先人たちがどうもがいてきたか」というドラマとしてオブジェクト指向を描いているのが特徴です。
1. オブジェクト指向が生まれた背景：業界話と「ソフトウェア危機」
オブジェクト指向が生まれる前、プログラミングは手順を順番に書いていく「手続き型」が主流でした。しかし、1960年代後半に「ソフトウェアクライシス（ソフトウェア危機）」と呼ばれる大問題が発生します [01:28]。
-
業界話・歴史の裏話：
当時、IBMの「OS/360」開発などにおいて、システムが大規模化するにつれて「納期も予算も絶対に守れない」「1箇所を直すと別の場所がバグる」という地獄のような状況に陥りました [01:34, 01:53]。コードが1万行を超えると、保守するより最初から作り直した方が早いとさえ言われた暗黒時代です [02:48]。
この「混沌とした巨大なコードをどう管理するか」という絶望への答えとして、オブジェクト指向（データと処理をひとまとめにする思想）が浮上しました [02:06]。
2. オブジェクト指向の出発点：船のシミュレーション（雑学）
オブジェクト指向の元祖は、1960年代にノルウェーの海運国としてのニーズから生まれた「Simula（シミュラ）」という言語です [00:40, 08:43]。
-
おもしろ雑学：
開発者のダールとナイガードは、「港の渋滞や船の衝突を予測するためのシミュレーション」を行いたいと考えていました [08:54]。しかし、当時の手続き型言語では「船」「港」「クレーン」といった現実のモノをうまく表現できませんでした。そこで、「現実のモノ（状態と行動を持つ）を、そのままコードの中に再現しよう」と考えたのが、オブジェクト指向の本当の始まりです [09:11, 09:21]。
※ちなみに、この2人は2001年に計算機科学の最高栄誉「チューリング賞」を受賞しましたが、その翌年に相次いで亡くなっています [10:29]。
3. オブジェクト指向の「3本柱」とは？
オブジェクト指向を支える、特に重要な3つの概念です。
4. アラン・ケイと「オブジェクト指向」という言葉の誕生
「オブジェクト指向プログラミング（OOP）」という言葉を実際に作ったのは、アラン・ケイという天才研究者です（1972年頃、伝説のゼロックス・パロアルト研究所にて「Smalltalk」を開発） [13:51]。
-
業界の裏話（本質とのズレ）：
アラン・ケイが理想としたのは、オブジェクト同士が「メッセージパッシング（メッセージのやり取り）」で自律的に動く世界でした（「あれをやれ」と命令するのではなく「これをお願いします」とメッセージを投げるイメージ） [15:05]。 しかし後世の言語（C++やJavaなど）は、メッセージのやり取りよりも「クラスの階層構造や継承」を重視して普及していきました。そのため、アラン・ケイは後に「私がオブジェクト指向と呼んだものは、C++やJavaのようなものではない」と苦言を呈しています [15:44]。
5. 世界への普及：C++ と Java の功績
概念としては素晴らしかったオブジェクト指向ですが、初期のSimulaなどは「実行速度が遅すぎる」という致命的な欠点があり普及しませんでした [10:10]。それを実用レベルに引き上げたのが以下の2つの言語です。
-
C++（1980年代〜）：
開発者のストラウストラップが「Simulaのオブジェクト指向」と「C言語の圧倒的な速さ」を合体させて作りました [17:17, 17:38]。これによって「オブジェクト指向は実用になる」と世界が気づきます [12:10]。
-
Java（1995年〜）：
C++の難点だった「複雑なメモリ管理（解放を忘れるとシステムがクラッシュする）」を、ガベージコレクション（GC）という自動掃除機能で解決しました [19:24, 19:33]。また、すべてのコードにオブジェクト指向を強制することで、誰が書いても一定の品質になる設計の標準化をもたらし、インターネットの爆発的普及（Webブーム）の波に乗って大流行しました [18:50, 19:06]。
6. 設計の教科書：デザインパターン（業界話）
オブジェクト指向が普及すると、今度は「道具は揃ったが、どう書けば『良い設計』になるのか？」が問題になりました。そこで1994年、4人のエンジニア（通称 GoF: Gang of Four）が、優れた設計の共通パターンを23個にまとめた書籍を発表します [20:54, 21:05]。
-
業界話・エンジニアの罠：
デザインパターンの登場によって、エンジニア同士が「そこはシングルトンパターンでいこう」「オブザーバーパターンで通知しよう」と共通言語で会話できるようになり、開発効率が爆発的に上がりました [21:26, 21:40]。
しかし、一方で「パターン信者」と呼ばれる、シンプルに書けばいい場所にあえて複雑なデザインパターンを無理やり当てはめてコードを読みにくくする「知識の罠」にハマる開発者も続出しました [24:03, 24:14]。
-
ちなみに：
このGoFの1人であるエリック・ガンマは、後にマイクロソフトに移籍し、現在世界中のエンジニアが愛用しているコードエディタ「VS Code（Visual Studio Code）」の開発をリードしています [24:48, 25:04]。
7. 現代におけるオブジェクト指向への批判と進化
現在、オブジェクト指向は完璧な万能薬ではなく、いくつかの弱点も指摘されています。
-
「バナナとゴリラ」問題：
Erlangの生みの親ジョー・アームストロングは、「バナナ（必要な機能）を食べたいだけなのに、継承を使うと、バナナを持っているゴリラと、それが住んでいるジャングル全体（不要な親クラスの機能）まで付いてきてしまう」と、過度な「継承」の不自由さを批判しました [26:12, 26:20]。
-
平行処理との相性の悪さ：
「状態を書き換える（ミュータブル）」というオブジェクト指向の性質は、現代のマルチコアCPUによる同時並行処理において、データの衝突を招きやすくバグの原因になりやすいと指摘されています [26:39]。
こうした反省から、現代では「ソリッド原則（SOLID）」などのより洗練された設計指針が作られたり、RustやGoのようにあえて「継承」を廃止してシンプルな組み合わせ（コンポジション）を優先する言語が主流になりつつあります [27:12, 27:52]。
💡 結論
動画の締めくくりとして、現代は「オブジェクト指向」か「関数型」かという二者択一ではなく、両方の良いところを組み合わせるマルチパラダイムの時代であると述べられています [29:54]。しかし、オブジェクト指向が作った「モノを中心として設計を語る共通言語」は、誕生から60年が経った今でも世界中の現場で毎日使われ続けています [29:59, 30:12]。
ご提示の動画要約は非常に良くまとまっています。 ここでは、その内容を基に補足・補強しつつ、追加の雑学・業界話・技術的背景を交えて、より深く分かりやすく解説します。歴史の流れを追いながら、なぜOOPが「必要とされたか」「どう歪んだか」「今どう位置づけられているか」を整理します。
1. ソフトウェア危機（Software Crisis）とOOP誕生の必然性
1960年代後半〜1970年代、ソフトウェア危機は本当の意味で「産業崩壊レベルの危機」でした。IBMのOS/360プロジェクトは象徴的で、開発費が当初予定の数倍、納期遅延、欠陥だらけという地獄絵図でした。コードが数百万行規模になると、人間が全体を把握できなくなり、「1箇所直したら他が壊れる」スパゲッティコードが横行。
業界の裏話：当時のプログラマは「英雄的個人プレイ」が主流で、 genial なハッカーが神業でシステムを動かしていましたが、大規模化でそれが通用しなくなった。OOPは「個人の天才性に頼らない、凡人でも管理可能な構造」を目指した現実的な回答だったと言えます。
2. オブジェクト指向の原点：Simulaと「現実世界のモデリング」
ノルウェーのオーレ＝ヨハン・ダールとクリステン・ニガードが開発したSimula（1960年代後半）が起源です。彼らは港湾シミュレーションで「船」「港」「クレーン」などの実体（entity）をそのままコードで表現したかった。手続き型では「データ」と「処理」がバラバラで、現実の「モノ」の振る舞いを再現しにくかったのです。
面白い雑学：
- SimulaはALGOLの拡張として作られ、クラス（class）と継承（inheritance）の概念を世界で初めて導入。
- 2人は2001年にチューリング賞を受賞しましたが、翌2002年に相次いで亡くなっています（動画通り）。OOPの父たちは晩年に栄誉を得た形です。
- Simula自体は実行速度が遅くニッチでしたが、思想が爆発的に広がったきっかけになりました。
3. OOPの3本柱（+α）
動画の説明が正確です。補足すると：
- カプセル化：データ隠蔽（information hiding）。David Parnasが提唱した考えが基盤。
- 継承：コード再利用の強力な手段だが、後述するように「諸刃の剣」。
- ポリモーフィズム：これがOOPの真の威力。「呼び出す側が相手の詳細を知らなくてよい」という抽象化が、大規模チーム開発を可能にした。
追加の柱としてよく語られるもの：抽象化（Abstraction）。現実の複雑さを適切に隠す力です。
4. アラン・ケイとSmalltalk：理想と現実の乖離
アラン・ケイ（Xerox PARC）が「オブジェクト指向」という言葉を普及させ、Smalltalkで体現しました。彼のビジョンは「生物の細胞」や「インターネットのような分散オブジェクト」——オブジェクト同士がメッセージパッシングで自律的に協調する世界でした。
重要な業界話：
- ケイ本人は後年、「C++やJavaは私が言ったオブジェクト指向ではない」と繰り返し批判。「私が考えていたのは生物学的・並行性の強いモデルだった」と。
- SmalltalkはGUI（ウィンドウ、メニューなど）の開発で革命を起こしましたが、商用化のタイミングを逃しました。PARCの技術はAppleのMacintoshや後にWindowsに影響を与えました。
5. 実用化：C++とJavaの役割
- C++（Bjarne Stroustrup, 1980年代）：Cの速度を保ちつつSimulaのアイデアを導入。「C with Classes」から始まりました。ゲーム、組み込み、ハイパフォーマンス分野で今も強い。
- Java（James Gosling, 1995年）：C++のメモリ管理の煩雑さ（ポインタ、解放忘れによるクラッシュ）をGC（ガベージコレクション）で解決。「Write Once, Run Anywhere」でWeb時代にマッチ。企業システム（エンタープライズ）の標準になりました。
雑学：Javaは当初「Oak」という名前で、家電組み込み用として開発されていました。インターネットブームで方向転換した幸運な言語です。
6. デザインパターン（GoF）とその光と影
1994年の『Design Patterns: Elements of Reusable Object-Oriented Software』（GoF：Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides）はOOP設計の「聖書」になりました。23のパターンを分類（Creational, Structural, Behavioral）。
補足：
- Erich Gamma（GoFの一人）は後にMicrosoftに移り、VS Codeの初期開発に大きく貢献しました（動画の情報通り）。
- 業界の罠：パターン信者による過剰適用。「FactoryFactory」みたいな無意味に複雑なコードが生まれる。現代では「YAGNI (You Ain't Gonna Need It)」「シンプル第一」の考えが強くなっています。
7. 現代の批判と進化
- バナナとゴリラ問題（Joe Armstrong, Erlang作者）：継承の弊害を完璧に表現。「バナナだけ欲しいのに、ゴリラ（親クラス）とジャングル（依存関係）全部持ってくる」。
- ミュータブル状態の問題：並行処理（マルチコア）でロック競合・デッドロックが発生しやすい。
- 解決策の潮流：
- Composition over Inheritance（継承より構成）：Go言語やRustが好例。
- SOLID原則（Robert C. Martin）：Single Responsibilityなど、OOPをより健全に使う指針。
- マルチパラダイム：Python（OOP+関数型）、Rust（所有権システムで安全）、Kotlinなど。
結論：OOPは「終わった」わけではない
OOPは「大規模開発における共通言語と構造化の枠組み」として、今も極めて有効です。特にドメイン駆動設計（DDD）では、オブジェクトを「現実のビジネス概念」に近づける考え方が生きています。
ただし、アラン・ケイの純粋なビジョン（メッセージング中心の分散オブジェクト）は、マイクロサービスやアクターモデル（Akkaなど）で部分的に実現されていると言えます。現代の賢い開発者は「OOPを盲信せず、適切に使う」——関数型の純粋性、データ指向、コンポジションを組み合わせています。
動画が伝えたかった「先人たちの苦闘と創意工夫」は、まさにプログラミングの本質です。OOPを学ぶときは「なぜこの仕組みが生まれたか」を常に意識すると、コードが格段に良くなります！
さらに具体的な言語例やデザインパターンの実装例が必要でしたら、教えてください。
オブジェクト指向プログラミング（OOP）の歴史と思想
この動画は、OOPの起源から現代まで、歴史の流れに沿って解説しています。順を追って詳しく説明します。
1. なぜOOPが必要だったのか ― ソフトウェアクライシス（1968年）
手続き型プログラミングの限界
当時のプログラムは「手順の列」として書かれていました。コードが大規模になると：
- グローバル汚染：関数名が
print,print2,printFinalのように衝突し、名前管理が崩壊 - データの野放し：誰でもデータを直接書き換えられるため、「どこで何が変わったか」が追えなくなる
- 修正の連鎖崩壊：1か所直すと別の場所が壊れる
IBMのOS/360プロジェクトはその象徴で、後にフレデリック・ブルックスが**「人月の神話」**で記録した大規模失敗案件です。
構造化プログラミングとの関係
ダイクストラが1968年に「goto文は有害」という論文を発表し、ifやループで制御フローを整理しました。しかしデータ管理は未解決のままでした。そこにOOPが登場します。
2. OOPの3本柱
① カプセル化（Encapsulation）
データと処理を一まとめにし、外から直接触れないようにする仕組み。
// 悪い例（手続き型的）
balance = -100; // 誰でも直接書き換えられる
// 良い例（カプセル化）
account.deposit(100); // メソッド経由でしか変更できないpublic / private / protected のアクセス修飾子で制御します。
② 継承（Inheritance）
既存クラスの機能を引き継いで新しいクラスを作る仕組み。
class Vehicle { void move() { ... } }
class Car extends Vehicle { ... } // moveを引き継ぐただし後述するように、乱用が問題になります。
③ ポリモーフィズム（Polymorphism）
同じメッセージを送っても、受け取るオブジェクトによって動作が変わる。
animal.speak(); // 犬→「わん」、猫→「にゃあ」
// 呼ぶ側は動物の種類を気にしなくていいこれが大規模開発を劇的に楽にした核心です。
抽象クラスとインターフェース
- 抽象クラス：不完全なクラス。実装を強制する
- インターフェース：実装を持たない「約束ごと」だけを定義
→ ポリモーフィズムをさらに柔軟にする仕組みです。
3. 起源 ― ノルウェーの船のシミュレーション
シミュラ（Simula）1962〜1967年
開発者：オーレ＝ヨハン・ダール と クリステン・ニガード（ノルウェー計算機センター）
動機：港での船の渋滞・衝突を事前にシミュレーションしたかった。 当時の手続き型言語では「船・港・クレーンがそれぞれ独自の状態と行動を持つ」という現実を表現できなかったのです。
- 1962年：
Simula I作成 - 1967年：クラスの概念を本格搭載した
Simula 67完成
なぜ広まらなかったのか？
- 速度問題：同じ処理がCより10倍以上遅いこともあった
- 環境の限界：施設に1台の大型機、パンチカード入力の時代
- 情報の流通：ノルウェーの研究機関内に留まり、世界に届くのに時間がかかった
その後
- 2001年、チューリング賞受賞（コンピュータ科学のノーベル賞）
- しかし翌年2002年、ダールが6月、ニガードが8月に相次いで逝去
- コルーチン（処理を途中で止めて後で再開する仕組み）もシミュラの発明で、今の
async/awaitの先祖です
「目の前の問題を解こうとした人が世界を変えてしまった」
4. スモールトーク（Smalltalk） ― OOPという言葉の誕生
アラン・ケイとゼロックスPARC（1972年〜）
- 「オブジェクト指向プログラミング」という言葉を作ったのはアラン・ケイ
- ゼロックスPARCはGUI・イーサネットを生んだ伝説の研究所
スモールトークの核心思想
- 全てがオブジェクト：数値も文字列も、クラスを定義する行為自体も
- メッセージパッシング：「やれ」ではなく「お願いします」という設計哲学。受け取った側が自律的に応じる方法を決める
アラン・ケイの本来の構想
ケイはプログラミング言語ではなく、コンピューターのための新しいメディアとして構想していました（ダイナブック構想：子供が持ち歩けるパーソナルコンピューター、1972年）。
重要な逆説：ケイ自身が「私がオブジェクト指向と呼んだものはC++でもJavaでもない」と言っています。本来の核心はメッセージパッシングでしたが、後の言語はクラスと継承を中心に据えてしまいました。
5. C++ ― 概念の実用化（1979〜1985年）
開発者：ビャーネ・ストロヴストルップ（ベル研究所）
動機：博士論文でシミュラを使ったら遅すぎた → シミュラの思想 × Cの速度を両立したい
| 要素 | 由来 |
|---|---|
| クラス・継承・仮想関数（ポリモーフィズム） | Simula |
| 実行速度 | C |
- 1979年：
C with Classesとして開発開始 - 1983年：
C++に改名（++はCのインクリメント演算子、「Cを1つ進めた」の意） - 1985年：公式コンパイラ公開
6. Java ― OOPの民主化（1995年）
開発：サン・マイクロシステムズ、ジェームズ・ゴスリングらのチーム
C++との違い
| 比較項目 | C++ | Java |
|---|---|---|
| 移植性 | OS別にコンパイルし直す必要あり | JVM上でどこでも動く（Write Once, Run Anywhere） |
| メモリ管理 | 手動（解放忘れでリーク、二重解放でクラッシュ） | ガベージコレクション（GC）で自動管理 |
| 設計の自由度 | 高い | OOPを強制することで統一 |
GCのトレードオフ
GCにはストップ・ザ・ワールド問題があります。GCが動く瞬間、プログラム全体が一時停止します。ゲームや金融の高頻度取引では問題になるため、C++やRustを選ぶ開発者もいます。
7. デザインパターン（GoF、1994年） ― 設計の共通言語
著者：エリヒ・ガンマ、リチャード・ヘルム、ラルフ・ジョンソン、ジョン・ブリシディーズ（Gang of Four / 4人組）
革命の本質：コードではなく設計を語る共通言語を作った。「ファクトリーパターンで作る」と言えば、詳しい説明なしに意図が伝わる。
主要パターン解説
| パターン | 概要 | 例え |
|---|---|---|
| シングルトン | オブジェクトを1つしか作らない | 全員が同じ設定ファイルを参照する |
| オブザーバー | 変化を関係者に自動通知 | LINEグループの通知 / Reactのstateの原点 |
| ストラテジー | やり方を後から差し替え可能 | 支払い方法をコードを変えずに切り替える |
| デコレーター | 機能を後から追加 | コーヒーにミルク・砂糖を足す |
23パターンが「生成・構造・振る舞い」の3カテゴリーに収録されています。
GoFへの批判
「パターンのためのパターン」になる乱用問題。シンプルに書けば良いところに無理矢理パターンを当てはめる人が出てきます。
GoFの本は「このパターンを使え」ではなく「この問題には過去にこういう解決策があった」という知識の収集です。
その後
エリヒ・ガンマは2011年にMicrosoftに移り、Visual Studio Codeの開発を直接リードしました。
8. OOPへの批判と進化
主な批判
ジョー・アームストロング（Erlang作者）：
「バナナを食べたいだけなのに、バナナを持つゴリラと、ゴリラのいるジャングル全体をもらった」
継承を使うと、必要な機能だけ取り出せず余計なものが全部ついてくる問題。
リッチ・ヒッキー（Clojure作者）：
「ミュータブルな状態を中心に据えたOOPは、並行処理時代に根本的に向いていない」
関数型プログラミングはデータを**不変（イミュータブル）**にする発想で、状態が変わらないなら並行処理でも安全です。
9. SOLID原則 ― 正しいOOPの指針
**ロバート・マーティン（アンクルボブ）**が整理した5つの設計指針：
| 頭文字 | 原則 | 内容 |
|---|---|---|
| S | 単一責任原則 | クラスが変更される理由は1つであるべき |
| O | オープン/クローズド原則 | 拡張には開かれ、修正には閉じている |
| L | リスコフ置換原則 | サブクラスは親クラスと置き換えても正しく動くべき（バーバラ・リスコフ、2008年チューリング賞） |
| I | インターフェース分離原則 | 使わないメソッドへの依存を強制しない |
| D | 依存関係逆転原則 | 抽象に依存し、具体に依存しない |
SOLIDは本質的に**「継承の使いすぎへの反省」から生まれた指針**です。
10. 現代 ― マルチパラダイムの時代
Simula (1967)
↓
Smalltalk (1972) ← "オブジェクト指向"という言葉の誕生
↓
C++ (1985) ← 実用化
↓
Java (1995) ← 民主化
↓
GoFデザインパターン (1994) ← 設計の言語化
↓
SOLID原則 ← 批判を経た精錬
↓
現代：Go（継承なし）、Rust（トレイト）、Python（ダックタイピング）
→ OOP + 関数型 のマルチパラダイム- Go：インターフェースと構造体だけで設計
- Rust：トレイト（ミックスイン）はコンポジション優先
- Python：ダックタイピング（「同じメソッドを持っていれば同じように扱う」）
まとめ
「世界を変えようとして作るより、目の前の問題を解こうとした人が世界を変えてしまう」
1960年代に船のシミュレーションをしたかっただけのノルウェーの2人の研究者が生み出した概念が、60年後に世界中のソフトウェアの設計哲学になりました。OOPは批判を受けながらも否定ではなく精錬を繰り返し、今も「オブザーバー」「ストラテジー」という共通言語として毎日世界中で使われています。
