【コンウェイの法則】その組織構成が、ソフトウェア品質を決定づける

conways-law
コンウェイの法則

Conway’s law

システムの構造は、システムを設計する組織を真似る

コンピュータープログラマーの、メルビン・コンウェイの発言からきています。内容は次のとおり。

システムを設計する組織は、その組織のコミュニケーション構造のコピーであるような設計を行う

メルビン・コンウェイ

よいソフトウェアを作るなら、そのソフトウェアを作るチーム構成から考えないといけない。ということです。

目次

ソフトウェア構成とチーム構成の関係性

ソフトウェアを、コンポーネントに分ける

大規模ソフトウェアを作るとき、ソフトウェアをいくつかの部分に分けて開発します。このひとつひとつの部分が、コンポーネント。ソフトウェアは、いくつかのコンポーネントが協調して動きます。

ソフトウェアは、疎結合、高凝集であるほど、頑健性が高まります。

コンポーネントが持つべき性質
  • 高凝集 同じ技術や仕様に基づく処理は、できるだけ同じコンポーネントにまとめる
  • 疎結合 コンポーネント間のコミュニケーションは、できるだけ簡単にする

コンポーネントを、開発チームが開発する

コンポーネントを、それぞれのチームが開発します。1つのコンポーネントは、1つの開発チームが担当することになるでしょう。

なので開発チームは、コンポーネントと同じ性質を持っていることが大事になります。

開発チームが持つべき性質
  • 高凝集 同じ技術力や仕様に精通するメンバは、できるだけ同じチームにまとめる
  • 疎結合 チーム間のコミュニケーションは、できるだけ簡単にする

コンポーネント構成の考え方:縦割りか、横割りか

コンポーネント構成を考えるときの分割の仕方として、縦割りか横割りか、があります。

例えば、商品購入サイトのシステムを開発することを考えます。

縦割り:「機能」で分割

このシステムは、以下の機能があります。

  • 商品リスト管理機能
  • 購入決済機能
  • ユーザ管理機能

それぞれの機能の開発には、その機能に応じた業務知識が必要です。商品リスト管理なら商品の知識。購入決済なら商取引について。

機能ごとにコンポーネント分割するのは、自然な考えでしょう。

機能で分割したコンポーネント
機能で分割したコンポーネント

横割り:「技術」で分割

「商品リスト管理機能」「購入決済機能」「ユーザ管理機能」には、それぞれ以下の処理があります。

  • 操作用の画面
  • 裏で処理するロジック
  • データを管理するデータベース

画面、ロジック、データベースなどは、それぞれ異なる専門技術が必要になります。画面ならUIフレームワーク、データベースならスキーマ設計やSQL。この技術領域でコンポーネント分割するという考えもあります。

技術で分割したコンポーネント
技術で分割したコンポーネント

機能とアーキテクチャは交差する

困るのは、この縦割り(機能別)と、横割り(技術別)が、縦横に交差することです。

機能の技術の交差
機能の技術の交差

コンポーネントはどこかで分割しないといけない、これをどう分割するか、が課題になります。

そして、開発チームも、コンポーネントと合わせた分割を考える必要があります。

どのようにチームを分けるか

技術別チーム:おすすめしない

技術別のチームは、それぞれの専門家の技術者を集めればいいので、チーム編成はやりやすいです。

技術別チーム
技術別チーム

ただこの編成には、大きな欠点があります。

「商品リスト」や「購入決済」といった、業務知識(ビジネスロジック)を保証するチームがいないのです。プロジェクトはほぼうまくいきません。

機能別チーム:フルスタック対応の課題あり

通常は、機能別チーム編成にします。

機能別チーム
機能別チーム

ただし、このチーム編成を取るとき、以下の課題があります。

チーム別編成の課題
  • コミュニケーションチャネル増加 同じような技術を複数チームが使うため、チーム間で技術分野における情報交換量が多くなる
  • フルスタックエンジニア必須 複数技術を横断する開発となるので、それらの複数の技術に長けたエンジニアが必要

また、技術的なコミュニケーションチャネルの増加は、開発者間の二重化(同じようなモジュールを複数人が開発)を生み出す原因にもなります。

開発者間の二重化について→ DRY原則~コピペ禁止の、さらにその先

チーム分割の課題への対処

チーム分割の課題への対処としては、以下の方法があります。

技術力の簡易化と平準化を図る

技術的コミュニケーションチャネルを簡素化するため、技術に比較的左右されないコンポーネントを考える、これがひとつの手。

例えば、フレームワークを導入して簡易化、技術に依存するコンポーネントだけ切り出して別の開発チームを作る、など。

これはひと昔前は効果がありました。しかしいまは技術は進化が早く、また技術レイヤーの境界もはっきりしなくなっています。現在ではなかなか難しい施策です。

チームでフルスタックとなる編成とする

フルスタックエンジニアがいれば、それがベスト。ただそんなエース級のエンジニアはそうそういない。

なので、チームに個別の技術力をもったメンバーを揃えて、チームとしてフルスタックにする。これが現実的な解になります。

フロントエンドやバックエンドの技術については、タスクフォースをつくって横のつながりを持たせると盤石になります。※タスクフォース:課題を解決するために一時的に結成するチーム

ただタスクフォースは、トップが明確な意思を持っていないと、形骸化しやすいです。力強い意思で推進しましょう。

まとめ

コンウェイの法則は、いちどでもプロジェクトを経験したことがある人なら、ひしひしと実感する法則。

とはいえ理想的なチーム編成もなかなか難しい。プロジェクトリーダーのジレンマです。

正解がなかなか見つからない問題ですが、少しでも良いソフトウェア開発ができるよう、学んでいきましょう。

なお、ソフトウェア構造を改革するため、あえて組織を改編するという、逆コンウェイ戦略も存在します。いざとなったら使ってみる手もあるかも。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

コメント

コメントする

CAPTCHA


目次