エンジニアリング組織図：チームと担当システムを対応させる

ほとんどの組織図が答えるのは、誰が誰に報告するかという 1 つの問いだけです。エンジニアがその答えを必要とすることはあまりありません。インシデントの最中に知りたいのは、障害が起きているサービスをどのチームが担当していて、誰がオンコールかです。設計レビューで知りたいのは、変更がどのチームに影響し、それらのチームがどう連携しているかです。名前と肩書きを並べた図は、そのどれにも答えません。

この記事では、それに答えられるエンジニアリング組織図を作ります。人事面のためにレポートラインは残しつつ、エンジニアリングに必要な情報として、チームタイプ、担当システム、オンコールの時間帯、チーム間の連携方法を加えます。チームについては Team Topologies の用語を使い、最後に、何をラベルに書くか、図をどう最新に保つかを説明します。

エンジニアリング組織図に載せるべきもの

チームが数個を超えたら、個々のエンジニアは図から外し、チームリードごとに 1 枚のカードを置きます。60 人の名前が並ぶ図は電話帳ですが、8 つのチームの図は地図になります。名前が必要なら、各チームを専用のメンバー一覧にリンクしましょう。

レポートラインがすべてではない

Mel Conway の論文「How Do Committees Invent?」は、1968 年 4 月に Datamation に掲載されました。彼はこの法則についての自身のページで、その主張を次のようにまとめています。システムを設計する組織は、その組織のコミュニケーション構造を写した構造を持つ設計を生み出す。のちに Fred Brooks がこれをコンウェイの法則と呼び、その名前が定着しました。

「コミュニケーション」という言葉に注目してください。組織図が示すのはレポートラインであり、それは人がコミュニケーションをとる方法の一部にすぎません。別々のディレクターの下にいても毎日話している 2 つのチームは、マネージャー同士をつなぐ線よりも強くシステムの形を決めます。そのため、この記事の図には、チームが誰に報告しているかだけでなく、どう連携しているかも書いています。

この法則は設計の道具としても使えます。2 つのサービスを独立させておきたいなら、すべての変更を調整しなければならないチームにそれらを任せてはいけません。Conway の論文には系もあります。最初の設計が最善であることはまれなので、組織は設計とともに変われるだけの柔軟性を持つ必要があるというものです。

チームタイプとインタラクションモード

Matthew Skelton と Manuel Pais による Team Topologies は、チームに小さな共通語彙を与えます。4 つのチームタイプと、チーム同士の 3 つの関わり方です。

3 つのインタラクションモードは次のとおりです。

• コラボレーション。 2 つのチームが、API やプラクティスのような新しいものを見つけるために、決められた期間だけ密接に協力します。コストが高いので、終了日を決めましょう。
• X-as-a-Service。 一方のチームが何かを提供し、もう一方はほとんどやり取りせずにそれを利用します。デプロイパイプラインがその例です。
• ファシリテーティング。 一方のチームが、新しいテスト手法を導入しているときなどに、もう一方のチームを助け、指導します。

Team Topologies のサイト自体にも注意書きがあります。このアプローチは新しい組織図を設計するための手法ではない、というものです。これは仕事がチーム間をどう流れるかを説明するものです。その用語は図のラベルとして使い、すべてのレポートラインを描き直す理由にはしないでください。

オーナーシップは 1 か所で管理する

図にだけ書かれたオーナーシップは古くなります。信頼できる情報源はエンジニアがふだん見ている場所に置き、図はそれをチーム単位で反映するようにしましょう。

Backstage のようなサービスカタログでは、すべてのコンポーネントにオーナーを指定する必要があります。カタログの記述子フォーマットでは spec.owner が必須フィールドで、オーナーは単一のエンティティ、一般的にはチームです。リポジトリでは、CODEOWNERS ファイルがパスと担当する人やチームを対応づけます。ドラフトではないプルリクエストが担当コードを変更すると、GitHub はコードオーナーに自動でレビューを依頼します。

図とカタログが食い違っていたら、たいていはカタログのほうが正しく、図の見直しが遅れています。

例：オンラインショップのエンジニアリング部門

あるオンラインショップのエンジニアリング部門には、VP と 2 人のディレクターがいます。Product Engineering は 3 つのチームを率いています。どちらもストリームアラインドの Checkout と Search、そして決済処理と不正スコアリングを担当するコンプリケイテッド・サブシステムチームの Payments です。Platform Engineering は、CI/CD、Kubernetes クラスター、オブザーバビリティスタックを担当する Platform チームと、リードのポジションがまだ空いている Developer Experience チームを率いています。

今四半期は 2 つの連携が進行中です。Payments と Checkout は、第 2 四半期末まで 3-D Secure でコラボレーションしています。Developer Experience は、Checkout のコントラクトテストへの移行をファシリテーションしています。

図の読み方は次のとおりです。

• 上から下へ、レポートライン。 VP、2 人のディレクター、5 人のチームリードです。線が示すのは誰が誰に報告するかだけです。
• カードの色はチームタイプ。 ストリームアラインドはアンバー、コンプリケイテッド・サブシステムはローズ、プラットフォームはブルー、イネイブリングはバイオレットです。チームより上のマネージャーはグレーのままです。
• 各チームの下に、エンジニアリングの視点。 そのチームが担当するサービス、オンコールの時間帯、ほかのチームとの現在の連携です。
• 破線のカード は欠員です。Developer Experience にはまだリードがおらず、図はその空白を隠さずに示しています。

ラベルに書くこと

• チーム名は、人が実際に呼んでいるとおりに。 インシデントのチャンネルで「Checkout」と呼ばれているなら、図にも Checkout と書きます。
• 担当システム は、カタログ、ダッシュボード、アラートで使われている名前で書きます。
• オンコールの時間帯 と、エスカレーション先を書きます。
• すべてのコラボレーションに インタラクションモードと終了日 を書きます。
• 点線の関係。 たとえば、セキュリティチームに報告しつつ毎日 Payments と働くセキュリティエンジニアです。
• チームが複数の拠点にまたがるなら、拠点やタイムゾーン を書きます。
• 最後に見直した日付 を図そのものに書きます。

よくある間違い

• チームのない人の一覧。 名前のツリーでは、何かが壊れたときにどこへ行けばよいか誰にも分かりません。
• 誰も担当していないシステム。 どのチームの下にも出てこないサービスがあれば、それ自体が発見です。次のインシデントが割り当てる前に、担当を決めましょう。
• 共同オーナーシップ。 オーナーが 2 人いるのは、たいていオーナーがいないのと同じです。Backstage が単一のオーナーを求めるのには理由があります。
• 終わりのないコラボレーション。 コラボレーションは決められた期間のためのものです。いつまでも終わらないなら、2 つのチームの境界が間違った場所にあることが多いでしょう。
• 負荷が大きすぎるチーム。 十数個のサービスと 2 つのオンコールローテーションを抱えるチームは、すべてにおいて遅くなります。Team Topologies はチームの認知負荷を設計上の制約として扱います。図にすれば、その負荷が見えるようになります。
• 誰も更新しない図。 組織変更や新しいサービスのたびに更新し、定期的に見直しましょう。

組織図は誰が何を担当しているかを示しますが、システム同士がどう組み合わさっているかは示しません。それには C4 モデルの図やマイクロサービスアーキテクチャの図を描き、古びないアーキテクチャ図で説明しているように、両方を最新に保ちましょう。

Archboard で作る

1. Google または GitHub でサインインし、図を作成するか、組織図テンプレートから始めます。
2. 組織図パックから VP 用の 社員 カードを追加し、名前、肩書き、部署、勤務地を入力します。
3. プラスのハンドルで人を追加します。下は部下、横は同僚、上は上司です。図は上から下へ自動でレイアウトされます。
4. 採用中のポジションごとに 欠員 カードを追加します。
5. 各チームリードのカードの色をチームタイプに合わせ、チームより上のマネージャーはグレーのままにします。
6. 各チームリードの下に、チームタイプ、担当システム、オンコールの時間帯、現在のインタラクションモードを書いた基本パックの テキスト を追加します。

この例で使うダイアグラムノードは 8 個で、Free プランの範囲に収まります。テキストはこの上限に数えられません。組織図作成のページでは、共有とエクスポートを紹介しています。

よくある質問

エンジニアリング組織図にはエンジニア全員を載せるべきですか？ チームが少なければ、載せてもかまいません。それを超えたらチームとリードだけを示し、各チームを専用のメンバー一覧にリンクしましょう。図が読みやすく保たれ、更新の頻度も減ります。

点線の上司はどう表せばよいですか？ 2 人目の上司から破線を引き、実線は人事評価を行う上司のために残します。Archboard では、2 人目の上司からの接続は点線になり、レイアウトは 1 人目の上司を基準にしたままです。

組織図とチームトポロジーの違いは何ですか？ 組織図はレポートラインを示します。チームトポロジーは、チームタイプとチーム同士の関わり方を示します。両方を描くか、この例のように組織図に連携を書き添えましょう。

サービスのオーナーシップはどこで管理すべきですか？ ツールと人が見つけられるサービスカタログか CODEOWNERS ファイルです。組織図はそれをチーム単位で反映します。

エンジニアリング組織図はどのくらいの頻度で更新すべきですか？ 組織変更、新しいチーム、新しいサービスのたびに更新し、加えて月に一度などの定期的な見直しを行います。最後に見直した日付を図に書きましょう。

無料で始める — 1 シート、クレジットカード不要。