最強の組織は何か
普段そういうメタ認知というか、全体的な構造を考えずに、git commitし、PRを作成したり、トラブル対応したりする日々ではないでしょうか。
たまには俯瞰するべき。
手元のオライリー本ズたちや、色々な記事から、エンジニア組織に関係する項目を抜き出してみました。
本記事は以下の構成です。
・原理原則
・構成パターン、アンチパターン
・具体例
・分類する
・まとめ
組織論の原理原則 コンウェイの法則
コンウェイの法則
システム（ここでは単なる情報システムより広く定義されたシステム）を設計するあらゆる組織は、必ずその組織のコミュニケーション構造に倣った構造をもつ設計を生み出す。
Oreilly 『マイクロサービスアーキテクチャ』
コンウェイの法則とシステム設計 より
p.223
言われてみればそうかもしれません。
疎結合なシステムには疎結合な組織が必要なのかもしれません。
以下の記事もわかりやすかったです。
『SREの探求』にも以下の記述があります。
コンウェイの法則を侮辱と考え、あらゆる組織がこれに反証しようとしてきたように思えます。
これはほとんど成功しませんでした。ちなみに、このほとんどは、全く、という意味で使っています。ソフトウェアコンポーネントが最終的に人間のコンポーネントと同じような配置になることには十分な理由があります。どちらの場合も、コンポーネント間のインターフェイスを注意深く定義して変更には時間をかけるのでないかぎり、大規模なシステムは機能しません。どのような呼び方をするにせよ、コンポーネントからシステムを構築するとは、コンポーネント間のやり取りにおいて、それぞれの側が相手側に何を期待するかを伝えるための抽象化に依拠できるようにする契約なのです。
『SREの探求』のp.568-569 31章 複雑なシステムのためのエレジー
31.1 コンピュータのシステムと人間のシステムは分離できない
構成パターン
feature型組織、職能型組織の2種類があるようです。
職能型組織
フロントエンドやバックエンド、QAチーム、SREチームなど専門性を活かしたチームです。
feature型組織
サービスやプロダクトごとに縦割りになったチームです。
※1より
また、スキルセットチーム、機能横断チームという分け方もあるようです。
スキルセットチーム
専門知識を集約し、特定のスキルや技術のベストプラクティスを確実に実行するチーム。
専門家が全員集まって一緒に働いていて、日ごろからコミュニケーションしている
機能横断チーム
アプリケーションにまったく新しい機能を追加するといった共通のゴールに向かって進めるチーム。チームはプロジェクトのライフサイクル全般に関わる。プロダクト中心の企業で一般的であり、新機能をリリースするにはデザイン、プロダクトマネジメント、UX、バックエンド、フロントエンド、QAなどさまざまなインプットが必要になる。
オライリー『エンジニアリングマネージャーの仕事』p.254-255 14章 良いハウスキーピング 14.1 コミュニケーションがソフトウェアの設計を決める より
和訳の問題？なのか同じ分類ですね。
スキルセットチーム、機能横断チームの分類を以下で使います。
構成アンチパターンと打開策
サイロ化がアンチパターンとしてあります。
サイロ化
→局所化してしまうこと。
【用例1】組織がサイロ化する→組織が
【用例2】メトリックスがさまざまなシステムにサイロ化されている多くの組織を見てきました。
オライリー『マイクロサービスアーキテクチャ』 p.196 監視 8.12 将来
また、このサイロ化はいずれの組織構造においても起き得るようです。
この打開策として、ギルドが挙げられるようです。
ギルド
部門間を超えた組織間の繋がり。部門横断で特定の目的をもって集まり、何かを達成すること。特定のプロジェクトだけでなく、勉強会もこれに含む。
パッと思い浮かべるだけでも、社内勉強会、部門をまたがったプロジェクトなど、所属組織の中で、いくつかギルドとして思い当たるものがあるのではないでしょうか。
Spotifyはこのギルドについて先進的な思想をもち、以下の名前のようなグループがあるとのことです。
・スクワッド・・・機能横断的な開発チーム
・トライブ・・・たとえばインフラストラクチャーなど、関連する領域で働くスクワッドの集合。
・チャプタ・・・トライブのなかで共通するスキルを持つ個人のグループ。
・ギルド・・・部門全体で共通の興味を持つ個人のグループ。
※2
具体例
これらの原理、組織構造の類型を元に組織例を見ていきます。
私が現在SREに所属していることもあり、SREの組織論について見ていきたいと思います。
一旦SREとは？についても２秒説明しておきます。
SRE(Site Reliability Engeneering)
サイトの信頼性を担保することを目的としてエンジニアリングする組織。
英語を訳すと２秒説明ができますね。
以下の記事に、よるとSREの組織類型は4パターンになるようです。
以下の4類型の要約には上記記事の引用に対し、ChatGPT4を使用しました。
黒太字にしている部分は私の判断です。違いが浮き立つ部分を黒太字にしています。
The Google Model
専用のエンジニアリングチームが製品の運用とスケーリングに集中し、信頼性のためのコードベースの更新とサポートツールの構築を行います。
チームはオンコールであり、信頼性が特定の閾値を下回る場合は、機能チームにサポートを引き継ぐことができます。
We Are Now SRE
従来のオペレーション、DevOps、およびプラットフォームチームは、信頼性とスケーラビリティの向上を重視するエンジニアリングに焦点を当てることで、サイト信頼性エンジニアとしてブランドを再構築しました。
これらのチームは通常、製品コードに大きな変更を加えることはありませんが、インフラストラクチャやサポートに重要な役割を果たします。
SRE Center of Practice
信頼性ツールとプロセスを作成し、推進することに焦点を当てた中央集権的なチームです。オンコールの責任は外部顧客向けのツールに限られます。
このチームは、SREパターンとツールの採用を支援するための内部コンサルティング部門として機能しますが、製品の直接的な責任はありません。
Embedded SRE
SREエンジニアは、ビルドから廃棄までの製品のライフサイクル全体を所有する機能横断的なチームに組み込まれています。これは、エンジニアが製品チーム内にフルタイムで組み込まれるマトリックス型SRE組織の形を取る場合と、製品チームが専用のSREエンジニアを雇用する場合があります。SREエンジニアは、ライフサイクル全体を通じて適切なスケーラビリティと信頼性を確保するために、チームがエンジニアリングの慣行とツールを採用するのを支援する信頼性/スケーラビリティの主題専門家です。
分類する
この5類型を前半で見た、組織類型(スキルセットチーム、機能横断チーム）で分類しました。
| The Google Model | We Are Now SRE | SRE Center of Practice | Embedded SRE | |
|---|---|---|---|---|
| スキルセットチーム | 〇 | 〇 | 〇 | 〇 |
| 機能横断チーム | △ | × | △ | 〇 |
どれもSREという分類の中のサブカテゴリなので、スキルセットチームに分類できます。
しかし、一方で、機能横断的なチームに組み込まれているという点で、Embedded SREが唯一、両方の性質を持っていると言うこともできるのでは？と考えました。
こういう性質をもとに、コンウェイの法則から、ソフトウェアの問題点の根本的解決策も見えてくるのでは？と思いました。
まとめ
以上、組織論の基本を確認したのちに、具体例をもとに組織を考察しました。
以下のようなことがわかりました。
・エンジニア組織は類系化できる。
・組織構造がソフトウェアの構造にも反映されることから、組織を考えることは問題の根本的解決の手がかりとなる。
・いずれの組織形態にせよ、サイロ化されないように、ギルドを作ることが重要・
・Embedded SREという組織は機能横断的なチームに組み込まれているという点で独自の分類ができる。
一方で以下の点は本記事では網羅できていませんが今後このあたりも考えられるかもしれません。
・SRE以外の組織に対する具体例
・所属組織とそこで可能なキャリアラダーの関連
・より広く一般的な組織論の知識。コンウェイの法則やギルドは一般的な組織論用語であるようだが、その他にもあるか。
・組織の構成ではなく、内部的な構成。組織の構成員をどう配置するかなど。
など
今後の課題にしたいです。
以上、最後まで読んでいただきありがとうございました。
普段の業務の何かのヒントになれば幸いです。
引用元
※1
※2 p.257 オライリー『エンジニアリングマネージャーの仕事』ギルドでサイロを壊す p.257
参考文献