出典：「コンウェイの法則」

発行から42年後の著者のメモ：

おそらくこの記事で最も顕著なのは、最後から3番目の段落で説明されている声明のためです。 前の45段落を克服する難しさを緩和するために、今すぐ自由形式で表明します。



システムを設計する組織（ここでは単なる情報システムではありません）は、必然的に組織自体の通信構造を繰り返すモデルを作成します。



この原則は、ソフトウェア開発だけでなく、その文脈でよく言及されることもあります。



素材に慣れてから、他の領域を見て回ることをお勧めします。



現在、私のお気に入りの例は、アメリカの貧困に関連する社会問題の複合体です。労働市場、住宅、教育、医療へのアクセスです。 記事を読んだ後、さまざまな政府の構造がそのような問題に対する態度にどのように影響するかを考えてください。

委員会はどのように新しいものを作成しますか？

メルビン・E・コンウェイ

オリジナルPDF



全体が異なる部分から作成される知的活動は、システム設計と呼ぶことができます。 大規模な軍事施設の準備、社会問題の解決のための推奨事項、またはコンピュータープログラムのリストです。 設計組織の典型的な目標は、一貫性のある構造化された量の情報を含むドキュメントを準備することです。 この情報をシステムモデルと呼びます。 通常、イニシエーターは、モデルを使用してさらなるアクションを提供したい顧客です。 たとえば、政治家は、最近の災害の再発を防ぐための法案を提案しようとしています。これは、彼がチームを雇って災害の原因を突き止めるためです。 または、製造業者は新製品を必要とし、責任者を任命して新製品を決定し、そのリリースを計画します。



設計組織は、設計されたシステムの実装に関与する場合としない場合があります。 多くの場合、政府の取り組みでは、グループが独自の勧告に従って行動することを妨げる規範がありますが、民間部門では逆の状況が優勢です。 この条件がシステム設計プロセスに影響を与えると仮定するのは合理的であり、開発者自身の将来についての他のアイデアもあります。 後で見るように、従来の管理環境に存在するインセンティブは、顧客の目標に反する可能性があります。 [1]

設計手順

最初の設計段階では、システムの開発よりもプロセス自体の構造化に言及しています[2]。 完全な開発の前には、次のような特定の予備措置があります。

1. プロジェクト活動の境界の決定と、顧客と既存の現実によって確立された最終結果。
2. 開発チームのバランスの取れた形成を目標としたシステムの構造の初期評価。

将来的には、チームの組織構造がプロジェクトの実装に直接または間接的にすでに影響していることを詳細に説明します。 したがって、従業員の検索に理想的な条件を提供できない場合でも、チームの形成は完全に客観的ではありません。 そして、チームの形成後、責任はサブグループに委任され、研究の範囲が狭められ、同時にシステム開発の選択肢の数が減ります。



責任を割り当てられたマネージャーは、ワーキンググループレベルでの調整の問題に直面します。これは、均一なシステムを作成するための各グループの作業の統合に悪影響を及ぼします。 この個人の役割の減少の可能性にもかかわらず。



システム設計プロセスには次の段階があります。

1. 基本的なルールに従って境界を定義します。
2. 予備的なシステムコンセプトの開発。
3. コンセプトに沿った設計作業とタスクの委任の編成。
4. 委任されたタスクのレベルでの調整。
5. サブシステムをシステムに結合します。

単一の設計作業では、すべての段階がトレースされない場合があります。 その過程で、新しい、より完璧なプロジェクトコンセプトが見つかることがあります。 もちろん、これは非常に有利な瞬間ではありません。これは、その後の仕事の中断が苦痛で費用がかかるためです。 もちろん、歴史家の観点からは、すべてが繰り返されます。



この場合、なぜすべてを正しく行う時間がないのに、何かをやり直すのに十分な時間が常にあるのはなぜですか？

システム設計

シリアルシステムは、相互接続されたサブシステムで構成されます。 システムの内部構造の説明は、外部環境との接続およびサブシステムの相互接続を反映する必要があります。 下位レベルに進むと、サブシステムをシステムと見なして、サブシステムについても同じことが言えます。 など、そのようなサブシステムに至るまで、非常にシンプルで不可分です。

例

州の大陸横断輸送システムは、バス、電車、飛行機、タクシー、駐車場、ターミナルなどで構成されています。 これは非常に異種のシステムであるため、そのサブシステムは非常に多様です。 たとえば、飛行機レベルに進むと、そのサブシステム、フレーム、エンジン、配電、通信、ペイロードが表示されます。 エンジンシステムには、燃料、点火などのサブシステムが含まれます。



それほど明白ではありませんが、理論もシステムです。 外部環境、観察可能なイベントを指し、それらは説明するか、少なくとも矛盾しないようにする必要があります。 これは、同様の方法で互いに関連するパーツ理論で構成されています。 たとえば、飛行機のcrash落事故の調査中に、航空機の軌道、通信、損傷、および事故中の他の物体との相互作用を説明する理論が作成されました。 これらの各項目自体は個別のストーリーであり、個々の情報単位までサブ項目に分割することもできます。

スキーム

図 図1では、システムは線の形の接続（ブランチ）と円の形のメインノード（ノード）を備えた図の形で描かれています。 各ノードは、他のサブシステムと通信するサブシステムを象徴し、同様の方法で表すことができます。 開発者の間で人気が高まっているインターフェイスという用語は、線で示されているサブシステムの相互作用を指します。







グラフィックイメージは、システムとそれを設計する組織という、私たちが検討している2つの概念の同一の形を明確に示しています。 交換してみてください：

1. 「システム」から「委員会」
2. 「サブシステム」から「小委員会」
3. 「コーディネーター」への「インターフェース」

システムの場合と同様に、設計組織はいくつかのレベルの複雑さを考慮して検討できることがわかります。 連邦政府は、どんなエンジニアでも満足できるレベルの複雑さを備えた設計組織の好例です。 これは特に興味深い例であり、私たちが検討している2つの概念の類似性を示しています。連邦政府は設計組織（法律、協定、ポリシーを策定）と設計組織（憲法を主要な設計文書）の両方であるためです。

一次相互作用

これで、この記事の主要な問題の準備ができました。 設計組織の構造と設計するシステムの間に予測可能な関係はありますか？ 正解は「はい」です。この接続は非常に単純なので、多くの場合一定です。 次の「証拠」を考慮してください。



システムとそれを開発した組織を任意に選択し、設計されたシステムの複雑さのレベルをランダムに選択して、それを図式的に描写します（興味深い関係を観察すれば、任意の設計組織と複雑さのレベルに拡張できるため、選択は任意です）。 図 図2は、以下の記述が当てはまる構造を（わかりやすくするために）示しています。







システム内の任意のノードxについて、それを開発した設計組織のワーキンググループを識別できます（Xで示します）。 このように



このプロセスを要約すると、システム内の任意のノードについて、適切なワーキンググループを見つけるためのルールがあります。 比率は1：1、つまり 同じ設計組織で2つのサブシステムを設計できます。



興味深いことに、ブランチに関して同様の声明を出すことができます。 同じシステムの2つのノード、xおよびyを使用します。 それらは接続されている場合とされていない場合があります（つまり、システムの機能にとって重要な何らかの方法で相互作用するかどうか）。 それらの間に接続がある場合、2つのデータノードを開発した2つのワーキンググループXとUは、ノード間の通信の可能性を実現するためにインターフェイスの機能に同意する必要がありました。 xとyの間に接続がない場合、サブシステムは相互に通信しません。これは、ワーキンググループが相互に対話しなかったことを意味します（XとYの間に接続がないため）。 [3]



今示したものは何ですか？ 簡単に言えば、システムの構造とその設計に関与する組織の構造との間に密接な関係があることを示しました。 各サブシステムに個別のワーキンググループがある場合、ワーキンググループとサブシステムの構造（スキーム）が同一であることがわかります。 複数のワーキンググループが1つのサブシステムを開発する場合、設計組織構造はシステム構造のように見えますが、サブシステム（図のノード）が少なくなります。



2つのオブジェクト間の構造を保持する同様の関係は、準同型と呼ばれます。 数学言語では、システム図とそれを設計する組織のスキームとの間に準同型性があります。

システムは、それを設計している組織を反映しています

多くの経験豊富なシステム設計者は、誰でもシステム設計を改善できると考えています。 言い換えれば、場所、時間、知識と技術のレベルの文脈を除いて、設計タスクについて話すことは誤りであり、間違っています。 これは、オブジェクトを設計する作業のストーリーを読んだり、作業を覚えて分析したりする人によって記憶される必要があります。



FORTRANやCOBOLなどのプログラミング言語のコンピュータートランスレーターの開発は、優れた例です。 1950年代半ば、これらの言語のプロトタイプが登場したとき、それらのコンパイラはコンピューター自体よりもさらに面倒で、コマンドを実行するはずだった当時は巨大でした。 今日、これらの翻訳者は、現代のコンパイラと共通点のない歴史的な驚異に過ぎません。 （コンパイラーの開発における大きなブレークスルーは、以前はコンピューター製造業者の家柄と考えられていた地域の人々の新しいグループの出現に関連していたことに注意する価値があります-これは、最初は独立したソフトウェア開発者が続く小さな凝集した大学グループでした）。



システム要件に対して、この要件を満たすシステムプロジェクトが多数あると想定する場合、設計組織の選択がこのシリーズからシステムプロジェクトを選択するプロセスに影響するかどうかも確認する必要があります。 準同型を信じる場合、どのような影響を与えるかについて同意します。 組織には柔軟なコミュニケーション構造がないため、この組織はプロジェクト製品に自身のコピーをスタンプします。 組織が大きいほど柔軟性が低くなり、このプロパティがより明確になります。

例

ある研究組織には、COBOLおよびALGOLコンパイラーを作成することになっている8人がいました。 複雑さと予想される期限の初期評価の後、そのうちの5つがCOBOLで動作するように決定され、3つがALGOLで動作するように割り当てられました。 その結果、COBOLコンパイラは5つのパスで機​​能し、ALGOLコンパイラは3つのパスで機​​能しました。



司令官の指揮下にある2つの軍事サービスは、彼らのニーズに応じた武器システムを開発しました。 その後、努力なしではなく、組織構造のコピーを作成しました（図3aを参照）







このタスクに関係するコンピューターのオペレーティングシステムに注意してください。 詳細に検討した結果、ハードウェア、ソフトウェア、アプリケーションの3つの部分で構成されていることがわかりました（図3bを参照）。 開発者はこれらのサブシステムに対応します：コンピューターメーカーのエンジニア、彼のシステムプログラマー、ユーザーアプリケーションの開発者（ハードウェアとソフトウェアのスペシャリストが協力するとき、まれに互いに困難に耐えるだけではない場合）。

システム管理

大規模システムの構造は、発達するにつれて減衰する傾向があります。 この観察は、過去10年間に大規模な軍事情報システムを検討する場合に特に顕著です。 それらは、以前に人間によって作成されたすべての最も複雑なオブジェクトです。 システムが構成要素に分離する傾向を含め、「システム管理」と呼ばれるアクティビティが発生しています。 この記事の主なアイデアのコンテキストでシステム管理の実用性を見てみましょう。



大規模なシステムがバラバラになるのはなぜですか？ このプロセスは3つの段階を経ており、最初の2つは制御可能です。3番目の段階は準同型の直接的な結果です。

1. 第一に、開発者は、設計されたシステムのサイズを認識し、それを作成するためにできるだけ多くの人を雇う誘惑に抵抗することができません。
2. 第二に、このような大規模プロジェクトの実装に通常の管理モデルを適用すると、その通信構造は別々の部分に分割されます。
3. 第三に、組織設計者の構造で発生する崩壊プロセスは、準同型の現象に従って、システムの構造で発生します。

まず、「人口過剰」の状況を考えてください。 システムの複雑さのレベルが彼の理解の境界に近づくとき、タスクを委任する開発者の自然な欲求は非常に理解しやすいです。 これは、開発プロセスのターニングポイントです。 彼はシステムを単純化するために戦って勝つか、それに対するコントロールを失います。 時間枠と予算のプレッシャーを考えると、結果はほぼ予測可能です。



期限が過ぎた場合、マネージャーはこれを防ぐためにすべてのリソースを使用しなかった場合、責任を負うことになります。 したがって、彼は開発者に影響を与えようとします。開発者は、おそらくシステムの複雑さに対処し、タスクを他の人に委ねることを好まないでしょう。 その結果、関係するリソースの数が増加します。



または、マネージャーと設計されたシステムの整合性が競合する同様のケースを示す別の例。 マネージャーは、実装のために作業の重要かつ複雑な部分を提供する必要があります。 彼は2つのパフォーマーのいずれかを選択できます。創造的なアプローチと低賃金で区別される新しい中小企業、またはより「現実的な」価格を持つ定評のあるオフィスです。 彼は、若くて明るい会社がその仕事に対応しなければ、プロジェクトを混乱させる罪を犯すことを知っています。 有名な組織が失敗した場合、これはタスクが本当に難しいことを示すだけです。



ここでのキャッチは何ですか？ 基本的に、伝統的に使用されているリソースの評価と割り当ての方法で。 したがって、リソースの単位はドルであるため、すべてのリソースはドル単位で表されます。 リソースが人件費の場合、測定単位は、1時間の作業のコストに作業者の数を掛けたものになります。



このアプローチの誤りは、1年間の2人の作業が1週間の数百人の作業と同じ方法で評価されることです。 しかし、準同型を考えると、二百の仕事の組織構造は異なるので、彼らは異なるシステムを作成すると主張できるので、彼らの仕事のコストを比較すべきではありません。 経験から、2人の正しく選択された人々は、うまく対処すれば最良の結果を示すことがわかります。 ジャガイモの皮むきやレンガの敷設に当てはまるかもしれない仮定は、システム設計において間違っています。



パーキンソンの法則[4]は、プロジェクト活動における労働資源の再配分において非常に重要です。 マネージャーの評判が予算の大きさに依存している限り、彼は組織の拡大に興味を持ちます。 これは、システム開発の問題を解決するための適切な動機ではありません。 組織が存在すると、もちろんそれが使用されます。 おそらく、今日非常に多くの設計が不十分なシステムが存在する最も説得力のある理由は、仕事を求めている設計組織の存在にあります。



第二に、システム設計プロセスの崩壊の理由-設計組織のコミュニケーション構造の断片化-は、タスクの委任の開始とともに現れ始めます。 初等確率の理論によれば、可能なコミュニケーションの数は、組織の従業員数の2乗の半分に等しくなります。 小さな組織であっても、人々が仕事を終えられるように、コミュニケーションを制限する必要があります。 開発者間の通信技術を改善する研究は、システム管理に大きな影響を与えるでしょう。



軍隊型の組織は通常、管理構造に定量的な制限を使用します。 したがって、全員に上司と約7人の部下が必要です。 コミュニケーションは従属の原則に従って行われます。 したがって、そのような組織は、その構造とともに独自の組織構造に似たシステムを開発します。

おわりに

この記事の主な論文は、システムの開発と設計（ここでは広義に解釈される）に関与する組織は、コミュニケーション構造をコピーするプロジェクトを作成する運命にあるということです。 このプロパティは、設計プロセスの管理に重大な影響を与えることがわかりました。 プロジェクト組織の組織構造の重要な基準を特定しました。問題を解決するためのリソースは、組織構造のコミュニケーション能力に応じてのみ増加させる必要があります。 通信の必要性は特定の時点でのシステムの概念に依存するため、この基準では困難が生じます。 初期段階でのタスク評価は決して最適ではないという事実により、システム概念は変更を必要とする可能性があり、これは設計会社にとってこのような重要な品質を柔軟性として思い起こさせます。



企業の費用対効果と柔軟性に関心を持つように、開発プロセスの管理者に報酬を与えるような方法を見つける必要があります。 必要なのは、追加の労働力が生産性を向上させるという仮定に基づかない、新しいシステム開発と設計哲学です。 この方向での開発は、リソースのコストとコミュニケーションの方法に関する基本的な問題に対処する必要性に注意を喚起します。 これがなければ、システム開発の進歩を想像することは不可能です。

注釈

[1]プロジェクト会社の行動についてのより理解しやすい議論は、ジョン・K・ガルブレイスの「新しい工業国」にあります。 特にVI章、Technostructureに注意してください。



[2]プロジェクト活動の機能的環境におけるプロジェクトへの変換の詳細については、C。ミドルトン、「プロジェクト組織の設立方法」（C.J.ミドルトン、「プロジェクト組織の設立方法」、1967、p。73）を参照してください。



[3]この声明はさまざまな角度から考えることができます。 重要な交渉の定義に密接に関連する、些細なことです。 または、あるグループの開発者が、順序なしに別のグループを喜ばせるために自分の開発の変更に決して同意しないことを観察した結果かもしれません。



[4] S.N. パーキンソンの「パーキンソンの法則」（C.ノースコートパーキンソン、パーキンソンの法則とその他の行政の研究、1957）



翻訳：セルゲイダンシン

もっと

• 「委員会はどのように発明しますか？」
• 製品アーキテクチャと組織アーキテクチャの二重性の調査：「ミラーリング」仮説のテスト
• Conwayの法則はLinuxに適用されますか？
• コンウェイの法則[今日のフレームワーク]
• メル・コンウェイとマイク・アムンセンと一対一

エンゲルバートプロジェクトについて

GoogleドキュメントとHabraの翻訳«人間の知性の向上：

概念フレームワーク”ここで 、追加できます。



Engelbartプロジェクト の不可能なタスクは、最初の（現在の）バージョンのすべてのエラーを考慮に入れて、情報技術、インターネット、およびコンピューターハードウェアの分野全体を 「マトリックスをリロード」、「再構築」することです。



次のステップは、1か所で重要な概念文書を翻訳および収集し、志を同じくする人々 を探します （ 目を覚まし、Neo！あなたが探しているものもあなたを探しています ）。 Lebedev、Ershov、WikiPedia、Web Archive、Knol、Quora、Cyber​​syn、Xanadu、DARPA、IARPA。



詳細- 50年後。 すべてのデモの母

NLSを本当に理解したい場合は、今日の現実を忘れなければなりません。 コンピューターについて知っていることはすべて忘れてください。 あなたはまだコンピューターが何であるかを知らないと想像してください。 1962年に戻ります。 それから彼が考えていることを読んでください 。

-ブレット・ビクター、 ダグラス・エンゲルバートについての一言