人月の神話―狼人間を撃つ銀の弾はない [プログラミング]
著者はIBMのシステム/360の開発マネージャーをしたひとで、最初の版は1975年に出版された。
ソフトウエア開発について述べた本がほとんどないなかで大きな反響を呼び、この版は20周年記念の増補版
なぜソフトウェア開発（特に大規模なもの）は予算も工期も予定通り進まないのか？
それは人と月が交換可能だという神話による。人を増やせば、その分その人の教育、これまでの情報の伝達が必要で、コミュニケーションの手間がかかることになる。だから生産性はかえって低下するのだ。しかもプログラマの生産性は調査によると10倍の差があるという。これをすべて均一な能力があると見積もるのも無理がある。
ソフトウェア開発で大切なのはアーキテクトの一貫性である、デザインと実現はわけるべきである。そして外科手術のようにチームで役割分担して仕事をすべきである。そして最初からアーキテクトの一貫性をつらぬく仕掛け(プログラム手引書など）をもつべきである。
絶対的に有効な処方箋はないにしても、役割を分担すること、手引書、打ち合わせ、電話などのコミュニケーションをとることで被害をもっとも小さくすることができるはずだ。
第1章 タールの沼
大規模開発チームが長い期間かけてつくりあげたものより、二人のプログラマがガレージでつくったものの方が優れているという意見がある。しかし、大規模開発チームはなくなってはいない。その理由は作り出されるものの違いである。
プログラム自体をつくりだすのは短くても、それをプログラミング製品にするには、一般化、テストメンテナンスとその3倍の時間がかかり、プログラミングシステム（システム統合のインターフェース）にするには3倍の時間がかかる。この両方を兼ね備えたプログラミングシステム製品となると、プログラムの実に6倍の手間がかかるのだ。
プログラミングは創作意欲を満たす楽しい作業であるが、呪文を一句たりともまちがえてはいけない魔法であり、大規模になると他人のプログラムに依存することが必要になり、そのための時間がとられていくようになる。そしてデバックは果てしなく続くしらみの卵探しである。そうしてやっと作り上げたものは時代にあわなくなっていたりするのだ。
第2章 人月の神話
プログラマはみな楽観主義者である。「今度こそきっとうまくいく」「バグはこれが最後」と思っている。それを前提にスケジュールをたててしまう。しかし私たちのアイデアの不完全さや不整合性は実現段階になってはじめてわかるのだ。すべての仕事がうまくいく確率はゼロに近い。
仕事の単位「人月」はあやまり、仕事の大きさを測る単位としての人月は疑うべき危険な神話。人と月は交換できない。
人と月が交換できるのは作業者の間でコミュニケーション（意思疎通）を図らなくても仕事が分担できる場合である。コミュニケーションを図ることで増える負担は教育・訓練と相互コミュニケーションからなる。負担の増加分は要因にあわせて増えるので、要員をふやしてもスケジュールは短くならない。
楽観主義者たちはバグの数を実際より少なくみつもって間違ったスケジューリングをしてしまう。著者の目安、1/3計画、1/6コーディング、1/4単体テストおよび初期テスト、1/4システムテスト。特にシステムテストには十分時間をかけるべきである。
見積りの精度をあげるには、生産性やバグの発生率の数量化、見積り基準の開発をすること。
遅れているソフトウェアプロジェクトへの要因追加はさらに遅らせるだけの例。
第3章 外科手術チーム
少数精鋭チームが、何百人もの二流プログラマを抱えたプロジェクトより望ましいという意見がある。その通りではあるが、大きなシステムをつくるときには少数精鋭チーム（通常10人以下）では時間がかかりすぎる。確かに効率性とコンセプトの完全性は小数精鋭チームがよいが、時間がかかりすぎればタイムリーに製品をだせなくなる。
ハーラン。ミルズは大規模な仕事の各セグメントに外科手術チームのように編成されたチームでとりくむことを提唱している。デザインと構造は少ない人数で考えだし、実際の作業開発には人をたくさん投入する。
外科手術チームをモデルに考えたプログラミングチームの役割分担
執刀医・・・チーフプログラマ、プログラムをデザインしコーディングしテストしてドキュメントを書く。プログラムのバージョン管理のほか、文書管理にもアクセスできる。才能と10年以上の経験がある。
福執刀医・・・執刀医の分身で、どの仕事もこなせるがまだ経験の浅いもの。
管理者・・・執刀医はボスであるが、人事や昇給設備には手がまわらないので、そこを補う。
編集者・・・執刀医の文書作成をたすける
二人の秘書・・・管理者と編集者につける
プログラム事務係・・・チームの技術記録全般のメンテナンスをうけもつ。これによりプログラムコードが個人のものではなく、全体のものであるという認識ができ、プログラミングを個人の技術から集団の技術に変えることができる。
ツール製作者・・・用途の限られたユーティリティやカタログ化されたプロシージャやマクロライブラリを作成する。
テスト担当者・・・制作中と終わってからの全体をテストするためのテストケースを用意する、テスト環境を整える。
言語エキスパート・・・プログラミング言語の複雑さを習得することに喜びを覚える人をこれにあてる。言語を巧妙に効率よく使うための助言を求める。一人の言語エキスパートが2-3人の執刀医をサポートする。
こうすることで、システムそのものは一心同体の二人が考えだしたものになる。
また、主従関係がはっきりしているので、判断をめぐって相違がでない。役割が特化されているのでコミュニケーションが簡素化される。
大規模開発チーム（5千人年）にこのコンセプトをとりいれるには、各部分でのコンセプトの完全性が根本的にかいぜんされてデザイナーの数が1/7になれば成功である。調整には独自のテクニックがいるが、トップダウンでシステムアーキテクトがデザインされることが肝要である。
第4章 貴族政治、民主政治、そしてシステムデザイン
コンセプトの完全性ことはシステムデザインにおいてもっとも重要な考慮点。
機能と簡潔さの比率がシステムデザインの究極の試金石。どちらかだけではいけない。
大規模プロジェクトではアーキテクチャとインプリメンテーションを切り離すことはコンセプトの完全性を得る強力な方法。
システムのアーキテクチャとは、ユーザーインターフェースについての完全かつ詳細な仕様書である。コンピュータにとってはプログラミングマニュアルであり、コンパイラにとっては言語マニュアルである。
「アーキテクチャは何が起こるかを語るのにインプリメンテーションはいかにして起こせるかを語るのだ」
アーキテクトだけがアーキテクチャについてよいアイデアをもっているわけではない。しかしコンセプトと合わないものはすぐれた機能やアイデアでも除外することがいい。コンセプトの完全性をもとめるなら、だれかがコンセプトをコントロールしなければならない。
アーキテクチャの外部規定はインプリメンテーションの創造性を拘束するのではなく、むしろ高める効果があることをみてきた。
アーキテクトが決定するまでインプリメンテーション担当はすることがない。だからといってインプリメンテーショングループに仕様書作成をまかせてはいけない。仕様書ができるまでは、システムの機能の大雑把な概要をもとに、システム構成の理解や、モジュール境界、テーブル構造、工程の細分化、アルゴリズム、ツールデザインなどの仕事があるし、アーキテクトとのコミュニケーションも必要だ。
実現段階でも、プログラミング技法の選定や、機械の習得など多くのすべきことはある。
経験上、統合されたシステムの方がより早く調和し、テスト時間が短くなることが実証されている。
第5章 セカンドシステム症候群
アーキテクトの創作意欲に弾みを与えるのはアーキテクトと実現者の間で交わされる徹底的で注意深く、さらに相手の立場を考慮したコミュニケーションである。
見積りが高くなりすぎる場合、アーキテクトはデザインを切り詰めるか、インプリメンテーションを安く抑えるかを選ぶ、後者を選ぶなら感情的対立を避ける為に穏やかに非公式に、インプリメンテーション側に創意工夫および創造の責任があることを常に忘れないようにすること。相手の提案をうけいれるようにすること。通常実現者はアーキテクトを変更するという提案で対抗してくる、それが正しいこともよくある
最初の仕事は自生して、余計な機能やアイデアはいれないでいられるが、二度目はこの時制がきかなくなってしまうことがよくある。また時の流れとともにシステムの基本的前提が変化して技術自体がすでに時代遅れの考え方になっているのに、それを改良しようとする間違いもよくある。
これらを踏まえた十分な自己鍛錬がアーキテクトには必要である。
第6章 命令を伝える
マネージャがアーキテクトの決定内容を全員にしらせ、コンセプトを維持するために、仕様書とマニュアルは必要なツール。つくるときには一人かせいぜい二人で一貫性が必要。制限事項(規定されていないもの）を定義する。
定義を周知徹底させるため、パラメータもしくは強要ストレージの宣言をデザインしてきめてコンパイルする方法がある
ミーティングは2階層で、第一階層はアーキテクト全員とハードソフトの実現者の代表と市場規格車を加えた週に半日の会議。ここで蓄積された予測されなかった問題や、抗議や不満を解決するための年1回の全体会議が2週間。本当は半年がよかったとおもうそうだ。
システム/360のアーキテクトは複数のインプリメンテーションの同時開発が行われ、仕様書を徹底させるうえで抜群の働きをした。
インプリメンテーションが進むといかに仕様書が的確でも解釈の疑問が出てくる、ここで困惑した実現者に推察して先にすすまれると困るので、アーキテクトに電話させるのは大切なこと、そしてそれを記録する。
仕様書に即して機械とプログラムをチェックし、重箱の隅をつつく製品テストグループは製品マネージャにとって最良の友。最終的には顧客が独立した監査役である。
第7章 バベルの塔はなぜ失敗におわったか
どんな崇高な目的や機材があってもコミュニケーションとそれから生まれる組織がなければプロジェクトは失敗に終わる。
チームの相互のコミュニケーションをとる方法
・非公式な方法による電話サービス
・定期的ミーティング
・手引書
プロジェクト手引書は、プロジェクトで作成される文書はプロジェクト手引書の構成に従わなくてはならない。構成が先にあることで良質なマニュアルが生まれる。情報を伝達し、すべの必要な人に伝わるようにするために手引書は必要。OS/360では先に手引書をつくり書くプログラマが全資料を読まなくてはいけなくした、またタイムリーな更新をおこなった。手引書が厚くなったのでマイクロフィッシュに切り替えたという。方法はともかく今でも手引書は必要とされている。
コミュニケーションは人数が増えるにしたがって必要になる。不要にするには作業の分割と機能の専門化しかない。
プロジェクト開発組織には制作主任＝マネージャと技術主任＝アーキテクトが必要。
小規模なら両方を一人できるが、二人いる場合はその関係がどのようであれば成功するか述べていた。
第8章 予告宣言する
独立した小さいプログラム開発のデータはプログラミングシステム製品にはあてはまらない。
ICLのチャールズ・ポートマンの調査ではプログラマは機械の故障やミーティング、事務、病気などで時間の半分しかプログラミング・デバッグにあてられていなかった。一人あたりの作業時間数がまちがっていたのである。
いろんな大規模プロジェクトにおける生産性のデータ。作業そのものの複雑さと難しさで生産性の違いがある。適切な高水準言語を使うと生産性はあがる可能性がある。
第9章 5ポンド袋に詰め込んだ10ポンド
プログラムが占めるスペースは主要なコスト。システムデザイナはそれが何をしてくれるものなのか考えて常駐させるか決定し、プログラマはなるべくコストを抑えるテクニックを考えるべき。
常駐スペースだけでなく、全体サイズの割り当ても行う。そうしないと実行スピードが(ハードウェアアクセスによって）おそくなる。モジュールのすべきことを明確にし、サイズを指定せよ。
メモリとスピードはトレードオフである。うまく対処できるようにプログラミングテクニックの習得を十分にさせ、なるべく短期間で学び共有する必要がある。またコンポーネントを汲みたてなければならないということを認識させよ。
職人技をこえたところにアイデアがあり、簡潔で余分なところがなくて
スピードの速いプログラムが生まれるのは戦略的突破である。これは新しいアルゴリズムである場合もあるが、むしろデータやテーブル表現のやり直しの場合が多い。
第10章 文書の前提
ソフトウェアプロジェクトで文書が実際どのように機能するのか理解し、役立てる。
コンピュータ製品のための文書の例
大学の学部のための文書の例
ソフトウェアプロジェクトのための文書の例
マネージャの仕事は計画を作成してそれを実現することだが、文書化された計画の実が明確で伝達可能だ。
何を・いつ・いくら・どこで・だれがという文書が構成されるはずだ。そしてその重要性がわかれば、マネージャーは文書作成を面倒な仕事でなく、使いやすい道具として対処できる。
第11章 一つは捨て石にするつもりで
化学工業では研究所でうまくいく工程でも工場では一足飛びに実施できないことがわかっていた。プログラミングシステム製作も同じである。最高のプランニングでさえも一回で成功するほどには計算されつくされていない。
不変なものは変化そのものだけだ。だｋら変化に備えるシステム計画＝変更の量子化、組織計画＝IBMの二重昇進機構が必要なのだ。
プログラムは配布されたあとも変化する＝プログラムメンテナンスがあるのが普通。
MITのベティ・キャンベルの研究ではインストール後の経過月数と1か月のバグ発見数は、一時おちたあと、再び上昇するそうだ。これはごく小さな欠陥がなにか局所的エラーに見えるが、実際にはシステム全体の問題であることが多いからである。修正の際に以前のシステムテストをすべて実施することはできないので、副作用が発生するのだ。
M・レーマンとL/ベラディの大規模オペレーティングシステムのリリース研究によると、リリース番号とともにモジュールの総数は線形に増加するが、影響をうけるモジュールは指数的に増加するとわかった。修正は創造を破壊する。常に最初が最高の状態であるのだ。プログラムメンテナンスはどんなに器用におこなっても、エントロピー増大なのだ。
第12章 切れ味のいい道具
熟練した機械工は長年にわたり収集し、大切にしまって守ってきた7つ道具をもっている。
熟練したプログラマも同じように、自分用に役に立つユーティリティをもっているものだ、これをチームで使えるように専門のツール製作者をおこう。
マネージャーが方針をたてて計画するのはソフトツールだけでなく、コンピュータ設備、オペレーティングシステム、言語、ユーティリティ、デバック支援、テストケース生成、文書作成用テキスト処理システムである。
ひとつひとつ解説していた。
もっとも重要なのは高水準言語と対話型プログラミングといってた。
第13章 全体と部分
どのようにしてきちんと動くプログラムを作るのか？どのようにプログラムをテストするのか、テスト済みにコンポーネントプログラム一式を統合し信頼できるシステムにする方法は？
・バグを取り除くデザインにする。
コンポーネント間の前提の不整合、コードが出来上がる前に仕様書をテストする、トップダウンデザイン、構造化プログラミング
・コンポーネントのデバッグ
デバッグ方法の変遷、機械上でのデバッグ、メモリダンプ、スナップショット（選択ダンプや選択トレース）、対話型デバック、テストケース
・システムデバッグ もっとも予想外に困難なもの
デバッグ済みコンポーネントを使う、十分な足場固めをする（すべてのプログラムとデータ、あるいはダミーコンポーネントとミニチュアファイル、補助プログラムによる分析やテストケース生成）、変更の統制方法をもつ、一回に追加するコンポーネントは一つにする、更新を量子化する
第14章 破局を生み出すこと
たいていの遅れは日ごとに発生し蓄積し、気づくことも予防することも取り戻すことも困難になる。
スケジュールにマイルストーンを置く、これは具体的で明確で測定可能なイベントでなければらなない。
どうせ他の部分もおくれているんだからは、使ってはいけない口実
上司は行動をとるための情報と状況を理解するための情報を区別して、行動にはたちいらないよう自制すべき。ミーティングは状況検討のためか、問題対策のために開くのかはっきり区別する。
こうしたプランをコントロールするグループをもつことはとこても有効である。
第15章 もう一つの顔
書き上げられたプログラムは人間から機械へのメッセージであるか、人間の利用者に語りかける顔をもつ。
プログラムを使用するために必要な文書を解説。
プログラムを信用するために必要な文書(正常に実行されているか）
プログラムを修正するための文書、フローチャートは過大評価されている。
ソースに文書を組み込む自己文書プログラムを推奨していた。ソースコードが増大するが、その価値はある。
第16章 銀の弾などない ソフトウェアエンジニアリングの本質と偶有的事項
すべてのソフトウェアの構築には本質的作業として抽象的なソフトウェア実態を構成する複雑な概念構造体を作り上げることと、偶有的作業としてそうした抽象的実在をプログラミング言語で表現し、それをメモリスペースとスピードの制約内で機械言語に写像することが含まれている。
過去のソフトウェアの生産性における大きな収穫のほとんどは、偶有的作業をはなはだ困難にする人為的障害を除去すること（きびしいハードウェアの制約、扱いにくいプログラミング言語、機械使用時間の不足など）で得られた。これからは本質的な部分について議論すべき。
狼人間を倒す銀の弾のように、ハードウェアのコストを下げるのと同じように、ソフトウェアのコストも劇的に下げてくれる特効薬を私たちはもとめるが、10年間は（1986年から）ありそうもない。しかし王道はなくても道はある。
ハードウェアの発達があまりに速いために、ソフトウェアはまったく進歩していなくみえるということもある。
ソフトウェア構築において困難な部分は、この概念構造体の仕様書作成とデザイン・テストにあって、表現することやその表現に忠実化をテストすることではない。構文上の誤りはコンセプトの誤りに比べると大したことはない。
ソフトウェアの基本的要素に含まれる固有の性質は、複雑性（どの二つの部分をとっても似ることがない、そしてソフトが大きくなると複雑性が非線形的に増す、そして技術も管理も信頼性がなくなる）、同調性（物理のように統一原理はなく、最後に登場したもの、従わせやすいとみなされるものに従う）、可変性（常に変更という圧力にさらされていて、そして制作されたものより容易に変更できるのでさせられる）、不可視性（視覚化できない、そのため一人の人間のデザインプロセスを妨げるだけでなく、コミュニケーションの妨害になる）
過去にもっとも成果のあったソフトウェアテクノロジーの三段階の発展、いずれも偶有的困難で本質的ではない。高水準言語、タイムシェアリング、統一されたプログラミング環境
銀の弾になる可能性があるものとして最も発展をとてげている技術
・Adaとその他の高水準言語の進歩。Adaの哲学（デザインとモジュール化概念）は言語以上に進んでいるが、機能が豊富すぎるし、言語である以上は銀の弾にはならないであろう
・オブジェクト指向・・・デザインの本質を表現するのに向いているが、デザインの複雑性は本質的で、それを変えることはできないので銀の弾になりえない
・人工知能・・・問題ごとに技術が異なるので期待できないと思う
・エキスパートシステム・・・一般化した推論とルールベースを持つプログラム、ただしつくるのにエキスパートがいる
・「自動」プログラミング・・・整ったケース（ソートや微分方程式）ならできても、通常はそうではない
・ビジュアルプログラミング・・・フローチャートから製作するのだが、フローチャートはソフトウェア構造を抽象化するにしては貧弱、現在のピクセルで表示される画像はソフトウェア構成図の詳細を表示するには範囲と解像度の両方で貧弱。そしてソフトウェアの視覚化は難しい。
・プログラム検証・・・膨大な労力を投入して実現やコストを行う前にデザインを修正しようという考え、これを行ってもプログラムが仕様書とあっていることを立証するだけで、完全で一貫した仕様書を作る役にはたたない
・環境とツール・・・階層型ファイルシステム、統一ファイルフォーマット、一般化されたツールは役にたっている。やがては統合データベースシステムが役にたつ。しかし本来の性質からあまり役にたちそうもない
・ワークステーション・・・プログラムや文書作成には十分。コンパイルはまだ早くなるだろうが、プログラマの思考時間は短くはならない
コンセプトの本質への有望な戦略
・購入対自主製作・・・製作のコストを購入者全員で負担するから安い。スプレッドシートと簡易データベースとう劇的なツールにより、多くの企業にとってソフトウェア生産性をあげる最強にして唯一の戦略は、コンピュータ初心者の知的労働者にPCとすぐれた汎用ワープロ、描画プログラム、ファイル管理プログラム、スプレッドシートを与えることであり、科学者なら数学や統計の汎用パッケージと若干の単純なプログラミング能力があればいいということになる。
ソフトウェア構築のもっとも困難な部分は、何を構築するのか的確に決定すること。そして顧客自身も自分の欲しいものがわかっておらず、しかも自分が要件を指定した製品を数バージョン使ってみなければ、正しい要件を指定することは不可能。だからソフトウェア問題に対する技術的な努力でもっとも有望で、偶有的事項でなく本質を攻略するものは、対話しながら要件を指定していく方法の一部としてシステムのプロトタイピングを迅速に行うアプローチの仕方とツールを開発すること。
ソフトウェアを建築にたとえ、構築するといったのは強力なメタファーだったが、今日では構築する概念が複雑すぎて前もって正確に指定することができず、欠陥なしに構築できないので、アプローチを変えるべき。複雑な生命をモデルに脳のようにソフトウェアを育てる＝漸増敵開発と考えてみる。この方法はトップダウンのデザインを伴うので後戻りが容易で、初期のプロトタイプがそのまま使え、追加された機能や新しく加えたものが、すでにあるものから生物の器官のように育っていく。しかもすでに稼働中のシステムは「やる気」を跳ね上げる効果がある。著者の演習で証明されているそうな。
ソフトウェア技法の改善はまず人間の問題に集中する。すぐれた練習法は教えることが可能。しかし、優れたデザインと偉大なデザインとの差は、偉大なデザイナーかどうかで決まる。ソフトウェア構築は創造的プロセスであり、こつこつ仕事をする人＝優秀なデザインができるひとを、偉大なデザイナーにすることはできない。だから偉大なデザイナーを開発する努力をソフトウェア会社や団体はするべきだ。
第17章 「銀の弾などない」再発射
銀の弾などないの論文にはたくさんの反論がきた。主に自分は銀の弾を開発したというものだ。著者は自腹で購入した利用者が正真正銘、これを使ったらソフトウェアの生産性が10倍改善された」といったら銀の弾が発射されたとみなすと書いていた。
偶有的は偶発発生したとか災難ではなく、副次的とか付随の意味でつかっている。ソフトウェア開発ではインプリメンテーションのことである。
作業の偶有的または表現的部分は全体の半分以下に減っているというのが著者の主張。
ソフトウェアの難しさは概念構造体をつくる部分=本質にあるといっているのあって、再利用可能で互換性のあるコンポーネントで改善できるのは偶有的部分である。
ソフトウェア構造体における概念上の複雑性の大半は、アプリケーションそのものの自由さがもたらす複雑性からきている。ソフトウェア構造体における複雑性の大半は、外部世界への同調性によるものというよりは、むしろデータ構造やアルゴリズム、それに接続性などといったインプリメンテーション自体によるものだ。以前に作ったものを再利用したり、他の人が構築したものをつかうことで複雑性の全階層に直面しなくて済む。また階層化したモジュールやオブジェクトをもつ、漸増性は必要な複雑性であると述べている。
あまりに悲観的という意見もあるが、1986年当時に進行中のさまざまな改革が十分に開発利用された場合、それらを結び付けて生産性における大規模な改善が達成できると予想している、王道はないが道はある。ソフトウェアの本質そのものが銀の弾など見つからないようにさせていると書いたつもりだ。
1986年当時の銀の弾候補を個別に論じて却下したのは、どれも決定的秘薬であるとはいえなかったからだ。
ハレルは「銀の弾などない」が1952年にかかれたと仮定して思考実験をした＝背理法。でもそれは使えない。規模もちぐので。ハレルの主張するモデル化技法「バニラフレームワーク」は銀の弾候補である。またソフトウェアの概念構造体の多くが本来はまったく位相的であり、関係は空間的、図形的に自然に写せるといっている。著者の主張はソフトウェア構造は三次元空間に埋め込まれているのではないから、概念的デザインから図式への一つの自然な写像を得ることはできないということであって、まったくできないということではない。
ジョーンズは生産性より品質に焦点をあてるべきで、生産性は後からついてくると主張。系統だった品質管理の欠如はスケジュールの破たん殿相関関係があるというデータを提供している。
生産性を示す値は今きちんと定義されたものはない。しかしパッケージを購入することが生産性をあげることは証明されたと思っている。
オブジェクト指向の成長が遅かったのは程度のあまり高くない抽象化をおこなっていたからと主張する人がいる。事前のコストが高くつくのだ。
ソフトウェア構築の本質を攻略する最良の方法は全然構築しないこと。または再利用。継承して再利用というのはオブジェクト指向技法のもっとも大きな魅力。しかし、やってみると意外とてこずることもある。再利用はいま企業ではほとんどされていない。もっとも統計もあまりとられていないのだが。
思考レベルが高くなれば、取り扱わなければならない初歩的試行要素も多くなる。だからプログラミング言語は機械言語より複雑で自然言語はもっと複雑なのだ。再利用にはプログラミング語彙の大きさも関係してる。言語の習得法帆運い関する研究と知見が必要。
解決策についての要点は変わっていない。複雑性がわれわれのとりくんでいる仕事である、制約しているものである。登場しそうもない解決策＝銀の弾を待っているのではなくて、可能性のある漸増的な改善をすすめていくべきだ。
第18章 「人月の神話」の命題－真か偽か
1975年の提言のうち、データと経験によって支持されたもの、反証されたもの、時代遅れになったものを判断できるように、各章の真髄を並べたもの。
第19章 「人月の神話」から二十年を経て
人月の神話の息がながいのは、ソフトウェア開発という分じゃが正常に適切に進歩していないからだという意見がある。ハードウェアの生産性が二十年で千倍になっているので余計にそうみえるのだろう。しかしハードの方が異常なのだ。またソフトウェアについてではなく、チームでモノを作る方法について書かれているからだともいわれるが、当たっていると思う。
書いたときも正しく、現在も相変わらず正しいことについて考える。
・中心になる主張 コンセプトの完全性とアーキテクト
大規模プロジェクトで利用者という一人の頭脳から見たコンセプトの統一性をとるためにプロジェクト管理をするには、小規模プロジェクトとは異なる周到かつ大胆な管理行動が必要。アーキテクトは一人にする。アーキテクチャはインプリメンテーションと実現から分離する。アーキテクトの再帰利用（大きな製品は一人ですべてのアーキテクチャをこなせないので、サブシステムにわけて主任アーキテクトを置く）、コンセプトの完全性こそ、製品の品質にとって中心的なものであるという主張は、現在もより確信をもっていることである。
・セカンドシステム症候群－多機能主義と度数推測
汎用ツールをデザインする方が、特別な目的のツールをデザインするより難しい。多様な利用者のさまざまなニーズに重みづけをしないといけないので。市場が要求していると多機能主義に陥るにつれ使いやすさは消える。利用者群を定義すること、度数を推測するべきである。あいまいなままでいるより、明白に間違っているとわかる方がずっとまし。
・WIMPインターフェースの勝利
WIMP・・・ウィンドウ、アイコン、メニュー、ポインティングインターフェース、はコンセプトの完全性をもったユーザインターフェースの最高の例。メニューの使い勝手(コマンド＝動詞と名詞を指定する方法）を例に利用者の力と使いやすさのバランスをとるのもアーキテクトの直面する問題を述べていた。著者は1世代でWIMPは歴史的遺物になり、音声が動詞を表現する適切な方法になるといっている。
・捨て石にするつもりで構築してはならない－ウォーターフォールモデルは間違いだ
一つは捨て石にするつもりでは間違いであると考えるようになった。インプリメンテーションでアーキテクトはの修正がわかったら上流にもどることが必要、漸増的モデルの方が勝っている。どの段階でも実働システムがあり、それが「やる気」を引き出す。利用者による早期テストも行えるのだ。ソフトウェア製品を関連製品のファミリーとしてデザインするのはデービット・パルナスの考えで、変更されることがないと見込まれるデザイン部分の根元付近を基本製品においている。マイクロソフトは「毎晩構築」アプローチを使っている。
・情報隠ぺいに関して、パルナスは正しく私は誤っていた
モジュールコードは適切に定義されたインターフェースを使って隠ぺいすべきだというパルナスの主張を否定したが、今ではソフトウェアデザインのレベル上げる唯一の方法と確信している。パルナスの定義はオブジェクト指向プログラミングの知的先祖で、抽象データ型、継承、再利用のためにデザインされテスト済みのモジュールライブラリまたはクラスのアイデアである。
・人月はどの程度神話的なものか－べーむのモデルとデータ
バリー・ベームが63種類のソフトウェアプロジェクトについて行ったものによると、要員と月数の間のトレードオフは線形どころではなく、人月は生産性の尺度としては実に神話的だとするものであった。そしてコスト曲線についていくつかの発見をした。要員追加についての、細かい研究によると、どのようにどんな要員を追加するかについて有益な知見も得られている。やみくもな要因追加がプロジェクトを破たんさせるのはいうまでもない。
・人間がすべて（そう、だいたいのところは）
ピープルウェアは大きな収穫。技術的というより社会的。プロジェクトの移動をチームの融合の観点から注意を払っている。
・力を断念する力
創造性は個人から発するもので工程や組織から発生ｓるものではない。だから創造性を伸ばす組織と工程を感がることが必要だ。権限委譲である。
・最近あった最大の予想外の事件は何か？－何百万台ものコンピュータの普及
マイクロコンピュータ革命がコンピュータの利用方法を変えた。シューマッハの主張がかないつつある。マイクロコンピュータ革命がソフトウェアの構築方法を変えた。ネットワークの利用で変更やテストが楽におこなえるようになった。
・まったく新しいソフトウェア産業－パッケージソフトウェア
古典的ソフトウェア産業は分裂し、アプリケーションユーザーは細分化している、一方で機能豊富なソフトウェアパッケージが一人のプラグラマの一日のコストより少ない値段で購入できるようになった。OSの世界は小数に収れんした。
・購入して構築する－パッケージソフトをコンポーネントとして
これは概念構造体を作り上げることの本質を攻略するものだから急速に成長していくだろう。パッケージ利用者は、そのままの利用者、メタプログラマ、外部機能作成者、一つあるいは複数のアプリケーションをより大きなシステムのコンポーネントとして使用するメタプログラマに分類される。アプリケーション群のなかで相互作用をコントロールするスクリプト言語があると実に効果的。
・ソフトウェアエンジニアリングの現状と将来
化学工学とソフトウェアエンジニアリングの展開には類似点がある。パルナスはソフトウェアは電気工学のように数学的基礎をもったエンジニアリングとして展開できないといっている。ソフトウェアエンジニアリングは、経営工学同様、人間の行動の複雑性によって永久的に混乱させられるものなのかもしれない。ただし、絶望的なわけではなく、未熟なだけだと思う。当分はタールの沼であるであろう。しかし展開させていくことはできる。
エピローグ 五十年間の不思議 興奮 それに喜び
著者が13歳のときハーバード・マークIの記事を読んで、知識を大きなハイパーテキストのおりものとして構成し、既存の道に従いながら新しい連想の先鞭をつけるような機械を利用者に与えるという提案に興奮した。その後コンピュータの道をすすみつづけたが、この分野は爆発的に進歩してきている、すべてを把握することは難しくなり、周辺分野をすてているくらいだ。コンピュータ関連分野は進歩のスピードをゆるめず、終わりも見えない。これからますます楽しみだ。
ソフトウエア開発について述べた本がほとんどないなかで大きな反響を呼び、この版は20周年記念の増補版
なぜソフトウェア開発（特に大規模なもの）は予算も工期も予定通り進まないのか？
それは人と月が交換可能だという神話による。人を増やせば、その分その人の教育、これまでの情報の伝達が必要で、コミュニケーションの手間がかかることになる。だから生産性はかえって低下するのだ。しかもプログラマの生産性は調査によると10倍の差があるという。これをすべて均一な能力があると見積もるのも無理がある。
ソフトウェア開発で大切なのはアーキテクトの一貫性である、デザインと実現はわけるべきである。そして外科手術のようにチームで役割分担して仕事をすべきである。そして最初からアーキテクトの一貫性をつらぬく仕掛け(プログラム手引書など）をもつべきである。
絶対的に有効な処方箋はないにしても、役割を分担すること、手引書、打ち合わせ、電話などのコミュニケーションをとることで被害をもっとも小さくすることができるはずだ。
第1章 タールの沼
大規模開発チームが長い期間かけてつくりあげたものより、二人のプログラマがガレージでつくったものの方が優れているという意見がある。しかし、大規模開発チームはなくなってはいない。その理由は作り出されるものの違いである。
プログラム自体をつくりだすのは短くても、それをプログラミング製品にするには、一般化、テストメンテナンスとその3倍の時間がかかり、プログラミングシステム（システム統合のインターフェース）にするには3倍の時間がかかる。この両方を兼ね備えたプログラミングシステム製品となると、プログラムの実に6倍の手間がかかるのだ。
プログラミングは創作意欲を満たす楽しい作業であるが、呪文を一句たりともまちがえてはいけない魔法であり、大規模になると他人のプログラムに依存することが必要になり、そのための時間がとられていくようになる。そしてデバックは果てしなく続くしらみの卵探しである。そうしてやっと作り上げたものは時代にあわなくなっていたりするのだ。
第2章 人月の神話
プログラマはみな楽観主義者である。「今度こそきっとうまくいく」「バグはこれが最後」と思っている。それを前提にスケジュールをたててしまう。しかし私たちのアイデアの不完全さや不整合性は実現段階になってはじめてわかるのだ。すべての仕事がうまくいく確率はゼロに近い。
仕事の単位「人月」はあやまり、仕事の大きさを測る単位としての人月は疑うべき危険な神話。人と月は交換できない。
人と月が交換できるのは作業者の間でコミュニケーション（意思疎通）を図らなくても仕事が分担できる場合である。コミュニケーションを図ることで増える負担は教育・訓練と相互コミュニケーションからなる。負担の増加分は要因にあわせて増えるので、要員をふやしてもスケジュールは短くならない。
楽観主義者たちはバグの数を実際より少なくみつもって間違ったスケジューリングをしてしまう。著者の目安、1/3計画、1/6コーディング、1/4単体テストおよび初期テスト、1/4システムテスト。特にシステムテストには十分時間をかけるべきである。
見積りの精度をあげるには、生産性やバグの発生率の数量化、見積り基準の開発をすること。
遅れているソフトウェアプロジェクトへの要因追加はさらに遅らせるだけの例。
第3章 外科手術チーム
少数精鋭チームが、何百人もの二流プログラマを抱えたプロジェクトより望ましいという意見がある。その通りではあるが、大きなシステムをつくるときには少数精鋭チーム（通常10人以下）では時間がかかりすぎる。確かに効率性とコンセプトの完全性は小数精鋭チームがよいが、時間がかかりすぎればタイムリーに製品をだせなくなる。
ハーラン。ミルズは大規模な仕事の各セグメントに外科手術チームのように編成されたチームでとりくむことを提唱している。デザインと構造は少ない人数で考えだし、実際の作業開発には人をたくさん投入する。
外科手術チームをモデルに考えたプログラミングチームの役割分担
執刀医・・・チーフプログラマ、プログラムをデザインしコーディングしテストしてドキュメントを書く。プログラムのバージョン管理のほか、文書管理にもアクセスできる。才能と10年以上の経験がある。
福執刀医・・・執刀医の分身で、どの仕事もこなせるがまだ経験の浅いもの。
管理者・・・執刀医はボスであるが、人事や昇給設備には手がまわらないので、そこを補う。
編集者・・・執刀医の文書作成をたすける
二人の秘書・・・管理者と編集者につける
プログラム事務係・・・チームの技術記録全般のメンテナンスをうけもつ。これによりプログラムコードが個人のものではなく、全体のものであるという認識ができ、プログラミングを個人の技術から集団の技術に変えることができる。
ツール製作者・・・用途の限られたユーティリティやカタログ化されたプロシージャやマクロライブラリを作成する。
テスト担当者・・・制作中と終わってからの全体をテストするためのテストケースを用意する、テスト環境を整える。
言語エキスパート・・・プログラミング言語の複雑さを習得することに喜びを覚える人をこれにあてる。言語を巧妙に効率よく使うための助言を求める。一人の言語エキスパートが2-3人の執刀医をサポートする。
こうすることで、システムそのものは一心同体の二人が考えだしたものになる。
また、主従関係がはっきりしているので、判断をめぐって相違がでない。役割が特化されているのでコミュニケーションが簡素化される。
大規模開発チーム（5千人年）にこのコンセプトをとりいれるには、各部分でのコンセプトの完全性が根本的にかいぜんされてデザイナーの数が1/7になれば成功である。調整には独自のテクニックがいるが、トップダウンでシステムアーキテクトがデザインされることが肝要である。
第4章 貴族政治、民主政治、そしてシステムデザイン
コンセプトの完全性ことはシステムデザインにおいてもっとも重要な考慮点。
機能と簡潔さの比率がシステムデザインの究極の試金石。どちらかだけではいけない。
大規模プロジェクトではアーキテクチャとインプリメンテーションを切り離すことはコンセプトの完全性を得る強力な方法。
システムのアーキテクチャとは、ユーザーインターフェースについての完全かつ詳細な仕様書である。コンピュータにとってはプログラミングマニュアルであり、コンパイラにとっては言語マニュアルである。
「アーキテクチャは何が起こるかを語るのにインプリメンテーションはいかにして起こせるかを語るのだ」
アーキテクトだけがアーキテクチャについてよいアイデアをもっているわけではない。しかしコンセプトと合わないものはすぐれた機能やアイデアでも除外することがいい。コンセプトの完全性をもとめるなら、だれかがコンセプトをコントロールしなければならない。
アーキテクチャの外部規定はインプリメンテーションの創造性を拘束するのではなく、むしろ高める効果があることをみてきた。
アーキテクトが決定するまでインプリメンテーション担当はすることがない。だからといってインプリメンテーショングループに仕様書作成をまかせてはいけない。仕様書ができるまでは、システムの機能の大雑把な概要をもとに、システム構成の理解や、モジュール境界、テーブル構造、工程の細分化、アルゴリズム、ツールデザインなどの仕事があるし、アーキテクトとのコミュニケーションも必要だ。
実現段階でも、プログラミング技法の選定や、機械の習得など多くのすべきことはある。
経験上、統合されたシステムの方がより早く調和し、テスト時間が短くなることが実証されている。
第5章 セカンドシステム症候群
アーキテクトの創作意欲に弾みを与えるのはアーキテクトと実現者の間で交わされる徹底的で注意深く、さらに相手の立場を考慮したコミュニケーションである。
見積りが高くなりすぎる場合、アーキテクトはデザインを切り詰めるか、インプリメンテーションを安く抑えるかを選ぶ、後者を選ぶなら感情的対立を避ける為に穏やかに非公式に、インプリメンテーション側に創意工夫および創造の責任があることを常に忘れないようにすること。相手の提案をうけいれるようにすること。通常実現者はアーキテクトを変更するという提案で対抗してくる、それが正しいこともよくある
最初の仕事は自生して、余計な機能やアイデアはいれないでいられるが、二度目はこの時制がきかなくなってしまうことがよくある。また時の流れとともにシステムの基本的前提が変化して技術自体がすでに時代遅れの考え方になっているのに、それを改良しようとする間違いもよくある。
これらを踏まえた十分な自己鍛錬がアーキテクトには必要である。
第6章 命令を伝える
マネージャがアーキテクトの決定内容を全員にしらせ、コンセプトを維持するために、仕様書とマニュアルは必要なツール。つくるときには一人かせいぜい二人で一貫性が必要。制限事項(規定されていないもの）を定義する。
定義を周知徹底させるため、パラメータもしくは強要ストレージの宣言をデザインしてきめてコンパイルする方法がある
ミーティングは2階層で、第一階層はアーキテクト全員とハードソフトの実現者の代表と市場規格車を加えた週に半日の会議。ここで蓄積された予測されなかった問題や、抗議や不満を解決するための年1回の全体会議が2週間。本当は半年がよかったとおもうそうだ。
システム/360のアーキテクトは複数のインプリメンテーションの同時開発が行われ、仕様書を徹底させるうえで抜群の働きをした。
インプリメンテーションが進むといかに仕様書が的確でも解釈の疑問が出てくる、ここで困惑した実現者に推察して先にすすまれると困るので、アーキテクトに電話させるのは大切なこと、そしてそれを記録する。
仕様書に即して機械とプログラムをチェックし、重箱の隅をつつく製品テストグループは製品マネージャにとって最良の友。最終的には顧客が独立した監査役である。
第7章 バベルの塔はなぜ失敗におわったか
どんな崇高な目的や機材があってもコミュニケーションとそれから生まれる組織がなければプロジェクトは失敗に終わる。
チームの相互のコミュニケーションをとる方法
・非公式な方法による電話サービス
・定期的ミーティング
・手引書
プロジェクト手引書は、プロジェクトで作成される文書はプロジェクト手引書の構成に従わなくてはならない。構成が先にあることで良質なマニュアルが生まれる。情報を伝達し、すべの必要な人に伝わるようにするために手引書は必要。OS/360では先に手引書をつくり書くプログラマが全資料を読まなくてはいけなくした、またタイムリーな更新をおこなった。手引書が厚くなったのでマイクロフィッシュに切り替えたという。方法はともかく今でも手引書は必要とされている。
コミュニケーションは人数が増えるにしたがって必要になる。不要にするには作業の分割と機能の専門化しかない。
プロジェクト開発組織には制作主任＝マネージャと技術主任＝アーキテクトが必要。
小規模なら両方を一人できるが、二人いる場合はその関係がどのようであれば成功するか述べていた。
第8章 予告宣言する
独立した小さいプログラム開発のデータはプログラミングシステム製品にはあてはまらない。
ICLのチャールズ・ポートマンの調査ではプログラマは機械の故障やミーティング、事務、病気などで時間の半分しかプログラミング・デバッグにあてられていなかった。一人あたりの作業時間数がまちがっていたのである。
いろんな大規模プロジェクトにおける生産性のデータ。作業そのものの複雑さと難しさで生産性の違いがある。適切な高水準言語を使うと生産性はあがる可能性がある。
第9章 5ポンド袋に詰め込んだ10ポンド
プログラムが占めるスペースは主要なコスト。システムデザイナはそれが何をしてくれるものなのか考えて常駐させるか決定し、プログラマはなるべくコストを抑えるテクニックを考えるべき。
常駐スペースだけでなく、全体サイズの割り当ても行う。そうしないと実行スピードが(ハードウェアアクセスによって）おそくなる。モジュールのすべきことを明確にし、サイズを指定せよ。
メモリとスピードはトレードオフである。うまく対処できるようにプログラミングテクニックの習得を十分にさせ、なるべく短期間で学び共有する必要がある。またコンポーネントを汲みたてなければならないということを認識させよ。
職人技をこえたところにアイデアがあり、簡潔で余分なところがなくて
スピードの速いプログラムが生まれるのは戦略的突破である。これは新しいアルゴリズムである場合もあるが、むしろデータやテーブル表現のやり直しの場合が多い。
第10章 文書の前提
ソフトウェアプロジェクトで文書が実際どのように機能するのか理解し、役立てる。
コンピュータ製品のための文書の例
大学の学部のための文書の例
ソフトウェアプロジェクトのための文書の例
マネージャの仕事は計画を作成してそれを実現することだが、文書化された計画の実が明確で伝達可能だ。
何を・いつ・いくら・どこで・だれがという文書が構成されるはずだ。そしてその重要性がわかれば、マネージャーは文書作成を面倒な仕事でなく、使いやすい道具として対処できる。
第11章 一つは捨て石にするつもりで
化学工業では研究所でうまくいく工程でも工場では一足飛びに実施できないことがわかっていた。プログラミングシステム製作も同じである。最高のプランニングでさえも一回で成功するほどには計算されつくされていない。
不変なものは変化そのものだけだ。だｋら変化に備えるシステム計画＝変更の量子化、組織計画＝IBMの二重昇進機構が必要なのだ。
プログラムは配布されたあとも変化する＝プログラムメンテナンスがあるのが普通。
MITのベティ・キャンベルの研究ではインストール後の経過月数と1か月のバグ発見数は、一時おちたあと、再び上昇するそうだ。これはごく小さな欠陥がなにか局所的エラーに見えるが、実際にはシステム全体の問題であることが多いからである。修正の際に以前のシステムテストをすべて実施することはできないので、副作用が発生するのだ。
M・レーマンとL/ベラディの大規模オペレーティングシステムのリリース研究によると、リリース番号とともにモジュールの総数は線形に増加するが、影響をうけるモジュールは指数的に増加するとわかった。修正は創造を破壊する。常に最初が最高の状態であるのだ。プログラムメンテナンスはどんなに器用におこなっても、エントロピー増大なのだ。
第12章 切れ味のいい道具
熟練した機械工は長年にわたり収集し、大切にしまって守ってきた7つ道具をもっている。
熟練したプログラマも同じように、自分用に役に立つユーティリティをもっているものだ、これをチームで使えるように専門のツール製作者をおこう。
マネージャーが方針をたてて計画するのはソフトツールだけでなく、コンピュータ設備、オペレーティングシステム、言語、ユーティリティ、デバック支援、テストケース生成、文書作成用テキスト処理システムである。
ひとつひとつ解説していた。
もっとも重要なのは高水準言語と対話型プログラミングといってた。
第13章 全体と部分
どのようにしてきちんと動くプログラムを作るのか？どのようにプログラムをテストするのか、テスト済みにコンポーネントプログラム一式を統合し信頼できるシステムにする方法は？
・バグを取り除くデザインにする。
コンポーネント間の前提の不整合、コードが出来上がる前に仕様書をテストする、トップダウンデザイン、構造化プログラミング
・コンポーネントのデバッグ
デバッグ方法の変遷、機械上でのデバッグ、メモリダンプ、スナップショット（選択ダンプや選択トレース）、対話型デバック、テストケース
・システムデバッグ もっとも予想外に困難なもの
デバッグ済みコンポーネントを使う、十分な足場固めをする（すべてのプログラムとデータ、あるいはダミーコンポーネントとミニチュアファイル、補助プログラムによる分析やテストケース生成）、変更の統制方法をもつ、一回に追加するコンポーネントは一つにする、更新を量子化する
第14章 破局を生み出すこと
たいていの遅れは日ごとに発生し蓄積し、気づくことも予防することも取り戻すことも困難になる。
スケジュールにマイルストーンを置く、これは具体的で明確で測定可能なイベントでなければらなない。
どうせ他の部分もおくれているんだからは、使ってはいけない口実
上司は行動をとるための情報と状況を理解するための情報を区別して、行動にはたちいらないよう自制すべき。ミーティングは状況検討のためか、問題対策のために開くのかはっきり区別する。
こうしたプランをコントロールするグループをもつことはとこても有効である。
第15章 もう一つの顔
書き上げられたプログラムは人間から機械へのメッセージであるか、人間の利用者に語りかける顔をもつ。
プログラムを使用するために必要な文書を解説。
プログラムを信用するために必要な文書(正常に実行されているか）
プログラムを修正するための文書、フローチャートは過大評価されている。
ソースに文書を組み込む自己文書プログラムを推奨していた。ソースコードが増大するが、その価値はある。
第16章 銀の弾などない ソフトウェアエンジニアリングの本質と偶有的事項
すべてのソフトウェアの構築には本質的作業として抽象的なソフトウェア実態を構成する複雑な概念構造体を作り上げることと、偶有的作業としてそうした抽象的実在をプログラミング言語で表現し、それをメモリスペースとスピードの制約内で機械言語に写像することが含まれている。
過去のソフトウェアの生産性における大きな収穫のほとんどは、偶有的作業をはなはだ困難にする人為的障害を除去すること（きびしいハードウェアの制約、扱いにくいプログラミング言語、機械使用時間の不足など）で得られた。これからは本質的な部分について議論すべき。
狼人間を倒す銀の弾のように、ハードウェアのコストを下げるのと同じように、ソフトウェアのコストも劇的に下げてくれる特効薬を私たちはもとめるが、10年間は（1986年から）ありそうもない。しかし王道はなくても道はある。
ハードウェアの発達があまりに速いために、ソフトウェアはまったく進歩していなくみえるということもある。
ソフトウェア構築において困難な部分は、この概念構造体の仕様書作成とデザイン・テストにあって、表現することやその表現に忠実化をテストすることではない。構文上の誤りはコンセプトの誤りに比べると大したことはない。
ソフトウェアの基本的要素に含まれる固有の性質は、複雑性（どの二つの部分をとっても似ることがない、そしてソフトが大きくなると複雑性が非線形的に増す、そして技術も管理も信頼性がなくなる）、同調性（物理のように統一原理はなく、最後に登場したもの、従わせやすいとみなされるものに従う）、可変性（常に変更という圧力にさらされていて、そして制作されたものより容易に変更できるのでさせられる）、不可視性（視覚化できない、そのため一人の人間のデザインプロセスを妨げるだけでなく、コミュニケーションの妨害になる）
過去にもっとも成果のあったソフトウェアテクノロジーの三段階の発展、いずれも偶有的困難で本質的ではない。高水準言語、タイムシェアリング、統一されたプログラミング環境
銀の弾になる可能性があるものとして最も発展をとてげている技術
・Adaとその他の高水準言語の進歩。Adaの哲学（デザインとモジュール化概念）は言語以上に進んでいるが、機能が豊富すぎるし、言語である以上は銀の弾にはならないであろう
・オブジェクト指向・・・デザインの本質を表現するのに向いているが、デザインの複雑性は本質的で、それを変えることはできないので銀の弾になりえない
・人工知能・・・問題ごとに技術が異なるので期待できないと思う
・エキスパートシステム・・・一般化した推論とルールベースを持つプログラム、ただしつくるのにエキスパートがいる
・「自動」プログラミング・・・整ったケース（ソートや微分方程式）ならできても、通常はそうではない
・ビジュアルプログラミング・・・フローチャートから製作するのだが、フローチャートはソフトウェア構造を抽象化するにしては貧弱、現在のピクセルで表示される画像はソフトウェア構成図の詳細を表示するには範囲と解像度の両方で貧弱。そしてソフトウェアの視覚化は難しい。
・プログラム検証・・・膨大な労力を投入して実現やコストを行う前にデザインを修正しようという考え、これを行ってもプログラムが仕様書とあっていることを立証するだけで、完全で一貫した仕様書を作る役にはたたない
・環境とツール・・・階層型ファイルシステム、統一ファイルフォーマット、一般化されたツールは役にたっている。やがては統合データベースシステムが役にたつ。しかし本来の性質からあまり役にたちそうもない
・ワークステーション・・・プログラムや文書作成には十分。コンパイルはまだ早くなるだろうが、プログラマの思考時間は短くはならない
コンセプトの本質への有望な戦略
・購入対自主製作・・・製作のコストを購入者全員で負担するから安い。スプレッドシートと簡易データベースとう劇的なツールにより、多くの企業にとってソフトウェア生産性をあげる最強にして唯一の戦略は、コンピュータ初心者の知的労働者にPCとすぐれた汎用ワープロ、描画プログラム、ファイル管理プログラム、スプレッドシートを与えることであり、科学者なら数学や統計の汎用パッケージと若干の単純なプログラミング能力があればいいということになる。
ソフトウェア構築のもっとも困難な部分は、何を構築するのか的確に決定すること。そして顧客自身も自分の欲しいものがわかっておらず、しかも自分が要件を指定した製品を数バージョン使ってみなければ、正しい要件を指定することは不可能。だからソフトウェア問題に対する技術的な努力でもっとも有望で、偶有的事項でなく本質を攻略するものは、対話しながら要件を指定していく方法の一部としてシステムのプロトタイピングを迅速に行うアプローチの仕方とツールを開発すること。
ソフトウェアを建築にたとえ、構築するといったのは強力なメタファーだったが、今日では構築する概念が複雑すぎて前もって正確に指定することができず、欠陥なしに構築できないので、アプローチを変えるべき。複雑な生命をモデルに脳のようにソフトウェアを育てる＝漸増敵開発と考えてみる。この方法はトップダウンのデザインを伴うので後戻りが容易で、初期のプロトタイプがそのまま使え、追加された機能や新しく加えたものが、すでにあるものから生物の器官のように育っていく。しかもすでに稼働中のシステムは「やる気」を跳ね上げる効果がある。著者の演習で証明されているそうな。
ソフトウェア技法の改善はまず人間の問題に集中する。すぐれた練習法は教えることが可能。しかし、優れたデザインと偉大なデザインとの差は、偉大なデザイナーかどうかで決まる。ソフトウェア構築は創造的プロセスであり、こつこつ仕事をする人＝優秀なデザインができるひとを、偉大なデザイナーにすることはできない。だから偉大なデザイナーを開発する努力をソフトウェア会社や団体はするべきだ。
第17章 「銀の弾などない」再発射
銀の弾などないの論文にはたくさんの反論がきた。主に自分は銀の弾を開発したというものだ。著者は自腹で購入した利用者が正真正銘、これを使ったらソフトウェアの生産性が10倍改善された」といったら銀の弾が発射されたとみなすと書いていた。
偶有的は偶発発生したとか災難ではなく、副次的とか付随の意味でつかっている。ソフトウェア開発ではインプリメンテーションのことである。
作業の偶有的または表現的部分は全体の半分以下に減っているというのが著者の主張。
ソフトウェアの難しさは概念構造体をつくる部分=本質にあるといっているのあって、再利用可能で互換性のあるコンポーネントで改善できるのは偶有的部分である。
ソフトウェア構造体における概念上の複雑性の大半は、アプリケーションそのものの自由さがもたらす複雑性からきている。ソフトウェア構造体における複雑性の大半は、外部世界への同調性によるものというよりは、むしろデータ構造やアルゴリズム、それに接続性などといったインプリメンテーション自体によるものだ。以前に作ったものを再利用したり、他の人が構築したものをつかうことで複雑性の全階層に直面しなくて済む。また階層化したモジュールやオブジェクトをもつ、漸増性は必要な複雑性であると述べている。
あまりに悲観的という意見もあるが、1986年当時に進行中のさまざまな改革が十分に開発利用された場合、それらを結び付けて生産性における大規模な改善が達成できると予想している、王道はないが道はある。ソフトウェアの本質そのものが銀の弾など見つからないようにさせていると書いたつもりだ。
1986年当時の銀の弾候補を個別に論じて却下したのは、どれも決定的秘薬であるとはいえなかったからだ。
ハレルは「銀の弾などない」が1952年にかかれたと仮定して思考実験をした＝背理法。でもそれは使えない。規模もちぐので。ハレルの主張するモデル化技法「バニラフレームワーク」は銀の弾候補である。またソフトウェアの概念構造体の多くが本来はまったく位相的であり、関係は空間的、図形的に自然に写せるといっている。著者の主張はソフトウェア構造は三次元空間に埋め込まれているのではないから、概念的デザインから図式への一つの自然な写像を得ることはできないということであって、まったくできないということではない。
ジョーンズは生産性より品質に焦点をあてるべきで、生産性は後からついてくると主張。系統だった品質管理の欠如はスケジュールの破たん殿相関関係があるというデータを提供している。
生産性を示す値は今きちんと定義されたものはない。しかしパッケージを購入することが生産性をあげることは証明されたと思っている。
オブジェクト指向の成長が遅かったのは程度のあまり高くない抽象化をおこなっていたからと主張する人がいる。事前のコストが高くつくのだ。
ソフトウェア構築の本質を攻略する最良の方法は全然構築しないこと。または再利用。継承して再利用というのはオブジェクト指向技法のもっとも大きな魅力。しかし、やってみると意外とてこずることもある。再利用はいま企業ではほとんどされていない。もっとも統計もあまりとられていないのだが。
思考レベルが高くなれば、取り扱わなければならない初歩的試行要素も多くなる。だからプログラミング言語は機械言語より複雑で自然言語はもっと複雑なのだ。再利用にはプログラミング語彙の大きさも関係してる。言語の習得法帆運い関する研究と知見が必要。
解決策についての要点は変わっていない。複雑性がわれわれのとりくんでいる仕事である、制約しているものである。登場しそうもない解決策＝銀の弾を待っているのではなくて、可能性のある漸増的な改善をすすめていくべきだ。
第18章 「人月の神話」の命題－真か偽か
1975年の提言のうち、データと経験によって支持されたもの、反証されたもの、時代遅れになったものを判断できるように、各章の真髄を並べたもの。
第19章 「人月の神話」から二十年を経て
人月の神話の息がながいのは、ソフトウェア開発という分じゃが正常に適切に進歩していないからだという意見がある。ハードウェアの生産性が二十年で千倍になっているので余計にそうみえるのだろう。しかしハードの方が異常なのだ。またソフトウェアについてではなく、チームでモノを作る方法について書かれているからだともいわれるが、当たっていると思う。
書いたときも正しく、現在も相変わらず正しいことについて考える。
・中心になる主張 コンセプトの完全性とアーキテクト
大規模プロジェクトで利用者という一人の頭脳から見たコンセプトの統一性をとるためにプロジェクト管理をするには、小規模プロジェクトとは異なる周到かつ大胆な管理行動が必要。アーキテクトは一人にする。アーキテクチャはインプリメンテーションと実現から分離する。アーキテクトの再帰利用（大きな製品は一人ですべてのアーキテクチャをこなせないので、サブシステムにわけて主任アーキテクトを置く）、コンセプトの完全性こそ、製品の品質にとって中心的なものであるという主張は、現在もより確信をもっていることである。
・セカンドシステム症候群－多機能主義と度数推測
汎用ツールをデザインする方が、特別な目的のツールをデザインするより難しい。多様な利用者のさまざまなニーズに重みづけをしないといけないので。市場が要求していると多機能主義に陥るにつれ使いやすさは消える。利用者群を定義すること、度数を推測するべきである。あいまいなままでいるより、明白に間違っているとわかる方がずっとまし。
・WIMPインターフェースの勝利
WIMP・・・ウィンドウ、アイコン、メニュー、ポインティングインターフェース、はコンセプトの完全性をもったユーザインターフェースの最高の例。メニューの使い勝手(コマンド＝動詞と名詞を指定する方法）を例に利用者の力と使いやすさのバランスをとるのもアーキテクトの直面する問題を述べていた。著者は1世代でWIMPは歴史的遺物になり、音声が動詞を表現する適切な方法になるといっている。
・捨て石にするつもりで構築してはならない－ウォーターフォールモデルは間違いだ
一つは捨て石にするつもりでは間違いであると考えるようになった。インプリメンテーションでアーキテクトはの修正がわかったら上流にもどることが必要、漸増的モデルの方が勝っている。どの段階でも実働システムがあり、それが「やる気」を引き出す。利用者による早期テストも行えるのだ。ソフトウェア製品を関連製品のファミリーとしてデザインするのはデービット・パルナスの考えで、変更されることがないと見込まれるデザイン部分の根元付近を基本製品においている。マイクロソフトは「毎晩構築」アプローチを使っている。
・情報隠ぺいに関して、パルナスは正しく私は誤っていた
モジュールコードは適切に定義されたインターフェースを使って隠ぺいすべきだというパルナスの主張を否定したが、今ではソフトウェアデザインのレベル上げる唯一の方法と確信している。パルナスの定義はオブジェクト指向プログラミングの知的先祖で、抽象データ型、継承、再利用のためにデザインされテスト済みのモジュールライブラリまたはクラスのアイデアである。
・人月はどの程度神話的なものか－べーむのモデルとデータ
バリー・ベームが63種類のソフトウェアプロジェクトについて行ったものによると、要員と月数の間のトレードオフは線形どころではなく、人月は生産性の尺度としては実に神話的だとするものであった。そしてコスト曲線についていくつかの発見をした。要員追加についての、細かい研究によると、どのようにどんな要員を追加するかについて有益な知見も得られている。やみくもな要因追加がプロジェクトを破たんさせるのはいうまでもない。
・人間がすべて（そう、だいたいのところは）
ピープルウェアは大きな収穫。技術的というより社会的。プロジェクトの移動をチームの融合の観点から注意を払っている。
・力を断念する力
創造性は個人から発するもので工程や組織から発生ｓるものではない。だから創造性を伸ばす組織と工程を感がることが必要だ。権限委譲である。
・最近あった最大の予想外の事件は何か？－何百万台ものコンピュータの普及
マイクロコンピュータ革命がコンピュータの利用方法を変えた。シューマッハの主張がかないつつある。マイクロコンピュータ革命がソフトウェアの構築方法を変えた。ネットワークの利用で変更やテストが楽におこなえるようになった。
・まったく新しいソフトウェア産業－パッケージソフトウェア
古典的ソフトウェア産業は分裂し、アプリケーションユーザーは細分化している、一方で機能豊富なソフトウェアパッケージが一人のプラグラマの一日のコストより少ない値段で購入できるようになった。OSの世界は小数に収れんした。
・購入して構築する－パッケージソフトをコンポーネントとして
これは概念構造体を作り上げることの本質を攻略するものだから急速に成長していくだろう。パッケージ利用者は、そのままの利用者、メタプログラマ、外部機能作成者、一つあるいは複数のアプリケーションをより大きなシステムのコンポーネントとして使用するメタプログラマに分類される。アプリケーション群のなかで相互作用をコントロールするスクリプト言語があると実に効果的。
・ソフトウェアエンジニアリングの現状と将来
化学工学とソフトウェアエンジニアリングの展開には類似点がある。パルナスはソフトウェアは電気工学のように数学的基礎をもったエンジニアリングとして展開できないといっている。ソフトウェアエンジニアリングは、経営工学同様、人間の行動の複雑性によって永久的に混乱させられるものなのかもしれない。ただし、絶望的なわけではなく、未熟なだけだと思う。当分はタールの沼であるであろう。しかし展開させていくことはできる。
エピローグ 五十年間の不思議 興奮 それに喜び
著者が13歳のときハーバード・マークIの記事を読んで、知識を大きなハイパーテキストのおりものとして構成し、既存の道に従いながら新しい連想の先鞭をつけるような機械を利用者に与えるという提案に興奮した。その後コンピュータの道をすすみつづけたが、この分野は爆発的に進歩してきている、すべてを把握することは難しくなり、周辺分野をすてているくらいだ。コンピュータ関連分野は進歩のスピードをゆるめず、終わりも見えない。これからますます楽しみだ。
人月の神話―狼人間を撃つ銀の弾はない (Professional Computing Series)
- 作者: フレデリック・P,Jr. ブルックス
- 出版社/メーカー: アジソンウェスレイパブリッシャーズジャパン
- 発売日: 1996/02
- メディア: 単行本
コメント 0