～「Committee・新開発体制」導入後の成果と魅力～
目次
エニグモのエンジニア組織の新しいマネジメント体制と、新開発体制についてCOOの安藤、エンジニアリングマネージャー（EM）の木村・山本にインタビューした記事の続編です。
前編は、Committee体制（エンジニア組織をCTOや部長を頂点とするワントップ型ではなく、EM陣で構成する「Committee」という合議体を意思決定のトップ機関）ができた経緯や、どのような体制でエンジニア組織を運営しているかを中心にお話ししました。
後編は、エンジニア組織全体がどのような体制になり、エニグモのプロダクトを開発しているのか、実際に新しい体制になりどのような効果があったのか、当社エンジニア組織の魅力やキャリアなどについてお話しします。
前回の記事はこちらです。
tech.enigmo.co.jp
新開発体制について
大谷：
Committee体制の取り組みの第一弾として、エンジニア組織・開発体制をDomain、Squad、Chapter体制（以下、新開発体制）に移行したかと思います。後編ではまずは、新開発体制の概要についてお聞きできればと思います。
木村：
エンジニアの新開発体制は、実態としてはチームトポロジーの概念( Spotifyモデル)を参考に組織設計しました。
プロダクトの開発を担う機能別のDomain(ドメイン)と呼ばれるチームがあり、それをさらに細分化・構造化する形で、縦割りチームのSquad(スクワッド)や、横串チームのChapter(チャプター)があります。
Squadは事業的なミッションが与えられ、そのミッション達成に向けたシステムについてオーナーシップを持ちます。システムの全開発ライフサイクル（設計、開発、テスト、本番化、運用、不具合対応など）を担当します。
Chapterは、Squadの中でも特定の専門分野を担当するメンバーを横串に束ねた組織です。Squadに所属しながらSquad外でも、テクニカルな改善・基盤整備を独自に実施します。
※新開発体制の詳細は下記記事でまとめていますのでご覧いただければと思います。
tech.enigmo.co.jp
新開発体制導入の背景／なぜこのような体制にしたのか
大谷：
Committee体制の中で、なぜこのような新体制を構想したのかについて背景をお聞かせください。
木村：
トップの役割をCommittee体制に引き継ぐ際に、開発組織はトップに依存せず、各チームに裁量を持たせ、自律的に成長・進化し続けることで、ビジネス課題を迅速に解決できる組織としたいという考えがありました。
各組織・チームに裁量を持たせるためには、各組織・チームが担うべきロール(役割)を改めて明確に定義し直す必要があると考えました。
その中で最適な組織の形は何かを考えた結果、この新開発体制が上手くフィットしました。
安藤：
以前からエニグモでは、ビジネスメンバー、ディレクター、エンジニアが、Oneチームで同じ事業課題解決に向かってプロダクト開発する「ユニット」体制がありました。昔からどういった体制がベストであるかを模索していた中で、この1、2年でDomainやSquadとして再定義し、メンバーをアサインして、継続的にプロダクトを磨いていこうという体制になったと記憶しています。
山本：
そうですね。SquadはもともとSpotifyのSquadモデルを参考にしたり、「ユニット」の考え方を応用して、一部のチームでは導入していました。Squadの領域を定義し、リーダーを決め、縦に割って効率化しつつもSquad間でも横で連携して取り組もうという体制がありました。
また、ミッションが類似・関連しているSquadを束ねたDomainという考え方も以前からありました。
Committee体制を導入するタイミングで、木村さんがトップの役割を棚卸した際に、以前からあったDomainやSquadをより言語化・明確化することで、上手くかみ合ったのかなと思います。
もともとはChapterの概念は省いていましたが、専門のロールをChapterとして整備し取り入れました。
安藤：
Committee体制で進めることで、組織的にどのような体制で進めるのが自然であるかを改めて考える良い機会となりました。
トップの仕事は属人的であるということに気づき、トップが変わったとしても、組織を存続させるためには、こういうCommittee体制というハコ(仕組み)でやるのが自然だよねとなり、新開発体制へと昇華されました。
新体制導入後に感じている進化や手ごたえ
大谷：
Committee体制、新開発体制の導入後に感じる手ごたえはどうでしょうか？
木村：
手ごたえとしては、各メンバーが裁量を持ち、且つ負担がかかりすぎない良い体制で、元々のコンセプト通りに運営できているように感じます。
私はCommittee Headですが、HeadというのはあくまでCommitteeの中の役割で私がタッチしていない部分も多いです。そんな中でも、トップ(Head)に依存しすぎず、各メンバーが決めた持ち場でしっかり役割を担っていただいていると感じます。
山本：
マネージャーやSquadリーダー同士での話し合う機会が増えてました。
例えば「開発で、今こういうことをやっていて、ちょっと相談したいんですけど」みたいな話は、Squad Weekly（Squadのリーダー以上が参加するミーティング）でしており、他のチームリーダーにも意見や相談ができます。
開発に関わること以外でも、「採用はどうしましょうか？」「組織をもっとこうしたい」「チームのマネジメントについて相談したい」といった話題はCommittee体制になりより話すようになりました。
大谷：
経営側からみて、安藤さんが感じる「ここらへんが変わり始めたな」というところはありますでしょうか。
安藤：
すでに明確に変わっていると感じるところはあり、今まで言語化されていなかった組織やチームの役割やミッションが「こういうチームを目指していきたい」としっかりと言語化され、クリアになりました。そのことで、経営やビジネス的な視点で意思決定する際も説得力が持てるようになりました。
例えば、本来は優秀なメンバーは機能開発にアサインしたいところです。直近立ち上がった（技術的な課題を解決する）チームも「Squadメンバーの生産性を最大化させるためにあるチーム」と定義することで、これからのエンジニア組織やサービス成長において重要な役割であることが明確になり、メンバーのアサインにおいて納得感あるコンセンサスになりました。
採用に関しても、新しい体制下でのスピーディーでチームが一体となった採用活動ができるようになったことも、大きな進化だと感じています。
大谷：
新開発体制に移行したことによる、プロジェクトの進め方やメンバー間コミュニケーションの変化について、さらに詳しくお聞きしたいです。
木村：
以前は、プロジェクトが始まるタイミングで手が空いているメンバーを優先的にアサインしていました。新開発体制のSquadではエンジニアとして担当する機能が固定化され、システムについてのオーナーシップを持つことができるようになりました。この変化により、技術領域とドメイン領域の両方に精通することができ、非常に効果的であると感じています。
以前は、「今日からあなたは、この機能を開発してください」となったときに、都度キャッチアップしながら探り探り進めることが多くありました。その結果、コードを壊してしまったり、元々の設計志向を理解せずに違う方向に修正してしまうことがありました。しかしこのような事態は新開発体制の導入によって解消されました。
山本：
Squadは毎回新しいメンバーと組むわけでなく、2〜3名の小さいチームで同じメンバーで開発・振り返りを行うことができるため、チームごとにノウハウが蓄積し、息の合った開発・プロジェクト進行が可能となります。さらに、蓄積されたノウハウは他のチームにも共有され、良いアイデアが取り入れられる好循環が生まれています。
安藤：
新開発体制となり、エンジニアと企画•ビジネスメンバーが同じOKRをディスカッションして決めて、良い形で一体となってプロダクト・サービスを作っているように感じます。これは2人にとってはどう映っていますか？
木村：
エニグモの企画・ビジネスメンバーはエンジニアへの理解が強く、理解しよう・寄り添おうとしてくれるメンバーが多いように感じます。
エンジニアが強すぎるというわけでも、ビジネス側が強すぎるわけでもなく、言われた物を言われたままに作るというわけでもなく、バランスのとれた形で開発が進められていると思います。
エンジニアも、長く働くメンバーが多いのは（10年以上在籍するメンバーもいる）のは、そういう環境にやりがいや面白みを感じているからかもしれません。
山本：
もともとはビジネス側から、こういう企画がやりたいという話があり、さらに間にディレクターが入り要件定義し、エンジニアに下りて来るという形で、比較的受託開発のような開発の流れがあり、ビジネス側との距離感が少し遠いと以前は感じていました。
新開発体制になった後は、ビジネス側のメンバーが同じチームに所属することで、エンジニアが直接コミュニケーションを取れるようになりました。 エンジニアも参加するMonthly定例で、ビジネス側で持っている課題感や数値の進捗共有があり、「こういう数値を見てたんだ」といった新しい発見もあります。ビジネス側との距離がより近くなったと感じます。
さらに、SquadでOKRを決めて開発を進めるため、ビジネス的な目標についてもエンジニアとしてコミットし、プロダクトへの意識が変わってきています。
OKRを設定するためにはエンジニアも含めて多くのディスカッションが必要なため、ビジネス側の視点を持って開発をしたい方にとっては面白い環境であると思います。
当社エンジニア組織の魅力・キャリア
大谷：
エニグモではエンジニアとして、どのような経験やスキルを身につけたり、キャリアを積むことができますか？
木村：
エンジニアは事業志向と技術志向の方がいると思っています。
事業志向の方は事業のミッションと向き合えるようなポジションに配置されるため、プロダクトの成長にどう貢献するかを考える機会があり、そういった方向でスキルを伸ばし、キャリアが積めると思います。
技術志向の方は、Squadで開発の一連のサイクルを経験できますし、またChapterやその他専門チームに所属することで、専門的なスキル・技術を深めることができます。 また、マネジメントを志向する方にも、DomainやChapterごとにマネージャーが配置されているため、そういったマネジメントのポジションを目指すこともできます。
山本：
実際のユーザーとの距離が近く、フィードバックをダイレクトに受け取ることができます。ユーザーのフィードバックを受けながらビジネス側のチームと協力して、エンジニアの視点でサービスやプロダクトに関する課題解決に取り組むことができます。
技術的な面では、大量のトラフィックを想定した開発など、大規模なアプリケーションの開発についての一通りの経験が得られるのが魅力です。
また、BUYMAはユーザーも機能もすごく多く、機能も複雑に絡み合っているため、コードの一部を変更すると他の機能に影響が及ぶ可能性があります。そのため、自然と質の高い開発をする意識が養われます。
安藤：
確かに、プロダクト志向やビジネスに興味がある人も、技術的に突き詰めたい人にも、マネジメント志向の人にも様々なキャリアの可能性がありますね。
まとめ
エニグモにマッチするエンジニアとは？
大谷：
最後に、さらなる組織進化にむけて今後どのような人材に加わっていただきたいか、こういう方はエニグモで活躍できる（マッチする）などお話ください。
山本：
事業や、組織的、システム的なところなど課題をどんどん見つけて、もっとこういう風にした方が良いという思い(改善思考)を持ち、周囲を巻き込んで行動し、挑戦できる人が一番かと思います。
木村：
どういう方が楽しめるのかなと考えると、世の中一般的にこうあるべきみたいなのがあって、そこに向かって今のその会社の形を無理やり変えていくみたいな人というよりは、会社それぞれで最適な形というのは当然あるため、会社や事業、組織、人のリアルな課題に向き合い最適解を探せる方ではないでしょうか。
安藤：
エニグモが求めている人物像は、基本的にはエニグモのバリューに沿った方が良いと思っています。
※バリューについての詳細はこちら
チームワークで解決できる人、物事をよりよく・より深く考えることのできる人。現状に満足せずに変えることができる人ですね。
変革の過程でギスギスすることやハードなこともあるため、そういった場面でも楽しみながら業務に取り組み、最終的には「夕日を見て肩を組めるような人、いろいろあったけど一緒にやれて良かった」と感じられる人が良いと思います。そんなに熱くなくてもいいですけどね笑。
大谷：
夕日を見て肩を組む、、、いいフレーズですね（笑）エニグモが求める人物は「変革期で逆境やカオスな状況を乗り越えた先に、夕日を見て肩を組める人」ということで今回のインタビューは締めといたします。ありがとうございました。
