「コンウェイの法則」の再現性

システム開発

IT関連の法則で、以前、「ブルックスの法則」というものを紹介しました。同じように有名な法則で「コンウェイの法則」というものがあります。

この「コンウェイの法則」は「ブルックスの法則」が書かれているフレデリック・ブルックス著の「人月の神話」の「第10章 文章の前提」でも引用されています。

「コンウェイの法則」とは

メルヴィン・コンウェイが1968年に発表した「How Do Committees Invent?」に書かれている以下の法則です。

Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure. 

Melvin E. Conway著 How Do Committees Invent?

ざっくりと訳すると「システムを設計する組織は、その組織のコニュニケーション構造とそっくりな設計を行う。」ということです。

システム設計のライフサイクル

メルヴィン・コンウェイはこの論文の中でシステム設計のライフサイクルを以下のように記しています。

  1. 基本的なルールに従って、境界線を設定する。
  2. 予備的なシステムを選択する。
  3. 設計活動を組織化し、そのコンセプトに基づき作業を委任する。
  4. 委任したタスクの調整を行う。
  5. 作成されたサブシステムの設計を一つのシステムにまとめる。

表現や分割の仕方は異なると思いますが、今でも似たようなことをしているのではないでしょうか。

上記の手順では、システムは複数のサブシステムから構成されていることになります。これをもとに「システム」を「委員会」、「サブシステム」を「小委員会」、「インターフェース」を「コーディネーター」に置き換えると、設計をする組織構造になるということです。

システム開発プロジェクト崩壊

また、大規模なシステムの開発は、小規模なシステムの開発に比べて、失敗する傾向が多いとのことです。

原因としては、以下の3点が挙げられます。

  1. 規模が大きくなると、必要以上に多くの人に設計を割り当てたくなる。
  2. 人が増えることによりコニュニケーションが困難になる。
  3. 崩壊した設計組織と同じようなシステム設計ができあがる。

ここでは、「人月の神話」につづく解説があり、2人の1年間分の仕事と100人の1週間分の仕事が同じ成果があるという安易な考え方があると述べています。スケジュールのプレッシャーにより、必要以上に多くの人に仕事を割り当てるようにしていまう誘惑を管理者に与えるということです。

「コンウェイの法則」を受けて

私は「コンウェイの法則」は、設計対象の組織と同じシステムを設計者が再現してしまう。という法則だと誤認していました。IT業界の中でSIerへの勤務経験が長く、「お客様を良く見て」設計すること求められてたので、そのような誤認をしてしまっていまいた。(このような誤認をしている方をたまに見かけます。)

正しくは設計する組織と同じシステムを設計者が再現してしまう。という法則です。日本とアメリカの雇用慣行の違いにより、日本ではシステム開発をSIerに委託するのが一般的ですが、アメリカでは事業会社がシステムを開発するたびに開発者を雇用するのが一般的です。このため、アメリカでは「設計対象の組織と設計する組織」は同じになるのが一般的なため、日本では誤認しやすいものと思います。

設計する組織が適切でないと、できあがるシステムは適切なものにならない。なるほど。と思いました。思い当たるフシがたくさんあります。無駄がある組織が開発したシステムは無駄が多い。よくある話だと思います。予算やスケジュールに無理があるプロジェクトが開発したシステムは、品質が悪いか、当初の要求を満たしたシステムにはならない。これもよくある話だと思います。

日本でも事業会社がIT系の人材を直接雇用したりすることが多くなってきました。(実際に、数年前に登録した転職エージェントさんから、転職する意思はないですが求人情報がたまに来ます。そのほとんどは事業会社さんからものです。)

より良いシステムを構築しようと思ったら、まずは、自分の組織を見直す。ということを一番にやるべきものだと考えさせられました。

コメント

タイトルとURLをコピーしました