471 人月の神話・銀の弾などない・ピープルウェアのWikipediaが面白い件。
人月の神話
13の言語版
出典: フリー百科事典『ウィキペディア（Wikipedia）』
人月の神話
The Mythical Man-Month: Essays on Software Engineering著者フレデリック・P・ブルックス Jr.訳者山内正弥
滝沢徹
牧野祐子
宮澤昇発行日
日本 1977年、1996年、2002年、2014年ジャンルソフトウェア工学
ソフトウェアプロジェクト管理国
アメリカ合衆国言語英語形態上製本ページ数321（2002年版）コードISBN 978-4-89471-665-0
『人月の神話』（にんげつのしんわ、英: The Mythical Man-Month: Essays on Software Engineering）は、フレデリック・ブルックスが著したソフトウェア工学とソフトウェアプロジェクト管理の書籍である。
概要[編集]
ブルックスの考察は、自身がIBM で OS/360 というオペレーティングシステムの開発に携わったときの失敗に基づいている。 プロジェクト管理者がソフトウェアプロジェクト管理において、繰り返し何度もこのような誤りを犯すという傾向があるため、ブルックスは自分の本について、次のような皮肉を述べている。
この本は「ソフトウェア工学の聖書」と呼ばれている。なぜなら、誰もがこの本を読んでいるが、誰もこの本で述べていることを実践しないからである。
最初に刊行されたのは1975年である。1995年に20周年記念版として再刊された。20周年記念版では、『銀の弾などない——ソフトウェアエンジニアリングの本質と偶有的事項』という論文 (エッセイ) と著者による解説が、収められている。1977年に出版された日本語訳の書籍では『ソフトウェア開発の神話』という書名であった。1996年、2002年に出版された日本語訳の書籍では『人月の神話 狼人間を撃つ銀の弾はない』の書名であった（ISBN 978-4-89471-665-0）。
本書の表紙と第1章「タールの沼」には、タールの沼と複数の獣たちの絵が描かれている（参照: #問題の所在—表紙とタールの沼）。また本書の20周年記念版で、新たに追加された第16章「銀の弾などない」の扉には、狼人間の絵が描かれている。
本書の目次[編集]
2002年に出版された日本語訳の書籍より目次を記す。なお第16章から第19章は、二十周年記念版で新たに追加された章である (初版には無かった章である) 。
二十周年記念増訂版の序文
初版の序文
訳者まえがき
第1章 タールの沼
第2章 人月の神話
第3章 外科手術チーム
第4章 貴族政治、民主政治、そしてシステムデザイン
第5章 セカンドシステム症候群
第6章 命令を伝える
第7章 バベルの塔は、なぜ失敗に終わったか
第8章 予告宣言する
第9章 五ポンド袋に詰め込んだ十ポンド
第10章 文書の前提
第11章 一つは捨石にするつもりで
第12章 切れ味のいい道具
第13章 全体と部分
第14章 破局を生み出すこと
第15章 もう一つの顔
第17章 「銀の弾などない」再発射
第18章 「人月の神話」の命題——真か偽か
第19章 「人月の神話」から二十年を経て
エピローグ 五十年間の不思議、興奮、それに喜び
注釈および参照文献
訳者あとがき
索引
問題の所在—表紙とタールの沼[編集]
本書の表紙には、タールの沼と複数の獣たちの絵が描かれている。
太古の昔から、タールの沼に落ちた巨大な獣が死にもの狂いで岸に這い上がろうとしている光景ほど、鮮烈なものはない。恐竜やマンモス、それにサーベル・タイガーが、タールに捕らえられまいとしてもがく様が目に浮かぶ。激しくもがけばもがくほど、タールは一層絡みつき、どんなに力強い獣でも、また賢く器用な獣でも、ついには沈んでいってしまう。
大規模システムプログラム開発は、過去十年以上もの間そうしたタールの沼のようなものだった。そして、多くの強大な獣たちが、その中へ乱暴に突き落とされてきた。たいていは稼働システムを作り、這い上がってきたものの、目標とスケジュール、それに予算にかなったものはほとんどなかった。
規模の大小、また大量動員あるいは少数精鋭であろうとも、開発チームは次から次へとタールでがんじがらめになってしまう。問題を引き起こす原因は、一つだけではないように思われる。原因が一つだけなら、足のどれか一本くらいはタールから抜けるはずだ。だが、同時かつ相互に影響し合う要因が重なり合っているのなら、動きがどんどん遅くならざるをえない。この問題が執拗でやっかいなのは、誰にとっても驚異であり、その本質を理解することは困難である。しかし、問題を解決しようというならば、理解するように努めなくてはならない。— フレデリック・P・ブルックス Jr.、滝沢徹、牧野祐子、宮澤昇、2002年、p.4
本書で述べられている見解[編集]
以下では、ブルックスが本書で述べている見解を説明する。
人月の神話（第二章）[編集]
まず、ブルックスは、次のような問題を指摘する。
時間が足りなかったせいで失敗したプログラミング・プロジェクトは、その他のすべての原因で失敗したプログラミング・プロジェクトよりも多い。
そして、その原因は、「人月」という考え方を使って見積もりをしているからであるとする。ブルックスは、人月の問題点を次のように指摘している。
私たちが使っている見積もり手法は、コスト計算を中心に作られたものであり、労力と進捗を混同している。人月は、人を惑わす危険な神話である。なぜなら、人月は、人と月が置き換え可能であることを暗示しているからである。
つまり、人月を使ってスケジュールを見積もることで、その見積もりが失敗し、スケジュールが遅れてしまうのである。そういう事態に陥ってしまった場合、スケジュールの遅れを取り戻すために、プロジェクトの人員を増やすという対策が取られることが多い。しかし、それでは、火に油を注ぐことになってしまうとブルックスは主張する。彼は、それを「ブルックスの法則」と呼び、以下のように定義している。
ブルックスの法則：遅れているソフトウェア・プロジェクトに人員を投入しても、そのプロジェクトをさらに遅らせるだけである。
そして、ブルックスは、その法則が成り立つ理由を以下のように分析している。
ソフトウェア・プロジェクトに人員を追加すると、全体として必要となる労力が、次の3つの点で増加する。すなわち、再配置そのものに費やされる労力とそれによる作業の中断、新しい人員の教育、追加の相互連絡である。
したがって、人員を追加することで、遅れているプロジェクトに対処することはできない。そこで、ブルックスは、スケジュールが遅れているときには、
スケジュールを立て直す
仕事の規模を縮小する
ことを提案している。ちなみに、ブルックスは、次のような目安で、スケジュールを運用している。
私の大まかなやり方は、スケジュールの1/3を設計に、1/6をコーディングに、1/4をコンポーネント・テストに、1/4をシステム・テストに割り当てるというものである。
外科手術チーム（第三章）[編集]
外科手術チームでは、一人の外科医が指揮を執る。そして、その外科医は最も重要な作業を行う。一方、他のメンバーは、その外科医を補助したり、それほど重要ではない仕事をする。このやり方は、ソフトウェアプロジェクトにも活用できる。つまり、一人の「優秀な」プログラマが、重要なシステム・コンポーネントを開発し、他のメンバーが、そのプログラマに対して、必要なものを提供する。
コンセプトの完全性（第四章）[編集]
ブルックスは、システム開発において、コンセプトを統合することの重要性を指摘する。
コンセプトが統合されたシステムは、より速く作り上げられるし、より速くテストできる。
そして、コンセプトを統合するためには、次のことが必要であると主張する。
基本設計と実装を分離することは、非常に大きなプロジェクトでコンセプトを統合するうえで、非常に強力な方法である（これは、小さなプロジェクトにおいても当てはまる）。
さらに、基本設計（アーキテクチャ）と実装を分離するためには、次のことが必要である。
コンセプトを統合するためには、設計は、一人の人間から、合意の取れている小さなグループへと進まなければならない。
つまり、システムの基本設計は、一人または少数のアーキテクトがするのである。したがって、誰かが「非常に気の利いた」考えを思いついたとしても、その考えがシステム全体の設計にうまく適合しないのであれば、却下される。
セカンドシステム症候群（第五章）[編集]
セカンドシステムは、人間が設計したものの中で、最も危険である。なぜなら、作り込みすぎてしまうというのが、一般的な傾向だからである。
パイロットシステム（第十一章）[編集]
ブルックスは、パイロットプラントという考え方を紹介する。
化学エンジニアは、プロセスを実験台から工場にそのまま持ち込まない。彼らは、規模を拡大し、保護されていない環境で操作するという経験を積むために、パイロット・プラントを作る。
そして、ブルックスは、その考え方をソフトウェア・プロジェクトでも活用するべきであると主張する。
この中間の手順は、プログラミング製品にも同じように必要である。しかし、ソフトウェア・エンジニアは、実際の製品の納品に着手する前に、規則として試作のシステムを実地テストにかけるということをいまだに行っていない。
ブルックスによると、最初に作られるシステムは、粗悪である。
多くのプロジェクトでは、最初に作られたシステムは、ほとんど使えない。なぜなら、遅すぎるし、大きすぎるし、使いにくいからである。これら3つがすべて揃っている場合もある。
ブルックスは、そこから次のように主張する。
使い捨てであるはずのファーストシステムをユーザに納品すれば、時間稼ぎにはなるだろう。しかし、結局は、ユーザを激しく苦しめ、再設計をしているときにシステムをサポートしている開発者をイライラさせ、製品の評判が取り返しのつかないほど悪くなるだけである。
そのため、次のようなことが起こる。
したがって、捨てるプランを立てるべきである。いずれにせよ、そうするだろう。
ファーストシステムが捨てられた後に開発されるシステムをセカンドシステムという。このセカンドシステムは、ファーストシステムより洗練されている。このセカンドシステムを製品として納品するべきである。
その他[編集]
進捗の追跡
「プロジェクトは、どのようにして一年も遅れるようになるのか…一日ずつ」
多くの方面において増加する遅延が蓄積して、全体として大幅な遅延という結果になってしまう。細かい粒度でのそれぞれのマイルストーンごとに継続的に注意することが、各水準の管理 (マネジメント) では必要である。
マニュアル主席アーキテクトが作成したアーキテクチャは、マニュアルとして役割を果たす。したがって、マニュアルは、システムの外部仕様を詳細に記述していなければならない。ここで「詳細に記述する」とは、利用者がシステムを使用するときに見えるものをすべて記述するということである。そして、マニュアルは、実装担当者やシステム利用者から意見が寄せられたときには、改訂するべきである。形式に即した文書全てのソフトウェアプロジェクト管理者は、形式に即した文書の小さな中核となるセットを作成するべきである。この形式に即した文書の小さなセットは次の役割を果たす。
プロジェクトの目標群に向けた道標
プロジェクトの目標群をどのようにして達成するかについての道標
目標群の達成を担当する人物を明らかにする
目標のそれぞれについて、達成することを予定している時期
目標のそれぞれについて、必要となる費用
形式に即した文書の小さなセットはまた、プロジェクトの遂行に不整合があることも明確に示す。こうした不整合は、形式に即した文書の小さなセットが無い場合は、その存在を認識することが難しい。
プロジェクトの見積りソフトウェアプロジェクトの時間の見積りをするときには、コンパイラ (製品としての品質水準をもつソフトウェア) を開発することは、アプリケーションソフトウェアを開発することよりも、3倍難しい作業であるということを憶えておくべきである。そしてシステムプログラム (オペレーティングシステム、製品としての品質水準をもち且つシステムとして統合されたソフトウェア) を開発することは、コンパイラを開発することよりも、さらに3倍難しい作業である。また、1週間の作業のうち何時間を、技術的な問題に取り組むことに費すかについて、心に留めておくべきである。このことは管理に費す時間や技術的ではない問題 (会議や療養休暇など) に費す時間について考えることよりも、重要なことである。コミュニケーション
チームは、できるだけたくさんの方法で、お互いに連絡を取るべきである。非公式には、いつものプロジェクト会議で、技術的なブリーフィングで、共有の公式プロジェクトワークブックで（そして、電子メールで）。
プログラマは、何かを仮定するべきではない。つまり、プログラマは、自分が実装する機能について曖昧なところがあれば、自分で勝手に想像するのではなく、アーキテクトに機能の意図するところを明確にするために質問をするべきである。
コードの凍結とシステムのバージョンソフトウェアは、目に見えない。そのため、新しいシステムは、それが完成したときには、まだ十分に理解されていない。利用者がそれを使うようになったときに、初めて理解されるのである。つまり、利用者は、新しいシステムを使うことを通して、そのシステムを深く理解するのである。そして、システムについての理解が深まると、利用者は、システムに異なる要求をするかもしれない。そして、システムは、利用者が変更した要求に合わせて、変更されるべきである。システム要求の変更は、ある時点までは可能であるが、ある時点を境にして、コードが凍結されるべきである。なぜなら、そうしなければ、システムは、永久に完成しないからである。そして、そのとき受け入れられなかった変更要求は、そのシステムの次のバージョンまで延期される。切れ味のいいツールプログラマは、それぞれ個別のツールを使うべきではない。プロジェクトでは、指定されたツールを作る担当者を決めておくべきである。ツール作成担当者は、プロジェクトチームが行っている仕事のために、高度にカスタマイズされたツールを作成する。たとえば、仕様を基にしてコードを生成するコードジェネレータを作るなどである。また、システム全体で使われるツールは、共通ツールチームで開発するべきである。なお、共通ツールチームは、プロジェクトマネージャの監督下におかれる。ソフトウェア開発の費用を抑えるブルックスは、ソフトウェア開発の費用を抑えるうえで、二つの方法を挙げている。
システムのアーキテクチャが完成してから、プログラマをプロジェクトに参加させる(なぜなら、システムの基本設計を完成させるには、何ヶ月もかかることが多いため、そのときにプロジェクトに参加したところで、プログラマは何もすることがないからである)。
ソフトウェアをすべて開発するのではなく、「すぐに手に入る」ソフトウェアがすでにあれば、それを購入する。
銀の弾などない——ソフトウェアエンジニアリングの本質と偶有的事項ブルックスが1986年に発表した論文である。『人月の神話 20周年記念版』では、第16章として収められた。「銀の弾丸」として魔法のようにすぐに役に立ちプログラマの生産性を倍増させるような技術や特効薬は、今後10年間 (1986年の時点から10年の間) は現れないだろう。そもそも、ソフトウェア開発の複雑性には、「本質的な複雑性」と「偶有的な複雑性」とがある。これまで、ソフトウェア開発者は、高水準プログラミング言語、タイムシェアリングシステム、統一されたプログラミング環境により、偶有的な複雑性の多くをやっつけてきた。しかし、現在 (1986年) のプログラマは、ほとんどの時間を本質的な複雑性に取り組むことに費している。ブルックスは、次のことを提案している。
購入できるものをあえて構築しないようにするための大市場の利用。ソフトウェア要件の確立に際し、開発循環計画の一部として、迅速なプロトタイピングを使用すること。実行と使用とテストが行われるにつれて、より多くの機能をシステムに追加しながら、ソフトウェアを有機的 (系統的) に成長させること。若い世代の素晴らしいコンセプトデザイナーを発掘し、育てること。— (フレデリック・P・ブルックス Jr.、滝沢徹、牧野祐子、宮澤昇、2002年、第16章、P.166)
「銀の弾などない」再発射詳細は銀の弾などない#「銀の弾などない」再発射を参照。ブルックスが『銀の弾などない』の9年後に発表した論文である。『人月の神話 20周年記念版』では、第17章として収められた。『銀の弾などない』で主張した「銀の弾はない」という見解は、変わらない。また、オブジェクト指向プログラミングは成長が遅かったが、少しずつ成果が出ている。「人月の神話」から二十年を経てブルックスが『人月の神話』の初版を出版してから20年後に書いたエッセイである。『人月の神話 20周年記念版』では、第19章として収められた。『人月の神話』の初版を書いた当時と変わらず現在も正しいこと、今になってみると間違っていたと思うこと、もう時代遅れになっていること、ソフトウェア・エンジニアリングにおいて本当に新しいこと、などについて書かれている。なお、「コンセプトの完全性」は正しかったと述べているが「パイロットシステム」については誤りであったと述べている。
引用[編集]
第二章[編集]
カレンダーの時間が足りなかったせいで失敗したプログラミング・プロジェクトは、その他のすべての原因で失敗したプログラミング・プロジェクトよりも多い。
More programming projects have gone awry for lack of calendar time than for all other causes combined.
私たちが使っている見積もり手法は、コスト計算を中心に作られたものであり、労力と進捗を混同している。人月は、人を惑わす危険な神話である。なぜなら、人月は、人と月が置き換え可能であることを暗示しているからである。
Our estimating techniques, built around cost-accounting, confuse effort and progress. The man-month is a fallacious and dangerous myth, for it implies that men and months are interchangeable.
多数の人々の中で、仕事を再配分することによって、さらなるコミュニケーションの労力が発生する。すなわち、教育と相互連絡である。
Partitioning a task among multiple people occasions extra communication effort ― training and intercommunication.
私の大まかなやり方は、スケジュールの1/3を設計に、1/6をコーディングに、1/4をコンポーネント・テストに、1/4をシステム・テストに割り当てるというものである。
My rule of thumb is 1/3 of the schedule for design, 1/6 for coding, 1/4 for component testing, and 1/4 for system testing.
ブルックスの法則：遅れているソフトウェア・プロジェクトに人員を投入しても、そのプロジェクトをさらに遅らせるだけである。
Brooks's Law: Adding manpower to a late software project makes it later.
ソフトウェア・プロジェクトに人員を追加すると、全体として必要となる労力が、次の3つの点で増加する。すなわち、再配置そのものに費やされる労力とそれによる作業の中断、新しい人員の教育、追加の相互連絡である。
Adding people to a software project increases the total effort necessary in three ways: the work and disruption of repartitioning itself, training the new people, and added intercommunication.
第三章[編集]
非常に優秀なプロのプログラマは、下手なプログラマの10倍の生産性がある。たとえ、同じ訓練と2年間の経験を経ているとしても（ザックマン、グラント、エリックソン）。
Very good professional programmers are ten times as productive as poor ones, at same training and two-year experience level. (Sackman, Grant, and Erickson)
主任プログラマと外科手術チームの組織を採用すると、コミュニケーションが徹底的に削減されるので、少人数で設計することで、製品の統合性が見込める。また、多人数で開発することで、全体的な生産性も見込める。
A chief-programmer, surgical-team organization offers a way to get the product integrity of few minds and the total productivity of many helpers, with radically reduced communication.
第四章[編集]
「概念上の統合性は、システム設計における最重要事項である」。
"Conceptual integrity is the most important consideration in system design."
コンセプトを統合するためには、設計は、一人の人間から、合意の取れている小さなグループへと進まなければならない。
To achieve conceptual integrity, a design must proceed from one mind or a small group of agreeing minds.
「基本設計と実装を分離することは、非常に大きなプロジェクトでコンセプトを統合するうえで、非常に強力な方法である」（これは、小さなプロジェクトにおいても当てはまる）。
"Separation of architectural effort from implementation is a very powerful way of getting conceptual integration on very large projects." [Small ones, too.]
コンセプトが統合されたシステムは、より早く作り上げられるし、より早くテストできる。
A conceptually integrated system is faster to build and to test.
第五章[編集]
セカンドシステムは、人間が設計したものの中で、最も危険である。なぜなら、作り込みすぎてしまうというのが、一般的な傾向だからである。
The second is the most dangerous system a person ever designs; the general tendency is to over-design it.
第六章[編集]
たとえ設計チームが大きなものであっても、小さな決定を一貫させるためには、一人か二人の人間が設計をすることになる。
Even when a design team is large, the results must be reduced to writing by one or two, in order that the minidecisions be consistent.
重要なのは、設計者が、実装する人の質問に対して、電話で応答して説明することである。そして、そのやりとりを記録して公開することは、必須事項である（電子メールは、今や選択肢の一つである）。
It is important to allow telephone interpretations by an architect in response to implementers' queries; it is imperative to log these and publish them. [Electronic mail is now the medium of choice.]
第七章[編集]
チームは、できるだけたくさんの方法で、お互いに連絡を取るべきである。非公式には、いつものプロジェクト会議で、技術的なブリーフィングで、共有の公式プロジェクトワークブックで（そして、電子メールで）。
Teams should communicate with one another in as many ways as possible: informally, by regular project meetings with technical briefings, and via a shared formal project workbook. [And by electronic mail.]
第八章[編集]
プログラミングは、プログラムサイズの累乗で、増大する。
Programming increases goes as a power of program size.
発表されているいくつかの研究によると、およそ1.5乗である（ベームのデータは、これと完全に一致していないが、1.05乗～1.2乗の誤差である）。
Some published studies show the exponent to be about 1.5. [Boehm's data do not at all agree with this, but vary from 1.05 to 1.2.]
適切な高水準言語を使えば、プログラミングの生産性が、5倍も上昇する可能性がある。
Programming productivity may be increased as much as five times when a suitable high-level language is used.
第十二章[編集]
高水準言語とインタラクティブ・プログラミングが広く採用されていないのは、ひとえに怠惰と無気力である。
Only sloth and inertia prevent the universal adoption of high-level language and interactive programming.
高水準言語を使うことで、生産性が向上するだけでなく、デバッグ作業も楽になる。なぜなら、バグが少なく、おまけに見つけやすいからである。
High-level language improves not only productivity but also debugging; fewer bugs and easier to find.
初版のエピローグ[編集]
ソフトウェアシステムは、（異なる部品の種類の数の点から言えば、）人間が作ったものの中で、おそらく最も難解で複雑なものである。
Software systems are perhaps the most intricate and complex (in terms of number of distinct kinds of parts) of the things humanity makes.
今後長い間、ソフトウェア・エンジニアリングというタールの沼は、厄介なものであり続けるだろう。
The tar pit of software engineering will continue to be sticky for a long time to come.
参考文献[編集]
The Mythical Man-Month : essays on software engineering, Brooks, F. P., Addison Wesley, 1975, ISBN 978-0201006506
『ソフトウェア開発の神話』、フレデリック・フィリップス・ブルックス、山内正弥 (訳) 、企画センター、1977年、ISBN 9784873670232
The Mythical Man-Month : essays on software engineering (Anniversary Edition with four new chapters), Brooks, F. P., Addison Wesley, 1995, ISBN 978-0201835953
『人月の神話 狼人間を撃つ銀の弾はない』 (原著発行20周年記念増訂版) 、フレデリック・P・ブルックス Jr.、滝沢徹 (訳) 、牧野祐子 (訳) 、宮澤昇 (訳) 、星雲社、アジソン・ウェスレイ・パブリッシャーズ・ジャパン、1996年、ISBN 978-4795296756
『人月の神話 狼人間を撃つ銀の弾はない』 (原著発行20周年記念増訂版、新装版) 、フレデリック・P・ブルックス Jr.、滝沢徹 (訳) 、牧野祐子 (訳) 、宮澤昇 (訳) 、ピアソン・エデュケーション、2002年、ISBN 978-4-89471-665-0
関連項目[編集]
ブルックスの法則 - 「遅れているソフトウェアプロジェクトに人員を追加すると、そのプロジェクトはさらに遅れる」というブルックスの見解。
銀の弾などない - 『人月の神話』の20周年記念版に収められたブルックスの論文。
ピープルウェア - ブルックスが、『人月の神話』の20周年記念版で、全ての読者に推薦している書籍。
外部リンク[編集]
銀の弾などない
8の言語版
出典: フリー百科事典『ウィキペディア（Wikipedia）』
この記事には参考文献や外部リンクの一覧が含まれていますが、脚注によって参照されておらず、情報源が不明瞭です。脚注を導入して、記事の信頼性向上にご協力ください。（2021年4月）
『銀の弾などない— ソフトウェアエンジニアリングの本質と偶有的事項』（ぎんのたまなどない ソフトウェアエンジニアリングのほんしつとぐうゆうてきじこう、英: No Silver Bullet - essence and accidents of software engineering）とは、フレデリック・ブルックスが1986年に著した、ソフトウェア工学の広く知られた論文である。
論文概要[編集]
原論文は英語である。日本語では『銀の弾丸はない』と、翻訳されることもある。ブルックスは、「銀の弾丸」（Silver Bullet）として、魔法のように、すぐに役に立ちプログラマの生産性を倍増させるような技術や実践 (特効薬) は、今後10年間（論文が著された1986年の時点から10年の間）は現れないだろう、と記載した。
銀の弾とは、銀で作られた弾丸であり、西洋の信仰において狼人間、悪魔を撃退する際に用いるものとされていた。
ブルックスの警句は、非常に多く引用されており、生産性、品質、制御に適用されている。ブルックスは、自身の警句で述べているプログラマの生産性の限界は「本質的な複雑性」（essential complexity）についてのみ当てはまると述べているのであり、「偶有的な複雑性」（accidental complexity）に対する挑戦については支持している。ブルックスは、偶有的な複雑性については著しい改善（おそらく今後10年間で10倍以上）がみられるだろうと述べている。
ブルックスは、この論文で本質的な複雑性に対処するために、次のことを提案している（詳細は#提案を参照）
購入できるものをあえて構築しないようにするために大市場を利用する。
実行と使用とテストが行われるにつれて、より多くの機能をシステムに追加しながら、ソフトウェアを有機的（系統的）に成長させる。
若い世代の素晴らしいコンセプトデザイナーを発掘し、育てる。
（ブルックス、滝沢、牧野、宮澤、2002年、第16章、P.166）
『銀の弾などない』は、1986年のIFIPでの論文である。1987年に IEEE Computer Society の「コンピュータ」誌に再録された。また、この論文とこの論文に対するブルックス自身の省察『「銀の弾などない」再発射』（No Silver Bullet - Refired）の2つの論文は、ブルックスの著書『人月の神話』（The Mythical Man-Month）の20周年記念増訂版に収められている。
『銀の弾などない』が収録された「コンピュータ」誌の表紙と、『人月の神話』の20周年記念増訂版の第16章「銀の弾などない」の扉には、狼人間を描いた絵が掲載されている。
問題の所在—銀の弾とソフトウェアプロジェクト[編集]
この論文が対象とする問題の所在を説明するために、論文の序の文章を引用する。
民話の中の悪夢に登場する怪物のうちでも、狼人間ほど恐ろしいものはない。というものも、狼人間は慣れ親しんでいるものを不意に恐怖に変えてしまうからだ。だから、私たちは、この狼人間を魔法のように鎮めることができる銀の弾を探し求める。
慣れ親しんだソフトウェアプロジェクトにもこうした性質が若干あり（少なくとも非技術担当マネージャーの目から見ると）、ふだんは無害でまともなのだが、スケジュールの遅延、膨れ上がった予算、そして欠陥製品といった怪物にもなり得る。そして私たちは銀の弾、すなわちコンピュータハードウェアのコストと同じようにソフトウェアのコストも急激に小さくしてくれる特効薬を求める必死の叫び声を聞くのである。
しかし、これから十年間という範囲で眺めると、銀の弾などはどこにも見えない。技術においても、管理手法においても、それだけで十年間に生産性や信頼性と容易性での飛躍的な改善を一つでも約束できるような開発は一つとしてない。本章では、ソフトウェア問題の本質と、提案されているそれぞれの銀の弾の特性の両方を検証することによって、それがなぜ特効薬になりえないのかについて見ていくことにする。
とはいっても、懐疑主義は悲観主義とは違う。輝かしい進展は見えないが、実際のところそう決めてかかることはソフトウェアの本質からは離れている。多くの頼もしい新機軸 (革新) が着々と進められている。それらを開発、普及、利用するという苦しいが一貫した努力こそ、飛躍的な改善をもたらすはずだ。王道はない。しかし、道はある。
病気治療の第一ステップは、悪魔信仰を細菌説によって生理学的理論に置き換えることだった。そのステップこそ希望の始まりであり、すべての魔法のような解決の夢を打ち砕いた。医療従事者は、進歩は段階を追いながら多大な労力を払って遂げるもので、健康回復には持続的で根気強い看護がなされなければならないと教え込まれた。今日のソフトウェアエンジニアリングにおいても、それは変わらない。
主張[編集]
ブルックスが本書で主張していることを述べる。
本質的な複雑性と偶有的な複雑性を区別する[編集]
ブルックスの主張で重要なことは、ソフトウェア開発の複雑性について、「本質的な複雑性」 (essential complexity) と「偶有的な複雑性」 (accidental complexity) を区別していることである。なお、これは、アリストテレスの分類にヒントを得たものである。
偶有的な複雑性は、ソフトウェア開発者自身が発生させている解決可能な問題に関連する。例えば、アセンブリ言語のプログラムコードの記述、最適化、バッチ処理などによってもたらされる遅延は、偶有的な複雑性に由来する。
本質的な複雑性は、解決すべき問題によってもたらされるものであり、これを取り除くことはできない。もし利用者が30の異なることを行う1つのプログラムを望む場合、この30のことは本質的であり、開発するべきプログラムはこの30の異なることを実行しなければならない。
ブルックスによると、ソフトウェア開発者はこれまで偶有的な複雑性の多くを退治してきたが、その一方で、現在 (1986年) のプログラマは自分の時間の大部分を本質的な複雑性に取り組むことに費している。
偶有的な複雑性におけるブレークスルー[編集]
過去に行われてきたソフトウェア技術の発展は、ソフトウェア開発における偶有的な複雑性を攻略した。ただし、これはあくまでも偶有的な複雑性を攻略しただけであって、本質的な複雑性を攻略したわけではない。
高水準プログラミング言語[編集]
偶有的な複雑性の領域における大きなブレークスルーの一つは、FORTRANのような高水準プログラミング言語である。高水準プログラミング言語は、データ型やデータ構造、操作などのような高水準な概念でプログラミングできる環境を提供し、プログラマは低水準な複雑性を考える必要がなくなった。
タイムシェアリングシステム[編集]
タイムシェアリングシステムより古いバッチ処理の環境では、ターンアラウンドが遅いため、プログラマは思考を中断させられてしまい、また時間コストがかかってしまっていた。しかし、タイムシェアリングシステムの登場により、プログラマは、早いレスポンスの環境で作業ができるようになった。
統一されたプログラミング環境[編集]
UNIXとInterlispによる統一されたプログラミング環境が広く普及し、次のような特長により、プログラマの生産性は大きく向上した。
統合されたライブラリ
統一されたファイルフォーマット
銀の弾の候補[編集]
次に、銀の弾になる可能性のあるとされている技術について述べる。
Adaとその他の高水準プログラミング言語の進歩[編集]
ただし、Adaなど現在のプログラミング言語の出現は、高水準プログラミング言語が初めて出現したことよりも、影響は小さい。
しかし、Adaもまた高水準プログラミング言語の一つに過ぎない。
そのため、Adaなどの現在のプログラミング言語が出現したことによる影響は、あくまで偶有的な複雑性を低減することにとどまる。
オブジェクト指向プログラミング[編集]
オブジェクト指向プログラミングでは、クラスの概念を導入し、カプセル化と継承を活用することができる。
多くのソフトウェア工学分野の研究者が、オブジェクト指向プログラミングの有効性に大きな期待を寄せている (グラディ・ブーチ) 。
そして、ブルックス自身も、オブジェクト指向プログラミングに非常に期待している。
ただし、オブジェクト指向プログラミングも、ソフトウェア開発の過程における偶有的な複雑性の一つを除去するにとどまる。
したがって、オブジェクト指向プログラミングが発展しても、本質的な複雑性が低減されるわけではない。
人工知能[編集]
音声認識や画像認識に象徴される人工知能技術からは、あまり収穫は得られない。
ソフトウェア開発についての困難は何を表現するかを決定することであり、表現することそれ自体ではない。
エキスパートシステム技術については、次の節で述べる。
エキスパートシステム[編集]
多くのソフトウェア科学者が、エキスパートシステム技術をソフトウェア開発環境に適用しようと努力している (デイビッド・パーナス) 。
もしエキスパートシステム技術をエキスパートアドバイザーとして活用することができれば、ソフトウェア開発者の役に立つだろう。
エキスパートシステム技術では、知識ベースを構築することが困難であり、そのことが障害となっている。
知識ベースを構築するためには、専門家 (エキスパート) を確保する必要がある。しかし、これは簡単なことではない。
また、たとえ専門家を確保できたとしても、彼らの豊富な知識を知識ベースに登録するための効率的な方法を開発しなければならない。
「自動」プログラミング[編集]
自動プログラミングとして言及されてきた技法は、つまるところ高水準プログラミング言語を使ったプログラミングの婉曲的表現である (デイビッド・パーナス) 。
ビジュアルプログラミング[編集]
ビジュアルプログラミングを使って生産性を向上させることは難しい。
フローチャートは、ソフトウェアの構造を抽象的に表現するものとしては貧弱である。そのため、プログラマは、実際にはフローチャートを描いてからプログラミングをするのではなく、プログラミングしてからフローチャートを描いている。
重要なソフトウェア構成図の詳細を表示するには、現在のディスプレイは範囲と解像度の点で力不足である。そのため、ハードウェア技術のさらなる進歩が必要である。
ソフトウェアは、基本的に複雑であり視覚化することが難しい。そのため、ソフトウェアの視覚化を試みても、特定の一つの視点による一面的な認識しか得られない。
プログラム検証[編集]
プログラム検証には労力がかかる。そのため、全ての開発対象を検証することはできず、一部の重要なプログラムを検証することしかできない。 また、たとえプログラムを検証したとしても、それは、プログラムが仕様書通りに実装されていることを証明するだけであり、仕様書にバグがないことを証明するわけではない。
プログラム開発の本質の多くの部分は、仕様書のデバッグである。
完全で一貫した仕様書に到達することは、非常に難しい作業である。
環境とツール[編集]
プログラミング環境とツールの整備については、既に大きな成果が出ており、今後のさらなる成果はあまり期待できない。
ワークステーション[編集]
ワークステーション (プログラム開発のための作業用コンピュータ) の性能は、飛躍的に向上した。
プログラムや文書の作成には、現在のワークステーションの性能で既に十分であり、ワークステーションの性能が現在以上に向上しても生産性に寄与する余地はない。
プログラムのコンパイルは、特にワークステーションの性能を必要とする作業だが、現在のワークステーションの性能でも、既にほとんど生産性の阻害要因とならない水準になっている。
提案[編集]
以下のことを提案する。
ソフトウェア製品の大市場の利用[編集]
購入できるものをあえて構築しないようにするために、市場を活用するべきである。
要件の洗練と迅速プロトタイピング[編集]
洗練された手法で丁寧に要件定義をしたり、顧客自身が要件を明確に認識していなかったりすることが多いため、迅速にプロトタイピングを行うことが有用である。
漸増的開発[編集]
実行と使用とテストが実施されるにつれて、ソフトウェアは、機能を増やしながら、有機的 (系統的) に成長する。
漸増的開発を通して有機的に「育成されていく」ソフトウェアを支持する。
まずメインプログラムを実装して、その後にサブプログラムを実装してゆくことを推奨する。
このような漸増的開発を採用することによって、開発のどの段階でもシステムが動作するので、プログラマのやる気が出る。
漸増的開発を採用することによる恩恵は、大規模プロジェクトにおいても得られる (ベーム) 。
偉大なデザイナー[編集]
若い世代の素晴らしいコンセプトデザイナー (設計者) を発掘し、育てる。
プログラミングは、創造的な過程である。そのため、設計能力が非常に高い「偉大なデザイナー」と設計能力が平均的な「よいデザイナー」が存在する。
よいデザイナーは、優れた練習法でソフトウェア設計を学ぶ。こうした教育は、まったく理にかなったことである。
しかし、偉大なデザインは、偉大なデザイナーからしか生まれない。よいデザイナーは、偉大なデザインを生み出すことはできないのである。
ソフトウェア企業にとっては、偉大なデザイナーを発見し育成することに大きな労力を費すべきである。
偉大なデザイナーを偉大なマネージャと同等に処遇する。
偉大なデザイナーと偉大なマネージャに対して、同等の給与を与えるだけでなく、高い地位に伴う全ての給付を与えることを（広いオフィス、スタッフ支援、出張旅費など）。
その他[編集]
多くの企業にとっては、知的労働者 (プログラマではなくエンドユーザ) に、パーソナルコンピュータとワープロソフト、表計算ソフトなどを与え、自由に使わせることが、強力な戦略である。
「銀の弾などない」再発射[編集]
ブルックスは、1986年に論文『銀の弾などない』を発表してから9年目にあたる1995年に、同論文を省察する『「銀の弾などない」再発射 ("No silver bullet" reloaded)』という論文を発表した。
『「銀の弾などない」再発射』の内容を抜粋・補足して説明する。
なお、デービッド・ハレルは、1992年に論文『銀の弾丸をかみしめて』を発表して、『銀の弾などない』について慎重に分析を行った。
オブジェクト指向プログラミングの現状[編集]
オブジェクト指向プログラミングの手法は成長が遅かった。
この理由には次のようなものが考えられる。
オブジェクト指向のプログラマは、C++で連結リストやセット (集合) のような比較的低水準な抽象化によるクラスを作る傾向があり、高水準な抽象化を行ってクラスを作ることは行ってこなかった。 (ジェームズ・コギンズの雑誌記事より)
オブジェクト指向についてプログラマを教育するとき、オブジェクト指向を特定のツール/言語を使うことだと教えてしまうことが多かった。本来はオブジェクト指向は設計 (ソフトウェア設計) の一つの種類 (オブジェクト指向設計) だと教育し、設計の原則を与えるべきであった。プログラマは設計の原則を学ばずに単にオブジェクト指向言語を使うだけであったため、恩恵は少なかった。恩恵が少ないのでは普及しないのは当然である。 (デイビッド・パーナスからブルックスに宛てられた手紙の内容より)
オブジェクト指向の技法は厳しい状況にある。
プログラマにまったく新しい思考法 (オブジェクト指向の考え方) で考えるよう再教育しなければならないなど、事前に多額の投資が必要であり、さらに効果が目に見える形で現れるまで時間がかかる。
「オブジェクト指向テクニックは、最初や二度目のプロジェクト開発を速めるのではない。そのファミリーで五度目にあたるものなら、猛烈に速く進むことだろう」(ジェームズ・コギンズ)
とはいえ、多くの組織でC++をCの代わりに採用する動きがあり、ゆっくりとではあるが着実に情況は前に向けて進んでいるようである。
再利用可能なプログラムコードの開発には、1回限りのプログラムコードの開発と比べて、2倍、3倍の労力がかかる。
再利用可能なプログラムコードの開発には、優れた設計と優秀な文書の両方が必要である (デイビッド・パーナス) 。
再利用可能なプログラムコードを利用するためには、そのプログラムコードについて学習する必要がある。
プログラムコードの再利用は、企業内では特に大規模な企業において精力的に行われている傾向がある (ケーパーズ・ジョーンズ) 。
市場では再利用可能なプログラムコードがいくつか流通している (ケーパーズ・ジョーンズ) 。
見解は変わらない[編集]
見解は変わらない。
銀の弾などない。
魔法のようにすぐに役に立つ解決策（特効薬）は、身近にはない。
ソフトウェア開発の専門家にとっては、革命的改善をただ待ったり、期待するのではなく、発展的改善を検証する時が来た。(フレデリック・ブルックス、デイビッド・パーナス、R・L・グラス)
参考文献[編集]
Brooks, Fred P. (1986). “No Silver Bullet — Essence and Accident in Software Engineering”. Proceedings of the IFIP Tenth World Computing Conference: 1069–1076.
Brooks, Fred P. (April 1987). “No Silver Bullet — Essence and Accidents of Software Engineering”. IEEE Computer 20 (4): 10–19.
Brooks, Fred P. (1975). The Mythical Man-Month. Addison-Wesley. ISBN 0-201-00650-2
Brooks, Fred P. (1995). “Chap. 16”. "No Silver Bullet — Essence and Accident" (Anniversary Edition with four new chapters ed.). Addison-Wesley. ISBN 0-201-83595-9
Brooks, Fred P. (1995). “Chap. 17”. "'No Silver Bullet' Refired" (Anniversary Edition with four new chapters ed.). Addison-Wesley. ISBN 0-201-83595-9
『人月の神話 狼人間を撃つ銀の弾はない (20周年記念増訂版、新装版)』ピアソン・エデュケーション、2002年。ISBN 978-4-89471-665-0。第16章 銀の弾などない——ソフトウェアエンジニアリングの本質と偶有的事項第17章 「銀の弾などない」再発射
関連項目[編集]
外部リンク[編集]
No Silver Bullet - IEEE Computer Society の「コンピュータ」誌に掲載された『銀の弾などない』の論文（全文を英語で閲覧可能）
No Silver Bullet abridged - 『銀の弾などない』の論文のダイジェスト版（英語）
ピープルウェア
5の言語版出典: フリー百科事典『ウィキペディア（Wikipedia）』
ピープルウェア（英: Peopleware）は、 ハードウェア、ソフトウェアと共に、コンピュータ技術の三つの中心的な側面の一つを表す用語である。ピープルウェアとは、ソフトウェア・ハードウェアシステムの開発、使用に際する人間の役割、関連したいかなるものも指す。たとえば、開発者の生産性、チームワーク、集団力学、プログラミングの心理学、プロジェクト管理、組織上の要素、ヒューマンインターフェイスの設計、人間と機械の相互作用、などである [1] 。
概要[編集]
ソフトウェアの領域におけるピープルウェアの概念は、様々な側面をカバーする [2]。
生産性の高い個人の育成
従業員の管理
組織の文化
組織的な学
生産性の高いチームの育成
人間の能力のモデル化
歴史[編集]
「ピープルウェア｣という用語は、1977年にPeter G. Neumann が初めて用いた[3] 。また、それとは独自に、1980年に Meilir Page-Jones が用い[4]、 1987 年に出版されたトム・デマルコと Timothy Lister の著書"Peopleware: Productive Projects and Teams"で普及した[5]。
また「ピープルウェア」という用語は、Software Development 誌に長期連載されたラリー・コンスタンチン（英語版）のコラムの題名と主要な話題になった [6]。
書籍 Peopleware: Productive Projects and Teams[編集]
ピープルウェア著者トム・デマルコ、ティモシー・リスター原書名Peopleware: Productive Projects and Teams翻訳者松原 友夫、山浦 恒央原書の言語英語主題ソフトウェア工学、ソフトウェアプロジェクト管理出版年1987年、第二版1999年出版年（日本語訳）1994年、第二版2001年ページ数328ページ（日本語訳第二版）ISBN978-4-8222-8110-8（日本語訳第二版）
ピープルウェアに関して、おそらく最も有名で影響の大きいのはデマルコと Lister の書籍 Peopleware: Productive Projects and Teams であろう。ソフトウェアのコンサルタントだったトム・デマルコとティモシー・リスターは、プロジェクト管理のみならず、個々人の仕事の考え方と、会社の考え方との衝突、チームの結束(team jelling)、グループの化学反応(group chemistry)、会社のエントロピー、作業時間(flow time)、チーム化(teamicide)、(最適化のための)職場環境理論、などについて述べている。
本書の最初の章で、「われわれの抱える主要な問題は、そもそも技術的ではなく社会学的なものである」と述べ、たとえば職場環境の静かさや離職に伴うコストといった社会学的な問題、政治的な問題に取り組むとしている。
著者らは、多くのテーマを具体的な話題や情報に基いて原理として示し、たとえば、｢スパゲッティ・ディナー｣という章では、マネージャが新しいチームをディナーに招待し、チームの成功のために、食事を準備する、という話が紹介されている（フィクションだが、実話に近い話）。他の章でも現実的な話や様々な研究結果を示して、原理を説明しようとしている。
日本語版[編集]
日本では、日経BP社が訳書を出版している。
脚注[編集]
[脚注の使い方]
^ Larry Constantine Constantine on Peopleware Prentice Hall, 1995, p. xxi. (ISBN 0-13-331976-8)
^ Silvia T. Acuna (2005). A Software Process Model Handbook for Incorporating People's Capabilities. pp.9-11.
^ Peter G. Neumann "Peopleware in Systems." in Peopleware in Systems. Cleveland, OH: Assoc. for Systems management, 1977, pp 15-18. (ISBN 0-93-435613-0)
^ Page-Jones, M. Practical Guide to Structured Systems Design. New York: Yourdon Press. (ISBN 0-13-690769-5)
^ Tom DeMarco and Timothy Lister. Peopleware: Productive Projects and Teams. New York: Dorset House, 1987. (ISBN 0-932633-43-9)
^ Larry Constantine The Peopleware Papers Prentice Hall, 2001. (ISBN 0-13-060123-3)
関連項目[編集]
フレデリック・ブルックス『人月の神話』 - ソフトウェア工学とソフトウェアプロジェクト管理のバイブルとして知られる本
ITゼネコン
言語を追加
ツール
出典: フリー百科事典『ウィキペディア（Wikipedia）』
ITゼネコンとは、建設業界のゼネコンと同じように、情報処理産業において官公需を寡占する大手のシステムインテグレーター（SIer）のこと。またはそれらが形成する多重の下請け構造のことである[1]。
概説[編集]
ゼネコンとは、元請負者として工事を一式で発注者から直接請負い、工事全体のとりまとめを行う建設業者を指す。現在の日本では、建設業界と同様に、IT業界においても元請け、下請け、孫受けの多重構造が形成されている[1]。
NTT系列や国内大手ITベンダー（日立、NEC、富士通）の三社、外資系ITベンダー（IBM、HP、Oracleなど）系列のSIerが大手の顧客を囲い込み、インフラ構築からコンピュータ機器の設置、納入後の運用メンテナンスに至るまでを一括受注して利益を得ており、実際のプログラミングやテスト作業を中小のSIerに丸投げしている状態となっている[2]。このようなIT業界の構造を揶揄して、「ITゼネコン」という用語が批判的文脈で使用されるケースが近年多くなってきている（なお、下請けのプログラマは「デジタル土方」という言葉で揶揄されている）。また、システムの規模の計算は、人数と日数の掛け算の「人月計算」という単純な方法で金額が決められて発注が行われるため、この点においても建設業界のゼネコンの構造と類似している。
そして何より、官公需の独占がある。経済産業研究所の報告書によると[3]、平成13年度の政府調達において、NTTグループで全体のシェアの4割、ITゼネコン大手4グループ（NTTグループ、日立グループ、NECグループ、富士通グループのいわゆる「旧電電ファミリー企業」[4]）で6割、ITゼネコン大手10グループで8割を受注している。政府調達は巨額であり、市場規模は中央官庁と地方自治体を合わせて約2.2兆円にのぼる。これは日本のIT産業の約2割のシェアを占める。
スキャンダル[編集]
1997年（平成9年） - オウム真理教の関連会社が、日本国政府機関や大企業が絡むコンピューターシステムのソフト開発業務を受注していたオウム真理教ソフト開発業務受注問題が発覚した。
2001年（平成13年） - 公正取引委員会はNTTデータ、日本IBM、日本ユニシス、松下通信工業に対して、超安値落札が不当廉売（独占禁止法第19条6項）に当たる恐れがあるとの注意を行った[6]。NTTデータは当初予算5億5210万円のシステムを1万円で落札したとされる。
2002年（平成14年） - 公正取引委員会はNTTデータ、日立、富士通に対して超安値落札が不当廉売（独占禁止法第19条6項）に当たる恐れがあるとの警告を行った[7][8][9]。
2007年（平成19年） - 年金記録問題が発覚。1967年度以来、1兆4000億円を費やしたシステム運用にかかる不備、システム化される以前の記録管理の杜撰さが顕在化された。NTTデータは1兆632億円、日立は3558億円を売り上げる一方で、15人の天下りを受け入れていた[10]。
ITゼネコン登場の背景[編集]
通常、大手企業や官公庁の仕事を受注するには経営規模が大きい方が有利である。中小のSIerが直接受注したとしても、開発リソース等の面で要求に応えきれない[11]。また万が一システム開発に失敗し多額の損害賠償を求められた場合に、資金的なリスクを負担しきれない。例えばスルガ銀行が日本IBMに対し、システム開発失敗に伴う損害賠償として111億7000万円の支払を求める訴訟を起こした[12]。
このような問題に対しジョイントベンチャーなどで対応できる。マルチベンダー開発ともいわれるが、
ベンダー同士による連携コストが高い
機能で切り分けても共通処理・非機能要件・想定外な部分であいまいになりマネジメントしづらい
問題発生時に責任の所在が不明になりやすい
など問題もあり発注者の負担も大きくなる。結果、システム構築でマネジメント力のない発注者は大規模開発ができる大手ITベンダーに発注する流れとなっている。
技術的な問題として、各社独自の設計様式がある。メインフレームの時代、大手コンピュータメーカーの提供する大型コンピュータの仕様は非公開であり、他のメーカーは保守や改修に関わりづらかった。そのため、1つのSIerが受注した後は、同じSIerに対して費用を払い続けるという構造が成立していた[13]。その後、オープンシステムが普及し、異なるSIerがシステムの保守・運用に途中から参入することが容易になると期待された。しかしオープンシステムでも既に完成したプログラムの内部仕様を開発元以外のSIerが把握することは難しかった。技術的には、昔から出入りしていた企業の既得権益は守られやすいのである（ベンダロックイン）。
最大の要因は、政府調達制度が単年度会計原則であるため、「初年度安値落札・次年度以降随意契約ビジネスモデル」が一般的となり、次年度以降の高額な随意契約を暗黙の前提として、初年度は極端な安値落札を行うというビジネスモデルが慣習化していることである。1円入札が行われる場合すらある。このようなルールの下では、役所の仕組みに精通し、初年度の赤字に耐える経営体力のある大企業が圧倒的に有利で、中小企業の新規参入は難しい。
天下りの問題がある。ITゼネコンは官僚の天下りを受け入れたことで、官公庁との太いパイプを維持してきた。例えばNTTデータやその関連会社は、厚生労働省や社会保険庁の官僚を受け入れた一方で[14]、契約見直しの最中であったこと等から正式な利用契約の締結まで至っておらず、年間1000億円、累計1兆円もの取引を行っていたことが[15][16]、年金記録問題で明らかになった。天下りによる癒着で随意契約すら形骸化しており、天下りを受け入れていない中小のSIerの参入機会は皆無なのである。現在は各業者も見直しを行っており、天下りの受け入れは減っている。
このようにして、旧電電ファミリー企業のように昔から役所に出入りしていた大企業が利幅の大きな公共事業を押さえて、ITゼネコン化していった。
ITゼネコンの弊害[編集]
ITゼネコンも建設業界のゼネコンと同じく、高コストで無駄な公共事業の元凶になっている。経済産業研究所の報告書はこれを裏付けている。また池田信夫は地球シミュレータを例に挙げて、ITゼネコンによる税金と人材の浪費を批判している[17]。ベンダーの言い値で発注していると言う意見もある[18]。
新興企業が現れにくい・育たないことも問題である[1]。日本のIT業界はそのイメージとは異なり、古色蒼然とした業界である。情報通信白書によると[19]、売上高が80億ドル（約1兆円）を超える日本の主要ICTベンダーは、大半が1950年代以前に設立されており、1960年代以降に設立されたのはNTTから分社化した、NTTデータのみである。経済産業研究所の報告書でも、政府調達に中小企業が参入できない現状が指摘されている。
IT業界で働く大半が指示された単純な仕事をこなすだけとなり、高度な技能を有する人材が不足する原因ともされる[1]。ソフトウェア技術者でライターでもある中島聡は自らのブログで、上流のエンジニアが設計し下流のエンジニアがコーディングするという建築業界のような下請け構造が日本のソフトウェアの国際競争力を失わせたのではないかと指摘し、批判している[20]。
政府調達制度の改革[編集]
2001年（平成13年）12月 - 情報システムに係る政府調達府省連絡会議の設置。
2002年（平成14年）3月 - 「情報システムに係る政府調達制度の見直しについて」を策定[21]。
2007年（平成19年）3月 - 「情報システムに係る政府調達の基本指針」を決定[22]。
脚注[編集]
[脚注の使い方]
^ a b c d “私はロボット？ IT人材が育たぬ国、背景に「ゼネコン体質」：朝日新聞デジタル”. 朝日新聞デジタル. 2021年10月29日閲覧。
^ 第23回 「ITゼネコン構造」の日本と専門職意識のインド、どちらがよい？ ビジネス-竹田孝治のインドIT見聞録:IT-PLUS
^ 電気通信関係の発注で一大発注者であった電電公社（NTTの前身）の機器やメンテナンスを受注していた諸企業群を「電電ファミリー」と呼ぶ[1]。
^ 佐高信『戦後企業事件史』 ISBN 978-4-06-149191-5
^ 「社保庁システム、総額１兆４千億円 委託先に幹部天下り」 朝日新聞2007年06月14日
^ “ITゼネコンとは？下請け構造から見える課題を現場視点で解説！”. IT転職・SE転職を徹底支援するIT業界の歩き方. 2020年7月29日閲覧。
^ なお、NTTデータは契約はあったと反論している。社会保険オンラインシステムに関する一部報道について 2007年06月29日
^ “Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている”. 2022年8月23日閲覧。
関連項目[編集]
この項目は、コンピュータに関連した書きかけの項目です。この項目を加筆・訂正などしてくださる協力者を求めています（PJ:コンピュータ/P:コンピュータ）。
ゼネコン
出典: フリー百科事典『ウィキペディア（Wikipedia）』
この項目では、建設業者について説明しています。軸部を手で回すことにより電磁誘導を発生させ電気を起こす発電機については「手回し発電機」をご覧ください。
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方）
出典検索?: "ゼネコン" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL（2014年3月）
ゼネコンは、元請負者として各種の土木・建築工事を一式で発注者から直接請負い、工事全体のとりまとめを行う建設業者を指す。日本語では総合工事業者（そうごうこうじぎょうしゃ）[1][2]、総合建設業（そうごうけんせつぎょうしゃ）に該当する。
語源[編集]
この記事は言葉を濁した曖昧な記述になっています。Wikipedia:言葉を濁さないおよびWikipedia:避けたい言葉を参考に修正してください。（2014年3月）
ゼネコンは、"general contractor"（ゼネラル・コントラクター）の略である[1][2]。英語でcontractor（コントラクター）は建設工事分野の「請負者」という意味を指し、general contractor（ゼネラル・コントラクター、すなわち「総合工事業（者）」[1][2]又は「総合請負（者）」）は、特定工種の工事だけを委託 specialist contractor（専門工事業（者））あるいは元請業者から工事の一部を委託subcontractor（下請業（者）・サブコン・協力会社）に対する用語である。
ただし一般的に、欧米でgeneral contractorと呼ばれる建設業者は比較的小規模であることが多く（特定工種に特化せず、よろず屋的にあらゆる工事を請け負う建設業者という意味合いが強い）[要出典]、スーパーゼネコンに代表されるような、各種専門工事業者の複合体である日本の総合建設業（ゼネコン）の業態をGeneral Contractorという英語で表現することは、必ずしも適切でない面がある。[要出典]
generalの「ゼネラル」への転写や、「ゼネコン」という略し方は、日本語独自のものである。
日本のゼネコン[編集]
日本では、第二次世界大戦後の高度経済成長期に建設需要が飛躍的に伸びたことで、急成長を遂げたゼネコンだったが、計画的に経営（経理）遂行をしなかった企業があり、資本を組む前に建設を始めたが急成長した会社もある。バブル崩壊後の建設需要の低迷、構造改革による政府の公共事業縮小などが原因で、1990年代後半から2000年代初頭には準大手以下で経営破綻に追い込まれたり、金融機関などの債権放棄・合併（クレジット）などで意地を見せた企業があり統合は別である。統合と言う事を言われ始めたのは数年後である。
多くのゼネコンでは、建設業法上の複数の建設業許可を有する一方で、得意とする分野に特化するものや、その成り立ちから鉄道事業者や鉱業会社・鉄鋼会社の系列であるものも少なくない。前者については、国や自治体の競争入札において専門工事を分割発注する傾向が見られる等の理由もあって、ゼネコンから専門工事部門を分社化、子会社化したり、事業合弁により複数社の専門工事部門からなる新たな専門工事業者が組織されるなどの動きも見られる。
スーパーゼネコン[編集]
2020年度の売上高（単独）が1兆円を超えるゼネコン。建築・土木ともに日本を代表する建設工事を手掛ける。
日本における建設大手のうち完成工事高上位5社を、その歴史と規模などから俗にスーパーゼネコンと呼ぶ。
スーパーゼネコンは、建設工事の施工を営業の中核として、社内に設計部門・エンジニアリング部門・研究開発部門を抱えており、建設に関する幅広い技術力を生かし成長をしている。
欧米の建設業界では、設計業と施工業は設計会社、施工会社と別会社組織で、明確な分業体制をとっているが、日本のスーパーゼネコンは世界的に見てもかなり特異的な経営方針を行っている。
準大手ゼネコン[編集]
2020年度の売上高（単独）が3,000億円を超えるゼネコン。スーパーゼネコンにつぐ規模で、土木・建築・不動産開発など大型工事を手掛ける。
中堅ゼネコン[編集]
2020年度の売上高（単独）が1,500億円を超えるゼネコン。
その他の主要ゼネコン[編集]
JRグループ
私鉄系
その他企業系列
主要地方ゼネコン
伊藤組土建（北海道が地盤）
平野組（岩手県が地盤）
佐藤工業（福島県が地盤。KTI川田グループの佐藤工業とは無関係）
福浜大一建設（同上）
植木組（新潟県が地盤）
加賀田組（同上）
本間組（同上）
真柄建設（石川県が地盤。2008年7月5日に民事再生法適用を申請）
北野建設（長野県が地盤）
守谷商会（同上）
長田組土木（山梨県が地盤。2008年2月に民事再生法適用を申請）
早野組（同上）
佐田建設（群馬県が地盤）
関東建設工業（同上）
株木建設（茨城県が地盤）
伊田テクノス（埼玉県が地盤）
徳倉建設（愛知県が地盤）
TSUCHIYA（旧・土屋組。岐阜県が地盤）
日本土建（三重県が地盤）
奥村組土木興業（大阪府が地盤。中堅ゼネコンの奥村組とは無関係）
金下建設（京都府が地盤）
桑原組（滋賀県が地盤）
新井組（兵庫県が地盤。2008年10月8日に民事再生法適用を申請。経営破綻するまでNISグループ傘下）現スピードパートナーズ傘下
村本建設（奈良県が地盤）
淺川組（和歌山県が地盤）
アイサワ工業（岡山県が地盤）
大本組（同上）
増岡組（広島県が地盤）
二神組（愛媛県が地盤）
大旺新洋（旧・大旺建設。高知県が地盤）
姫野組（徳島県が地盤）
岩永組（熊本県が地盤）
梅林建設（大分県が地盤）
佐伯建設（同上。旧・佐伯建設工業（現・あおみ建設）の九州支店が独立）
國場組（沖縄県が地盤）
その他
建設会社における「組」[編集]
建設会社の商号には、「大林組」、「熊谷組」、「鴻池組」といったように「組」を使用している会社は多くある。これは江戸から明治にかけて現在の建設業の始まりともいえる大工たちの労働組織が一棟梁単位で分けられ、それを「○○組」と呼んでいたことに由来する。なお、暴力団に「○○組」と名乗っている組織が多いのは、この時期に博徒の多くが取り締まりから逃れる為に土木建築請負の看板を利用したからであって（ヤクザを参照）、それ以上の関連は無い。世間の多くの人々は、建設会社と暴力団との両者に何らかの関連性があるものと誤解しているため、正しい知識が必要である。現在でも伝統を重んじる姿勢から「○○組」という名称を用いる建設会社が多い。
脚注[編集]
[脚注の使い方]
関連項目[編集]
よろしければサポートお願い致します。いただいたサポートはこれからの投資のために使わせていただきます。