本章では、ここまで述べられてきたソフトウェア開発で生じるさまざまな問題に対し、
その解決を図ろうとしたソフトウェア工学について、その取り組みと限界を検討する。そ の上で、ソフトウェア・ファクトリーのような開発プロセスに基づいたソフトウェア開発 がいかなる問題をもたらしうるのか、こうした問題の克服において従来の分業構造を再編 する必要があるとすればそれはどのような再編であるのか、こうした論点に対する分析的 視点および枠組みを検討する。
(1) ソフトウェア工学
ソフトウェアはコンピューターとともに発展してきており、その歴史は60年程だが、近 代化とともに大規模・複雑化し、それに対し、製造業や建築業の知見や手法を取り入れな がら発展してきた（表 7-1）。
特にハードウェア産業からの影響により、これまで手工業的で個々の技術者に任せられ がちであったソフトウェア開発は、ある程度の秩序を持つようになり、製品の品質管理、
生産性、再利用率が向上していった（妹尾, 2001; 中所, 2014）。
製造業などの手法が取り入れられた理由として、品質管理手法やソフトウェア開発の各 工程を順に追っていくWaterfall Modelに取り入れやすいことがあげられる。また、オブジ ェクト指向技術の導入とともに、建築家の著作123を例にとって、ソフトウェア・アーキテ クチャー構築のデザインパターンの研究も進んでいる（妹尾, 2001）。
コンピューターが登場して間もない第二次世界大戦後の1950年代から60年代にかけて、
ソフトウェア開発の主体は個人であった。特に初期の頃は、仕様書もないままプログラム を記述し、問題が発生したらその都度修正するような、統制や規律のない手工業的な開発 が行われていた（妹尾, 2001; 中所, 2014）。その後、コンピューターの信頼性が増すにつれ てオンラインを利用したシステムが実用化され、日本では銀行の ATM や旧国鉄の座席予 約システムなどが開発された。しかし、当時はソフトウェアを利用できる企業はそれほど 多くなく、その理由としてコンピューター本体が数億円近い高価格なものであったため、
一部の限られた企業しか導入することができなかった。
1960年代後半から1970年代に入ると、コンピューターの高性能化、大容量化に伴い、
ソフトウェアも大規模化していった。このソフトウェアの大規模化に対して、バグなどに 対する障害の防止や開発スケジュールの管理などがより求められるようになっていった。
123 Alexander他（1983）『パタン・ランゲージ―環境設計の手引』（邦訳）。建築分野の設計
において、問題と解決方法を数百種類のパターンに識別し、再利用しようと試みた。
表 7-1 ハードウェア・ソフトウェア開発環境の変化
年代 ハードウェア・環境の変化 ソフトウェア開発への影響
1950年
代～ コンピューターの登場
ソフトウェア創世記。
ソフトウェアの開発の主体は個人。仕様書もな いままプログラムを記述し、問題点は都度修正 する、統制や規律のない手工業的な開発手法。
1970年 代～
コンピューターの高性能・大容量 化
ソフトウェアの大規模化、複雑化。
個人の手工業的な開発手法では耐えられなくな り、品質（バグ等の障害の防止）やスケジュー ルを管理していく必要性が発生。
1990年 代～
コンピューターのダウンサイジン グ・高性能化（PC）・ネットワー クの普及
PCやインターネットの普及により、ユーザーの ソフトウェアの利用が活発化。
開発期間の短期化と外部との関係の緊密化が求 められるようになった。
2010年 代～
インターネットの高速・大容量化、
クラウドサービスの普及 スマートフォンの普及
クラウドを利用したソフトウェアサービスの利 用が増加。
業務と情報技術の一体化の組織的・体系的取り 組みが求められるようになった。
出所：妹尾（2001）, 立川（2003）, 古殿（2006）, 野田（2006）, 島田・高原（2007）を もとに筆者作成。
このソフトウェアの開発過程を構造化して管理するフレームワークとして、ソフトウェ ア工学124が存在する。本節では、このソフトウェア工学の役割と、日本におけるソフトウ ェア工学の取組みについて検討する。
124 Software Engineering。1968年にNATOがソフトウェア・エンジニアリング会議を開催し
た。会議ではコンピューターの高性能化とソフトウェアの複雑化からソフトウェア危機
（software crisis）が叫ばれ、その対応としてソフトウェア開発を工学的な観点から方法論 や開発論を整備することが必要だとされた。日本でソフトウェア工学の導入が強く求めら れたのは、それから10年以上経過した1980年頃となる（Tomayko and Hazzan, 2004; 中所, 2014）。
① ソフトウェアの複雑化と危機
1968年にNATOが開催したソフトウェア・エンジニアリング会議で、コンピューターの 高性能化とソフトウェアが複雑化していくことの問題についてソフトウェア危機が提唱さ れ、将来のソフトウェア開発に対する危機意識が高まり、ソフトウェア工学の重要性が認 識された。ソフトウェア工学は、ソフトウェア開発の工程を細分化することによってそれ ぞれの工程を定量化しようとする試みである（野田, 2006）。1968年当時のソフトウェアは 急速に拡大、複雑化していたため、将来的に技術者の不足と従来の手工業的な開発手法で は限界が来ることから、ソフトウェア工学の必要性が高まっていた。
ソフトウェア工学が誕生したことで、工程アーキテクチャーに基づいてソフトウェアの 開発プロセスは工程ごとに分離して厳格に管理されるようになっていった。
1970年頃のコンピューターメーカーは、ロックイン戦略を採用しており、一度あるコン ピューターメーカーのハードウェアとそれに合うソフトウェアを導入すると、そのユーザ ーはそのソフトウェアを継続的に使用せざる得ない状況となっていた。これにより、IBM や日本の富士通、NEC、東芝といったコンピューターメーカーは、そのユーザーと独占的 に取引することができ、安定的な利益の確保が期待されていた（高橋, 2010）。
しかし、このような特定のハードウェアのために開発されたソフトウェアは、他のメー カーのハードウェアで使用できないため、各メーカーのハードウェアに適合するソフトウ ェアをそれぞれ開発しなければならず、独自のソフトウェア製品の開発への障害ともなっ ていた。
1990年代になると、コンピューターのダウンサイジング、パーソナルコンピューターの 高性能化、ネットワークの普及が進んだ。特に2000年以降は、インターネットが爆発的に 普及したことにより、ユーザーのソフトウェアの利用が活発化している。技術の進歩や市 場の変化により、ソフトウェアがかつて以上に陳腐化し易くなり、開発期間が短期化され てきた。また、今までのようなシステム開発だけでなく、コンテンツの開発も同時に求め られており、ユーザーなど外部との関係の緊密化が求められてきた。例えば、最小のシス テムを開発し、一般ユーザーにサービスを利用してもらい、その反応を見て徐々にコンテ ンツを追加、変更し続けていく手法も登場した。特にインターネットを利用したWeb系シ ステムは速さが重視されており、機能を絞ってリリースを最優先に行うことが多い（妹尾, 2001）。
一方で、ソフトウェア開発は製造業の品質管理などの工学手法を取り入れてきたが、下 請け構造のもと属人的で労働集約型産業の特徴が非常に強い側面を残しており、ソフトウ ェア工学の導入はまだ多くの余地が残されている。
こうした状況に対し、ソフトウェア工学は社会科学的に成功事例を整理したものにすぎ ず、工学のベースとなる尺度が不十分のため、いまだ工学の体をなしていないとの批判が ある（阿草, 2009）。
今井他（1989）も、ソフトウェア工学の貢献は既存の道具の改良にすぎず、生産性の向 上に成果を上げていないとし、ソフトウェア開発は依然として職人技に留まっていること を指摘している。くわえて、ソフトウェアを分散して開発するようなことについても、1 人で処理できない作業を人海戦術で行おうとしていることと大差ないと指摘している。そ のうえで、ソフトウェア工学に対し、工学を名乗っているものの実際には定量的なものが なく、そのため基礎的な理論と実務への適用、さらにはその誤差の範囲といったものが明 確にできておらず、工学でありたいとする願望の現れにすぎないと指摘している。
このような厳しい指摘があるとおり、半導体の設計や生産、バイオ・テクノロジーの開 発などの他の分野では、製造や設計プロセス、精密に系統立てられた作業が成し遂げられ てきたが、ソフトウェア産業ではまだその域に達していないといえる（Cusumano, 2004）。
② 日本におけるソフトウェア工学
ここまでソフトウェア工学の問題が指摘されたが、日本におけるソフトウェア工学の導 入は特に遅れている。1968 年の NATO の会議におけるソフトウェア危機の宣言により、
1970代から1980年代にかけて世界的にソフトウェア・エンジニアリング研究がピークを 迎えたが、日本国内では関心が示されなかった（有賀, 2008）。
情報通信産業のうち、コンピューター産業に関しては、国策産業として保護育成が行わ れてきた。一方で、ソフトウェアなどの情報サービス産業については、その歴史が浅いこ ともあり、コンピューター産業と比べその重要性への認識が遅れており、本格的な政策も 遅れている（田中, 1988a）。そのため、日本のソフトウェア・エンジニアリングの研究は遅 れ、学生などの人材を十分教育しなかったため、その後ソフトウェア業界は、急増するソ フトウェア開発のニーズ対応することができず、専門的な教育を受けていない学生も技術 者として採用することで、質よりも量で勝負する体質が浸透してしまった（有賀, 2008）。
さらに、日本のソフトウェア産業では、下請け企業をプロジェクト費用のコストという 視点で見ており、ソフトウェア開発の実作業の下支えをしている下請け企業の技術者がレ ベルアップできるような施策を採ってこなかったことが IT サービス全体の生産性が向上 しない要因の一つにもなっている（工藤, 2009）。その結果、情報サービス・ソフトウェア 産業の従業者数は2000年代に急増したものの、質までは確保できていない状況となってい る。
このような日本のソフトウェア工学の導入状況については、角埜・椿・鶴保（2007）が、
ソフトウェア工学と企業の収益性の関係を調査し、人材育成や開発技術、プロセス改善な どの取組みが事業収益の向上に有効であることを指摘している。また、伊藤（2009）は、
静岡県内のソフトウェア開発企業を対象としたアンケートを実施し、多くの企業が生産管 理などの重要性を認識しているものの、その生産性の測定や開発技法の導入までには至っ ておらず、現時点では結局のところ個人スキルに依存していることを明らかにしている。