前回、「EoM(保守容易性)が良い設計の基準だ、そして、EoM=EoT+EoCだ」という議論を書いた。ここまでの議論は、ソフトウェアの設計についてのものであり、開発の「プロセス」(あるいはプラクティス)とは無関係に進めてきた。ここで、1つの経験則を使って、プロセスの方(鏡の反対側)を見てみたい。その経験則とは、 コーンウェイの法則: ソフトウェアの構造は開発チームの構造に一致する。コンパイラを4チーム編成で作れば、4パスコンパイラになる である。(※この法則は、ソフトウェアとチームの「構造」(organization)について述べたものだが、ここでは、プロセスについて拡大解釈する) この法則を使うと、3つの設計品質についての方針は、そのまま、プロセスについての方針にミラーコピーできる。 EoTに関するプロセスの命題は、テストというより、「テスティング」という活動が、プロセスの中で最も重要な