Baldwin, Carliss Y., Kim B. Clark, “Design Rules: The Power of Modularity,” MIT Press, 2000.　（邦訳：安藤晴彦訳，『デザイン・ルール―モジュール化パワー―』，東洋経済新報社, 2004）

[第�U部　第6〜8章要約]

第6章では、1944年のENIACの製作から1961年のIBMシステム／360の登場までの期間に焦点をあて、モジュール化の起源を辿る。コンピュータ設計の領域において、モジュール化の概念は、人工物それ自体の設計の登場以前に設計者たちの頭の中にひとつの可能性として存在した。IBMの標準モジュールシステム：SMSは、人工物の単なる概念分解ではなく、設計と対応するタスク構造を効率的にモジュール化したもので、これには、基礎にあるパラメータの相互依存性の性質を理解するために、多くの設計サイクルを経た着実な知識の積重ねが要求された。IBMシステム／360は、1961年に独立に適用されてきたフォン・ノイマンの分解、マイクロプログラム制御の発明、回路設計標準化の概念が単一の文脈に結集したものである。

第7章では、IBMシステム／360のデザイン・ルールの作成についてみる。IBMは当時、拡大する非互換製品群に共通する2つの問題、１）構成要素の冗長性と、旧式な設計による制約に苦しんでいた。1961年にSPREADと呼ばれる13人のタスク・グループがモジュール型コンピュータ設計とモジュール型タスク構造についての勧告レポートを策定し、ここでアーキテクチャの基本原則が決まり、CPCを軸にシステム／360のデザイン・ルールづくりが進められた。注目されるのは、１）アーキテクチャ上の決定は、関連するとトレードオフの詳細な知識に基づいていた、２）デザイン・ルールの創造はそれ自体非常に相互連関したタスクの集合だった、３）ルール設定作業はたった一度で行われなくてはならなかった点である。デザイン・ルールの不備が統合・検証段階で現れることがあるが、システム／360ケースでは致命的なものはひとつもなく、このルールは長生きした。

第8章では、システム／360で採用した事業体設計と、その設計が顧客、競争相手、従業員と他社のアーキテクトたちに与えた影響を説明する。IBMが実行した契約構造は「戦前」のものを微調整したものであり、その中核部分には、顧客との黙示・明示の了解の集合、すなわち、ユーザーらは（削除、追加、アップグレードする）選択肢と、製品群内での低いスイッチング費用と、コントロールされたカニバリゼーションを持っていた。「広範な統制」と名づけられるこの構造は、ひとつのモジュール型システムとその関連製品の「タスク構造全体」を取り囲む契約の集合として捉えることができ、IBMは自社の境界線内に全ファミリーの全モジュールおよび全作業グループを格納することを目指した。主要競合企業は完全撤退するかニッチへ追い込まれるに至ったが、同時に、この価値の変化によって、モジュールへの投資や、モジュールに基づく事業体の可能性がもたらされ、ここから「設計進化」と呼べる非集権的な価値探求プロセスが始まっていった。

[コメント]

モジュール化の創造は、それまでの多様な設計経験に基づく知識の蓄積を基にしていることが理解できる。これらの蓄積知識を背景とした技術的要請から生まれたモジュール型タスク構造を事業体設計として実現できた点が革新的である。複雑系の設計パラメータの分解に成功することが、事業設計の基となることが確認できる。

（2004年10月4日　坂井　健太郎）