エンジニアリングチームのリーダーに贈る“チーム構築”の正攻法 ── 海の向こうからオピニオン！その26

エンジニアリングチームのリファレンスモデル

ここ数年来、エンジニアリングチームを組織する際のリファレンスモデルとして、「Spotifyモデル（*1）」が広く用いられてる。

ただし、Spotifyモデルのように、「分隊（Squads）」「部隊（Tribes）」をベースにした組織の構造には、いくつかの落とし穴がある。そうした一般的なモデルの欠点や長所を把握したうえで、「リスク」や「スケール（規模）」を勘案しながら、自社の戦略にフィットしたチームをどう組織していくかが、エンジニアリングチームの構築を巡る最大の課題と言える。

エンジニアリングチームの構造は通常、チームの効力を最大化するという主眼の下、いくつかの要素のバランスを適正化していくことで決められる（下図参照）。

上図のようなトレードオフスライダーを使うことで、例えば、「技術チーム」「マトリクスチーム」「プロダクトチーム」のそれぞれについて、以下のような事柄を決定することができる。

もっとも、スライダーを動かすことは簡単だが、その設定を実際のチーム作りに反映する作業は簡単ではなく、設定の変更が必要になった場合、その変更に基づきチームの構造を変えるのも難しい。果たして、エンジニアリングの現場では、どのようにしてチームの構造を定め、また、変更しているのだろうか。

そうした疑問を解き明かすべく、本コラムでは、アトラシアンのエンジニアリング責任者であるステファン・ディジー（Stephen Deasy）に協力を仰ぐのと併せて、InVision社、Slack社、Dropbox社を始めとする業界のプロフェッショナルたちにインタビューし、その知見をご教示いただいた。

以下では、インタビューを通じて引き出した知見に基づきながら、エンジニアリングチームを組織したり、構造を変更したりする際の要点をお伝えする。

「トライアド」の調整

今回インタビューしたチームリーダーたちは一様に、エンジニアリングチームにおいて、3つのコアコンピテンシー、つまりは、チームの「トライアド」をどう設定・結合するかをどう築き、調整するかに力を注いでいた。

アトラシアンとInVision社のトライアドモデルは、「プロダクト」「エンジニアリング」「デザイン」の3つから構成されている（図2）。

「プロダクトとエンジニアリング、デザインの3つは、当社のエンジニアリグチームの3本柱です。多くの企業では、エンジニアリングチームを組織する際に、デザインの重みづけを、エンジニアリングとプロダクトと同レベルにするところは意外と少ないのですが、当社ではデザインワークが我々のビジネスの中核となるため、同等に扱っています」（InVision社、エンジニアリングSVP、アサンカ・ジャヤスリヤ氏）。

こうした人員構成のエンジニアリングチームでは一般的に、最終的な意思決定を誰が担うべきかという問題が浮上する。その問題は、InVision社も例外なく抱えているようだ。

一方、Dropbox社では、「コンテンツ（Content）」「コーディネーション（Coordination）「コミュニケーション（Communication）」の3つをコンピテンシーとして設定している。

また、Slack社では、小規模なチームのトライアドがいくつもあり、それが相互に連携することで構成されているという。「Slackにおけるエンジニアリングチームは、高次では“ビジネスユニット”を形成するのですが、ベースのユニットはトライアド型です。Spotifyモデルで言うところの部隊（Tribe）やギルド（Guild）に近い組織も存在しています」（Slack社、エンジニアリングディレクター、スティーブン・チェン氏）。

ちなみに、いずれの企業でも、エンジニアリングチームの構造が現在のかたちに至るまでには、幾度もの実験と方向転換、反復と改善があったという。言い換えれば、トライアドモデルはエンジニアリングチームに適した構造と言えるが、開発のスピードやチームの規模、自律性のバランスを適切に取るためには、実践を通じた試行錯誤の繰り返しが必要とされるということだ。

大規模プロジェクトのためのチーム構造

チームの構造を考えるうえで大きなポイントとなる一つは、規模の拡大である。

小規模な企業、あるいは小規模なチームは、文字通りのチームであり、目標、ニーズ、問題は、チームのリーダーとメンバーの目前にあり、大抵の場合、目標や問題の達成・解決に適した人材だけでチームが組織されている。ゆえに、特に組織の構造を考えなくても、チームは効果的に機能できる。

ところが、チームメンバーの数が10人から50人へ、50人から150人、300人へと増えてくると、組織の構造をしっかりとデザインしなければ、チームを有効に機能させることはできない。

実際、ダンバー数（Dunbar's number）に従うと、人が他者を認知し、社会的なつながりが保てる限界数は150人であるという。実際、会社組織の規模が150人を超えると、成長の痛みを強く感じるようになるのが一般的であるらしい。この点について、アトラシアンのディジーは次のように話す。

「チームの人数が15人程度なら、リーダーはメンバー全員の状況を、目視で捉え続けることができます。ところが、メンバーの数が40人に膨らみ、それぞれが複数のフロアに分散して働くようになると、全員の動きをとらえ続けることは物理的に不可能になり、重要なマイルストーンごとに確認をとるために、隔週での会議を行うようになるでしょう。さらに、メンバーが150人規模になると、プロジェクトにおけるチーム内でのやり取りはより機械的になり、メンバー全員が共通の使命を持ったチームであるという一体感は薄れていくのが通常です」

ディジーが指摘するとおり、150人規模のチームで、コミュニケーションや成果物の品質を高いレベルで維持するのはかなり難しい。ゆえに、チームの構造を常に評価しながら、必要に応じて変更を加える必要があるようだ。

なお、この規模のチームでは、チーム内でいくつかの「ビジネスユニット」を組織し、それぞれにトライアドのグループを持たせ、小規模の会社のように機能させる方式がとられることがある。これによって、各グループはフォーカスが明確になるものの、反面、チームの自律レベルが高まるにつれて、全体を制御するのが難しくなるという問題が頭をもたげてくる。

前述したSpotifyモデルは、こうした問題の解決を可能にするとされている。チームリーダーはプロダクトの開発をリードするのではなく、メンバーのマネジメントに集中し、各チームは自ら目標を設定して、自走する。その中で、リーダーは、チームのコーチ役に徹し、チームの中には入らない。そして経営幹部は、解決すべき課題を把握しているものの、実際に何が作られているのかまでは把握できないため、不安を感じることもある。そのため、経営幹部に対するケアを含めて、Spotifyモデルによる大規模なエンジニアリングチームの運用には、頻繁なコミュニケーションと適切な管理が不可欠となる。

「組織の構造には完璧なかたちは存在せず、構造の変更にも完璧なものはありません。常に何かを得る代わりに、何かを捨てなければならず、プロダクトの目標やコーディングの効率性、チームの士気のバランスをとりながら、調整を図る以外に方法はないと言えます」と、取材当時Dropbox社に所属していたティナ・シュシュマン氏は言う。

また、チェン氏は次にように指摘する。

「全ての組織はユニークで、組織が担うビジネスも、ビジネスのコンセプトもユニークです。また、アジャイル開発は素晴らしい方法論ですが、誰もがそれに簡単に適応できるわけではありません。つまり、何がエンジニアリングチームにとってベストかは、チームごとに異なり、ベストなものが何かを都度見定める必要があるということです」

チームの構造を変える前に成すべきこと

「組織の成長に応じて、チームの構造も成長し、適応する必要があります。ところが、多くの人が、それまでのやり方に固執して、変化になかなか適応しようとしないのが現実です」と、元Darby Smart社CTOのカール・メンデス氏は指摘する。

同氏の言うように、チームを新しく構築したり、構築し直したりすることは、メンバー各人に新しい仕事のやり方への転換を求める。ゆえに、チームの構築、ないしは再構築に際しては、相応の原則、ないしは哲学をもって臨むことが必要になるようだ。

「私が大切にしている原則は、チームの柔軟性を高く保つことです」と、チェン氏は語り、こう続ける。

「例えば、当社では毎年のようにチームの小さな再編を繰り返しています。これは、チームが成すべきことの優先順位がさまざまに変化し、適切な人に適切な問題を解決してもらうための施策ですが、小さな再編の繰り返しは、チームの柔軟性を高く保つうえでも有効です。例えば、チームというのは、メンバーを一人増員するだけで、これまでとは異なる新しいチームになります。そのような変化にメンバーが慣れることで、チームの柔軟性は高められていくわけです。」チームの構造は静的なものと見なされがちだが、動的であるのが本来の姿なのだ。

これに対して、シュシュマン氏は次のような見解を示す。

「チーム再編においては、相反する2つのアプローチと向き合うことになります。それは、人中心でチームを組織するのか、それとも、生み出す成果物（プロダクト）の目標を起点にチームを組織するかという問題です。人中心で組織を構成する場合、まずチームリーダーを決めることから始めて、そのリーダーを中心にチームを組織します。一方、プロダクトの目標を起点にする場合、その目標の達成をリードするのにふさわしい人物をリーダーに据えて、チームを構成していきます。私が個人的に志向するのは、プロダクトの目標に合わせて、チームのリーダーとメンバーを決めていくアプローチです。このアプローチのほうが人員構成の微調整が行いやすいからです。人中心でチームを組織してしまうと、チームの能力とビジネス目標との間にズレが生じても、人員の調整を図るのが難しくなります」

アトラシアンのディジーが志向するチーム構築のアプローチも、シュシュマン氏のそれと近く、「戦略」を起点にチームの「構造」を確定し、最後に人を決めるというものだ。

「私がまず考えることは、チームに何を達成させるかの戦略です。その戦略を定めたうえで、その戦略をどのように遂行するかを決めて、チームの構造を確定します。そして、その組織構造の中で有効に機能しうる人材を探し、メンバーとして起用するわけです」（ディジー）。

このアプローチは非常にシンプルで合理的と言える。ただし、考慮すべき事柄も多くあると、ディジーは明かす。

「例えば、戦略起点でチームのリーダーを探す場合、リーダーとしての適任者が社内にいない場合があります。この場合、リーダーとして経験の浅い社内の誰かにリーダー役を担ってもらうか、社外に人材を求めて雇用するかのどちらかの方法を選択しなければなりません。その前者のアプローチを選んだ場合、リーダー役を担わせる人間の能力をいかにして押し広げるかという課題に直面します。しかも、選んだ人材がリーダーとしての能力を身に付けられるかどうかは未知数です。それに対して、社外の人材の雇用には、現有の人材から成長の機会を奪ってしまうリスクがあります。戦略起点でのチーム作りには、そうしたトレードオフの問題と向き合いながら、構造を最適化していく難しさがあります。」