2年間で社員数40人→300人に急成長したX Mile。一人目エンジニア・蝦名さんに聞く“営業組織と強いタッグを組めた秘訣”

ノンデスク(ブルーカラー)産業のスタートアップX Mile社(クロスマイル)。2019年の創業から、現在は社員数300名にもなる急成長を遂げています。社員数40名の頃に一人目のエンジニアとして入社した蝦名潤さんに、エンジニア組織が拡大するタイミングでの課題と、解決するための取り組みを伺いました。

蝦名 潤(えびな じゅん)

X Mile株式会社 開発責任者
青森出身。公立はこだて未来大学にてコンピュータサイエンスを専攻。在学時には仮想通貨やブロックチェーン技術を独学。卒業後、不動産Techベンチャーにエンジニア1期生として入社。コアメンバーとして、フロントエンド・バックエンド・インフラと境目なくWebサービス開発に従事。2022年、X Mileに1人目のエンジニアとしてジョインし、開発基盤から組織構築までリード。

立ち上げ期から成長期にはエンジニア採用と教育に苦労した

――会社で一人目のエンジニアだったということですが、どのようにプロダクトをスタートしていったのですか。

僕が入社した2022年3月は、社員数が40名になる頃でした。それまでは他社のパッケージを購入して、他社のベンダーに依頼して保守する、という形のビジネスモデル。自社のサービスを作るべく僕が採用され、現在の主力プロダクトである「ロジポケ」の開発がスタートしました。

ロジポケには社内で代表と僕だけが関わっており、月に20〜30時間ほどの業務委託が1名。代表は営業としてお客様にヒアリングし、需要のあると思える機能を作成しました。僕はエンジニアとして3年目で、技術選定なども不安だらけで、本当に売れるのか疑心暗鬼でした。ところが、モックアップを作って代表が営業していたところ「1社取れました」との報告が。一気に不安が払拭され、「これで行けるんだ」という自信に繋がりました。それが、入社して4ヶ月目の頃でした。

――その後、エンジニア組織や開発方法はどのように変化していきましたか。

2022年7月からの半年ほどを「成長期」と考えています。エンジニアが僕を含めて社員2人、業務委託が2名になり、社員数は80〜100名ほどに増えました。ロジポケの営業担当も数名になり、僕は代表や営業の要望を噛み砕いて技術面をフォローアップすることになります。

新しいエンジニアには、未経験に近い人を採用しました。教育コストが膨れ上がり、技術的なクオリティを求めるとリリーススピードが間に合いません。技術的に正しいことより、お客様の課題解決や、商談でフィードバックが得られることを優先しました。また、新機能の場合、売れる可能性がわからないままに作り込むのもリスクが大きい。そのため、一部分ずつ作ってお客様の反応を見ながら、破棄するものと作り込むものを選別。ビジネス的観点と、スピードを重視して取捨選択していました。

新機能のアイデアは、お客様にヒアリングするだけでなく、物流業界から転職してきた営業社員から案を出してもらったり、社長が他社のプロダクトを調査して必要そうな機能をピックアップしたりして決めていきました。

――その頃、エンジニア組織の課題はありましたか。

端的にいうと業務過多です。営業が組織化すると、ノルマはKPIといった目標数値が敷かれ、契約前のお客様のニーズが出てきます。お客様ごと、つまり営業担当ごとに欲しい機能が異なり、実装しなければ失注し、ノルマが未達で終わる可能性があります。営業部門とエンジニアのコミュニケーションもケアしたいという意向から「基本全部やる」というスタンスになり、業務量でカバーせざるを得なくなっていました。

プロダクトの機能が増えていき、業務の属人化も課題でした。60点のクオリティでリリースするという方針で進めていましたが、ユーザーが使い始めるとむやみやたらに手をつけられず、データ補正もままならない。ある程度予測はしていたものの、複雑度が高まり、お客様からの質問に答えるための調査にも時間がかかるようになっていました。

この時は本当に大変でしたが、ほぼ未経験で採用したエンジニアのスキルは高まりましたし、気合と根性を見せたことで営業部門との関係性はとても良くなりました。

過渡期はエンジニアの数が増えたが、スピードアップがままならない

――2022年は走り切ったという印象ですね。2023年からは、どのようなフェーズに入り、どのように変化しましたか。

2023年は「過渡期」と捉えています。営業組織が数十名になり、社員数は年始の120名ほどから、年末には200人超となりました。エンジニア組織も変化し、新卒2名、中途2名を加えた6人体制に。業務委託の方を加え、全部で7人になりました。僕は引き続きエンジニアチームのリーダーでしたが、組織が大きくなったため、コードを書く機会は減りました。

その分、業界の知識をインプットしました。Slackで共有されている営業のレポートや商談資料、ネットニュースはもとより、国土交通省や日本トラック協会といった機関が出している何百枚ものPDF資料を読み込んだりしました。業界のルールに沿って機能を作る必要があったからです。

――過渡期の大きな課題はどんなところでしたか。

一番の課題はエンジニアの採用です。即戦力を求めていますが、市場になかなかおらず、いてもかなり厳しい取り合いになります。育てる前提で、若手やポテンシャルのある人を採用しました。ただ、育てる余力が十分とは言えないままに人数が増えてしまいました。営業部やお客様からは「さばける量が増えるだろう」と思われてリクエストが増えるのですが、実はなかなかスピードは速まらない、という悪いサイクルに入っていたと思います。

加えて、プロダクトの機能が増えていくにつれ、それぞれのエンジニアが、自分の担当以外の機能を理解できていない、という状況になっていました。また、次々と増える機能は、他社製品の機能をTTP(徹底的にパクる)したもの。エンジニアから見ると、理由がよくわからないまま、売れそうな機能を作る、というタスクが次々と積み重なっていきます。働いても働いても終わりがないような雰囲気になっていました。

これらの対策として、一人1機能と担当を決めることにしました。「誰に問い合わせればよいか」を明確にして、コミュニケーションの整理を優先したのです。業界知識も全て網羅するのではなく、担当機能の部分だけ責任を持てばいいのでリリーススピードに響きにくくなります。モチベーションの部分でも、ある程度の効果がありました。要件定義のミーティングに参加してファシリテーションしながら、方向性や重要性も知ったうえで機能作りに取り組むからです。

狙いどおりに進みはしましたが、一方でデメリットもありました。業界知識をキャッチアップするハードルが高くて成果が出しにくかったのか、数ヶ月で退職してしまったメンバーが数名。担当機能を分けていたので、辞めた人のフォローも苦労しました。

――前のフェーズ「成長期」で、気合と根性で乗り切った体制は改善できたのでしょうか。

対策は、やり切れていなかったと思います。もともと60点のクオリティで出し続けたコードを読みながら修正する作業はかなり時間がかかり、能力も必要。私ともう一人の初期メンバーは体力でカバーした部分がありましたが、いつまでも続けるわけにはいかない。組織が大きくなればなおさらです。それぞれのエンジニアにはハンズオンなど業務のフォローアップのほか、業務と関係のないところでランチに誘って打ち解けるなど、メンタルのケアも心がけていました。それでも、なかなか足りていなかったと思います。

現在はロードマップを決め、優先度を定められるように

――2024年初頭から現在は、エンジニア組織としての変化はありましたか。

エンジニア組織は社員は一桁、全体では10名を超える組織になってきており、業務委託の方も含めて増えています。実は昨年まで、なかなか達成が得にくい環境でした。というのも、お客様からのフィードバックは、今の機能で困っている部分を直して「便利になりました!」というものがほとんど。作った新機能はなかなか売れず、会社としての売り上げにつながっていかなかったのです。

対策として、昨年に実施した一人1機能というルールに加えて、ロードマップを策定しました。リクエストされた機能は「気合で全部作る」というスタンスでしたが、ロードマップを決めたことで、含まれないものは優先順位を下げられるようになりました。作りたいものに集中できるようになり、長期的な計画も立てられます。エンジニアのモチベーションはかなり上がったと思います。

新機能の販売については依然として課題ですが、少しずつ売上に繋がっており、お客様に価値提供できているという実感が高まりつつあります。

――現在の課題はどのようなことでしょうか。

エンジニアは今も不足しており、採用面は課題です。過渡期には教育リソースのないうちから若手を採用してしまったので、今年はハイレイヤーの方を採用して教育リソースを増やす、という決断をしました。業務委託としても、海外ベンチャーでCTOを経験している方にお願いしており、社内外共にマネジメントできる人が増えています。受け入れ態勢を整えたので、若手を採用しやすくなりました。もちろん、即戦力の方がいれば積極的にアプローチしてスケールを目指していきます。

プロダクトは2年を経ており、過去に積んできた技術的負債の解消が求められます。当時は最新だった技術も古くなっているので、そのメンテナンスも必要です。

新機能の部分では、他社のプロダクトをベンチマークする時期は終わり、そろそろ「ロジポケ」独自の強みを作らなくてはなりません。業界知識とお客様のニーズに新しい技術を掛け合わせ、課題解決できる機能を作っていく予定です。

営業部門と伴走して信頼関係を構築できたのが一番の財産

――これまでを振り返って、特に良かった点や、こうすればよかった、という点はありますか。

営業部門と伴走できたのは良かったと思っています。自分たちの都合で機能を出すのではなく、営業とお客様に求められているものを作れた。営業部門とは今も信頼関係が成り立っており、コミュニケーション経路もかなり良好に維持できています。それは弊社の一番の強みだと思っています。

「こうすればよかった」という点は、難しいですね。スタートアップで体力、資金力のない中で、けっこうよくやれていたと自負しています。とはいえ、場当たり的な対応は少なくなかったので、全体を俯瞰して行動できていれば、もっとよかったのかもしれません。

――今後、エンジニアチームで実現したいことはどんなことですか。

やはり、わが社のプロダクトにおける強みを作っていくことです。お客様目線を最優先として機能を作ってきましたが、技術的な背景を持ちつつお客様目線で考えたときに、新しいアプローチができるのではないかと思っています。

今扱っているのはロジスティックスですが、これからは建設や警備といった複数業界で使えるホリゾンタルSaaSを作る可能性もあります。ノンデスク(ブルーワーカー)業界全般をターゲットとして、プロダクトに合わせてチームを組成して、上のポジションを狙っていくつもりです。