techcellar logo
Tips エンジニア採用のヒント

updated_at: 2026/3/31

非エンジニア創業者のための1人目エンジニア採用実践ガイド

非技術系の創業者がスタートアップで1人目のエンジニアを見極め、口説き、迎え入れるまでの全手順を解説

tip Image

非エンジニア創業者のための1人目エンジニア採用実践ガイド

Startup Life Illustration

「プロダクトのアイデアはある。資金も確保した。あとはエンジニアだけ ―― でも、どう探して何を基準に選べばいいのか分からない」

スタートアップの非技術系創業者にとって、1人目のエンジニア採用は事業の命運を左右する最重要イベントです。にもかかわらず、技術的なバックグラウンドがないと「本当にこの人で大丈夫なのか」という不安を拭えないまま意思決定を迫られます。

この記事では、技術がわからない創業者でも1人目のエンジニアを正しく見極め、口説き、チームに迎え入れるまでの全ステップを解説します。

このページでわかること

  • 1人目エンジニアに求めるべきスキルセットとマインドセットの定義方法

  • 非技術系でも使える技術力の見極めポイント

  • 候補者を見つける具体的なチャネルとアプローチ手順

  • 「CTO」をいきなり任せるべきかの判断基準

  • オファー設計からオンボーディングまでの実務フロー


TL;DR(この記事の要約)

  • 1人目エンジニアは「技術スペシャリスト」ではなく**「0→1を一人で回せるジェネラリスト」**を狙う

  • 非技術系でも見極められるポイントは「説明力」「過去の成果物」「不確実性への耐性」の3つ

  • いきなり「CTO」のタイトルを付けるのはリスク。「リードエンジニア」からスタートが安全

  • 年収だけで口説こうとしない。ビジョン・裁量権・ストックオプションの3点セットで勝負する

  • 入社後30日間の「共同作業期間」を設計し、技術選定とプロダクト方針を一緒に決めるプロセスが定着のカギ


1. なぜ「1人目エンジニア採用」はこれほど難しいのか

Ideas Illustration

通常のエンジニア採用との決定的な違い

2人目以降のエンジニア採用には、社内に技術がわかる人間がいます。スキルの見極めも、技術スタックの説明も、開発文化のアピールも、既存のエンジニアが担ってくれます。

1人目はそうはいきません。

比較項目

2人目以降の採用

1人目の採用

技術力の評価

CTOやリードが面接で判断

創業者自身が見極める必要あり

技術スタックの説明

既に決まっている

一緒に決める前提

開発文化のアピール

実績を見せられる

「これから作る」と伝えるしかない

候補者の期待値

チームやプロダクトを見て判断

ビジョンと創業者の人柄で判断

採用失敗のリスク

チームでカバー可能

事業存続に直結

非技術系創業者が陥りがちな3つの罠

罠1:「とにかく優秀な人」を求めてしまう

GAFA出身、GitHub Star数千 ―― そんなスペックを追い求めても、シード期のスタートアップには響きません。優秀すぎるエンジニアは「環境が整っていないと動けない」タイプも多く、0→1フェーズに向いているとは限りません。

罠2:技術のことがわからないから丸投げする

「技術は任せるから、よろしく」は最も危険なフレーズです。創業者がプロダクトの方向性や優先順位を示せなければ、エンジニアは何を作ればいいのかわかりません。技術の「中身」はわからなくても、「何を、いつまでに、なぜ作るのか」は創業者が主導する領域です。

罠3:知り合いのツテだけで決めてしまう

「友達のエンジニアに頼んだ」というパターンは少なくありません。人柄の信頼性はあっても、スキルフィットや事業へのコミットメント度合いが不十分なケースが多いです。人間関係と雇用関係は別物。友人だからこそ、採用プロセスはきちんと踏むべきです。


2. 1人目エンジニアに求めるべき人物像を定義する

「スペシャリスト」ではなく「0→1ジェネラリスト」

シード期のスタートアップで求められるのは、特定技術の深い専門性よりも幅広く動ける実行力です。

1人目エンジニアに必要な能力を3層に分けて整理します。

必須レイヤー(Must):

  • フロントエンド・バックエンド両方を一人で構築できる

  • クラウドインフラ(AWS、GCP等)の基本的なセットアップができる

  • プロダクトの要件を聞いて、自分で技術選定・設計判断ができる

  • Git管理、CI/CD、デプロイまで一通りこなせる

重要レイヤー(Should):

  • ビジネスサイドとの対話に抵抗がない

  • 「正解がわからない状態」で手を動かし続けられる

  • ユーザーフィードバックを元にプロダクトを改善するサイクルを回せる

  • セキュリティやパフォーマンスの基本的な勘所がある

理想レイヤー(Nice to have):

  • チームが拡大した際にリーダーシップを発揮できる

  • 採用面接で技術力を評価できる

  • 技術発信(テックブログ、登壇等)に積極的

見落としがちな「マインドセット要件」

技術力と同等以上に重要なのが、スタートアップ初期に耐えられるマインドセットです。

  • 曖昧さへの耐性: 仕様が固まっていない段階から手を動かせるか

  • ピボットへの柔軟性: 「先週作ったものを捨てて方向転換」に耐えられるか

  • オーナーシップ: 「自分の仕事」の範囲を自分で広げられるか

  • 事業への関心: 技術だけでなく、市場やユーザーに興味を持てるか

面接では「前職で仕様がなかった・変わった経験をどう乗り越えたか」を深掘りするのが効果的です。


3. 候補者を見つける5つのチャネルと優先順位

Engineering Team Illustration

1人目エンジニアの採用チャネルには、通常の採用とは異なる優先順位があります。

チャネル1:創業者の直接ネットワーク(最優先)

1人目エンジニアの採用で最も成功率が高いのは、創業者自身の人脈です。ただし、前述の「知り合いの罠」を避けるため、以下のルールを設けましょう。

  • 候補者が複数いる状態を作る(最低3人以上と面談する)

  • 友人であっても選考プロセスを省略しない

  • 「一緒に働きたい」と「事業に必要な人材か」を分けて評価する

具体的なアクションとしては、起業の意思を表明した段階から「いずれエンジニアを探す」ことを周囲に伝えておきましょう。投資家、アクセラレーター、起業仲間の紹介も有効です。

チャネル2:スタートアップ特化の採用媒体

通常の転職サイトではシード期の求人は埋もれます。スタートアップに理解のある候補者が集まるプラットフォームを選びましょう。

  • Wantedly: ビジョンベースのマッチングに強く、ストーリー記事で企業の想いを伝えやすい

  • YOUTRUST: 副業・転職の両方に対応。リファラル文化が根付いている

  • bosyu(募集系SNS): カジュアルな募集で初期接点を作りやすい

媒体選びの詳細はエンジニア採用媒体の選び方を参照してください。

チャネル3:技術コミュニティ・勉強会

エンジニアが自然体で集まる場に、創業者自身が顔を出すことが重要です。

  • 業界特化のMeetup、もくもく会への参加

  • 自社のドメイン領域に関連する技術カンファレンスへの参加

  • connpass等のイベントプラットフォームでの情報収集

ポイントは**「採用目的で来ました」と言わないこと**。まず関係性を作り、事業の話を自然にする中で興味を持ってもらう流れが理想です。

技術イベントの活用法は技術イベント・コミュニティ活用でエンジニア採用を加速させる実践ガイドで詳しく解説しています。

チャネル4:エンジェル投資家・VCからの紹介

資金調達済みのスタートアップであれば、投資家ネットワークを積極的に活用しましょう。VCのポートフォリオ企業間での人材紹介は珍しくありません。

  • 投資家に「こういう人を探している」と具体的に伝える

  • VC主催のポートフォリオ交流会に参加する

  • 投資家のLinkedIn経由で候補者にアプローチしてもらう

チャネル5:ダイレクトスカウト

非技術系の創業者がスカウトを送る場合、技術的な深い話はできなくても、以下を正直に書けば刺さります。

  • なぜこの事業をやるのか(創業ストーリー)

  • なぜ「あなた」にスカウトを送ったのか(プロフィールの具体箇所に触れる)

  • 1人目のエンジニアとしてどんな裁量権と影響力があるか

  • 技術は自分にはわからないからこそ、対等なパートナーとして一緒に決めたい

スカウトメールの書き方はエンジニア採用を成功させるためのスカウトメールの基本も参考にしてください。


4. 非技術系でもできる技術力の見極め方

undraw source-code m0vh

「技術がわからない自分に、エンジニアの実力なんて判断できるのか」

これは非技術系創業者の最大の不安です。結論から言えば、完全に正確な評価はできなくても、致命的なミスマッチを防ぐことは十分に可能です。

見極めポイント1:「説明力」で地力を測る

優秀なエンジニアは、技術的に複雑なことを非エンジニアにもわかりやすく説明できます。

面接で試すべき質問の例を紹介します。

  • 「このプロダクトを作るとしたら、どんな技術を使いますか?その理由を、技術がわからない私にも理解できるように説明してください」

  • 「前職で最も難しかった技術的な課題は何ですか?それをどう解決したか、小学生にもわかるように教えてください」

説明が回りくどい、専門用語を多用して煙に巻く、あるいは「説明するのは難しいですね」で済ませるエンジニアは、非技術系の創業者と二人三脚で走るには向いていません。

見極めポイント2:「過去の成果物」で実行力を確認する

ポートフォリオやGitHubアカウントがあれば見せてもらいましょう。技術の中身がわからなくても、以下の観点で確認できます。

  • 個人プロジェクトがあるか: 業務外でもものを作る人は、0→1フェーズへの適性が高い

  • READMEやドキュメントが整備されているか: コードが書けるだけでなく、伝える力があるか

  • 継続的にコミットしているか: 一時期だけ活発ではなく、習慣的にコードを書いているか

GitHub評価の詳しい方法はエンジニア採用でGitHub・ポートフォリオを正しく評価する実践ガイドを参照してください。

見極めポイント3:「不確実性への反応」でマインドセットを見る

以下のようなシナリオ質問を投げてみましょう。

  • 「もし入社後1ヶ月でプロダクトの方向性が大きく変わったら、どう対応しますか?」

  • 「仕様が決まっていない状態で、まず何から手をつけますか?」

  • 「自分が詳しくない技術領域のタスクが降ってきたら、どう進めますか?」

ここでの回答に「正解」はありません。見るべきは、不確実な状況を楽しめるか、それとも避けたがるかの姿勢です。

見極めポイント4:技術顧問やアドバイザーの力を借りる

自分だけで判断するのが不安なら、外部の力を借りるのは合理的な選択です。

重要なのは、最終的な採用判断は創業者自身が下すこと。技術評価は外注できても、「この人と一緒に事業を作りたいか」の判断は委任できません。


5. 「CTO」のタイトルを最初から付けるべきか

安易にCTOを名乗らせるリスク

シード期のスタートアップでは、1人目のエンジニアに「CTO」のタイトルを付けるケースが一般的に見られます。しかし、これにはいくつかのリスクがあります。

リスク1:期待値のミスマッチ

CTOという肩書きは「技術のトップとして組織を率いる」ことを暗示します。しかしシード期に必要なのは、自らコードを書いてプロダクトを形にする「プレイヤー」です。肩書きと実態のズレがストレスの原因になりえます。

リスク2:後から変更しにくい

事業が成長し、より経験豊富な技術リーダーが必要になったとき、最初のエンジニアからCTOのタイトルを外すのは感情的にも法的にも厄介です。

リスク3:採用市場でのシグナル

2人目以降のエンジニアを採用する際、CTOのポジションが埋まっていると「自分のキャリアパスが限定される」と感じる候補者もいます。

推奨:段階的なタイトル設計

フェーズ

推奨タイトル

備考

シード期(1-3人)

リードエンジニア / 技術リード

実態に即したタイトル

シリーズA前後(5-10人)

VP of Engineering / CTO

組織マネジメントの実績を見て判断

シリーズB以降

CTO

技術経営の役割が明確に

もちろん、候補者が「CTOでないと入社しない」と言うケースもあります。その場合は、肩書きと役割の定義を書面で明確にしておくことが大切です。「最初の1年はプレイヤーとして開発に専念し、チームが5人を超えた段階でCTOの役割を再定義する」といった合意を取り付けましょう。


6. オファー設計:年収だけでは口説けない理由

Software Engineer Illustration

シード期スタートアップの報酬設計の現実

大手企業やメガベンチャーと年収で勝負するのは、シード期のスタートアップにとって現実的ではありません。仮に資金調達済みでも、ランウェイを削って高年収を提示するのは本末転倒です。

では、何で勝負するのか。以下の3点セットで考えます。

武器1:ビジョンとミッション

「なぜこの事業をやるのか」「世の中をどう変えたいのか」を、創業者自身の言葉で語れることが最大の武器です。1人目のエンジニアは「給料がいいから入る」のではなく、**「この創業者と一緒に何かを作りたい」**と思って入ります。

具体的に伝えるべきこと:

  • 創業の原体験(なぜこの課題に取り組むのか)

  • 市場の大きさと獲得戦略

  • 3年後、5年後の事業イメージ

  • 自分(創業者)がこの事業にかけている覚悟

武器2:裁量権と影響力

1人目のエンジニアには、大企業では絶対に得られない裁量があります。

  • 技術スタックを自分で選べる

  • アーキテクチャを自分で設計できる

  • プロダクトの方向性に直接影響を与えられる

  • 採用に関わり、自分のチームを作れる

この「何もないからこそ全部決められる」環境は、特定のエンジニア層にとって非常に魅力的です。面談では「あなたが技術面のすべてを決める立場になります」と明確に伝えましょう。

武器3:ストックオプション(SO)

現金報酬で劣る分を、SOで補うのはスタートアップの常套手段です。ただし、いくつかの注意点があります。

  • SOの「行使条件」「ベスティングスケジュール」を明確に説明する

  • 「いつか上場したら大金持ち」ではなく、現実的な想定シナリオを共有する

  • 税制上のメリット・デメリットも正直に伝える

  • SOの設計は必ず弁護士に相談する

オファー面談のチェックリスト

オファーを出す際に、以下の項目を書面で提示しましょう。

  • 基本年収(月額ベース)

  • ストックオプションの付与数・条件

  • 試用期間の有無と条件

  • リモートワークの可否・頻度

  • 開発環境(PC支給、ツール予算等)

  • 肩書きと役割定義

  • 評価・昇給の仕組み(または「これから一緒に作る」旨)

報酬設計の詳細はエンジニア採用で勝つための報酬設計と年収戦略の完全ガイドも参照してください。


7. 入社後30日間のオンボーディング設計

なぜ1人目エンジニアのオンボーディングが特殊なのか

通常のオンボーディングは「既存の環境に馴染ませる」プロセスです。しかし1人目エンジニアの場合、馴染む先がありません。開発環境も、コードベースも、プロセスも、すべて「これから作る」状態です。

そのため、オンボーディングの目的は「環境への適応」ではなく、**「創業者とエンジニアが共通認識を築き、プロダクト開発の基盤を一緒に作ること」**になります。

Week 1:ビジョンの共有と現状把握

  • 創業の経緯、市場の課題、ターゲットユーザーを徹底的に共有

  • 既存の資料(事業計画、ユーザーインタビュー記録等)をすべて開示

  • 競合プロダクトを一緒に触って分析する

  • 「何を作るか」の優先順位を議論する

この週はコードを書かなくていい。むしろ書かせないほうがいいです。事業を理解しないまま技術選定を始めると、後で手戻りが発生します。

Week 2:技術選定とアーキテクチャ設計

  • 技術スタック(言語、フレームワーク、インフラ)の選定を一緒に議論する

  • 創業者は「なぜその技術を選ぶのか」の説明を求める(理解する必要はない。説明を聞くことが大切)

  • 開発環境のセットアップ(リポジトリ、CI/CD、デプロイフロー)

  • MVP(最小限の実用可能なプロダクト)のスコープを定義する

Week 3-4:MVP開発の着手とリズムづくり

  • 1-2週間単位のスプリントを開始

  • 毎日15分のスタンドアップ(進捗共有)を習慣にする

  • 週1回のデモ(動くものを見せる)を必須にする

  • 創業者が「ユーザーの声」をエンジニアに継続的に届ける仕組みを作る

30日目のチェックポイント

1ヶ月後に、お互いの率直なフィードバックを交換しましょう。

  • 創業者 → エンジニア: 開発の進捗やコミュニケーションへのフィードバック

  • エンジニア → 創業者: 事業方針の明確さ、働きやすさへのフィードバック

  • 双方で確認: このまま一緒に走り続けられるか? 改善点はあるか?

この段階で重大なミスマッチが見つかった場合、早期に対処するほうが双方にとって健全です。試用期間を設けている場合は、このタイミングが判断の節目になります。

オンボーディング全般の設計についてはエンジニアのオンボーディング完全ガイドも参考にしてください。


8. よくある失敗パターンと回避策

失敗1:「安く済ませたい」で妥協する

「フリーランスに安く頼む」「知人に格安でやってもらう」というアプローチは、短期的にはコストを抑えられます。しかし、以下の問題が起きがちです。

  • コミットメントが薄く、いつの間にかフェードアウト

  • 「自分のプロダクト」として関わってくれない

  • 品質やセキュリティが担保されない

1人目のエンジニアは「外注先」ではなく「共同創業者に近い存在」です。それに見合う待遇と関係性を提供する必要があります。

失敗2:技術選定を創業者が決めてしまう

「周りに聞いたらReactがいいらしい」「AIを使ったほうがいいって記事を読んだ」 ―― こうした断片的な情報で技術スタックを指定してしまう創業者がいます。

技術選定はエンジニアの専門領域です。創業者が伝えるべきは「何を実現したいか」「いつまでに必要か」「予算やリソースの制約」であり、「何の技術を使え」ではありません。

失敗3:開発の進捗を放置する

「技術のことはわからないから口を出さない」を「進捗も確認しない」と解釈してしまうケースです。

非技術系でもできる進捗管理の方法:

  • 毎日15分の口頭での進捗共有

  • 週1回の「動くデモ」を見せてもらう

  • タスク管理ツール(Notion、Linear等)で可視化する

  • 「いつまでに何ができるか」を常に合意しておく

失敗4:2人目のエンジニアを採用するタイミングを逃す

1人目が順調に稼働し始めると安心してしまいますが、1人体制は持続可能ではありません。バス因子(その人がいなくなったら事業が止まるリスク)の問題もあります。

2人目のエンジニア採用を検討すべきサイン:

  • MVPがリリースされ、ユーザーからのフィードバックが増えてきた

  • 開発タスクが1人では回しきれなくなった

  • 1人目のエンジニアから「人が足りない」というシグナルが出た

  • 次の資金調達のタイミング

1人目のエンジニアを巻き込んで、2人目以降の採用計画を早めに立てましょう。採用計画の立て方はエンジニア採用計画の立て方を参照してください。


9. 副業・業務委託エンジニアから始めるという選択肢

「いきなり正社員で1人目を採用するのはハードルが高い」という場合、副業や業務委託から関係を始めるアプローチも有効です。

メリット

  • お互いの相性を低リスクで確認できる

  • 候補者側も本業を辞めずに参画できるため、心理的ハードルが低い

  • 正社員採用に比べてスピーディーに開始できる

注意点

  • 副業では稼働時間が限定されるため、開発スピードは遅くなる

  • 「いつか正社員になってもらう」前提なら、最初からその意向を伝える

  • 業務委託の場合、成果物の権利関係を契約で明確にしておく

  • 副業で関わっている間に「この人と一緒にやれるか」を見極める期間と位置づける

副業・業務委託の活用法は副業・業務委託エンジニアの活用で採用力を強化する完全ガイドで詳しく解説しています。


10. 採用プロセスの全体フロー(まとめ)

ここまでの内容を、実際の行動ステップとして整理します。

Phase 1:準備(2-4週間)

  1. 事業の方向性と「1人目エンジニアに何を期待するか」を言語化する

  2. 人物像の定義(Must/Should/Nice to haveの3層)を作成する

  3. 報酬パッケージ(年収+SO+福利厚生)の設計をする

  4. 簡易な採用ピッチ資料を準備する

採用ピッチ資料の作り方はエンジニア向け採用ピッチ資料の作り方を参照してください。

Phase 2:候補者探し(4-8週間)

  1. 自分のネットワークに声をかける(最低10人に「エンジニアを探している」と伝える)

  2. 採用媒体に求人を掲載する(Wantedly等)

  3. 技術コミュニティに顔を出す

  4. スカウトメールを送る(最低20通)

  5. 投資家・メンターに紹介を依頼する

Phase 3:選考(2-4週間)

  1. カジュアル面談(30分):事業説明+相互理解

  2. 本面接(60分):技術力・マインドセットの見極め

  3. (任意)技術顧問による評価面接(60分)

  4. (任意)トライアル課題(1-2日の小規模な開発タスク)

  5. リファレンスチェック

カジュアル面談の進め方はエンジニア採用のカジュアル面談完全ガイドも参考にしてください。

Phase 4:オファー・クロージング(1-2週間)

  1. 書面でオファーを提示

  2. 条件面の交渉

  3. 不安解消のための追加面談(必要に応じて)

  4. 内定承諾

内定辞退を防ぐためのクロージング手法はエンジニア内定辞退を防ぐ!承諾率を高めるクロージング完全ガイドを参照してください。

Phase 5:オンボーディング(4週間)

前述の30日間プログラムに沿って実施します。

全体で最短2ヶ月、標準的には3-4ヶ月を見込んでおきましょう。焦って妥協するより、適切な人材を見つけるまで待つほうが長期的なコストは低くなります。


FAQ(よくある質問)

Q1. 非技術系の創業者がエンジニアの年収相場を知るにはどうすればいいですか?

各採用媒体の求人情報を見ると、職種・経験年数別の年収帯がわかります。一般的に、シード期スタートアップの1人目エンジニア(フルスタック・経験5年以上)の場合、年収500-800万円+ストックオプションが一つの目安です。ただし地域やスキルセットで大きく変動するため、複数の媒体で相場観を掴むことをお勧めします。詳しくは報酬設計と年収戦略の完全ガイドを参照してください。

Q2. エンジニアの技術力を評価できる人が社内にいない場合、どうすればいいですか?

技術顧問やフリーランスCTOに面接への同席を依頼するのが最も確実です。投資家やアクセラレーターのメンターに紹介してもらえるケースも多いです。また、techcellarのようなエンジニア採用支援サービスを活用すれば、技術評価から選考設計までサポートを受けられます。

Q3. 1人目のエンジニアが辞めてしまったらどうなりますか?

正直に言えば、事業への打撃は大きいです。そのリスクを軽減するために、(1) 入社後すぐにドキュメント文化を定着させる、(2) コードレビューの習慣を早期から作る(2人目採用後)、(3) 属人的な知識を減らす仕組みを意識的に構築する、という3点を心がけましょう。

Q4. 共同創業者(Co-founder)としてエンジニアを迎えるべきですか?

事業の初期段階で強いコミットメントを引き出すには、共同創業者としての参画が理想的です。ただし、株式の配分や意思決定の権限について事前に合意が必要です。「まずは社員として入社し、相互に信頼が築けた段階でCo-founderに移行する」というステップもあります。

Q5. 開発を外注してから、あとでエンジニアを採用する方法はありますか?

可能ですが注意点があります。外注先のコードが内製に適さない品質だった場合、結局ゼロから書き直すことになります。外注する場合でも (1) コードのオーナーシップ(著作権)を自社で保持する契約にする、(2) 採用したエンジニアが引き継ぎやすいよう、ドキュメントと設計資料の納品を義務付ける、(3) 外注と並行して採用活動を進める、という点を守りましょう。

Q6. リモートワーク前提で1人目のエンジニアを採用しても大丈夫ですか?

可能ですが、初期段階では対面でのコミュニケーション頻度を意識的に高めることを推奨します。特に最初の1ヶ月は週2-3回以上の対面(またはビデオ通話)で、事業理解とチームビルディングを優先しましょう。リモートワーク下でも信頼関係を構築できる仕組みを整えることが重要です。リモート環境での採用力強化はリモート・ハイブリッド時代にエンジニア採用力を高める実践ガイドを参照してください。

Q7. エンジニア経験のない創業者でも、エンジニアから信頼されるにはどうすればいいですか?

技術の知識がなくても、以下の姿勢を示せば信頼は得られます。(1) 技術的な意思決定をエンジニアに委ね、口出しをしない、(2) ビジネス面の情報(ユーザーの声、市場データ、経営数字)をオープンに共有する、(3) エンジニアの意見を聞いて意思決定に反映する、(4) 「わからないことはわからない」と素直に言う。技術への敬意を行動で示すことが最も重要です。


まとめ・次のアクション

1人目のエンジニア採用は、スタートアップ創業期の最も重要な意思決定の一つです。技術的なバックグラウンドがなくても、正しいプロセスと判断基準を持てば、事業に最適なエンジニアを見つけることは十分に可能です。

今日からできるアクション:

  1. 人物像を定義する ―― Must/Should/Nice to haveの3層で、求める人材を言語化する

  2. 周囲に伝える ―― 10人以上に「エンジニアを探している」と声をかける

  3. 候補者と会う ―― 3人以上とカジュアル面談して相場観を掴む

  4. オファーを設計する ―― ビジョン・裁量権・SOの3点セットで勝負する

エンジニア採用は「待っていても来ない」領域です。創業者自身が動き、語り、口説く。その熱量こそが、1人目のエンジニアを引き寄せる最大の武器になります。


エンジニア採用にお困りの方は、techcellarの採用支援サービスにぜひご相談ください。非技術系の創業者向けに、1人目のエンジニア採用から技術評価まで伴走型でサポートしています。

Download


資料ダウンロード

エンジニア採用の課題解決を
techcellarチームがサポートいたします

techcellar
techcellar
techcellar
techcellar