コンウェイの法則と逆コンウェイの法則から組織構造を考える

この記事は、「コンウェイの法則」とその逆転の発想の「逆コンウェイの法則」について述べていきます。

組織体制とアーキテクチャの相関関係

組織体制はアーキテクチャは相関関係があります。わかりやすい例を出すと下図をご覧ください。

よくありがちなモノリシックな構成です。１つのモジュールにたくさんの機能を格納されており、組織体制としては職能型としてバックエンドチームなどが存在していきます。

これをマイクロサービス化したとします。ただ、組織体制はそのままです。このままだとせっかくServiceA,B,Cと責務を分けたのにそれを管轄しているチームは同じになっていました。つまり、マイクロサービス化のメリットが受けられません。

解決策としては、よくある構造としてfeatureチーム性としてサービスごとにチームを分ける形となります。

コンウェイの法則

こういった現状を的確に表したのが、「コンウェイの法則」です。

コンウェイの法則とはメルヴィン・コンウェイが提唱した概念です。

システム設計(アーキテクチャ)は、組織構造を反映させたものになる

となり、上の例でいけばマイクロサービス化というアーキテクチャにしたことによって組織構造も変化していくということです。

サービス開発で有益な指標としては、DevOpsの文脈で1日にどのくらいデプロイ・リリースできるか。というのが良い組織体制かどうかの指標としてあります。

コンウェイの法則に従い、マイクロサービス化 x 組織構造にすれば、Service間での依存関係も極力するなくなり、かつ人的な調整や障害もなくなります。リリースを妨げるのはおおよそこの要素と考えるとマイクロサービス化 x feartureチーム性というのはかなり有効だと感じます。

逆コンウェイの法則

これを逆手に取ったのが「逆コンウェイの法則」です。

つまり、アーキテクチャによって組織構造を変化させる後追いのではなく、そもそも最初から最適なアーキテクチャに合うような組織デザインを設計するという「アーキテクチャのための組織を作る」というイメージです。

職能型組織とfeature型組織

組織構造でいれば、職能型とfeature型どっちが良いかの議論があります。

• 職能型組織というのは、フロントエンドやバックエンド、QAチーム、SREチームなど専門性を活かしたチームです。
• feature型組織は、サービスやプロダクトごとに縦割りになったチームです。

職能型でいくかfeature型の組織構造にするかの議論はさまざまありますが、個人的には、基本的なベースとしては、feature型の組織であるべきだとおもっています。やはり、意思疎通や調整が明らかに早いのでリリースまでのリードタイムが違います。さらにプロダクトをフロントエンドからバックエンド、インフラ、データを使った仮説検証などフルスタックなエンジニアであるべきことが求められてくるので比較的キャリアパスとしていろいろな部分を触れることができます。※広く浅くといった意味ではなく。

ただ、feature型組織はあくまでも「開発スピード」の分野では有効だと思っています。QAチームやSREチームのようなサービス目線ではなく、ある意味社内BtoBの関係にある全体的品質・信頼性など開発スピードとは少し外れた部分に関しては横断型組織として必要だと思っています。

以上です。