📽 スライド版（右下の「0.5x」ボタンで表示倍率を0.5倍にするのがおすすめです）
See the Pen SE70 Slides LIFULL by satozguu-the-sans (@satozguu-the-sans) on CodePen.
ソフトウェアエンジニアリングの70年と、これからの話
今回はちょっと壮大なテーマなんですが、ソフトウェアエンジニアリングの70年間の歴史を振り返ってみようと思います。
なぜこんな記事を書こうと思ったかというと、最近「AIにエンジニアの仕事が奪われる」みたいな話をよく聞くんですよね。でも自分としては、歴史を振り返るとそういう不安は70年間ずっと繰り返されてきたものだと感じていて。
なので、「エンジニアが実際に何をしていたか」「社会からどう見られていたか」という軸で、1940年代から現在、そしてこれからの話をまとめてみます。
結論を先に言うと、こうです。
「コードを書く」の比重は70年間ずっと下がり続けている。AIはその最新の一歩にすぎない。
恐れるべきは「AIに仕事を奪われること」ではなく、「抽象化の階段を登り損ねること」。
かなり長い記事になりますが、お付き合いください。
目次
- 1. 1945〜1950年代: 「プログラマ」という職業の誕生
- 2. 1960年代: ソフトウェア危機と「エンジニアリング」の自覚
- 3. 1970年代: 構造化と方法論の時代
- 4. 1980年代: PCの普及とオブジェクト指向
- 5. 1990年代: インターネットとWeb、OSSの台頭
- 6. 2000年代: アジャイル、クラウド、モバイルの胎動
- 7. 2010年代: DevOps、マイクロサービス、データの時代
- 8. 2020年代前半: 生成AIの衝撃
- 通史から見える構造的パターン
- 9. 未来の展望: 自分が思い描く2030年代のソフトウェアエンジニア
1. 1945〜1950年代: 「プログラマ」という職業の誕生
Betty Jennings と Frances Bilas が ENIAC のメインコントロールパネルを操作している（出典: Wikimedia Commons, Public Domain）
そもそもの始まりの話ですね。
1945年、プログラミングとは**「ケーブルを差し替える」**ことでした。ENIAC（1945）の時代は、配線盤のケーブルを物理的に差し替えてプログラムしていたんです。文字通り「配線する」仕事。
その後パンチカードに移行するんですが、プログラムを紙に書き、パンチカードに穿孔し、オペレータに渡して実行を待ち、翌日結果を受け取る。1回のタイプミスで1日が無駄になる世界です。かなりしんどいですよね。
機械語（0と1の羅列）を直接書いていた時代で、アセンブリ言語が登場して「人間が読める記号」で書けるようになったのが大きな進歩でした。
見落とされがちな事実
ここ、個人的にかなり面白いと思うんですが、初期のプログラマの多くは女性だったんですよね。ENIACのプログラミングを担当した6人は全員女性（Kay McNulty, Betty Jennings ら）。当時「プログラミング」は配線作業＝事務的な仕事と見なされていて、「知的な仕事」であるハードウェア設計より格下とされていました。
コンピュータ自体が軍事・政府・大企業の独占物で、一般社会からは見えない存在。「ソフトウェアエンジニア」という言葉はまだなく、「コーダー」「プログラマ」「計算手（computer）」と呼ばれていました。
ちなみに、この「computer」って今は機械を指す言葉ですけど、もともとは計算を行う人間を指す職業名だったんですよね。弾道計算や天文計算を手作業で行う人たちが「computer」と呼ばれていて、その仕事を機械が代替するようになったから、機械の方が「computer」と呼ばれるようになった。つまり「コンピュータに仕事を奪われた」最初の人たちは、自分たち自身が「コンピュータ」だったわけです。結構驚きじゃないですか？
この時代の言語
- 機械語 → アセンブリ言語
- FORTRAN（1957）: 「数式をそのまま書ける」という革命。科学技術計算向け
- COBOL（1959）: 「英語に近い構文でビジネスロジックを書ける」。事務処理向け
2. 1960年代: ソフトウェア危機と「エンジニアリング」の自覚
アポロ誘導コンピュータのソフトウェアリスティングの山と並ぶ Hamilton（出典: Wikimedia Commons, Public Domain）
この時代、OS、コンパイラ、データベースなど基盤ソフトウェアの構築が始まります。IBM System/360のOS開発（OS/360）が象徴的ですね。
プロジェクトは大規模化し、数百人が関わるようになったんですが、管理手法は未成熟で、予算超過・納期遅延・品質問題が常態化していました。
Fred Brooksがこの経験から『人月の神話』（1975出版、経験は60年代）を書いています。「遅れているプロジェクトに人を追加するとさらに遅れる」——この教訓、60年経った今も有効なのがすごいですよね。
転換点: NATOソフトウェアエンジニアリング会議（1968）
ここで初めて**「ソフトウェアエンジニアリング」**という用語が公式に使われました。これ、かなり重要なポイントです。
背景は深刻な「ソフトウェア危機」。ハードウェアの能力は急速に向上するのに、ソフトウェアの開発は追いつかない。プロジェクトは失敗し、コストは膨張し、品質は低い。
つまり「プログラミングは職人芸ではなく、工学的な規律が必要だ」という問題提起がなされたわけです。
アポロ計画とソフトウェア
Margaret Hamiltonがアポロ11号の誘導コンピュータのソフトウェアを率い、月面着陸直前のアラーム（1202エラー）を彼女のチームの設計が救いました。宇宙開発でソフトウェアの重要性が初めて可視化された瞬間ですね。
この時代の言語
- LISP（1958）: AI研究向け。関数型プログラミングの始祖
- ALGOL（1960）: 構造化プログラミングの基礎。ほぼすべての後続言語に影響
- BASIC（1964）: 「非専門家でもプログラミングできるように」。後のPC革命の伏線
3. 1970年代: 構造化と方法論の時代
UNIXとC言語を生み出した二人（出典: Wikimedia Commons, CC BY-SA 2.0）
この時代は構造化プログラミングが普及した時代です。Dijkstraの「Go To Statement Considered Harmful」（1968発表、影響は70年代）により、goto文を排し、順次・分岐・反復の3構造でプログラムを書く規律が広まりました。
ウォーターフォール型開発が標準になったのもこの頃。要件定義→設計→実装→テスト→運用を順番に進める。Winston Royceの1970年の論文が起源とされるんですが、Royce自身は「一方向では失敗する」と書いていたんですよね。この皮肉は長く無視されました笑
リレーショナルデータベースの理論（Codd, 1970）が登場し、UNIXの開発（1969〜）が「小さなツールをパイプでつなぐ」という哲学を生みました。これが後のOSS文化の原型になっています。
ソフトウェア開発は「工場のライン」のアナロジーで語られることが多く、設計と実装を分離し工程管理する発想が主流でした。プログラマは「技術者」として安定した職業になりましたが、社会的な華やかさはなく、地味な裏方仕事という感じですね。
この時代の言語
- C（1972）: UNIXを書くために作られた。アセンブリに近い制御力と、高級言語の生産性を両立。以後50年以上にわたりシステムプログラミングの基盤
- Pascal（1970）: 教育用。構造化プログラミングの教科書的言語
- SQL（1974）: データベース問い合わせ言語。ソフトウェアエンジニアの日常を根本的に変えた
4. 1980年代: PCの普及とオブジェクト指向
パーソナルコンピュータ革命の起点（出典: Wikimedia Commons, CC BY-SA 3.0）
ここから一気に世界が変わります。パーソナルコンピュータの爆発的普及ですね。Apple II（1977）、IBM PC（1981）、Macintosh（1984）。ソフトウェアが「一般消費者向け製品」になりました。
GUIの登場により、ソフトウェアに「見た目」と「使いやすさ」が求められるようになったのも大きい。それまでは端末に文字を表示するだけでよかったわけですから。
オブジェクト指向プログラミングが主流になり、パッケージソフトウェアのビジネスが成立。Lotus 1-2-3、WordPerfect、dBASEなど。ソフトウェアが「箱に入って店で売られる」時代です。Microsoft、Oracle、SAPなどが急成長し、ソフトウェア産業が独立した巨大産業として確立されました。
「プログラマ」が一般に知られる職業になりましたが、まだ「オタク」「ギーク」のイメージが強かったですね。日本では「ソフトウェア工場」モデルが発展し、大手SIerが多重下請け構造で大規模システムを開発する形態が定着し始めました。
この時代の言語
- C++（1983）: Cにオブジェクト指向を追加。性能と抽象化の両立を目指した
- Objective-C（1984）: Appleエコシステムの基盤に（後にSwiftに置き換わる）
- Perl（1987）: テキスト処理とシステム管理。「実用的な汚さ」を許容する哲学。後のWeb CGI時代に大活躍
5. 1990年代: インターネットとWeb、OSSの台頭
Tim Berners-Lee が World Wide Web を構築した NeXT コンピュータ。「This machine is a server. DO NOT POWER IT DOWN!!」のラベルが有名（出典: Wikimedia Commons, CC BY-SA 3.0）
個人的に、ソフトウェアエンジニアリングの歴史で最もインパクトが大きかったのはこの時代だと思います。
World Wide Webの登場（1991）が全てを変えました。ソフトウェアの配布・実行・利用の形態が根本的に変わったんですよね。
初期のWebサイトは静的HTML。すぐにCGI（Perl, C）で動的ページ生成が始まり、掲示板・チャット・ECサイトが登場。クライアント/サーバーモデルが主流になり、デスクトップアプリ（VB, Delphi）でGUIを作り、裏側のDBサーバーと通信する構成が一般的でした。
Linuxカーネル（1991）の登場とGNU/Linuxの普及で、オープンソースソフトウェアが「趣味」から「産業基盤」へ。これはかなり大きな転換点ですね。
ドットコムバブル（1995〜2000）でWebに関わるエンジニアの需要が爆発。「HTMLが書ける」だけで高給が得られた時期もあったそうです。ソフトウェアエンジニアが「花形職業」になり、シリコンバレーの成功物語が世界に広まりました。
2000年問題（Y2K）で、社会がソフトウェアにいかに依存しているかが可視化されたのも印象的です。COBOLプログラマが緊急招集されたという話は有名ですよね。
この時代の言語
- Java（1995）: 「Write Once, Run Anywhere」。JVMによるプラットフォーム非依存。エンタープライズの標準に
- JavaScript（1995）: Brendan Eichが10日で設計。ブラウザ上で動く唯一の言語として、後に世界で最も広く使われる言語に
- Python（1991）: 読みやすさ重視。当初はニッチだったが、後にデータサイエンス・MLで爆発的に普及
- PHP（1995）: 「Personal Home Page」の略。Webの動的ページ生成で圧倒的シェア。WordPressの基盤
- Ruby（1995）: 松本行弘が設計。「プログラマの幸福」を重視。後にRails（2004）で一世を風靡
1995年、すごい年ですよね。Java、JavaScript、PHP、Rubyが全部この年に生まれています。
6. 2000年代: アジャイル、クラウド、モバイルの胎動
アジャイル宣言以降、Scrumに代表される反復型開発プロセスが主流に（出典: Wikimedia Commons, CC BY-SA 4.0）
アジャイル宣言（2001）。ウォーターフォールへの反動として、短いイテレーションで動くソフトウェアを届ける方法論が体系化されました。17人のソフトウェア開発者がユタ州Snowbirdのスキーリゾートに集まって宣言を出したんですが、これが業界全体を変えることになります。
ドットコムバブル崩壊（2000〜2001）後、生き残った企業がWeb 2.0を牽引。Google, Amazon, Facebookが台頭し、大規模分散システムの技術が急速に発展しました。MapReduce（2004）、BigTable、Dynamoなど。
Amazon Web Services（2006）の登場でクラウドコンピューティングが始まり、iPhone（2007）でモバイルアプリ開発が新しい領域に。Git（2005）はLinus Torvaldsが2週間で作ったという話が有名ですが、分散バージョン管理がOSS開発を一気に加速させました。
ソフトウェアが「すべての産業のインフラ」になり始めた時代ですね。銀行、小売、メディア、交通——あらゆる業界がソフトウェアに依存するようになりました。スタートアップ文化が隆盛し、少人数のエンジニアチームが巨大な価値を生み出せることが証明されたのもこの頃です。
この時代の言語
- C#（2000）: MicrosoftのJava対抗。.NETエコシステムの中核
- Go（2009）: Googleが開発。並行処理の簡潔さとコンパイル速度。クラウドインフラの標準言語に
- Scala（2004）: JVM上の関数型+OOP。Sparkの実装言語として大規模データ処理で普及
- Ruby on Rails（2004）がWebアプリ開発の生産性を劇的に向上。「15分でブログを作る」デモが衝撃を与えた
7. 2010年代: DevOps、マイクロサービス、データの時代
2013年に登場したDockerがコンテナ技術を普及させ、2014年にはKubernetesがオープンソース化（出典: Wikimedia Commons, Apache License 2.0）
DevOpsの普及で開発（Dev）と運用（Ops）の壁が壊れ、CI/CDパイプラインで継続的にデプロイする文化が広まりました。
マイクロサービスアーキテクチャでモノリスを小さなサービスに分割し、独立してデプロイ可能にする。Netflix、Uberが先駆ですね。Docker（2013）とKubernetes（2014）で「どこでも同じように動く」環境が標準化されました。
データエンジニアリングが独立した専門領域になり、Hadoop → Spark → クラウドデータウェアハウス（BigQuery, Redshift, Snowflake）と進化。機械学習が研究室から実用へ移り、TensorFlow（2015）、PyTorch（2016）が登場。「AIエンジニア」という職種が生まれました。
Marc Andreessenの「Software is eating the world」（2011）。この言葉が本当に現実になった時代ですね。GAFA/FAANGが世界の時価総額トップを独占し、ソフトウェアエンジニアの報酬が高騰しました。
とはいえ、テック企業の社会的影響力への懸念も出てきた時代でもあります。プライバシー、独占、アルゴリズムによる差別など。
この時代の言語
- TypeScript（2012）: JavaScriptに静的型付けを追加。大規模フロントエンド開発の標準に
- Rust（2010, 1.0は2015）: メモリ安全性をコンパイル時に保証。C/C++の代替として注目
- Swift（2014）: AppleがObjective-Cの後継として設計。iOS開発の標準
- Kotlin（2011, 1.0は2016）: JetBrainsが開発。Android開発の公式言語に
- Pythonがデータサイエンス・MLの爆発的成長に乗って「最も人気のある言語」の一つに
8. 2020年代前半: 生成AIの衝撃
2022年11月に登場したChatGPTが社会現象に（出典: Wikimedia Commons）
COVID-19（2020）でリモートワークが一気に標準化。非同期コミュニケーション、ドキュメント文化の重要性が増しました。
そしてGitHub Copilot（2021）の登場。AIがコードを補完する体験が初めて実用レベルになりました。ChatGPT（2022年11月）が社会現象になり、プログラミングの敷居が劇的に下がった。Claude, Geminiなど競合LLMの登場。コーディングエージェント（Cursor, Devin, Claude Code）が実用化。
正直、この数年の変化のスピードはすごいですよね。
テックバブルの調整（2022〜2023のレイオフ）で「エンジニアなら無条件に高給」の時代が終わりつつある一方、AIを使いこなせるエンジニアの需要は増加。「AIで生産性が10倍になるエンジニア」と「AIを使えないエンジニア」の格差が拡大しているように感じます。
通史から見える構造的パターン
ここまで70年を駆け抜けてきましたが、振り返ると面白いパターンが見えてきます。
パターン1: 抽象化の階段を登り続けている
配線 → 機械語 → アセンブリ → C → Java → Python → 自然言語プロンプト
各段階で「下のレイヤを意識しなくてよくなる」んですが、下のレイヤが消えるわけではないんですよね。
各時代で新しい抽象化が生まれるたびに、「もう○○は不要になる」と言われてきました。アセンブリが出たとき「機械語は不要に」、Cが出たとき「アセンブリは不要に」、Javaが出たとき「メモリ管理は不要に」。でも下のレイヤは消えなかった。むしろ、抽象化が進むたびに「ソフトウェアで解ける問題」の範囲が広がり、エンジニアがやれることは増え続けています。需要が減るどころか、新しい抽象化のたびにエンジニアの活躍の場は拡大してきたんですよね。
パターン2: 「コードを書く」の比重は一貫して下がっている
配線の時代は100%が「実装」でした。構造化プログラミングで「設計」が分離され、アジャイルで「何を作るか」の判断が重視され、今AIが「実装」をさらに自動化している。「問題定義 > アーキテクチャ判断 > 実装」の優先順位は、歴史的に見ても一貫した方向性ですね。
パターン3: 新しい言語は「人間の不便を解消する」ために生まれてきた
| 言語 | 解消した不便 |
|---|---|
| FORTRAN | 数式を直接書きたい |
| C | アセンブリより生産的に |
| Java | プラットフォーム非依存に |
| Python | 読みやすく |
| TypeScript | JSに型を |
そしてAIが「人間の不便」を吸収し始めた今、新言語を作る動機自体が変質しつつあるように感じます。
パターン4: 社会的位置づけの変遷
ソフトウェアエンジニアが社会からどう見られてきたかも、一貫した方向性がありますね。
- 1950年代: 配線工・計算手。事務的な裏方仕事
- 1960〜70年代: 専門技術者。社会的にはニッチで地味な存在
- 1980年代: 「ギーク」「オタク」。職業としては認知されたが華やかさはない
- 1990年代: 花形職業。ドットコムバブルでシリコンバレーの成功物語が広まった
- 2000〜2010年代: 社会インフラの担い手。あらゆる産業がソフトウェアに依存するようになった
- 2020年代〜: AIとの協働者。「AIに仕事を奪われる」と言われつつ、AIを使いこなせるエンジニアの需要は増加
面白いのは、社会的な評価が上がるたびに、エンジニアに求められるものも「技術力」から「判断力」へとシフトしていることですね。配線工に判断力は求められなかったけど、社会インフラの担い手には求められる。この流れは今後も続くと思います。
9. 未来の展望: 自分が思い描く2030年代のソフトウェアエンジニア
ここからは歴史の話ではなく、ここまでのパターンを延長した自分個人の展望です。当たるかどうかはわかりませんが、70年の流れを踏まえると、こんな方向に進むんじゃないかなと思っています。
9-1. 「コードを書く」は前提条件になるんじゃないか
読み書きと同じですね。できないと困るが、それだけでは差別化にならない。ちょうど「Excelが使える」が90年代は強みだったが今は前提なのと同じ。
コーディングスキルが不要になるのではなく、それだけでは足りなくなるんじゃないかと思います。AIの出力を正しく評価するには、基礎的なCS知識とドメイン理解の両方が必要なので。「AIがあるから基礎は不要」は個人的にはかなり危険な誤解だと感じていて、むしろ基礎がないとAIの出力の良し悪しが判断できないんですよね。
9-2. エンジニアの仕事は「判断」に集約されていくんじゃないか
AIは「与えられた問題を解く」のは得意ですが、「何が本当の問題なのか」を見極めるのは苦手だと感じています。もしそうなら、以下の領域の重要性が増していくはずです。
- 問題の発見と定義 — ビジネス上の曖昧な課題から、技術で解くべき問題を切り出す力。ステークホルダーの言語化されていないニーズを汲み取る力。「そもそもこれは作るべきか？」という判断。プロンプトを書く前段階の思考こそが、エンジニアの最も重要な仕事になっていくんじゃないかと
- アーキテクチャ判断と技術的意思決定 — トレードオフの評価（整合性 vs 可用性、開発速度 vs 保守性など）。組織の規模・チーム構成・事業フェーズを踏まえた技術選定。これらは正解が一つではなく、制約条件が暗黙的で、かつ時間とともに変化するので、AIが自律的に判断するのは当面難しいと思います
- AIの出力を評価・修正する力 — 生成されたコードのセキュリティリスクやエッジケースを見抜く。AIが自信満々に出す「もっともらしいが間違った」回答を検出する
- 運用と障害対応の「勘所」 — ログやメトリクスの断片から仮説を立て、影響範囲を見積もり、対処の優先順位を決める。不完全な情報下での意思決定とリスク受容
- 倫理的判断とアカウンタビリティ — AIが生成したコードであっても、デプロイした責任はエンジニアと組織にある
Ajey Goreの言葉を借りれば：
「専門知識がほぼ無料になったとき、"正しさの定義"が最も高価になる」
88%の企業がAIを使っているが、実際に成果を出しているのはわずか6%という調査もあります。これが事実なら、技術導入のギャップではなく組織設計のギャップなのかもしれませんね。
9-3. スキルの重要度が再編されるかもしれない
自分の見立てでは、スキルの価値は以下のように変化していくと思います。
より重要になりそうなスキル:
- 問題定義・要件策定力
- アーキテクチャ設計・技術的意思決定
- AIの出力を評価・修正する力
- 運用・障害対応の経験的推論
- コミュニケーション・組織への働きかけ
- 倫理的判断・アカウンタビリティ
差別化要因ではなくなりそうなスキル:
- コーディング自体（読み書きと同じ前提条件に）
- 定型的な実装作業（CRUD、ボイラープレート等）
- 特定言語・フレームワークの文法暗記
一言でまとめると: 「何を・なぜ作るか」を決める力と「AIの出力を正しく評価する力」の重要性が増し、「どう書くか」の実行部分は前提条件に近づいていくんじゃないかと。
9-4. 言語の多様性は「見えなくなる」かもしれない
「すべてを塗り替える1つの言語」が実現するとしたら、それは従来の意味での「プログラミング言語」とは別物になるんじゃないかと思っています。人間が触る表層が1つに統一され、裏側の多様性はAIが隠蔽する——統一は「言語レベル」ではなく「インターフェースレベル」で起きるんじゃないかなと。
自然言語の歴史との対比が示唆的ですね。自然言語が新しく生まれなくなった最大の理由は「全員がつながった」こと（隔離の消滅）。プログラミング言語の「隔離」に相当するのはドメインの技術的制約であり、AIがドメイン間の違いを隠蔽できるようになれば、プログラミング言語も似た道をたどるかもしれません。
9-5. 新しい「ソフトウェア危機」が来るんじゃないか
個人的に最も気になっている予感がこれです。
- 1960年代: ハードウェアの能力にソフトウェア開発が追いつかなかった → NATOソフトウェアエンジニアリング会議（1968）
- 2030年代: AIの生成能力に人間の検証能力が追いつかなくなる → ???
AIが1週間分のコードを一度に生成できるようになったとき、それを検証する方法が追いついていなければ、1960年代のソフトウェア危機と構造的に同じ問題が再び起きるんじゃないかと。
もしそうなるなら、解決策も1960年代と同じ方向になるでしょう: 工学的な規律。ただし今度は「コードを書く規律」ではなく「AIの出力を検証する規律」。
この文脈で、Ajey Goreが提案している戦略は参考になると思います:
- 自動化する前に「正しさ」を定義せよ — 成功基準、テストインフラ、早期に失敗を検知するフィードバックループに時間を投資する
- 実行ではなく検証を中心に組織を再編せよ — 10人のエンジニアでフィーチャーを作っていたチームが、3人のエンジニア＋7人の受入基準定義・テスト設計・アウトカム監視担当になる
- 判断力のレイヤーを構築せよ — 答えが自明でないときに「良い」を定義できる人材に投資する
- スピードを過信するな — 正しさなきスピードは、より速い失敗に過ぎない
展望
最後に、この記事で一番伝えたかったことをまとめます。
70年間、エンジニアの仕事は「配線」から「判断」へと移り続けてきた。
AIはその最新の一歩であり、最後の一歩ではない。
恐れるべきは「AIに仕事を奪われること」ではなく、「抽象化の階段を登り損ねること」。
1945年のENIACプログラマたちは、自分たちの仕事が「配線」から「コードを書く」に変わることを想像できなかったでしょう。1970年代のCプログラマは、自分たちの仕事が「メモリ管理」から「ビジネスロジック」に変わることを想像できなかった。
自分たちも同じ転換点にいると思います。コードを書く時間は減る。でもソフトウェアエンジニアリングの本質——問題を見つけ、構造を設計し、正しさを定義し、責任を持つ——は変わらない。
むしろ、それだけが残るんじゃないかなと。
そもそもエンジニアって何なんだろう、と考えてみると、自分は**「無機物と有機生命体をつなぐ架け橋」**だと思っています。石器を削った人も、蒸気機関を設計した人も、コードを書く自分たちも、やっていることの本質は同じで——人間が道具を使って世界を変えるための橋渡しをしている。
配線がコードになり、コードがプロンプトになり、その先がどうなるかはわかりません。でも、人間が道具を使う限り、その間をつなぐ存在は永遠に必要なんですよね。手法は変わっても、エンジニアという役割がなくなることはない。
70年の歴史が教えてくれるのは、結局そういうことなんじゃないかなと思います。
参考文献
記事中で直接言及した一次資料
- Fred Brooks『人月の神話』（1975, 増補版1995）— 2章: OS/360の経験
- Edsger Dijkstra「Go To Statement Considered Harmful」（1968）— 3章: 構造化プログラミング
- Winston Royce「Managing the Development of Large Software Systems」（1970）— 3章: ウォーターフォールの起源
- Ajey Gore「The Expensive Thing」（2026）— 9章: 判断力の価値
- Marc Andreessen「Why Software Is Eating The World」（2011）— 7章
- Ken Thompson「Reflections on Trusting Trust」（1984, チューリング賞講演）
歴史的事実の参照元
- ENIAC Programmers Project — 1章: 女性プログラマの歴史
- NASA「Margaret Hamilton, Apollo Software Engineer」— 2章: アポロ計画
- Agile Manifesto（2001）— 6章
- Software Engineering at Google（無料公開）— 通史の補助資料