人月の神話第19章：人月の神話を発表した後の20年を振り返って

ウォーターフォールモデルは間違っている。
インクリメンタル開発、つまり、少しずつ追加しながら作るやり方の方が優れている。
モジュールやクラスの内部はそれらの利用者には隠すべきだ。
成功するかは、ほとんど人にかかっている。
この要約作成者の個人的メモ

ウォーターフォールモデルは間違っている。

ウォーターフォールモデルの前提にある誤った考え

アーキテクチャや実装の設計には問題が無く、全ての失敗はそれらを具現化するときの作業で生じるものであり、全ての失敗は単体テストとシステムテストの期間に修正できると想定している。この想定は誤りだ。
全行程を1度だけ行うことを前提にしている。そのため、システムテストや実際のユーザーによる評価が最終盤に行われることになる。その結果、使い易さやパフォーマンス、エラーや悪意を伴った操作への耐性などの問題は、最終盤に見つかることになる。なお、実際のユーザーによる評価を、何かに置き換えることは不可能だ。序盤での仕様の検査に置き換えることも当然できない。
全ての設計、ほとんどのコーディング、及び、多くの単体テストを終えた後に、端から端までシステムテストを行うために、部品を合体させる、つまり、システムを一度に作ることを想定している。実際には、以下で示すように、インクリメンタルな作り方の方が優れている。

ウォーターフォールモデルが広まった背景とその後

ウォーターフォールモデルは、全ての軍用ソフトウェアに適用されるアメリカ国防総省の規格であるDOD-STD-2167の中へと祭り上げられてしまった。
そのため、思慮深い専門家のほとんどが不適切さに気づき使用を止めた後でも、ウォーターフォールモデルは長く残ることになってしまった。
アメリカ国防総省自身も、1988年の改訂版であるDOD-STD-2167Aでは、スパイラルモデルなどのより新しい開発モデルの使用を認めた。ただし、実際の調達の大半ではウォーターフォールモデルが使われ続けていることが報告されている。一方で、米国国防科学委員会は、1994年の報告書において、より現代的なモデルの全面的な使用を支持している。

上流工程へのフィードバックが必要だ。

実装の設計で分かったことによりアーキテクチャのやり直しが必要になることもあるし、コーディングで分かったことによりアーキテクチャや実装の設計に変更が生じてもおかしくはない。
コーディングの前に、アーキテクチャと実装の間の設計サイクルを2回以上繰り返すのは筋の通ったやり方だ。

インクリメンタル開発、つまり、少しずつ追加しながら作るやり方の方が優れている。

インクリメンタル開発の方法

最初は、メインルーチンから空のサブルーチンを呼び出すだけのようなプログラムを作る。つまり、実質的には何もしないが、コンパイルして、走らせて、正しく動作したこと（空のサブルーチンが意図したように呼ばれたこと）を確認できるものをまずは作る。
次に、基本的機能のみを持った入力モジュールや出力モジュールを1つずつ作って追加していく。つまり、機能を1つずつ作って追加していく。
全ての基本的機能が動くようになったら、今度はモジュールを1つずつ少しずつ改良していく。

インクリメンタル開発の利点

常に動くシステムがあるので、ユーザーによる評価を極めて早期に開始できる。
常に動くシステムがあるので、予算の分だけ作るという戦略を採用できる。これにより、機能不足との引き換えになるかもしれないが、スケジュールや予算の超過を完全に防ぐことが出来る。
入念に努力して開発を進めていれば、デバッグとテストが完了したシステムが常にあることになる。ただし、システムが増大するにつれ、回帰テストも増大することに注意。
動くシステムを早期に見ることは士気を大いに高める。

マイクロソフトのデイリービルド

プログラマとテスタで構成されるチームを複数設け、このうちの1チーム以上が、毎日、新機能と共にモジュールをチェックインする。
毎晩、開発中のシステムをビルドしてテストを走らせる。
ビルドしたものが壊れていたら、問題が判明して修正されるまで、プロセス全体を止める。
全てのチームメンバーがその状態を常に知っているようにする。

モジュールやクラスの内部はそれらの利用者には隠すべきだ。

本質的な難しさに取り組んで生産性を上げる方法の1つは、プログラム言語の1文より大きな概念的まとまり、つまり、サブルーチンやモジュール、クラスなどでプログラムを組み立てることである。すなわち、それらの概念的まとまりを事前に作りそろえておいて、それらにパラメータを与えて組み合わせるだけでプログラムができるようにするのである。
このアプローチの重要な源流はカプセル化の考えであるので、モジュールやクラスの内部に相当するコードは隠し、上手に定義したインターフェイスだけをモジュールやクラスの利用者に公開すべきである。また、内部を隠すことにより、変更に強いプログラムになる。
ただし、このようなモジュールやクラスは、第1章で述べたプログラム製品に相当する。製品相当の品質を持つ再利用可能なモジュールやクラス、つまり、汎用的で、頑健で、テストされ、ドキュメントも付いたそれらを作るのは単にプログラムを作るのに比べコストが大きい。（第1章で著者は、少なくとも3倍のコストがかかるとしている。）

成功するかは、ほとんど人にかかっている。

成功に導く要因として、人員の質とその人員による組織とマネジメントが、ツールや技術よりも重要であると著者は確信している。
BoehmのCOCOMOモデルによれば、チームの質が他を引き離して成功のための最大要因である。
DemarcoとListerは、著書である「Peopleware: Productive Projects and Teams」で、同じ組織で働くプログラマの生産性と不良発生レベルの両方がオフィス環境と相関を持つことを実データを用いて示した。
自ら経験したり注視したりしたのは6例ほどだが、ある研究所から別の研究所にプロジェクトを移して成功した例を見たことがない。全ての場合で新しいチームは最初からのやり直しになっていた。DemarcoとListerは、無形だが不可欠な資産としてチームのfusion（融合または結束と訳せるか）にかなりの注意を払っている。プロジェクトの移動は、前のチームにあったfusionを破壊してやり直しをもたらすのではないだろうか。

この要約作成者の個人的メモ

p. 257 システムの規模がとても大きく、1人のアーキテクトでは対応できない場合は、いくつかのサブシステムに分割して複数人のアーキテクトで分担する必要がある。この分割では、サブシステム間のインターフェイスが最小になるように、かつ、インターフェイスを厳密に定義するのが最も容易になるように分割するべきだ。
p. 258 市場から要求があるのだからと機能を盛り込んでいくと、バージョンアップのたびに、使いづらく遅いソフトウェアになっていってしまう。対策としてターゲットとするユーザー像を文字にしてアーキテクトの間で共有することが必要だ。そして、実際にどんな属性を持ったユーザーがどのように分布しているかを調査するのは困難なので、分布は仮定してしまうのが良いやり方だ。なぜなら、分布を仮定するための思考と議論は、状況を分析する作業とユーザー像を共有する作業として、それ自体が有益だからである。
pp. 260-264 GUIの発展と概念的な整合性（conceptual integrity）
pp. 268-269 Parnasのプログラムファミリーの概念は、インクリメンタル開発に応用できるかもしれない。
pp. 270-271 Harelの定義によれば、プロトタイプとは、概念的モデルの準備工程で行われた設計上の決定事項のみを反映し、実装への考慮が主導する決定事項は反映しないプログラムである。この定義に従った場合、インクリメンタル開発における早期のユーザー評価とプロトタイピングは、関係はしているが別物であり、片方だけを行うことも可能である。例えば、製品の一部には全くならないプロトタイプを作って、早期にユーザーの評価を得ても良い。逆に、インクリメンタル開発において、最初の節目のビルドが、ユーザー評価に使えないものであっても良い。ちなみに、プログラムの代わりに人間がシステムの応答をシミュレートしてもプロトタイピングは行える（Wizard of Oz technique）。また、早期にパフォーマンスの解析を行うために部分的なプログラムを作ることもあるだろう。
pp. 277-279 上の組織が権限を手放してより下の組織に渡し、仕事の進め方やスケジュールを下の組織に任せることは、個人の創造性と自主性を高めることにつながる。マイクロソフトやIBMでは実際にこういった取り組みが行われており、成果が上がったという証言もある。
pp. 279-282 20年を振り返って最も驚くべきニュースである何百万台ものコンピュータの普及に関して、その社会に与えた影響とソフトウェア開発に与えた影響の考察。
- コンピュータの普及にも当てはまる3つの重要なこと。1.誰もが使えるくらいに安いこと。2.ちょっとしたことのために使えること。3.人間の創造性への欲求と相性が良いこと。
p. 283 汎用的な手法や言語には向かわず、データベース問い合わせ言語に代表されるようなニッチな分野それぞれに合わせた手法や言語で開発を行う方向へ、昔からのソフトウェア産業は進んでいった。この方向性は、企業や官公庁が自ら使うために作るソフトウェアのような分野で顕著である。一方で、多数存在していたOSはいくつかに集約された。
p. 284 パッケージソフト産業は、激烈な競争がある自由市場であり、多くの企業はスタートアップ企業として始まった。このため、仕事の過程よりも仕事を成し遂げたかに強烈な焦点が当てられた。そして、昔からのソフトウェア企業では難しかった個人の実績に応じて報酬を与えることが、このスタートアップ文化では可能になった。
pp. 287-289 ソフトウェア工学は絶望的なわけではなく未成熟なだけではないかと化学工学の発展の歴史を見て著者は思っている。新たな技術・手法・ツールの継続的な開発と習得が、常識にとらわれないことが、そして、自分達が簡単に間違えることへの謙虚さと自分達の限界への謙虚さが、今後も求められるのだろう。

他の章はこちらから：