技術力が高くても採用を見送る理由。スリーシェイクCEOが語る採用したいエンジニア像

吉田：スリーシェイクの吉田です。僕自身、もともとはオンプレミスのインフラエンジニアからキャリアをスタートして、その後AWSやGoogle Cloudを中心としたSREを経験してきました。現在は会社の経営に携わりながら、エンジニアの採用にも関わっています。

僕らスリーシェイクでは、採用を「仕事を任せる相手を探すこと」ではなく「長く一緒に働く仲間を探すこと」だと考えています。そのため、どれだけ技術力が高くても、採用を見送ることがあるんです。

今日は、なぜ僕らがそう考えているのか？これまでの採用経験も交えながらお話しできればと思います。

技術力が高くても採用を見送るのはなぜか

優秀だからといって、必ずしも採用するわけではない

僕らは採用において、技術力だけでなくカルチャーフィットをかなり重視しています。実際、技術力は非常に高いけれど、僕らとは方向性が違うなと感じて、採用を見送ることもあります。

例えば、Kubernetesにものすごく詳しくて、OSS（Open Source Software）にも積極的にコントリビュートしているエンジニアがいたとします。技術力としては申し分ないですよね。ただ、その方が「ずっとOSSに貢献していきたい」「研究開発に集中したいので、サービスにはあまり関わりたくない」と考えていたらどうでしょうか。

僕らは、技術を使って世の中のToil（労苦）をなくしていくことを目指しています。技術そのものを追求するだけでなく、お客さまやサービスの課題を解決することを大切にしています。だからこそ、本人のやりたいことと僕らが提供できる仕事が違うのであれば、採用しない方がお互いにとっていいと思っています。

そもそも、採用するということは、その方の人生の時間をお借りするということです。「優秀だから採用する」という判断だけでは、お互いに幸せになれないことがあるんです。本人が望むキャリアを僕らが用意できるのか。そこまで考えて採用を判断するようにしています。

スキルシートだけでは見抜けなかったミスマッチ

なぜ僕がここまでカルチャーや相性を重視するのかというと、過去に採用で失敗してきた経験があるからです。

以前、アドテック領域の複雑なアーキテクチャを扱うプロジェクトで、求めていた技術力を持つエンジニアを採用したことがありました。当時はスキルシートや経歴を見て「この技術ができるなら、きっと活躍してもらえるだろう」と考えていました。

ところが、実際に入社していただくと、仕事の進め方や考え方が僕らのやりたいこととなかなか合わなかったんですね。結果的に、その方とはお別れすることになってしまいました。

「技術力があること」と「僕らの環境で活躍できること」は必ずしも同じとは限りません。スキルシートだけで判断することは、お互いにとって良くなかったと感じています。

人手を補うだけでは、うまくいかないこともある

もう1つ、業務委託のエンジニアの方に参画していただいた時の失敗もあります。BigQueryを使ったデータ基盤のプロジェクトで、パフォーマンスの問題を解決するために、インフラエンジニアの方に入っていただきました。

ただ、そのプロジェクトでは技術力だけでなく、金融や広告といった領域のドメイン知識も必要でした。僕らも十分にオンボーディングができておらず、なかなか成果につながりませんでした。結果として、その方も仕事に面白さを感じられなくなり、契約を終えることになってしまいました。

こうした経験から、単純に「この技術ができる人が欲しい」「人手が足りないから採用しよう」という考え方では、うまくいかないことがあると学びました。

僕はよく「採用は結婚と一緒だ」という話をしています。半年や1年でお別れすることになるのは、会社にとっても本人のキャリアにとっても良くありません。だからこそ、仕事への向き合い方や、お互いに期待していることを事前にしっかりすり合わせるようにしています。

スリーシェイクが採用で重視している3つのポイント

では、具体的にどんなエンジニアと一緒に働きたいのか。僕らが選考で見ていることを、大きく3つの観点からお話しします。

1. 技術そのものに興味があるか

まず大切にしているのが、シンプルに「テックが好きかどうか」です。僕らは新しい技術を世の中に広げていくことを大事にしている会社なので、技術に対する好奇心がある方と一緒に働きたいと思っています。

例えば、Kubernetesに興味があって、ローカル環境で少し触ってみたという話でもいいんです。「GKEやEKSまではまだ触れていないけど、今後やってみたいんですよね」こういう話を聞くと、僕らもすごく盛り上がります。

別に最初から全部できる必要はありません。まだ経験がなくても、面白そうだと思って自分で試してみます。そういう好奇心を大事にしています。

逆に、僕らが選考でほとんど見ていないのが資格の数です。もちろん資格を取ること自体はいいことですが、これまでの経験では、資格の数と入社後の活躍にはあまり関係がないと感じています。資格をいくつ持っているかよりも、技術が好きで、自ら学んだり試したりしていることを重視しています。

2. 自分から課題を見つけ、解決しようとするか

もう1つ大切なのが、課題解決への向き合い方です。

僕らのSreakeという事業では、お客さまから決められた仕様を渡されて、その通りに実装するだけの仕事は基本的にやらないようにしています。企画段階から議論に参加して、何をつくるべきか、どう改善していくべきかを一緒に考えることを重視しています。

例えば、Terraformを使ってインフラ環境をつくっていた時に、モジュールが対応していなくて、一部の作業が手動になっていたとします。そこで「仕方ないよね」で終わらず、自分でスクリプトを書いて自動化してみます。こういう話を聞くと、僕はすごくいいなと思います。

大きな成果である必要はないんですよ。目の前の非効率をそのまま受け入れず、自分なりに工夫してみます。 そういう姿勢を持っている方は、僕らのカルチャーにも合いやすいと思います。

また、技術的な課題をどう解決したかだけでなく、ほかの人とどう協力したのかも大切です。生成AIによって実装の仕事が変わりつつある中、周囲と連携しながらより良いサービスをつくっていく力は、ますます重要になると考えています。

3. サービスや仕事そのものに関心があるか

3つ目は、サービスや仕事への興味です。

例えば面接で「自分の力で事業の売上を倍にしたいです」「サービスを100万人が使うところまで成長させたいです」と話してくれる方がいます。もちろん、すごくいい話だと思います。ただ、僕としては、そこだけに期待を持って入社してほしくないとも思っているんです。

なぜかというと、事業やプロダクトの成長は、自分の努力だけではどうにもならないことがあるからです。スタートアップのサービスも、1年で急成長するとは限りません。4年、5年かけて成長することもあれば、途中でピボットすることもあります。

そうした時に、事業の成長だけを仕事の楽しみにしていると、うまくいかない時期に疲れてしまうことがあるんですよね。

だから、事業成長への関心に加えて、技術そのものが好きだったり、サービスの課題解決に面白さを感じたり、ほかにも興味を持てる部分があるといいなと思っています。そういう方の方が、長く一緒に働いていけるんじゃないでしょうか。

面接では「回答」よりも「質問」を見ている

ここまで採用で大切にしていることをお話ししましたが、実際の選考では、それぞれの面接で見るポイントを分けています。

一次面接では現場のエンジニアが技術力や課題解決の進め方を見て、二次面接ではポジションやキャリアの期待値をすり合わせます。そして、僕が担当する最終面接では、カルチャーや興味関心、中長期で一緒に働けるかを見ています。

逆質問から、候補者の関心が見えてくる

僕が面接で特に注目しているのは、候補者の方が僕らにどんな質問をしてくれるかというところです。こちらからの質問にどう回答するかだけでなく、何に疑問を持ち、僕らの何に興味を持っているのかを知りたいと思っています。

例えば、最初の質問が「給与はいくらですか」「リモートワークはできますか」「どんな技術を使えますか」といった条件面の話ばかりだったとします。

もちろん、こうした条件も大切ですし、確認すること自体が悪いわけではありません。ただ、それだけだと、会社やサービスそのものにはあまり興味がないのかなと感じてしまうことがあります。

僕らが見ているのは、質問の内容だけでなく、その関心がどこに向いているかということです。自分の条件だけでなく、サービスや顧客、チームにどれだけ関心を持っているかを知りたいと思っています。

「よくわからなかった」という率直な質問も歓迎する

例えば、僕らの事業について説明した後に「すみません、正直まだサービスの価値がよくわからなくて。もう一度教えてもらえませんか？」と質問されたことがあります。

一見サービスに興味がないと判断されがちですが、僕としてはすごくうれしい質問なんです。もちろん、僕の説明がわかりにくかったということでもあるんですけど（笑）。でも、わからないまま終わらせず、もっと理解しようとしてくれているわけじゃないですか。

ほかにも「このサービスがうまくいくイメージが湧かないんですけど、実際にはどうやっているんですか？」といった質問もいいと思います。そう聞かれたら、こちらも具体的なエピソードを交えて説明できますし、議論が広がっていきます。

最近はChatGPTやGeminiを使えば、面接で聞くべき逆質問も簡単につくれますよね。でも、AIがつくった模範的な質問よりも、自分で考えて、率直に疑問に思ったことをぶつけてほしいと思っています。

面接は、企業が一方的に候補者を評価する場ではありません。候補者の方も僕らのことを知って、お互いに合うかどうかを確認します。そういうフラットな関係で選考を進めていきたいと思っています。

AI時代にどんなエンジニアと働きたいのか

生成AIの普及によって、これからのエンジニアに求められるものも変わってきていると感じます。

僕自身、最近はClaudeやCodexなどを使ってプロダクト開発をすることも増えました。実際に使ってみると、ドキュメントの作成やコードの実装など、これまで人間が時間をかけていた仕事が大きく変わってきていると感じます。

ただ、そうなった時に人間のエンジニアに何が残るのか。僕はエンドユーザーにどんな価値を提供するのかを考えることとつくったものに責任を持つことはこれからも重要だと思っています。

分業の境界を越えて仕事の幅を広げていく

以前は、インフラはインフラエンジニア、バックエンドはバックエンドエンジニア、テストはQAエンジニアというように、役割が分かれていることも多かったと思います。

しかし生成AIを使うことで、一人のエンジニアがより広い範囲を担当できるようになってきました。実際に僕らの会社でも、SREのメンバーがAIエージェントを開発したり、バックエンドの実装をしたりするケースが増えています。

今までは自分の専門領域の中でしかできなかったことが、もっと広い範囲までできるようになります。僕は、これはエンジニアにとってすごくポジティブな変化だと思っています。

AIがつくったものに責任を持てるか

もう1つ重要なのが、AIの成果物に対して責任を持つことです。

生成AIは、すごい量のコードを出してくれます。でも、AIがつくったものに対して、AI自身が責任を取ってくれるわけではありません。そのコードが本当に正しいのか、どういう仕組みで動いているのか、どんなリスクがあるのか。最終的には人間が判断しなければいけません。

だからこそ、インフラやアーキテクチャの知識も重要になります。AIがつくったものを見ても、その構造や動作を理解できなければ、適切に評価することはできません。

そして、ここでも技術やサービスへの興味が大切になってきます。自分があまり興味のない領域だと、AIが出してきたものをそのまま使ってしまうことってありませんか？

逆に、自分が詳しい領域だったら「これで本当にいいんだっけ？」「もっといい方法があるんじゃないか？」と、AIの出力の小さな違和感に気づけると思うんです。

AIを活用するほど、出力を判断するための知識や経験も必要になります。場合によっては、生成AIを使わないという判断をすることだってあるでしょう。大事なのは、自分がどう判断して、どう責任を取るのかということです。

クライアントワークの面白さと今後の可能性

ここまで技術の専門領域を越えて仕事の幅を広げることや、AIの成果物に責任を持つことについてお話ししてきました。

こうした働き方を考えるうえで、僕らが取り組んでいるクライアントワークにも、まだまだ面白さや可能性があると思っています。

クライアントワークの面白さは仕事の受け方で決まる

エンジニアの方とお話しすると「クライアントワークよりも、自社サービスを開発する事業会社の方がいいんじゃないか」という声を聞くことがあります。

もちろん、自社サービスを長く育てていくことにも面白さがあります。ただ、クライアントワークが面白くないかというと、僕はそんなことはないと思っています。

例えば、多重下請けの構造の中で、既に決まった仕様通りに実装するだけの仕事だったらどうでしょうか。技術選定にも関われず、自分たちで意思決定できる範囲も限られてしまいます。これでは、エンジニアリングの面白さを感じにくいと思います。

でも、これはクライアントワークそのものというより、仕事の受け方の問題なんですよね。

僕らの場合は、お客さまのチームの一員として入り、企画段階から一緒に議論しています。何をつくるべきか、どんな技術を使うべきか、どうすればもっと良いサービスになるのか。そういったことを、お客さまと一緒に考えながら進めていきます。

単にシステムをつくって終わりではなく、最終的にはお客さま自身が運用・改善できる状態を目指しています。だから、技術的な意思決定にも関わりますし、サービスや顧客のドメイン知識も自分たちで取りにいく必要があるんです。

こうした働き方であれば、自社サービスの開発と同じように、エンジニアがオーナーシップを持ってものづくりに取り組めます。

どちらが良いという話ではなく、自分がどこまで意思決定に関われるのか、どんな課題を解決できるのかという観点で、働く環境を見てみるといいんじゃないかなと思います。

AI時代には、専門性を持って伴走する仕事が広がる

では、生成AIが普及すると、こうしたクライアントワークはどうなるのでしょうか。

実際「AIによって外部のエンジニアに依頼する仕事は減っていくのではないか」という話を聞くことがあります。確かに、決められた手順に沿って作業するだけの仕事や、単純に人手を補うための仕事は、AIによって減っていく部分があると思います。

一方で、僕らの会社では、むしろ新しい相談が増えています。例えば、AI基盤を構築したい、ローカルLLMを活用したいといったプロジェクトですね。

企業の内製化は進んでいますし、生成AIを使って自分たちで開発したいという会社も増えています。ただ、AIがコードを生成できても、それを実際のサービスとして運用していくには、技術的な判断や専門的な知識が必要です。特に、新しい技術に挑戦する場面では「専門的な知識のあるエンジニアと一緒に取り組みたい」というニーズがあります。

だから僕は、単に人手を提供するのではなく、専門性を持ってお客さまの課題解決に参加し、内製化まで伴走する仕事は、これからも重要になっていくと考えています。

様々な業界の課題に触れることで、キャリアの幅が広がる

もう1つ、クライアントワークの面白さとしてお伝えしたいのが、様々な業界の課題に触れられることです。

僕らの場合、自動車や金融、メディアなど、いろいろな業界のお客さまと一緒に仕事をしています。業界が違えば、事業の仕組みも求められるシステムの要件も変わります。

ただ、そこで使う技術には共通するものも多いんです。例えば、同じKubernetesでも、製造業で使う場合と金融サービスで使う場合では、解決したい課題や求められる設計が違ってきます。

つまり、自分の専門技術を異なる業界で活用しながら、新しいドメイン知識や課題解決の経験を積めるということです。

僕自身、以前はゲームのインフラに関わることが多かったのですが、その後金融など別の領域に関わる中で、求められるアーキテクチャや考え方が全然違うことを経験しました。一方で、ゲーム開発で得たリアルタイム処理の知見が、データ基盤の開発で役に立つこともありました。

一つの業界に深く関わることにも、もちろん価値があります。ただ、技術的な専門性を持ちながら複数の業界の課題を解決していくことで、自分の経験をほかの領域にも応用できるようになります。

そうした経験を積んでいくことで、技術のスペシャリストとして専門性を深めることもできますし、将来的にCTOやVPoE、PMといったキャリアを考えるうえでも選択肢が広がっていくと思います。

クライアントワークだから成長できない、というわけではありません。どんな技術を扱い、どこまで課題解決に関われるのか。そこを見ていくことが大切だと考えています。

長く一緒に働けるエンジニアとは

ここまで、僕らの採用の考え方や求めるエンジニア像についてお話ししてきました。

僕らが大切にしていることは、生成AIが普及したからといって、根本的にはそれほど変わっていません。「技術が好きであること」「自分から課題を見つけて解決しようとすること」「サービスやお客さまのことに興味を持つこと」そして「お互いにやりたいことや期待していることを理解して、一緒にいいものをつくっていけること」。

だからこそ、面接ではみなさんにも率直に話してほしいと思っています。自分はどんな技術が好きなのか。どんな仕事を面白いと感じるのか。これからどんなキャリアを歩んでいきたいのか。会社に対してわからないことや不安なことがあれば、遠慮せず聞いてほしいと思っています。

企業が候補者を選ぶだけではなく、候補者のみなさんも自分に合う企業を選んでいるわけですから。

技術力が高いことと、その会社で長く活躍できることは、必ずしも同じではありません。

お互いの考え方や目指す方向を理解したうえで、一緒に働きたいと思えるかどうか。僕らはこれからも、そういう採用を大切にしていきたいと思っています。

本編動画