> [!abstract] 概要 > ソフトウェア工学史家 Michael S. Mahoney による短編の歴史論考。1967年に「ソフトウェアエンジニアリング」という語が NATO の会議のために意図的に挑発的な語として選ばれた経緯を出発点に、なぜ当時の実務家たちがこの語を必要としたのか(1950年代の商用化以降、プログラマ人口が急増し、設計とプログラマ管理という新しい問題が生じたこと)を跡づける。そのうえで、ソフトウェア工学を語る際に暗黙に持ち込まれてきたモデル ── Taylor の科学的管理法、Ford の組立ライン、機械工具産業における互換部品への「収斂(convergence)」 ── を検討し、それらのモデルがなぜソフトウェア生産にそのまま移植できなかったかを分析する。結論として、1990年時点のソフトウェア工学は制度としての体裁を備えながらも定義上の進展に乏しく、その理由を「借用した起源から抜け出せていないこと」に求める。 ## 出典情報 - **著者**: Michael S. Mahoney(プリンストン大学) - **発表媒体**: *CWI Quarterly* 3, 4 (1990), 325–334 - **原型**: 1990年2月1日に CWI(オランダ国立数学・情報科学研究所)で行われた講演の拡張版。Alfred P. Sloan Foundation の助成による、1950–1970年の計算機産業史・「ソフトウェア危機」の起源に関する研究の一部 - **文献**: `[[.raw/papers/the-roots-of-software-engineering-2z5l02wq11.pdf]]`(全10ページ) ## 論考の骨格 ### 1. 方法論的立場: 実践としての歴史 冒頭は Mahoney 自身の議論というより方法論的な導入である。R.W. Hamming が1976年の Los Alamos 計算機史会議で掲げた課題「We Would Know What They Thought When They Did It」を引き、「名前・日付・初出の羅列」ではなく実践の文脈的発展を追う歴史記述を求める。Kuhn の『科学革命の構造』に触れつつ、科学の実践と科学の文献は一致しないという立場を採る ── パラダイム(disciplinary matrix)が導くのは科学者が「言うこと」ではなく「行うこと」であるため、過去の科学のパラダイムを見定めるには実践を観察しなければならない。技術史ではこれがさらに強く当てはまるとし、Derek Price の言葉を借りて「発明家・エンジニアは指先で考えてきた(thought with their fingertips)」── その思考の記録はテキストではなく設計された人工物に残る、とする。 計算機の歴史については二重の意味でこの点が特に強く働くとされる。第一に、計算機の主目的は「何かをする」ことであり、成功した実践こそが有効な理論の第一の尺度だった。第二に、計算機は「思考すること」を行う最初の機械であり、思考と行為の歴史的に類例のない結びつきを体現する。 ### 2. 「ソフトウェアエンジニアリング」の起源(1967年) Mahoney は1950–1970年の計算機産業史・「ソフトウェア危機」の起源を対象とする自身の進行中の研究の一部として、人々が最初に「ソフトウェアエンジニアリング」という語で何を意味しようとしていたかを検討する。語の起源には諸説あるが(J.P. Eckert が1965年のFall Joint Computer Conferenceで使ったとする説、D.T. Rossが1950年代末のMITの講義で使っていたとする説)、一般に流通し始めたのは1967年、NATO Science Committee の Study Group on Computer Science が国際会議を招集した際である。会議記録の編者 [[Peter Naur]]・[[Brian Randell]] は序文で「'software engineering' という語句は、ソフトウェア製造が既存の工学分野に伝統的な理論的基盤と実務的規律に立脚すべきだという含意を持つ、意図的に挑発的な語として選ばれた」と明言している。 しかし、この語が何を挑発しようとしたのかは当時から明確ではなかった、と Mahoney は指摘する。「既存の工学分野に伝統的な理論的基盤と実務的規律」とは具体的に何を指すのか。ソフトウェア工学における対応物はどのような姿になるのか。工学は製造(manufacture)においてどのような役割を担うのか。NATO Study Group は「ソフトウェアは製造できる」という前提には答えたが(実質的にYesと考えていた)、他の問いには明確な答えを与えなかった。工学そのものの捉え方についても、応用科学とみなす立場、設計技法の体系とみなす立場、組織・管理の問題とみなす立場が並立し、それぞれが暗黙のモデルと基準点を持っていた。 論点として重要なのは、1967年当時「ソフトウェアエンジニアリング」を定義できなかっただけでなく、その実践を指し示すこともできなかったという事実である。**語は進行中の活動を特徴づけるために作られたのではなく、そうした活動への希求(desire)を表現するために作られた**。1967年、計算機産業がまだ20年に満たない時点で、人々はソフトウェアエンジニアリングを「必要」と感じていたが、それが何であるかは分かっていなかった。 ### 3. なぜ必要とされたか: 計算機商業化とプログラマ人口の急増 なぜこの「奇妙な」希求が生じたのかを説明するため、Mahoney は計算機の起源に遡る。電子デジタル・ストアドプログラム計算機は、19世紀初頭に遡る2つの独立した発展系列 ── 自動操作可能な機械式計算器の設計と、数理論理学の発展 ── の**収斂**として現れた。この2系列は「合流」であって「偶然の一致」ではないという見方を取ることで、計算機が電気工学と理論数学の共同生産物であり、両分野の専門知が機械の中で交差し命令セットの上で重なり合っていたことが強調される。数理論理学者は Turing 機械のモデルで、特定の機械から独立した計算可能性の問題に関心を持ち、電気技術者は特定の入出力に対するスイッチング回路の合成・最適化に集中していた ── いずれもプログラミングを自らの本業に付随するものとみなしていた。数値解析者だけは計算機を自らの主題の一部として受け入れ、プログラミングを自らの仕事の一部とした。 1953年時点でイギリスの計算機台数が150台に達したとき、Ferranti社の B.V. Bowden(*Faster than Thought* 編者)はプログラミングの困難・非効率の増大に懸念を示した数少ない例外だった。Bowden は「多くの機械が稼働時間の半分をプログラムの検査とバグ発見に費やし、単純な計算に使われるのはせいぜい3分の1にすぎない」と指摘し、「機械が1000倍速くなっても、総出力は50%程度しか増えないだろう」という結論を導いた。しかし計算機が本質的に科学装置にとどまっていた間、この懸念はほとんど反響を呼ばなかった。 転機は1950年代初頭の計算機の**商業化**である。商業化とともにハードウェアが急速に進歩し(高速プロセッサ・大容量メモリ・高効率周辺機器)、マーケティング部門の想像力も同じ速さで拡張した。当初、誰が製品を実際に使えるプログラムを書くのかを気にする者はほとんどいなかった ── IBM でさえ「プログラマ」を職種として認め、キャリアトラックを作ったのは1950年代末になってからである。 企業はやがて、会計部門を縮小した代わりに際限なく肥大化するデータ処理部門を作り出したことに気づいた(あるいは、これも同様に肥大化する計算機サービス会社に依存することになった)。このプロセスは1950年代末に始まり、1968年までに約500社がソフトウェアを生産し、それらの企業と関連企業がおよそ10万人のプログラマを雇用し、さらに5万人の需要を広告していた。1970年にはその数はおよそ17万5000人に達した。この過程でプログラムは二重の意味で「ソフトウェア」となった ── 第一に、生の機械を実用アプリケーション生産のための道具に変換する一群のプログラム(アセンブラ・モニタ・コンパイラ・OS等)が形をなしたこと。第二に、プログラムが科学者でも数学者でも電気技術者でもない人々による生産の対象になったことである。 ### 4. ソフトウェアプロジェクトの巨大化がもたらした2つの新要素 ソフトウェアプロジェクトの規模拡大は、プログラミングに2つの新しい要素を持ち込んだ。第一は**設計と実装の分離**であり、これは(しばしば大規模な)プログラムを実際に書く前に設計する技法と、その設計をプログラマ群に伝達する手段への需要を生んだ。第二は**プログラマの管理**であり、プログラマの仕事の質を測定・統制する手段への需要を生んだ。1960年代の多くの成功にもかかわらず、実務家・管理者は一様に、こうした需要が満たされていないと認めていた。誰もが自分の「恐怖譚」を持っていた ── [[Fred Brooks]] は『人月の神話』(*The Mythical Man-Month*, 1975)としてそれを後に出版し、C.A.R. Hoare は1980年のチューリング賞講演「The Emperor's Old Clothes」でそれを語った。 ### 5. ソフトウェア危機の実相: F.L. Bauer の不満リスト こうした逸話の背後にあった共通認識を、Mahoney は [[F.L. Bauer]] が IFIP 71 での報告「Software Engineering」で挙げた不満リストで示す。 > - 既存のソフトウェア生産はアマチュアによって行われている(大学であれ、ソフトウェアハウスであれ、メーカーであれ) > - 既存のソフトウェア開発は場当たり的な試行錯誤(大学)、あるいはメーカーでは「人海(million monkey)」方式で行われている > - 既存のソフトウェアは信頼性が低く、恒常的な「保守」を必要とする。この「保守」という語は、生産者が最初から予期していた欠陥を指すのに誤用されている > - 既存のソフトウェアは乱雑で透明性を欠き、改良や積み増しを妨げる(少なくとも法外な代償を要求する) > - 既存のソフトウェアは期待より遅く、高いコストで届き、約束された機能を満たさない Bauer はこの報告の抄録で半ば冗談めかして「ソフトウェアエンジニアリングは今日よく理解されているようだ ── 対象そのものはともかく、少なくともその語は。実用上の定義としては、ソフトウェアエンジニアリングとはコンピュータサイエンティストには手に負えないほど困難なコンピュータサイエンスの部分である」と述べた。一方で真面目な定義として「経済的に、信頼性が高く実機上で効率的に動作するソフトウェアを得るための、健全な工学原理の確立と適用」を提示し、さしあたり産業工学(industrial engineering)のモデルで進めることを提案した。 当時の計算機科学(それが何であれ)にはプロジェクトマネジメントに類するものがまったく含まれておらず、John McCarthy らが1960年代初頭に力説したプログラミング理論の欠如とはまた別に、プログラマとプログラミングプロジェクトの実証的研究(彼らを支配する法則を確定する研究)も存在しなかった。伝統的にこれらは科学者ではなく技術者の関心事だった ── 特にアメリカの技術者は、世紀転換期以来、管理責任への準備を含む訓練を受け、同じく世紀転換期以来、効率的生産の組織化に関する優れた洞察を主張してきた。 ### 6. アメリカ工学の遺産: Taylor と Ford [[Edwin Layton]] が『The Revolt of the Engineers』で示したように、この主張はアメリカの機械工学の特有の遺産と、大量生産・組立ラインに結びついた機械産業の進歩に由来する。アメリカのソフトウェア工学思考の根底には、機械工場(machine shop)のイメージと言語が響いている。 例えば [[M.D. McIlroy]] が Garmisch の NATO 会議(1968年)で参加者に「大量生産されたソフトウェア(Mass-produced software)」を訴えたとき、彼は工学と管理の両面にわたるモデルの蓄積を引いていた。McIlroy は「我々は間違いなく後進的な技法でソフトウェアを生産している。ハードウェア屋との対決で割を食うのは、彼らが工業家で我々が小作人だからだ」と述べ、ソフトウェア生産の産業化の度合いは後進的な建設産業よりも下にあり、本来はもっと高い位置にあるべきだとして、ソフトウェアにおける大量生産技法の可能性を検討すると宣言した。彼は続けて「大量生産技法」という語句における力点は「技法」にあり、単純な大量生産(プロトタイプの無制限な複製)ではないと注記した ── サブアセンブリの発想はそのまま転用でき、互換部品の発想は「モジュール性」の語に大まかに対応し、機械工具の発想はアセンブラ・コンパイラに類似物を持つ。しかし、大量生産の他の有形の象徴 ── 標準部品のメーカー、標準部品のカタログ、個別仕様(サイズ・耐久性・速度・容量・精度・文字集合)に応じた部品の注文 ── の類推は成り立たない。 McIlroy が選んだモデルの説得力は、アメリカの機械工具産業史の研究が示す通り強力だった。1820年から1880年ごろにかけて、機械工具技術の進歩は日常的な工場精度を0.01インチから0.0001インチへと向上させた。経済学者 Nathan Rosenberg が「収斂(convergence)」と呼んだ過程を通じて、機械工具メーカーは特定顧客向けに開発した新技法を自社の汎用工具へと転用する術を学んだ ── 例えば撃発装置(percussion lock)の加工需要が垂直タレット旋盤の開発を導き、それがネジや小型精密部品の生産に転用され、さらに自動タレット旋盤へと発展した、という具合である。精度と自動操作の各進歩は、機械工の技能を機械の設計へと移し替えることで、より厳格な管理を可能にした。19世紀末に向かうにつれ、労働者はますます厳密な事前規定された標準に従わざるを得なくなった ── その標準が生産の道具そのものに組み込まれていたためである。この流れは、互換性に必要な公差通りに自動的に部品を生産する Ford の生産機械で頂点に達した。 McIlroy が知っていたように、大量生産は技法であると同時に管理の問題でもあった。個々の機械の洗練だけでなく、それらを連結・秩序づける**システム**こそがアメリカ産業を変貌させた。この変貌には2人の人物が大きく立ちはだかる ── **Frederick W. Taylor**(「科学的管理法」、近代マネジメントサイエンスの先駆)と**Henry Ford**(組立ライン)である。 しかし Garmisch会議で明らかになった事情に照らすと、Taylor の基本原理自体が彼のモデルのソフトウェア生産への適用可能性に疑問を投げかける。Taylor によれば管理の第一の義務は達成すべき課題の科学的基盤を確定することであり、それは次の4つの主要な職務に帰着する。 > 1. 経験則を置き換える、労働の各要素ごとの科学を確立すること > 2. 労働者が自ら仕事を選び自己流で訓練していた過去に代え、科学的に労働者を選抜・訓練・教育・育成すること > 3. 開発された科学の原理に従ってすべての作業が行われるよう、労働者と心から協力すること > 4. 管理と労働者の間で仕事と責任をほぼ均等に分担すること(過去には仕事と責任の大部分が労働者側に押し付けられていたのに対し、管理側は自らがより適した作業をすべて引き受ける) 計算機科学がソフトウェア生産における経験則をどこまで置き換えられるかは、まさに NATO 会議群で争点となった問題であり、楽観論者でさえ進展は遅いことを認めていた。第一の義務を果たせない以上、プログラミング管理者は第三の義務を遂行する立場にもなかった。ソフトウェアの品質標準の欠如は誰もが嘆く事態だった。第四の義務についても、大規模プログラミングプロジェクトで誰が何をするのに最も適しているかを言い切る者はほとんどいなかった。 1969年までに、プログラマの選抜・訓練に関する管理標準の確立の失敗は既に知れ渡っていた。ソフトウェアハウス経営者の一人 Dick H. Brandon が指摘したように、業界全体としてプログラマの職務の最も一般的な仕様にすら合意がなく、プログラミング未経験者を採用せざるを得ない管理者が頼れる適性検査はきわめて疑わしい1種類しかなく、採用後の訓練方法も誰も確信を持って知らなかった。Taylor は生産性を管理と労働者の五分五分の取り組みだと強調したが、1960年代の(何であれ)マネジメント科学は、(何であれ)計算機科学がいまだ確立できていないもの ── ソフトウェア生産の科学的基盤 ── を供給できなかった。 Taylor の手法で組織化できなかったものは、なおのことアメリカのもう一つの主要な生産性モデル ── Ford の組立ライン ── の射程外にあった。Ford方式の本質的特徴は、技能を労働者から生産の機械へと移し替えることにある。労働者は単にその機械に付き従うだけで、生産の質・量に対する統制権を持たない。それを決めるのは生産の機械である。ソフトウェア生産をフォード化するということは、自動機械の計算機類似物を提供することを意味し、したがって信頼性の設定標準を満たすソフトウェアを生成するソフトウェアシステムを設計しなければならないことを意味する。McIlroy が「大量生産されたソフトウェア」と語ったとき、彼は Ford のモデルの言語を話していた。 品質管理は Ford システムのもう一つの特徴だった ── 彼の機械は部品の完全な互換性のために0.0001インチの精度を保証した。McIlroy が擁護していた計算機類似物は、生産の問いを再び計算機科学の本質の問いへと連れ戻す。NATO 会議の一部の参加者はソフトウェア設計を実験として捉えていた ── プログラムを書き、計算機にかけ、デバッグを始める(Ford の言葉を借りれば「ひっくり返して、なぜ動かないか見てみよう」)。この見方に立てば、プログラミングは信頼性を許容誤差(tolerance)の観点で捉える実験科学・工学のように見える。しかし [[Edsger W. Dijkstra]] はこれとまったく異なる立場を熱烈に主張した ── 「プログラムテストはバグの存在を明らかにするために使えるが、その不在を示すためには決して使えない」。プログラミングは数学を志向すべきであり、すなわちプログラムの正しさを数学的に検証する手段を追求すべきである、というのが Dijkstra の立場である。バグの不可避性を受け入れそれを見つけるための入念なテストを考案するのではなく、プログラムが正しく動作することを証明すべきだ、とし、そうした証明の手段を「構造化プログラミング(structured programming)」と呼び、その構造をプログラミング言語とコンパイラに組み込もうとした。Ford の手法に目を向けて生産性の問いに応じていたのは、数学志向の計算機科学者たちだった。 ### 7. 10年後の検証: 「ソフトウェア危機」から「ソフトウェア不況」へ 過去10年間のソフトウェア工学文献の調査から、この分野の3つの顕著な特徴が浮かび上がる。第一に、ソフトウェア工学を生んだ問題群は大部分未解決のままである。NATO会議から10年後、R.W. Floyd は1978年のチューリング賞講演で Robert Balzer の言葉を引いた ── 「ソフトウェアは意気消沈した状態にあることはよく知られている。信頼性が低く、届くのが遅く、変化に無反応で、非効率で、高価である。さらに労働集約的であるため、需要が増しコストが上がるにつれ事態は悪化するだろう」。これに Floyd はこう付け加えるほかなかった ── 「これが10年ほど前の有名な『ソフトウェア危機』のように聞こえるなら、我々が10年から15年もの間同じ状態にあり続けているという事実は、『ソフトウェア不況(software depression)』のほうがより適切な語であることを示唆する」。同様の表現は今日のソフトウェア文献のどこにでも見つかる。 実際、ACM の *Software Engineering Notes* の号を開けば、ソフトウェアシステムの失敗 ── 生命・身体・財産・金銭・時間の損失を含む ── を列挙する新規項目のリストがそのまま示している。ソフトウェアに日常的に付随する免責条項は、ソフトウェア工学が「既存の工学分野」からいかに遠いかを物語る。 このように、学会・雑誌・カリキュラム・研究機関という確立された学問分野の外形を備えながらも、ソフトウェア工学は比較的「柔らかい(soft)」概念のままである。定義はあまり変わっていない。近年の一版(Watts Humphrey, 1989)は「品質の高いソフトウェアの経済的な生産のための、工学・科学・数学の原理と手法の規律ある適用」と述べる。この定義の意味は、その中心的な語 ── ソフトウェア生産に適用される工学・科学・数学のいかなる原理・手法か ── がどう解釈されるかにかかっている。 ### 8. 結論: 起源に規定され続けるソフトウェア工学 したがって、ソフトウェア工学をめぐる議論の背後には、しばしばその適用可能性をほとんど吟味されないまま、他の工学分野から借用されたモデルが存在し続けている。大半の場合、それはソフトウェア工学が新しい観念だった時代に人々の思考を形作っていたのと同じモデルである。例えば McIlroy の部品組立の発想はモジュラープログラミングとなり、次いでオブジェクト指向プログラミングとなったが、基底にあるモデルは互換部品による生産のままである。自動プログラミングはコンパイルから設計の実装へと射程を広げるにつれ意味を変えてきたが、依然として自動機械工具のモデルに立脚し続けている。 > [!key-insight] 結語 > **ソフトウェア工学はその起源からあまり進んでいない。おそらくその起源こそが理由である。**(Software engineering has not progressed far beyond its roots. Perhaps its roots are the reason.) ## 強み / 弱点・課題 **強み** - 「ソフトウェア工学」という語の起源とその意図的な挑発性を、NATO 会議編者自身の証言に基づき一次資料的に確定している。 - 語の成立を可能にした社会的条件(計算機の商業化・プログラマ人口の急増・ソフトウェア生産の非専門家化)を定量データ(500社・10万人・17万5000人)で裏づけている。 - Taylor と Ford という2つの異なる生産性モデルを分解し、それぞれの核心原理(4職務 / 技能の機械への移転)に照らして、なぜソフトウェア生産にそのまま適用できなかったかを個別に論証している点が分析として鋭い。 - 「借用モデルへの無自覚な依存」という診断は、モジュラープログラミング→オブジェクト指向という後続の展開にも同一モデルの継続として当てはめられ、射程が長い。 **弱点・課題** - 1990年時点の短編講演録であるため、Dijkstra 以降の形式手法・ソフトウェアプロセス改善(CMM 等、まさに引用されている Watts Humphrey 自身がその中心人物)がどうこの「借用モデル」枠組みに位置づくかは論じられていない。 - 「起源に規定され続ける」という結語は強い主張だが、反証可能な形での検証(借用モデル以外の独自モデルが後年生まれたか)は本論考の範囲外である。 - 脚注に依存する形での一次資料引用が多く(Bowden 1953, Taylor 1911, Brandon 1970 等)、本文だけでは各引用の文脈が薄い箇所がある。