スニーカーから始まり、現在はトレーディングカードやアパレルにも取扱いカテゴリを拡大しながら、2022年には海外進出も果たしたCtoCフリマアプリ「SNKRDUNK（スニーカーダンク、通称スニダン）」。

その運営を行うスタートアップである株式会社SODAは、2018年の創業から3年で100億円以上の資金調達を達成し、企業評価額は380億円を超える急成長を遂げている。

その成長スピードを表すかのように、組織全体は直近1年で3倍強の規模になり、中でもエンジニア組織は、採用活動を始めて2年間で「2名から20名体制」へと急拡大しているそうだ。同社でVPoE兼エンジニアリングマネージャー（以下、EM）を務める林 雅也さんは、1人目の正社員エンジニアとして入社し、直近まで月30件ほどに及ぶカジュアル面談をすべて担当するなど、エンジニア組織における採用と組織づくりを牽引。

採用に関しては、HR専任メンバーがいない中、エンジニアの9割が熱量高く採用活動に参加し、見極めなどの属人化に対する打ち手として「半構造化面接」を開始したという。

また、組織が10名ほどになった頃からアジャイル開発に移行し、現在は「ユーザーバリューストリーム」に沿った開発体制を構築。サービスにおける一連のユーザー体験プロセスをブロックに分解してチームを組み、チームごとにPdMとエンジニアが所属することで、チーム単位で開発を完結できる体制になっているそうだ。

今回は林さんと、エンジニア兼EMの冨永晃史さんに、事業の急成長を支えるエンジニア組織における採用と組織づくりの取り組みについて、詳しくお話を伺った。

CTO1名だけの開発チームにジョイン。急ピッチでの採用活動を開始

林　僕は、前職のサイバーエージェントでバックエンドエンジニアを経験した後、社会人2年目の2020年10月にソフトウェアエンジニアとしてSODAに入社しました。

2022年1月からはVPoE兼EMとして、アジャイル開発の導入やエンジニア採用といった、エンジニアリングマネジメントの領域で様々な役割を担っています。

弊社が開発・運営しているCtoCフリマアプリの「スニーカーダンク」は、これまでスニーカーの取扱いがメインでしたが、アパレルやトレーディングカードといったホビー領域にも商品カテゴリを拡大しているところで、今年からは海外展開も進めています。

林　開発チームは、CTOとEM陣に加えて、モバイルアプリとWeb開発を担うメンバーで構成されています。事業を拡大するにあたっては常にエンジニアのリソース不足が課題になっていましたし、20名規模になった現在でもその課題は解消されていません。

僕の入社前は、開発チームのメンバーは取締役のCTOのみで、あとは7名ほどの業務委託の方が協力してくださっている状態でした。当時のチーム課題は、やはり開発のレビューをできる人がCTOしかいないということで、そこがボトルネックになって本来注力すべき施策がなかなか進まないという状況になっていたんです。

そこで、僕が2020年6月に副業でジョインして、10月に正式に社員になったタイミングで業務委託は一旦ストップして、CTOと僕の2名だけで2〜3ヶ月開発を進めました。

その後、スニーカーダンク初のテレビCMを放映したり、開発環境を移行したりしたこともあってリソースが全く足りていなかったので、急ピッチでエンジニア採用に取り組むことになりました。

9割はダイレクトリクルーティング。開発チームが2名→20名へ急拡大

林　その採用活動にあたっては、多くの企業と同様にダイレクトリクルーティングの数を増やすことに注力しましたが、僕たちの場合は最初から現在に至るまで「転職ドラフト」での採用活動に最も力を入れてきました。

転職ドラフトはエンジニア向けの採用サービスの一つですが、候補者が参加表明できる期間が決まっていて、企業側が年収提示付きで候補者を指名して競争入札できる仕組みです。そのため、他のサービスと比較しても「転職意欲が高い人が非常に多い」という手応えを感じたのが注力先に選んだ理由ですね。

特にエンジニアが10人以下のフェーズでは、開発チーム内にマネジメントスキルを持っているメンバーがいない状況だったので自走力の高いエンジニアを採用する必要性が高く、指名する際の文章にはかなりこだわってコストを割きました。

また、一つのWebアプリケーションの機能開発における設計から実装まで、ほぼ一通り自走してお任せできる技術レベルを持つ方々にアプローチさせていただきました。

今在籍しているエンジニア20名のうち、自己応募で入社してくれた方は2、3名ほどなので、いかにダイレクトリクルーティングが重要かということを実感しています。

▼VPoE / エンジニアリングマネージャー 林 雅也さん

採用までのフローは「カジュアル面談→書類選考→採用面談（2〜4回）→オファー面談」という一般的な流れです。カジュアル面談は1ヶ月で30件ほど実施していて、直近ではEMを務める冨永にも出てもらっていますが、それまではカジュアル面談とオファー面談に関しては僕がすべて担ってきました。

というのも、エンジニアのカジュアル面談はやはり技術的な内容に加えて、組織のマネジメント領域についても話すので、候補者目線でもマッチ度を測れるように明瞭に答えられる人が出るべきだと考えているからです。

一方で、今年までHR専任のメンバーがいなかったこともあり、書類選考から採用面談に関してはエンジニアのみんなにも全面的に協力してもらっています。事業が急成長していくフェーズで開発も非常に忙しいのですが、本当に嬉しいことにエンジニアの9割以上が積極的に参加してくれていて。今はSpotifyモデルで言うギルドに近い概念で、サイドプロジェクトチームを組んで進めていますね。

このような形で、30代のエンジニアの方々を中心に毎月1〜3名のペースで入社いただけたことで、この2年間で開発チームを2名から20名へと急拡大させることができました。

Googleを参考に「半構造化面接」に着手。採用の属人化をなくす

冨永　僕は、2022年1月にFlutterのアプリエンジニアとしてSODAに入社しました。その後8月からはアプリ開発と並行して、EMとして採用や組織づくりを担っています。

僕たちはエンジニア主導で採用を進めていますが、開発リソースが不足している中で採用活動への協力体制を築くのが難しく、頭を悩ませている企業も多いかと思います。

それに対して、僕自身がいちメンバーとして採用に携わる中で感じるのは、トップダウンで林から何らかの指示をするのではなく、チーム内に「みんなで状況を改善していこう」という空気感が醸成されていて、課題に対する改善策をエンジニア自身が考えて実行するという文化が、採用活動にも良い影響を生んでいるということです。

そのおかげで、メンバーは忙しい最中でも「やらされ感」を感じずに、積極的に採用活動に関わってくれているんだろうなと思っています。

▼エンジニア / エンジニアリングマネージャー 冨永 晃史さん

林　ここまでは比較的順調に採用活動が進められた開発チームでしたが、実は今年は3ヶ月ほど採用実績がゼロになってしまった時期もありました。

僕個人としては、企業の組織課題でよく言われるような「20名の壁」がエンジニア組織にもあるんじゃないかなと思っています。

例えば、弊社に応募してくださる方々は比較的、初期のスタートアップ感や小さな組織が好きだという方が多いのですが、20名規模になると大きい組織のように感じられてしまって候補者のニーズと合わないケースが増えてきました。また、チーム全体をうまく動かしていくためのマネジメントの重要性も一気に増してきましたね。

ちょうどその頃、採用活動において「面接の型がなく属人化している」「候補者のマッチ度を見極める基準が言語化できていない」といった課題が浮き彫りになっていたので、それを解決すべく今年5月にエンジニアメンバーでキックオフをして、新たに「半構造化面接」に取り組んでいるところです。

これはGoogleも採用している「構造化面接（※）」に近いもので、「候補者にこういう質問をしたらマッチ度が測れるんじゃないか」や「どのように話を展開すれば具体的なエピソードまで話してもらえそうか」といった形で話し合いながら型を作り、ブラッシュアップしています。

※構造化面接：同じ職種に応募している候補者全員に対して、同じ面接手法で評価する手法

僕たちの半構造化面接の全体像としては、「組織面」「技術面」「キャリア面」という大きく三つのカテゴリで深掘りできるようにしています。

例えば「過去にどういうチーム体制で開発してきたのか」や、「開発する中で、エンジニア以外の他職種とどのようにコミュニケーションを取りながら進めてきたのか」といった質問から、本人のカルチャーフィットや、開発におけるどのプロセスでバリューが発揮しやすいのかといった点などを掘り下げるようにしていますね。

▼同社の「半構造化面接」フォーマット（一部抜粋）

バリューストリームに沿った体制で、各チームが独立して開発を進める

林　ここから開発体制についても触れていくと、現在の開発チームは従来のフロントエンド、バックエンドエンジニアなどの技術領域で分ける形ではなく、近年増えてきている「バリューストリームに沿った開発体制」を採用しています。

▼開発チームの組織構造「ユーザーバリューストリームとチーム」（同社提供）

林　具体的には、「スニーカーダンク」のサービスにおける「ユーザーによる出品〜発送操作」や「物流〜商品受取」などの一連のプロセスに沿って担当領域を分割し、それに連動する形でチームをA、B、Cに分けています。

そして、各チームにPdMやWeb担当、Flutter担当が所属する形です。いわゆる職能横断のようなクロスファンクショナルなチームで、機能開発のすべてをチーム内で完結できるような体制になっていますね。

▼各チームのメンバー構成（イメージ）

冨永　開発面においても採用活動と同様に、林やCTOから「こういう開発フローでやってほしい」といった具体的な手法が決められた形で下りてくるのではなく、各チームに裁量を持たせて自分たちに合ったやり方で改善するというスタイルで進めています。

なので、チームによって開発に使うツールも一部異なっていたり、アジャイル開発におけるスプリントレビューは特定のチームしかやっていなかったりするように、それぞれが開発を最適化するという風土が根付いていますね。

加えて、週に1回は全チームが集まって技術的な話をしたり、各チームでどんな取り組みをしているかを共有しながら、他のチームに連携するようなミーティングを実施しています。

その他にも、毎月の最終金曜日には、エンジニアチーム全体での歓迎会や飲み会を開催して交流を深めたり、EMの僕と林が隔週で各メンバーと1on1を行ってキャリアや具体的なアクションについて話したりする形で、個々人のサポートやチームビルディングをしています。

林　実は、少し前までは今と体制が異なっていて、エンジニアチームとは別の独立したPdMチームがあり、そこでチーム間の連携をしながらプロダクト開発を進めていました。

しかし、エンジニア一人ひとりがリソース効率を優先して、チケット駆動で開発を進めていたために、担当者しか開発内容の具体を把握しておらず属人化してしまったり、人によって開発スピードが異なっていてスケジュールの予測がしづらかったりといった不安定さがあったんですね。

それによって無駄なコミュニケーションコストが発生し、ドメイン知識がチームになかなか定着せず、PdMも施策ごとに毎回違うチームとすり合わせを行う必要が出ていました。そういった状況を解決するために、新たにアジャイル開発のプロセス導入を進めていき、現在のような体制に移行したという経緯があります。

現在の体制になったことで、スケジュールの予測が安定してきましたし、チーム全員で開発の具体を把握して属人化を防ぐという効果も生まれています。

「全員リードエンジニア」の姿勢で、課題解決力に長けたチームを作る

林　今までの話の中でもメンバーの自律性に触れてきましたが、僕たちの開発チームとして特徴的なものに、バリューの一つとしても掲げている「全員リードエンジニア」という文化があります。

▼エンジニア組織のバリュー（同社提供）

実は、このバリューは「これから全員リードエンジニアでやっていくぞ！」と言って掲げたわけではなく、エンジニアが10名を超えた頃にみんなが重視していることを言語化して、結果的に行き着いたような形です。

ですので、この言葉自体がポジションやロールを指しているわけではなく、SODAにはリードエンジニアという肩書がついたメンバーはいません。

ではどういうことかと言うと、僕たちは概念的な捉え方として「プロダクトや組織の課題に対して必要なことを提案したり、相談したり、実行したりできる人」をリードエンジニアと定義しているんです。

冨永　僕たちはそのような「課題解決力が高い人」を求め続けてきて、これまで順調に組織が拡大してきてはいるものの、今も常に課題として挙がるのは採用です。

スニーカーダンクのようなオンラインのCtoCサービスは、エンジニアのリソース規模によるビジネスインパクトがかなり大きいので、今後も求める人材に出会えれば上限なく採用したいと考えています。

また、今は各チームのエンジニアが主体的にコミュニケーションを取ることで、チーム間でうまく連携できていますが、今後チームが増えていっても連携を維持できるような体制への見直しは必要になるだろうと考えています。

林　冨永が言うように、今後開発チームが30名、50名に拡大していく中で一番課題になるのは、エンジニアとPdMとデザイナー間の連携や、ビジネスまで見据えた連携をしっかりとワークさせることだと思っています。

例えば、PdMはビジネスのKPIに紐づく施策を意思決定しているものの、ビジネスメンバーとエンジニアチーム全員が共に追うべきKPIにまで昇華できていない感じがあります。そのため、今は冨永と一緒に大規模な組織でアジャイル開発をしていく「スケーリングアジャイル」の領域について学びながら準備を進めているところです。

また、現在デザイナーは4名だけで独立したチームになっていて、各開発チームから施策ごとにクリエイティブの依頼が飛んでくる状況なので、同じチームとしてプロダクト開発を一緒にしている感覚をあまり醸成できていないと感じています。

そのため、今後はPdMとデザイナーとエンジニアが一つのプロダクト開発チームとして協力して、事業戦略の達成に動けるような組織にしていきたいですね。（了）