3年以内に3倍!
世界的に進む「エンジニアリング組織の拡大」

2022.10.26更新

2014年、私はエンジニアリングマネージャーとしてPagerDutyという将来有望なスタートアップ企業に入社しました。2013年にシリーズAで融資を受けた当社は、超高成長モードに入り、あらゆる分野で積極的な採用を行いました。当時、エンジニアリングチームは30人足らずで、急成長する組織が直面する構造的な問題について学ぶことはとても魅力的でした（今もそうです）。Dutonians（PagerDutyで働く仲間）のエンジニアが数百名に達する今、これまでの変化を振り返ってみるにはちょうど良い時だと思います。

組織構造の進化は興味深いプロセスです。たくさんの失敗や行き詰まり、車輪の再発明、そして願わくは、教訓があります。エンジニアリング組織を扱う文献は山ほどありますが、ほとんどは、長所と短所を理論的に扱ったリストか、執筆時に企業が採用しているプロセスを賞賛するブログ記事のどちらかに要約されます。私はこれまでと違うアプローチで、当社のエンジニアリングチームが、構造を継続的に実験して進化させるに至った歴史的な理由を、失敗や学習も含めて、検証したいと思います。

注記：都合上、一部の出来事や詳細は簡略されていますが、多くはそれだけで記事として掲載する価値があるものです。新しいコンテンツを見逃さないよう、当ブログのブックマークをおすすめします。.

組織のサイロ化

2014年初頭のPagerDutyの様子：

エンジニアリング組織は、サンフランシスコ（SF）とトロントのオフィスに分割。
オペレーションチームは、インフラの自動化、セキュリティ、パーシステンスを担当（SFのみ）。
Webアプリケーションチームは、PagerDutyの顧客向けのインターフェース部分を担当し（SFのみ）、主にRuby on RailsとMySQLを使って開発。
バックエンドサービスグループは、信頼性の高いデータの取り込みと通知の配信を担当し（SFとトロントのチームに分割）、主にScalaとCassandraを使って開発。
DevOpsには部分的にしか対応していませんでした。オペレーションチームはインフラモニタリングアラートにオンコールで対応し、その他のチームはデプロイしたコードにオンコールで対応していたのです。

エンジニアリングチームは、非常に短期間で、ごく少数のスタッフから分散した複数のチームへ拡大したため、製品開発プロセスは未熟なままでした。スタンドアップやスプリントで表面的にはアジリティを装っていたものの、基本的にはウォーターフォールモデルでした。つまり、経営陣が取り組むべきプロジェクトを決定し、個々のエンジニアにそれらのプロジェクトを割り当て、目標納期を設定していました。当然ながら、納期に間に合うことはほとんどなく、プロジェクト追跡用のスプレッドシートはいつまでたっても修正が必要な状態で、最終的に使われなくなりました。

現場の状況も良くありませんでした。新しいプロジェクトを開始するにあたって、プロダクトマネージャーは長々とした機能設計の仕様書を作成しました。最善を尽くして起こり得るあらゆる質問を想定したのです。これは、開発中にプロダクトチームとエンジニアリングチームの交流が非常に少なかったことによるものでした。仕様書は、Webアプリケーションチームとバックエンドチームに提示されるのですが、その後、両チームは別々にユーザー向けとバックエンド向けの作業に取り掛かりました。新しいインフラの導入は、数週間前にオペレーションチームに依頼する必要がありました。

バラバラの作業すべてをまとめて一貫した機能のリリースに統合することは、悪夢でした。インフラは足りないか不完全で、厄介なバグ、機能ギャップ（どのチームも他のチームが対処していると思っている）があり、エンジニアメンバーとプロダクトメンバー共にオーナーシップやエンパワーメントに欠き、スケジュールの遅れ、組織的なサイロなどがありました。納期に間に合わせようとしてリスクを取ることが少なくなり、実装も保守的になり、製品仕様の調整にも嫌々対処していました。

この部門構造と開発プロセスが組み合わさったことで、サイロ化はエンジニアリング部門におけるあらゆる議論を押しのけ、その年の最大のテーマになりました。私たちはサイロ化していたのです。

ウェブアプリケーションとバックエンドサービスの対立。この二つのグループの間には、はっきりそれと分かる敵対意識がありました。どちらも、相手のグループが取り組んでいることを実際には理解しておらず、どちらも不満を抱いていました。
RubyとScalaの対立。上の点と似たような対立ですが、もっと細かい点における対立で、どの言語で構築するかという問題でした。
オペレーションチームと開発チームの対立。どちらの側も、オペレーションチームがあらゆるサーバープロビジョニングの障害になっていることに不満を抱いていました。またオペレーションチームは、迫りくる期限という大きなプレッシャーを受けていました。
サンフランシスコとトロントの対立。すべてのチームが地理的に二つの場所に分かれていたため、二拠点のエンジニアたちの間には「彼ら対われわれ」という独特の雰囲気が生まれました。どちらの側も、何かと不満を漏らしていました。

一連の職務は厳密に決められていたため、どのチームにも機能横断的なコラボレーションを行う余裕がなかったのです。私たちは「ワーキンググループ」というコンセプトで簡単な実験を行いました。つまり、既存のチームから選ばれた人で構成される、少人数かつ多様性のある一時的なチームです。その目的は、特定の範囲における期限付きの分野横断的なプロジェクトに取り組むことでしたが、結局この実験は、当初のチームを不安定に陥れてさらなる混乱を招いたため、中断されました。

それでも、協力することが必要でしたし、一貫性と予測可能性を向上させることは何より重要でした。みんなサイロ化にうんざりしていたので、取り除かなければならなかったのです。そこで、私たちは自分たちに仕事が合うようにしました。

マトリクス組織

2015年の始めには、状況への不満とアジャイル方式への関心の高まりが臨界点に達し、部門再編をもたらしました。特定の製品の方向性に沿って、いくつかの新しいチームが作られました。スクラムプロセスに従って、プロダクトオーナー、スクラムマスター、UXデザイナーだけでなく、ウェブアプリケーションチームとバックエンドチームの両チームのエンジニアから構成されました。

前年の製品開発の進捗が遅かったことを考慮して、新しいチームではプロダクトデリバリーが最優先されました。彼らの時間をすべて新機能の開発に充てられるように、メンテナンス作業はバックエンドサービスチームに任されました。このチームは、かんばん方式を導入しており、「ベースチーム」と呼ばれました。全製品のオンコールを担当するほか、提供中のあらゆるサービスのオーナーシップを持つようになりました。さらに、ベースチームのメンバーをプロダクトチームに送りました。プロダクトチームの作業がスピードアップするのに伴い、エンジニアが次々に入れ替わりました。

これは明らかに大きな変化でした。チームの入れ替えによって個々のエンジニアが受ける影響を最小限にとどめるため（そしてリモートレポートへの対応を先送りにするため）、レポートラインには手をつけませんでした。そのためデュアルレポーティング構造（つまり、マトリクス組織）になり、当然、それによって日々の業務はひどく複雑になりました。エンジニアの多くは、直属の上司の管轄下にはないチームに所属することになり、マネージャーは「ピープルマネージャー」（他チームのメンバーも含め、人事を担当）と「ファンクショナルマネージャー」（別チームに上司がいるエンジニアも含め、チーム運営を担当する）の役割を果たすようになりました。

幸いなことに、古いサイロはほとんどなくなり、二度と表出することはありませんでした。ウェブアプリケーションエンジニアとバックエンドサービスエンジニアが近い距離で仕事をすることで、お互いの違いを乗り越えて理解し、共通の目標に向かって進むことができました。今でもほとんどのチームが地理的には分散していますが、二つのオフィスを一緒にしたことが功を奏しました。

一方で、新たな問題が次々と発生

技術メンテナンスに関するチームをまとめることは、とても大変でした。ベースチームは長期的なロードマップの作成や、あらゆる提供中のサービスの運用面でのオーナーシップと折り合いをつけるのに苦労していていました。
適宜メンバーを送り込むモデルは、チームの団結力にとても大きな影響を与えました。チームの編成を何度も変更すると、士気が低下することが分かったのです。
デュアルレポーティング構造は、あらゆる非効率性を生みました。直属の部下の日々の業務が分かりづらくなりました。ピープルマネージャーとファンクショナルマネージャーの間にコミュニケーションのオーバーヘッドが増え、責任の所在に関する全体的な混乱が発生しました。
私たちが採用したのは、アジリティではなく、アジャイルプロセスでした。スクラムは、確かにオーバースペック、統合、プロダクトオーナーの関与には役立ちました。しかし、ソフトウェアデリバリーに対するアプローチは変わりませんでした。つまり、機能リリースは大きな仕事でしたが、依然としてその価値には疑問があったのです。
チームが増えれば、オペレーション担当者の負担も増えます。インフラの要求が頻繁にあり、個々の新しいサービスへのオンコール対応が増えるため、この方法に拡張性がないことは明らかでした。

総合的に判断すれば、一年前に比べだいぶ良い状態でした。しかし、まだ先は長かったのです。

アジャイル組織

新しい組織体制を受け入れてから一年後、かなり多くの学びが蓄積されました。アジャイルは良かった（しかし十分ではない）、DevOpsも良かった（しかしこれも十分ではない）、マトリックス管理はあまり良くなかった（もう十分）ということです。

2016年の始めに再び改革を行いました。今度は「垂直的な」スクラムチームが、製品の一部を担当しました。「水平的な」チームは、製品やインフラに関する問題を分野横断的に担当し、ベストプラクティスの設定や、その他のチームが迅速に行動できるための任務を与えられました。プロダクトデリバリーチームは、ロードマップ、要件定義、実装、展開、さらに提供中の製品コードとインフラのメンテナンスも（！）担当しました。私たちは「コードを書いた者が、責任を持つ」（“you code it, you own it”）という真のDevOpsアプローチを採用しました。

以前の問題をどのように解決したのか？

メンテナンスチームはなくなりました。各チームが製品やインフラの一部に責任を持つことで、迅速に行動し、イノベーションを起こす権限を与えられたのです。
チームにメンバーを送り込むこともありません。特定のチームから必要な人員の募集がかけられました。
デュアルレポーティングもなくなりました！組織としてリモート勤務のエンジニアを雇用し管理することに、かなり慣れたのです。物理的な距離はもはや障害ではなく、社内の間接的な上下関係を気にせず、チームにマネージャーを配置することができました。
私たちは、仕事をやり遂げることに集中しています。GSD（Get Sh*t Done/すぐ片付ける）という信念が集団意識のなかに浸透しているため、チームが内省して、実用的で生産的なアジャイルデリバリー組織に成長するために、オーバースペックやオーバーエンジニアリングというレガシーを取り除くよう意欲的に取り組んでいます。
セルフサービスが成長をもたらしたのです。オペレーションチームは多くの作業を行い、ありとあらゆるインフラのニーズに各自で対応できる高度なChatOpsツールを提供するなど、プロダクトデリバリーチームを強化しました。これは、DevOpsを全面的に採用して、インフラのアラートをオペレーションから実際のホスト（とにかく、より早く問題を解決できる人）がいる関連チームに移行するうえで重要でした。

GSDのテーマは、もう少し掘り下げる価値があります。私たちは実践を通して、チームの自主性、つまり発明よりもイノベーション、ビジネスは解決策の実装よりも解決すべき問題の特定、という考えにますます慣れていったのです。自分たちはお客様にとって何がベストなのかを知っている、という考え方を捨てることは簡単ではありません。MVP（MinimumViable Product/実用最小限の製品）を提供することにしっかり集中し、即座にフィードバックを獲得して、それを開発サイクル中に組み込むことが鍵でした。これにより、迅速な繰り返し、価値の最大化、予定外の機能追加を最小化でき、試作品をお客様にお届けする期間を数か月から数週間や数日に短縮できるようになりました。

プロダクトデリバリーチームの数が増えるにつれて、興味深い現象が発生しました。いわゆる「部隊」が生まれたのです（Spotifyのチームモデルのひとつです）。つまり、共通の機能やミッションによって互いに関連するチームのグループです。このモデルの導入は、オーナーシップ、知識やロードマップの共有（個々のチームのバックログとは別）、そしてビジョンの共有といったメリットをもたらしました。部隊組織については、いまだ検証中です。今後、部隊についての学びをアップデートしていきますので、ご期待ください。

この体制で数年の間運営していますが、うまくいっています。会社が速いペースで成長を続ければ、チームや関連するオーナーシップラインは確実に進化するでしょう。また、自身を向上させるための投資を続ければ、詳細も変わるでしょう。それに、多くの間違いがあったからこそ、何が正しいのかを学んだのです。

教訓

初期に下したいくつかの決断や、中間期に組織が耐えてきた厄介なことを振り返ると、なぜ明らかに優れている最終状態にジャンプしようと思い付かなかったのか、自分の頭をたたきたくなります。もちろん現実はそう単純ではありません。決定はその時の状況、プライオリティ、人員、課題に応じてなされたのです。みなさんも、自社の課題をすでに認識しているかもしれません。その場合は、私たちの経験から何かを得てほしいと思います。

最初からやり直すとしたら、覚えておきたいこと

チーム間の依存を最小限にすること。依存は、ブロッキング、バグ、誤解、負の感情をもたらします。他のチームを待たずに実行する権限をチームに与えれば、生産性は大きく改善するでしょう。

Mチーム編成の変更を最小限にすること。現実のビジネスにおいては、人材をある場所から別の場所に異動させる必要がある時があります。チームの士気や生産性に深刻な影響を与える可能性があるため、人を異動させる前には長い時間をかけてよく考えてください。
チームのオーナーシップと責任を過度に規定しないこと。柔軟性は長期的な成功をもたらします。チームが自分たちの問題を解決するよう励ますことで、前述した二つの点に関する問題は少なくなります。
継続学習と実験を恐れないこと。これは、コード、プロセス、組織、すべてに当てはまります。同じことを繰り返していても、良い方には向かいません。
アジャイルプロセスは素晴らしいが、アジャイルカルチャーはより優れている。スタンドアップやスプリントレビューは、それだけで大きな価値をもたらすものではありません。MVP（実用最小限の製品）、迅速なフィードバックループ、コラボレーションへ焦点を当てるには、カルチャー変化を必要としますが、提供される顧客価値を最大化します。
コードの運用オーナーシップはチームに持たせる必要がある。これはシステムの信頼性、コード品質、組織的なスケーラビリティのバランスを取るうえでの最善策です。
機能横断的で、フルスタックのチームは、プロダクトデリバリーに最適。これは、上述した依存を最小化するポイントとほぼ一致します。各チームは、外部の専門家やプロジェクトの引継ぎを必要とせずに、要件の収集から展開までを行えるようにする必要があります。専門家チームにも役割がありますが、どちらかと言えば、先に述べた「水平的な」チームの領域です。
どんな環境でも仕事ができるゼネラリストを雇用すること。テクノロジーや技術的な方向性が変化するなかで、チームメンバーは、特定のツール、フレームワーク、スタックに固執すべきではありません。高成長環境で成功するのに最適な人材は、仕事に適したツールを集中して学び、それを活用します。ですので、学習と成長の機会を提供できるようにしましょう。
できれば、マトリクスマネジメントを避けること。デュアルレポーティングで解決できると思われる問題についても、別の対処方法があるかどうか検討します。
分散型チームを採用すること。リモート勤務のメンバーで結束力のあるチームを構築するには課題もありますが、多くのメリットがあります。「リモートチームにすることで、チームに参加する人の幅を広げることができます。リモートチームが同じ一つの場所で作業する（コロケーション）方が生産性は多少上がるかもしれません。それでもリモートチームは、あなたが組織できる最高のコロケーションチームよりも生産性が高い場合もあります」とMartin Fowler氏は指摘しています。つまり、リモートのメンバーを採用することで、より多くの人材プールを確保することができるため、全体としてより強力なチームを作ることができます。

組織は成長し成熟するにつれ、成長の減速、硬直化、保守的になるなどの傾向があります。私たちは、継続的な改善を実践して業務を進化させることで、時の流れに逆らい、よりアジャイルに、実用的かつ生産的に成長することに成功しました。あなたにもできるはずです。

では、次の3年間とその後の何年もの学びに乾杯！

公式資料
「デジタルオペレーションの現状」独自調査レポート

エンジニアの燃え尽きを防ぐ秘訣とは？
一段と信頼性の高いシステムを顧客が求めるようになり、勤務時間外や夜間の対応など、技術チームへの要求も増しています。本レポートでは、19,000 社以上、100 万人を超えるユーザーで構成されるPagerDutyプラットフォームから収集したデータを基にしたシステム運用の”今”を解説！→ PagerDutyの資料をみる（無料）

無料ダウンロード >