Conway’s law
システムの構造は、システムを設計する組織を真似る
コンピュータープログラマーの、メルビン・コンウェイの発言からきています。内容は次のとおり。
システムを設計する組織は、その組織のコミュニケーション構造のコピーであるような設計を行う
メルビン・コンウェイ
よいソフトウェアを作るなら、そのソフトウェアを作るチーム構成から考えないといけない。ということです。
ソフトウェア構成とチーム構成の関係性
ソフトウェアを、コンポーネントに分ける
大規模ソフトウェアを作るとき、ソフトウェアをいくつかの部分に分けて開発します。このひとつひとつの部分が、コンポーネント。ソフトウェアは、いくつかのコンポーネントが協調して動きます。
ソフトウェアは、疎結合、高凝集であるほど、頑健性が高まります。
- 高凝集 同じ技術や仕様に基づく処理は、できるだけ同じコンポーネントにまとめる
- 疎結合 コンポーネント間のコミュニケーションは、できるだけ簡単にする
コンポーネントを、開発チームが開発する
コンポーネントを、それぞれのチームが開発します。１つのコンポーネントは、１つの開発チームが担当することになるでしょう。
なので開発チームは、コンポーネントと同じ性質を持っていることが大事になります。
- 高凝集 同じ技術力や仕様に精通するメンバは、できるだけ同じチームにまとめる
- 疎結合 チーム間のコミュニケーションは、できるだけ簡単にする
コンポーネント構成の考え方：縦割りか、横割りか
コンポーネント構成を考えるときの分割の仕方として、縦割りか横割りか、があります。
例えば、商品購入サイトのシステムを開発することを考えます。
縦割り：「機能」で分割
このシステムは、以下の機能があります。
- 商品リスト管理機能
- 購入決済機能
- ユーザ管理機能
それぞれの機能の開発には、その機能に応じた業務知識が必要です。商品リスト管理なら商品の知識。購入決済なら商取引について。
機能ごとにコンポーネント分割するのは、自然な考えでしょう。
横割り：「技術」で分割
「商品リスト管理機能」「購入決済機能」「ユーザ管理機能」には、それぞれ以下の処理があります。
- 操作用の画面
- 裏で処理するロジック
- データを管理するデータベース
画面、ロジック、データベースなどは、それぞれ異なる専門技術が必要になります。画面ならUIフレームワーク、データベースならスキーマ設計やSQL。この技術領域でコンポーネント分割するという考えもあります。
機能とアーキテクチャは交差する
困るのは、この縦割り（機能別）と、横割り（技術別）が、縦横に交差することです。
コンポーネントはどこかで分割しないといけない、これをどう分割するか、が課題になります。
そして、開発チームも、コンポーネントと合わせた分割を考える必要があります。
どのようにチームを分けるか
技術別チーム：おすすめしない
技術別のチームは、それぞれの専門家の技術者を集めればいいので、チーム編成はやりやすいです。
ただこの編成には、大きな欠点があります。
「商品リスト」や「購入決済」といった、業務知識（ビジネスロジック）を保証するチームがいないのです。プロジェクトはほぼうまくいきません。
機能別チーム：フルスタック対応の課題あり
通常は、機能別チーム編成にします。
ただし、このチーム編成を取るとき、以下の課題があります。
- コミュニケーションチャネル増加 同じような技術を複数チームが使うため、チーム間で技術分野における情報交換量が多くなる
- フルスタックエンジニア必須 複数技術を横断する開発となるので、それらの複数の技術に長けたエンジニアが必要
また、技術的なコミュニケーションチャネルの増加は、開発者間の二重化（同じようなモジュールを複数人が開発）を生み出す原因にもなります。
開発者間の二重化について→ DRY原則～コピペ禁止の、さらにその先
チーム分割の課題への対処
チーム分割の課題への対処としては、以下の方法があります。
技術力の簡易化と平準化を図る
技術的コミュニケーションチャネルを簡素化するため、技術に比較的左右されないコンポーネントを考える、これがひとつの手。
例えば、フレームワークを導入して簡易化、技術に依存するコンポーネントだけ切り出して別の開発チームを作る、など。
これはひと昔前は効果がありました。しかしいまは技術は進化が早く、また技術レイヤーの境界もはっきりしなくなっています。現在ではなかなか難しい施策です。
チームでフルスタックとなる編成とする
フルスタックエンジニアがいれば、それがベスト。ただそんなエース級のエンジニアはそうそういない。
なので、チームに個別の技術力をもったメンバーを揃えて、チームとしてフルスタックにする。これが現実的な解になります。
フロントエンドやバックエンドの技術については、タスクフォースをつくって横のつながりを持たせると盤石になります。※タスクフォース：課題を解決するために一時的に結成するチーム
ただタスクフォースは、トップが明確な意思を持っていないと、形骸化しやすいです。力強い意思で推進しましょう。
まとめ
コンウェイの法則は、いちどでもプロジェクトを経験したことがある人なら、ひしひしと実感する法則。
とはいえ理想的なチーム編成もなかなか難しい。プロジェクトリーダーのジレンマです。
正解がなかなか見つからない問題ですが、少しでも良いソフトウェア開発ができるよう、学んでいきましょう。
なお、ソフトウェア構造を改革するため、あえて組織を改編するという、逆コンウェイ戦略も存在します。いざとなったら使ってみる手もあるかも。
コメント