これからのIVRyのエンジニア採用に思うこと
IVRyでエンジニアをしている成田(@mirakui)です。2024年2月に入社してから4ヶ月ほど経ちました。その間IVRyでは、AI自動応答によるレストラン予約がリリースされたり、0AB-J(03などの市外局番)に対応したり、シリーズCの調達をしたり、経営チーム的なものが立ち上がったり、プロダクトも事業も組織もたった4ヶ月でめまぐるしく進化しています。これがスタートアップか〜〜と驚く毎日で、スピードに置いてかれないように日々やっております。
いま自分がやってること
僕は前職では経営やマネジメントがメインでしたので、当面はチームや組織を持たずにIndividual Contributorとして働きたいな〜という思いがあり、IVRyはそれを快く受け入れてくれました。ICのエンジニアします、以外何も決めずに入社したんですが、一通り課題を見渡してみて、手つかずでレバレッジの効く課題が多いと感じた、インフラまわりやデータ基盤まわりを今はやっています。
IVRyは "人材ブラックホール" なのか…？
一部の界隈では "人材ブラックホール" という言葉が使われることがあり、ありがたいことに今のIVRyもそう呼ばれたりします。確かにビジネスサイドはいわゆる"N周目"、つまり事業を成功させたことがある著名な方が集まりつつあり、そういう方々がめちゃくちゃ活躍されていて身が引き締まる思いです。
僕はエンジニアなので、じゃあエンジニアはどうか？というと、僕がIVRyで16人目のエンジニアで、執筆時点でのエンジニアは全部で17人です。あれ、あんまり増えてない……。
というわけで、僕の目から見て今のIVRyのエンジニア採用をどう考えていて、今後どうしていくべきかを語っていきます。
シンプルなプロダクトが武器
IVRyという事業がエンジニアリング観点でかなり恵まれていると感じるのは、IVRyは非常にシンプルなプロダクトでPMF(Product-Market Fit)しているというところです。コード、データモデル、インフラ、どれをとってもまだ量が少なく、複雑性が低いです。たとえば人事システムや会計システムのようなSaaSを作ろうとすると、最低限の価値提供のためにも複雑なドメインを設計しなければならないはずです。現在のIVRyは電話自動応答という事業特性からか、シンプルな設計で作れています。
また、まだリリースから4年弱ほどで、大きなピボットもせずに成長しているので、技術的負債や歴史的経緯といえるものが相当少ないです。
事業が進んでいる以上、システムは遅かれ早かれ複雑化していくものですが、シリーズCの調達をして、事業展開のギアチェンジをしようとしている今、プロダクトが "まだ" シンプルであるということは大きな強みになると見ています。アーキテクチャが複雑で巨大であると、開発は遅くなり、プラットフォームのエンジニアリングコストが膨れ上がっていき、エンジニアを増やしても事業がスケールしにくくなります。
"人が足りない" は善
"やりたいことが沢山あるのにエンジニアが足りない" というのはエンジニア採用の常套句ですが、個人的には、人を増やすことには慎重になりたいという立場です。
スタートアップが大企業よりも素早く事業を生み出せる理由の1つは、人が少ないからだと考えています。人が足りないと、"本当はやった方が良いけど、事業に時間を使うために仕方なく諦めること" が沢山出てきます。採用計画を、戦略からでなくニーズからの積み上げで作ってしまうと、この "仕方なく諦めてきたこと" をやってもらうための採用をしすぎてしまいます。事業はスピードが命で、そのためには何を諦めるかという戦略は、スタートアップに限らずどのようなフェーズでも重要です。"やりたいけどできていない" は健全な状態なのです。
また、重要なのは、"いま会社に足りないこと" は今いるタレントによってもたらされた意見にすぎないということです。妥協のない採用基準によって常に新しい視座を持った人を仲間にできていれば、その人達がもっと精度高く課題を見つけてくれるはずです。
僕自身もまた、新しい視座を期待されている "外から来たタレント" の一人であると思っているので、僕から見た課題の一部をご紹介します。
こんなスペシャリストに来てほしい
いまのIVRyはまだ小さい組織のため分業は進んでいなくて、特定の技術領域のスペシャリスト的なエンジニアはほとんどおらず、どちらかというとジェネラリストな方が多い印象です。また、AIのチーム(といっても執筆時点で2名ですが)は特徴的で、PoCや研究開発だけではなく本番のコードをバンバン書いてデプロイしています。
今のIVRyのようなシニアなフルスタックエンジニアの集まりというエンジニア組織も楽しいんですが、僕の目線で、こういう分野のスペシャリストが来ていただけると可能性が広がるなと思っている領域がいくつかあるので、その一部を思いつくまま書いていきます。
ログ設計や実装の知見があるデータエンジニア
ビジネスの分析のために必要なログが全然とれてないので、ログ設計やログ基盤の実装をやらないとそろそろまずいです。情報セキュリティ観点で、監査ログも整えたいです。困ってます
ObservabilityをゼロからやりたいSRE
着電をフックして、自動応答のルールをDynamoDBから取得したり、発話ごとにAIに問い合わせたりするのですが、これを可視化して、通話体験を分析して改善していきたいです
プロダクトセキュリティをリードするセキュリティエンジニア
通信の秘密を扱うサービスなので、セキュリティの重要度は事業の進捗とともにどんどん上がっています。今のIVRyだったらセキュリティに詳しい方に日々のプロダクト開発に入ってもらえるのがベストかなと思ってます
RustやGoなどで電話のAPIを爆速に書き換えてみたいバックエンドエンジニア
着電を処理するAPIはPythonで書かれています。このAPIのレイテンシーは直接ユーザ体験を左右するのと、バグによる実行時エラーが入ったときに通話ができないという障害に繋がるため要求サービスレベルが高いシステムです。保守性やパフォーマンスを考慮するとRustやGoなどのコンパイル言語との相性が良いかなと思っています。まだそれほどコードベースが大きくないので、書き換えチャンスです
Webフロントエンド技術(TypeScript/Next.js)のキャッチアップと設計に詳しいフロントエンドエンジニア
ITに詳しくない方でも簡単に使いこなせるのがIVRyのキモなのでフロントエンドの重要性は高いです。フロントエンド技術のモダン化やIVRyの開発にとって最適な技術選定/設計を指南してほしいです
iOS / Android アプリの通話体験を最高にしてくれるモバイルアプリエンジニア
いまはIVRyのFlutter(iOS/Android)アプリがあって電話の受発信ができるのですが、アプリからの通話体験をどう改善するか、という課題の優先度が上がっています。Flutterのまま行くのかネイティブで作り直すのか、そのへんの判断も含めてリードしてほしいです
サービス品質を技術で担保するテストエンジニア(SET)
IVRyは電話のサービスなので要求サービスレベルが高く、また音声が絡むと自動テストも難しい部分があったりするので、QAのプロセスが重くなってしまいます。素早いプロダクト開発とサービスの安定性を両立させるテストエンジニアリングを持ち込んでほしいです
音声認識の得意なAIエンジニア
固有名詞や住所などの難易度の高い音声認識ができるようにしていきたいのと、音声データがお客様ごとに沢山蓄積されているので、音声からの情報抽出や音声理解はすごく可能性あると思います
この中でひとつのロールでも採用できたら景色ががらっと変わると思っています。IVRyは、人手不足の深刻化 x LLMの進化という社会背景とともにこれから大きな成長を遂げるはずで、今はまだその前夜です。なのにエンジニアはまだ17人しかいないので、自分で言うのもなんですが、こんなに良いチャンスは世の中にそうそう無いんじゃないかと思います。強くおすすめします。
もしご興味があれば採用情報をご一読ください。
カジュアル面談も受付中です！お気軽にどうぞ。