エンジニア組織が昨期から新体制になりました。今回は、エンジニア組織のトップが全社会議で新体制について説明した内容をまとめた記事となります。 エニグモはCtoCグローバルECのBUYMAというサービスを運営していますが、どういう体制で開発しているのかというお話です。
ぜひご覧ください！
目次
- Committeeとは？
- 新組織体制、新チーム、新ロールの概要
- 「Squad」「Domain」「Chapter」体制について
- 開発組織を支える5つのチーム
- あるプロジェクトの編成例
- 新体制の狙い
- この体制のメリット/Squad、Chapterの導入が納期短縮になる理由
- まとめ
Committeeとは？
まず、私がHeadを務めるCommitteeとは何かについてお話しします。 Committeeはエンジニア組織の意思決定を行うトップ機関です。CTOや部長を頂点とするワントップ型ではなく、複数名のエンジニアリングマネージャーで構成する合議体です。トップは輪番制となっており、現在私が担っています。 エンジニアの意思決定機関は、Committeeの他、優先順位が高い組織課題は分科会を設置して議論・意思決定のスピードを上げています。分科会にはマネージャーの他、分野ごとの適任のエンジニアメンバーが参加しています。
分科会は現在、アーキテクチャ分科会、KPI分科会、採用分科会などがあります。
Committee体制についての詳細は下記記事でも説明していますのでご覧ください。
新組織体制、新チーム、新ロールの概要
こちらの図を用いて、まずはエンジニア組織の全体像を話します。
実態としてはチームトポロジーの概念（ Spotifyモデル）を参考に組織設計しました。
Spotifyのスケーリングアジャイル – 部隊、分隊、支部やギルドと共に歩む（Spotifyモデル） | 『リーン開発の現場』越境せよ！
図の左側は主にプロダクトの機能開発を担うチームであり、Domainと呼ばれるチームが3つあります。それをさらに細分化・構造化する形で、縦割りチームのSquadや、横ぐしチームのChapterがあります。 右側の図はDomain/Squadを支援する位置づけのチームであり、5つのグループ・チームがあります。
「Squad」「Domain」「Chapter」体制について
前段で登場した「Squad」「Domain」「Chapter」がどのようなチーム単位で、実際にエニグモではどのように運営されているかをお話しします。
Squad（スクワッド）とは
図の中でも一番多くあるチーム単位のSquadは、事業的なミッションが与えられ、そのミッション達成に向けたシステムについてオーナーシップを持ちます。システムの全開発ライフサイクル（設計、開発、テスト、本番化、運用、不具合対応など）を担当します。
1つのSquadで開発者は2-5人程度のチームです。さまざまな技術領域・職能のメンバーが集まっています。 各Squadにはリードするメンバー1名がおり「Squad Lead」と呼びます。開発プロジェクトで設計・タスクへの落とし込み、タスクのアサイン、プロジェクトマネジメントを担います。
事業的なミッションの例としては、「魅力的な商品を増やす」や「競争力のある出品者さんにご活用いただける配送サービスを拡充する」「ユニークユーザー数・セッション数の改善を行う」などがあります。 エンジニアであってもビジネス的視点を持って開発を行い、メンバーに裁量や自律性を持たせた組織になっています。
他のSquad以外のチームの基本的なミッションはSquadチームを支援することと定義されています。
Domain（ドメイン）とは
Domainとはミッションが類似・関連している複数のSquadの集まりです。Domainのマネージャーを「Domain Head」と呼び、配下のメンバーのピープルマネジメント、リソース配分、Domain間の連携を担当します。 Domainは、ディレクター、データアナリスト、デザイナーなどエンジニア以外のメンバーも所属し、職能横断型組織となりプロジェクトを進めます。Domainはいわゆる事業部のような単位となっています。 BUYMAは現在、3つのDomainがあり、それぞれBUY Domain、SELL Domain、SI（SERVICE INFRA）Domainと呼びます。
3つのDomainがどういった開発をしているのかを説明します。
BUY Domain
BUYMAの購入者向け機能を開発するチームです。主なカバー範囲としては、会員登録、商品詳細、購入リスト、レコメンド、クーポン、広告、特集ページ、カート、商品レビュー等を開発します。
SELL Domain
BUYMAの出品者向けの機能を開発するチームです。主なカバー範囲としては、出品ページ、出品リスト、受注リスト、商品画像、お問い合わせ、タイムセール、ショップ連携等を開発します。
SI（SERVICE INFRA）Domain
BUYMAサービスの基盤となる決済連携、物流（配送・倉庫連携）、入金関連、セキュリティ関連等の機能を開発します。
※大型キャンペーン対応、商品画像施策など複数Domain横断のプロジェクトもあります。
Chapter（チャプター）とは
Squadの中でも特定の専門分野を担当するメンバーを横ぐしに束ねた組織です。Squadに所属しながらSquad外でも、テクニカルな改善・基盤整備を独自に実施します。 具体的な特定の専門分野は現在、フロントエンド、モバイルアプリ、QAがあります。
Frontend Chapter
フロントエンド独自の戦略にもとづき横ぐしで施策を実行し、プロダクトの品質向上やパフォーマンス改善、計画的なバージョンアップやリファクタリング、エンジニア組織全体の活性化や技術力の向上に取り組みます。
モバイルアプリ Chapter
iOS・Androidアプリの開発を担当するChapterです。
モバイルアプリのiOSやアンドロイドはそれぞれのチームとして独立していましたが、事業的なミッション達成の為には、どのDomainにおいてもiOSやアンドロイドの協力は絶対必要不可欠です。とくにiOSは流入UUの約半分以上を締めておりユーザーとの重要なコミュニケーション接点です。企画段階から開発に参加することが健全のため、横ぐしのChapter組織としました。
QA Chapter
サービス品質の維持・改善をミッションに持ち、各プロジェクトの上流工程から関わり、QAを担当します。
プロジェクト以外でも自動テストの導入、本番で検出された不具合分析など横ぐしでプロダクト全体の品質向上を目指した取り組みを行っています。
開発組織を支える5つのチーム
続いて右側の図の開発組織Domain/Squadを支援する5つのチーム（Application Platform、Data Technology、Infra、DX、DevRel）について説明します。
これらのチームはソフトウェア基盤の構築・改善、開発環境の整備、組織開発などエンジニア組織を下支えしています。 ミッションは「Squadの生産性向上」とすることでSE本部組織全体としてのベクトルを揃えています。
各チームがそれぞれどのような役割を担っているかを説明します。
Application Platform
Application Platformは新組織体制に移行した際に、新設したチームです。Squadが単独では担いきれなかったり、各Squadで横断的に共通するようなテクニカルな課題を解決し、Squadの生産性を向上させることがミッションです。
具体的な取り組み例として、言語・ライブラリ・フレームワークのバージョンアップ、AWS化に向けたアプリケーション修正、疎結合化・モジュラー化・マイクロサービス化などのアーキテクチャのモダナイズ、サービスの信頼性強化（SRE活動）などがあります。
Data Technology
Domain/Squadでは担いきれないデータ関連の専門知識（データ基盤・機械学習・検索）が必要とされるシステムを設計・開発から運用までを担当します。初期の設計や開発フェーズではSquadと密接にコラボレーションします。
データサイエンティスト、検索・MLOpsエンジニア、データエンジニアなどデータに関わるスペシャリストが所属します。
Infra
Domain/Squadでは担いきれないインフラ・セキュリティ関連の専門知識が必要とされるシステムを設計・構築から運用・監視までを担当しています。
現在の取り組み例として、BUYMAの環境をオンプレミスからAWSへの移行、Kubernetesクラスタの構築・運用および開発支援、サービスのセキュリティの強化などを行っています。
※次に紹介するDXチームとDevRelチームの2つのチームは、SE本部の組織の中でも人を集め、エンゲージメントを向上させる重要な役割を持ちます。専任メンバーでのチーム組成ではなく、他チームのメンバーが兼務するパートタイム組織となることも特徴です。
DX
DXはDeveloper Experienceの略で、日本語では開発者体験という意味です。
開発者体験の維持向上を行うことがミッションとなります。主に、BUYMAのローカル開発環境やCI/CD ツールの整備をしています。
DevRel
DevRelはDeveloper Relations の略で、社内エンジニアの技術力向上・知識共有や交流促進の為、社内向けに勉強会、開発合宿などを企画します。また、テックブログや対外イベント・カンファレンス協賛などの企画により、対外的に社内の技術力の広報活動を実施するチームです。
あるプロジェクトの編成例
今までは、開発組織がどういうチームで構成されているかをお話ししましたが、実際にプロジェクトベースでどのような流れ、関わり方になるかをお話しします。
プロダクトマネジャー（PdM）が企画をまとめプロジェクトがスタートし、PdMとSquad Leadやビジネスサイドのメンバーでどのようにシステムに落とし込むのかを要件定義します。その後、Squad Leadが設計を担い、タスク分解して、エンジニアメンバーにアサインします。
他にも、Data Technology、Application Platform、Infra などのこれらのチームはSquadの開発プロジェクトがいかに早く終わるかを支援していく立ち位置となります。
例えばプロジェクトで検索APIが必要だとなれば、データテクノロジーグループの検索チームが開発したり、インフラ構築が必要であればインフラがサポートする。そういうプロジェクト編成になります。
新体制の狙い
先ほどからも狙いを織り交ぜながら話していますが、新体制の一番の狙いとしては「案件（プロジェクト）の納期短縮によるユーザへの価値創造・事業への利益創出」です。
納期短縮により、案件のリリース回数が増えれば、その分PDCAがまわって、ABテストなど試行錯誤が進みUXが改善され、ユーザーへの価値創造になります。 案件1つ1つリターンを得るものだとすると、一定の工数でリリースされる案件を増やせば増やすほど、組織のROIが改善されるので、利益創出になると思っております。
この体制のメリット/Squad、Chapterの導入が納期短縮になる理由
新体制が具体的にどのように納期短縮なるか、その他新体制のメリットについて5つ紹介します。
①Squadはいわば、ミッション特化型職能横断チームで、ミッションが共通しているので職能間のベクトルが揃い開発スピードが上がります。
②職能間のタスクの受け渡しやすり合わせMTGを個別で実施する必要がなくなります。 以前だと、例えばフロントエンドとバックエンドで作業をお願いするミーティングがありましたが、全部1つのチームとなるので、最初の企画ミーティング以降はチャットベースで仕事が進み、ミーティングが減るのではないかと考えています。
③異なる職能間でお互いの進捗が見えやすくなり、メンバーが進んで仕事を取りにいけ、アサイン待ちや依頼待ちが発生しづらくなります。
④職能間でお互いの理解が進み、技術としては1人1人専門分野があるが、知識はフルスタック化していきます。例えば、フロントエンド側もバックエンド側の負荷を自然に気遣えるようになると考えています。
⑤Chapterはそれぞれの専門で実績のある新しいツール、ライブラリ、フレームワーク、プラクティスを常にChapterでフォローし、基盤やツールを整備しておけば、すぐにSquadへ展開可能になります。
まとめ
今回お話ししたエンジニア組織体制は目標とする体制で現在進行形の箇所も含まれますが、新体制のキックオフから約1年が経ち、目標の体制にかなり近づき、且つ全社に浸透し機能してきました。 ただ、チームとして組織として成果を出し・生産性を高めていくためには、まだまだ改善の余地があり、道半ばです。さらに、この体制は完成形ではなく事業や組織の状況によってアップデートしていければと思っています。また、Committee（組織運営や意思決定）に関わる人も今後、さらに増やしていきたいです。
よりよい価値のあるプロダクトをユーザーに届けられるよう、そしてエニグモがさらなる成長を遂げられるよう、これからも精進していく次第です。
