“会社の認知度ゼロ”状態から開発組織の立ち上げが始まった　会社の特徴を活かしたグループ企業横断の組織づくり

GENDA社・VPoEの荒井勇輔氏が組織・体制づくり、採用戦略の事例を紹介

荒井勇輔氏（以下、荒井）：それでは、「グループ会社を横断したエンジニア組織の立ち上げと挑戦」というタイトルで、GENDAの荒井が発表します。よろしくお願いいたします。

本日の構成です。本日は組織・体制づくり、採用戦略の事例を紹介しようと思っています。はじめにGENDAについて説明させていただき、その後に開発組織立ち上げの背景を紹介いたします。背景を説明後に、立ち上げにおける課題を紹介して、その後、具体的な取り組みの紹介に移りたいと思います。

あらためまして自己紹介ですが、GENDAでVPoEをしている荒井と申します。簡単にキャリアを紹介すると、私は2006年にヤフーにエンジニアとして入社して、バックエンドやフロントエンド開発をやっていました。

2011年にスタートアップに行って、そこではメインでiOSアプリ開発をしていました。この組織が大きくなるにつれてマネージャーのような存在が必要になって、そこでフロントエンド事業部長としてマネジメントといったキャリアになります。その後スタートアップはZOZOによるM&Aがあり、2018年からはZOZOテクノロジーズに所属してテックリードをしていました。

2021年に社会情勢の変化もあり、エンターテイメントの必要性を感じて、その時に縁があったGENDAに転職をして、現在VPoEとして開発組織の立ち上げをしています。よろしくお願いします。

GENDA社の事業を紹介

それでは内容に移っていきますが、はじめに、GENDAについて簡単に紹介いたします。GENDAは2018年にできた会社で、もうすぐ5年になります。従業員はグループ連結で4,000名を超えており、（スライドの）右側に写真がありますが、オフィスは汐留にあります。

GENDAの特徴としては、複数のエンターテイメント事業会社を傘下に収める純粋持株会社で、グループ各社の経営支援に従事しています。特徴的なのは、我々エンジニアも純粋持株会社に所属しているところです。既存事業の成長に加えて、「M&Aによる連続的な非連続な成長」を戦略の柱としています。

ここからが事業やプロダクトの説明になります。まず主力の事業としては、GENDA GiGO Entertainmentで「GiGO」というブランドでアミューズメント施設の運営をしています。全国に約250店舗ほどあるので、見かけたらぜひ遊んできてください。

2つ目はプロダクトの紹介なんですけれども、主にエンジニアが関わっているプロダクトの一つ目として、先ほど紹介したGiGO会員向けアプリを作成しています。プライズゲームのサービス券やサブスクリプション、会員グレードによる限定グッズのプレゼントなど、ゲームセンターにより足を運んでもらえるきっかけとか、より楽しんでいただくみたいなことを考えて開発をしています。

あと、会員向けではなくてスタッフ向けに作っているものもありまして、運営しているゲームセンターではまだまだアナログな運用も残っている状況があり、それをデジタルに置き換えて業務効率を上げていくDXの取り組みも行っています。また、データ基盤の整備・分析にも注力しています。

最後にオンラインクレーンゲームというプロダクトがあり、オフラインでしか遊べなかったプライズゲームをアプリで遊べるサービスを展開しています。

このようなプロダクトを1年ちょっと前の2021年当時、どんな風に開発していたかと、現CPOがCTOとして1人で業務委託中心の開発をリードしていました。2021年10月に現CTOと、私と、データエンジニアが加わるまでは、社員のエンジニアはゼロという状況でした。

こういう状況から、今までの1年ちょっとでこう変えていったというお話になります。

エンジニア組織立ち上げの背景と3つの課題

次に、エンジニア組織の立ち上げの背景について紹介します。すでにGiGOという名前を出しましたが、2020年12月に、社員4,000人規模で全国展開しているセガエンタテインメントがグループに参画したことにより、対応する事業領域・プロダクト開発に大きな変化がありました。

そこで、テクノロジーによる企業成長が必須となり、2021年10月にプロダクト開発組織を立ち上げたというのが背景にあります。

次に、当時の課題の説明です。いくつも課題があったのですが、今回は3つに絞って話そうかなと思っています。

1つ目が、組織を立ち上げるとなった時に、とにかく人がいない状況でした。その状況で複数のプロダクト開発に取り掛かる必要性があり、エンジニアの増やし方にも課題がありました。

グループ各社で採用をしていくと、柔軟なアサインができないとか、そもそも技術スタックがバラバラで、横のつながりもそんなにない状況の中で、なんとかすり合わせたりしていかなくちゃいけないという課題がありました。

2つ目としては、組織を立ち上げるという課題があったのですが、すでにある程度の規模のプロダクトが複数存在してユーザーがいたので、開発・運用を続けながら組織を作っていかなくてはいけないという状況でした。

最後は、認知度の低さがありました。1つ目、2つ目の課題を解決するために、短期間で採用しなくてはいけないのですが、（会社の）認知度が低いということもあり、採用に苦戦していました。

純粋持株会社のGENDA社にエンジニアが所属する体制にした

ここから3つの課題に対する取り組みを紹介していきます。1つ目は組織の構造です。私が経験したのは、画面にあるような大きく2つのパターンの組織です。

1つは、事業会社に開発チームがあってエンジニアが所属しているケース。わかりやすいのだと、会社名＝サービス名みたいなケースですね。

2つ目が、開発を担うグループ会社が存在していて、エンジニアがそこに集合しているケースです。この2つがよくあるパターンかなと思います。

GENDAがどういう挑戦をしてきたかというと、課題の1つ目の人員不足の状態でグループ会社の開発を担っていくことに対するアプローチとして、純粋持株会社であるGENDAにエンジニアが所属して開発支援をしていくという、図のような体制にしました。

各社に所属しないことで横断した開発が可能で、アサインなども柔軟に行うことを目指して組織を作っています。横断的に見られるのでツールの統一なども推進しやすいという特徴があります。

組織のモデルの図ですが、フロントエンド、バックエンド、モバイル、インフラエンジニアは、単一・複数のプロダクトを担当して開発を進めていって、SRE、データは、特定のプロダクトに所属せずに、それぞれのプロダクトを支援していく体制にしています。

ただ、「プロダクト開発部に所属」と書いているのですが、あくまでもGENDAとして定例の場や情報交換の場を設けて、担当以外のプロダクトの情報も入ってくるようにしていますし、知見の共有も行っています。また、案件の状況に応じて担当は流動的にしていて、それを効率的に行うために、開発方針やフレームワークを整えていくことを現在進めているところです。

正社員採用と並行して業務委託採用も実施

先ほど説明したのは、正社員がいる状況だからできる、現在できているアプローチです。最初の、正社員がゼロでプロダクトが複数存在しているという状況に対してどうしてきたかというと、最初は先ほど言った組織のモデルを作っていきつつも、短期的なプロダクト開発をなんとかするために正社員採用だけをやっていると入社までのリードタイムが非常に長いので、並行して業務委託採用を実施していました。

Phase 1では業務委託だけですが、Phase 2では業務委託も増やしつつ正社員も増やす。Phase 3では正社員のほうがどんどん増えていくみたいなかたちで、段階的に組織を作っていっています。

また、なるべく開発をスムーズに行う施策もしています。業務委託が多い状況だと、どうしても短期的な開発思考になりやすいという特徴があり、しかも正社員よりも流動的なので、そういう状況でも機能できる状況にする必要性がありました。

「属人化しない状況」を特に強く意識して改善を進めた

（スライドを示して）ここに挙げている4つに取り組んできた中で、特に「属人化しない状況」を強く意識して改善を進めていきました。

具体的には、さまざまな分野で活躍できる人を増やす取り組みをしています。私たちは、iOSやAndroidを「Chapter」という区切りで呼んでいるのですが、iOS1人、Android1人、フロントエンド1人、バックエンド1人、みたいな状況ではなく、複数のChapterで活躍できる人を優先的に採用していました。

フロントエンド、バックエンド、モバイル、みたいなかたちでAndroidをやっていた業務委託のAさんが去ってしまうと、Androidの開発が止まっちゃうみたいなことをなるべく避ける、人的な単一障害点を防ぐことに最初はすごく注力していました。

これによって、プルリクのレビュー体制とか開発の滞りが改善されました。これだけではなくいろいろやったのですが、プロダクト開発を円滑に進める要因は、これが一番大きかったかなと思っています。

採用における、「認知・興味関心・検討」のために行ったこと

次に、採用です。採用に関しては、すでに大きなプロダクトを抱えて成長もしているので、事業規模の拡大も早く、数十名のエンジニアを短期的に採用しなくちゃいけないということが想像できたため、まずはリードエンジニアの採用をしていくところに注力して採用活動を実施しています。そのリードエンジニアを中心にチーム化していく中期的な計画をしてスタートしました。

採用計画は立てても、とにかく何もない状況でした。エンジニアがいないのでテックブログみたいなものもありませんし、会社のサイトを見ても「エンジニア」という文言はないし、プロダクトの紹介もない状態なので、「採用困ったぞ」という感じでしたね。

採用には、認知とか興味とか検討という段階が必要だと思うのですが、まずは認知度を上げないと誰も来てくれないので、図にあるような取り組みをしています。

認知度の施策としては、『Creators Blog』、テックブログみたいなものを立ち上げたり、コーポレートサイトをリニューアルしたり。あとは勉強会で登壇したりしていきました。

あとは、関心を持ってもらう施策として、Culture Deckを作ったり、ChapterのDeckですね。iOSはこういう技術、こういうミッションでやっていますというものをChapterごとに作って、面談の質を上げる取り組みもしています。

あとは比較・検討してもらうものとして、働き方とかグレード設計をなるべく開示していきました。ほかには、メンバーと経営陣に直接会ってもらい、検討の材料としてもらうという取り組みをしています。

前述の取り組みはしつつも、認知度向上はどうしてもすぐにできるものではなく、求める採用スピードと時間軸が合わないので、最初のリードエンジニアはリファラル・スカウトで、ダイレクトで認知をして対応しようというところで取り組んでいます。

スカウト運用ではKPI設計、スカウト文のパーソナライズ、仕組み化に注力

特にスカウトに関しては、運用のKPI設計や、スカウト文のパーソナライズと仕組み化に注力して取り組んできたので、そこを紹介します。

上記の5つをKPIにしていました。メッセージ対応スピードにこだわっているのが特徴的で、最初は0.9日で設定をしていたのですが、現在の運用は0.4ぐらいなので、候補者を半日も待たせずメッセージを投げるというところもKPIに置いています。

採用はエンジニア全員で、ここに映っているサイクルで毎月取り組んでいます。これを行う際の運用ルールを徹底していて、スカウト文の書き方や検索の仕方など、情報共有の仕方を定義して全員でやっているのが、成果が出ている1つ（の要因）かなと思っています。

あとは、（会社の）認知度が低く、どれだけスカウトを送っても「この会社から来たからちょっと面談してみよう」みたいなものは期待できないので、そのための説明を非常に丁寧に行っています。共通の会社説明などを丁寧にするのはもちろん、なぜ指名しているかを、その人に合った文章で丁寧に説明して会ってもらうことを心掛けています。特にスキルや難易度など、短期的に取り掛かってもらいたいことも全部丁寧に書くという取り組みをしていました。