エンジニアを採用できない会社が、採用の前に整理すべき3つのこと

エンジニアを採用したい。そう考えて求人媒体に登録したものの、応募が来ない。スカウトを送っても、ほとんど返事がない。

これは、現在私が共同創業者・CTOを務めるKachiluで実際に経験したことです。

Kachiluでは、ミドルクラスから、その一歩手前のジュニア層を採用しようとしました。WantedlyやGreenに求人を掲載しましたが、当時は応募そのものがありませんでした。待っていても採用活動が始まらないためスカウトにも取り組みましたが、返信は多くありませんでした。

知名度の高くないスタートアップにとって、エンジニア採用は「求人を出せば候補者を比較できる」というものではありません。これから初めてITエンジニアを採用する中小企業であれば、その難易度はさらに高くなるはずです。

ただ、この記事で採用媒体の選び方やスカウト文面の書き方を解説したいわけではありません。採用手法を増やす前に、会社側で整理すべきことがあります。

私が重要だと考えているのは、次の3つです。

その人に何を作ってもらいたいのか
仕様や優先順位は誰が決めるのか
成果物の良し悪しを誰が判断するのか

採用媒体に登録しても、応募が来るとは限らない

エンジニア採用が難しいこと自体は、珍しい話ではありません。特に、まだ広く知られていない会社が経験者を採用しようとすると、候補者から見て会社を選ぶ理由が十分に伝わらないまま、多くの求人と比較されることになります。

Kachiluでも、求人を掲載した直後は、一定数の応募から候補者を選ぶことを想定していました。しかし実際には、選考以前に母集団ができませんでした。

周囲のスタートアップの採用状況を見聞きしていても、プレゼンスのない会社が同じ壁にぶつかることは少なくありません。特にシニアエンジニアや技術責任者を正社員として迎える難易度は高く、「まず優秀なシニアを一人採用する」という方針だけでは、長期間何も進まない可能性があります。

そこでKachiluでは、正社員採用だけでなく、副業で参加するエンジニアにも対象を広げました。副業の募集には正社員より応募があり、実際に一緒に開発する人を見つけられました。

しかし、副業エンジニアを採用すれば、すべて解決するわけではありませんでした。

エンジニアを採用する前に整理すべき3つのこと

1. その人に何を作ってもらいたいのか

最初に必要なのは、「エンジニアが欲しい」という状態から、任せたい仕事を具体化することです。

例えば、仕様がある程度決まった独立サービスを新しく作る仕事と、既存プロダクトを運用しながら毎日発生する要望へ対応する仕事では、必要な働き方がまったく異なります。

前者は、他の開発との依存関係を減らし、リリース日を調整できるなら、副業のエンジニアにも任せやすくなります。一方、後者は社内の状況を継続的に理解し、変化にすぐ対応する必要があります。限られた時間だけ参加する副業メンバーへ任せると、共有と調整の負担が大きくなります。

採用する職種や技術スタックを決める前に、まず次の点を言葉にする必要があります。

何を作るのか
既存のシステムや他の担当者と、どの程度連携が必要か
いつまでにリリースする必要があるか
リリース後も、顧客対応や運用を担ってもらうのか

ここが曖昧なままでは、正社員、副業、業務委託のどれを選ぶべきかも判断できません。

2. 仕様や優先順位は誰が決めるのか

エンジニアは、曖昧な事業上の要望を受け取れば、自動的に正しいプロダクトへ変換してくれるわけではありません。

顧客の要望をどこまで取り入れるのか。今月は新機能と安定性のどちらを優先するのか。予定していた開発を止めて、別の課題へ取り組むのか。こうした判断には、事業と技術の両方を見た意思決定が必要です。

Kachiluでは、参加するメンバー同士の開発ができるだけ影響し合わないように、担当するプロダクトとシステムの境界を分けていました。AIによる開発支援も使い、一人が担当できる範囲を広く取れるようにしました。

この設計により、副業メンバーと稼働する時間帯が一致しなくても、相手の返事を待つことが日々のボトルネックになりにくくなりました。リリース日を調整できるサービスだったことも重要です。

一方で、やることや優先順位が日々変わる仕事へ副業メンバーを巻き込むには、大きなコストがかかりました。背景を共有し、変更理由を説明し、限られた稼働時間の中で計画を組み直す必要があるからです。

仕様と優先順位を決める人がいない会社では、採用されたエンジニアが、本来想定されていなかったプロダクト責任者の役割まで背負うことになります。

3. 成果物の良し悪しを誰が判断するのか

完成した画面が動くことと、会社が継続して運用できるシステムであることは同じではありません。

設計は今後の変更に耐えられるか。セキュリティ上の問題はないか。障害が起きたときに調査できるか。特定の人しか変更できない状態になっていないか。こうした点を判断するには、一定の技術経験が必要です。

社内に判断できる人がいない状態で、ミドル手前のジュニアエンジニアを最初の一人として採用すると、本人に過度な責任を負わせることになります。経営者側も、開発が順調なのか、将来の問題を積み上げているのかを判断できません。

理想は、先にシニアエンジニアや技術責任者を確保することです。しかし、この層はそもそも採用市場に出てきにくく、知名度のない会社が正社員として採用するのは簡単ではありません。

現実的な方法の一つは、外部に技術判断のできる人を置き、その人と一緒に採用可能なジュニア層を採用・育成することです。

副業エンジニアに任せやすい仕事、任せにくい仕事

Kachiluでの経験から、副業エンジニアに任せやすい仕事には、次の条件があると考えています。

仕様がある程度固まっている
他のプロダクトや担当者との依存関係が少ない
一人で進められる範囲が明確になっている
リリース日をある程度ずらせる
稼働時間の違いが、他の人の仕事を止めない

反対に、次の仕事は副業には向きません。

優先順位や要件が日々変わる仕事
顧客とのやり取りをすぐ開発へ反映する仕事
複数プロダクトで利用する共通基盤やインフラ
全体へ影響する技術的な意思決定
障害対応や継続的な運用

これらは、社内の正社員か、少なくともフルコミットに近い形で参加する業務委託が担うほうがよいと考えています。

業務委託は、正社員より時間単価が高くなることがあります。能力や仕事の進め方にもばらつきがあり、発注側に技術的な見極めができる人がいなければ、期待した成果を得られない可能性もあります。

それでも、採用要件が固まっていない段階で正社員を採用するより、限定した仕事から一緒に働き、会社に本当に必要な役割を確かめる方法には価値があります。

シニアエンジニアを採用できない場合の選択肢

「最初の一人にはシニアエンジニアを採用すべきだ」という意見は正しいと思います。問題は、その人を採用できないことです。

採用できるまで開発を止めるか、判断できる人がいないままジュニアエンジニアに任せるか。この二択にする必要はありません。

外部のシニアエンジニアや技術責任者が、経営者と一緒に作るものを整理し、採用時の技術評価を行い、参加したメンバーの設計や成果物を確認する。そのうえで、採用可能なジュニア層や副業メンバーに、明確に区切った仕事を任せる方法があります。

これは、単に開発作業を外注することとは異なります。社内に不足している「何を作るか」「どう作るか」「出来上がったものを受け入れてよいか」という判断を補う考え方です。

AI時代でも、技術判断をする人は必要になる

AIを使うことで、一人のエンジニアが担当できる開発範囲は以前より広がりました。少人数で複数のサービスを開発・運用することも現実的になっています。

一方で、AIは会社の事業状況を踏まえて、何を優先すべきかを決めてくれるわけではありません。生成されたコードを採用してよいか、システムをどこで分けるか、どのリスクを受け入れるかという判断も残ります。

実装速度が上がるほど、間違った方向へ進む速度も上がります。 AI時代だからこそ、採用人数を増やす前に、意思決定と評価の責任を誰が持つかを明確にする必要があります。

採用を始める前のチェックリスト

エンジニアを採用できないと悩んでいる会社は、媒体を追加したり、スカウトの送信数を増やしたりする前に、次の3つを確認してみてください。

その人に何を作ってもらいたいのか

任せたい仕事、他の仕事との依存関係、期限、リリース後の運用まで説明できるか。

仕様や優先順位は誰が決めるのか

要望が変わったときに、背景を説明し、何をやめて何を進めるか決める人がいるか。

成果物の良し悪しを誰が判断するのか

動作確認だけでなく、設計、保守性、セキュリティ、運用まで評価できる人がいるか。

この3つに答えられなければ、採用活動だけを先に進めても、新しく参加した人が力を発揮できない可能性があります。

まとめ

Kachiluでは、正社員のエンジニア採用に取り組んでも応募が来ず、副業へ対象を広げたことで、一緒に開発する人を見つけられました。ただし、それが機能したのは、仕事を独立した単位へ分け、稼働時間の違いがボトルネックにならないように設計していたからです。

エンジニア採用が難しいとき、最初に見直すべきなのは求人票だけではありません。

誰に、何を任せるのか。誰が意思決定するのか。誰が成果を評価するのか。

この3つを整理することが、正社員、副業、業務委託のどれを選ぶ場合でも、採用した人が働ける環境をつくる第一歩だと考えています。

AI-assisted drafting; reviewed and approved by 松崎達朗 (Tatsuro Matsuzaki)