人材確保 起業家向け

最初のエンジニアの採用：役割の決め方と、コードの権利の押さえ方

最初のエンジニアを採用するときは、「どの技術が書けるか」よりも「何もない状態から、事業の検証に必要なものを自分で判断して作れるか」を基準にします。あわせて、入社前後の契約で、その人が書いたプログラムや発明の権利が会社に残るようにしておくことが欠かせません。プログラムの権利は、雇用か業務委託かで扱いが変わるためです。

この記事では、創業者がエンジニアではないスタートアップを主な読者として、最初のエンジニアの採用の進め方を整理します。共同創業者としての技術責任者（CTO）を探す場合は、株式の持ち分などの論点が加わるため、共同創業者の探し方と、組む前に決めておくこともあわせて読んでください。

採用の前に決めること

共同創業者か、最初の社員か

最初のエンジニアを「共同創業者（技術責任者）」として迎えるのか、「最初の社員」として迎えるのかで、求める人物像も報酬も大きく変わります。前者は事業の方向性の決定にも責任を持ち、株式の相当部分を持つ立場です。後者は、創業者が決めた方向の中で開発を担う立場です。どちらを求めているのかがあいまいなまま面接を始めると、候補者との期待がずれます。

今後半年で作るものを書き出す

採用の前に、今後半年程度で作る必要があるものを書き出します。例えば「顧客が使う画面の試作品」「既存の業務システムとのデータ連携」「決済の仕組み」などです。これにより、必要な技術領域（画面側か、サーバー側か、データか）と、どの程度の品質が必要なのか（検証用か、本番運用か）が見えてきます。MVPの段階での作り方はPoC・プロトタイプ・MVPの違いと進め方も参考になります。

外注やノーコードで足りないか

今の段階で本当に社員のエンジニアが必要かも確認します。検証段階では、ノーコードツールや開発会社への外注で足りることもあります。一方で、事業の中核が技術そのものにある場合や、仕様が頻繁に変わる場合は、社内にエンジニアがいないと検証の速度が落ちます。判断の軸はゼロから作るか、既存のパッケージを使うかの判断基準でも扱っています。

最初のエンジニアに求める力

最初のエンジニアは、既に仕組みが整った会社のエンジニアとは求められることが違います。

  • 自分で優先順位を決められる：仕様書がそろっていない中で、事業の検証に必要な順番を考えて作れること
  • 技術の選択を説明できる：採用する言語やサービスを、将来の保守や採用のしやすさも含めて説明できること
  • 作らない判断ができる：既存のサービスで済むものは作らず、作るべき部分に時間を使えること
  • 顧客や創業者と直接話せる：要望をそのまま実装するのではなく、背景の課題を聞き取れること
  • 後から来る人のことを考えられる：コードや設定の記録を残し、次のエンジニアが引き継げる状態にできること

特定の技術の経験年数は、これらに比べると優先度が下がります。逆に、大規模な組織で分業の一部だけを担ってきた人は、優秀であっても、最初の一人としては戸惑うことがあります。

見極め方

技術がわからない創業者はどう判断するか

創業者がエンジニアでない場合、候補者の技術力を自分で判断するのは困難です。信頼できる外部のエンジニアに面接への同席や、候補者の過去の成果物（公開しているコードや、作ったサービス）の確認を頼む方法があります。この協力者と継続的な関係を結ぶ場合は、アドバイザー・顧問の迎え方と報酬も参考にしてください。

実際の課題で一緒に働いてみる

最も確実なのは、実際の課題に一緒に取り組んでみることです。例えば、今作ろうとしているものの設計について議論する、小さな機能を作ってもらう、といった方法です。この場合、短期間であっても報酬を払い、業務委託として契約するのが基本です。ただし、業務委託と言いながら勤務時間や場所を細かく指定し、社員と同じように指示すると、実態は雇用と判断されることがあります。違いは業務委託と雇用の違い（フリーランス法を含む）で整理しています。

確認したい質問

  • これまでに、ゼロから作ったものは何か。その時どんな技術を選び、なぜそうしたか
  • 仕様が途中で大きく変わったとき、どう対応したか
  • 作らないと判断したものはあるか
  • 自分が抜けた後、他の人が引き継げるようにするために何をしたか

コードと発明の権利を会社に残す

最初のエンジニアが書くプログラムは、会社の最も重要な資産の一つになります。後の資金調達や事業売却の場面で、権利が会社にあることを説明できなければなりません。雇用か業務委託かで、法律上の扱いが異なります。

社員として雇う場合：職務著作

著作権法第15条第2項は、法人の発意に基づき、その法人の業務に従事する者が職務上作成するプログラムの著作物について、作成時の契約や勤務規則などに別段の定めがない限り、その法人を著作者とすると定めています。社員が職務として書いたプログラムは、原則として会社が著作者になるということです。

ただし、業務時間外に個人的に作っていたものを会社のサービスに組み込む場合など、境界があいまいになる場面があります。就業規則や雇用契約で、職務上作成したものの扱いを確認しておきます。

業務委託の場合：譲渡の契約が必要

業務委託で開発してもらう場合、職務著作の規定は通常あてはまらないため、著作権は原則として作成した本人に残ります。会社が権利を持つには、契約で著作権を譲り受ける必要があります。

このとき注意したいのが著作権法第61条第2項です。著作権を譲渡する契約で、第27条（翻訳権・翻案権など）と第28条（二次的著作物の利用に関する原著作者の権利）に規定する権利が譲渡の対象として特に明記されていないときは、これらの権利は譲渡した側に残ると推定されます。プログラムは改変を重ねて使うものなので、契約書では「著作権法第27条及び第28条に規定する権利を含む」と明記します。著作者人格権を行使しない旨の条項も、あわせて検討されることが一般的です。

なお、個人に業務委託する場合、フリーランス・事業者間取引適正化等法により、給付の内容などの取引条件を明示する義務があります。厚生労働省の資料では、フリーランスの知的財産権が発生する場合に、業務委託の目的である使用の範囲を超えて譲渡・許諾させるときは、その範囲を明確に記載し、その対価を報酬に加える必要があるとされています。

発明が生まれる場合：職務発明

技術的な発明が生まれる可能性がある場合は、特許法第35条の職務発明の規定も確認します。同条第3項は、従業者がした職務発明について、契約や勤務規則などであらかじめ使用者に特許を受ける権利を取得させることを定めたときは、その権利は発生した時から使用者に帰属すると定めています。職務発明規程を用意していない創業期の会社は、最初のエンジニアを迎える前に整備しておくと安心です。この場合、同条第4項により、従業者は相当の金銭その他の経済上の利益（相当の利益）を受ける権利を持つため、規程ではその内容の決め方も定めます。

条件の提示

条件を提示するときは、求人の段階から労働条件を正確に示す必要があります。職業安定法に基づく明示事項は新規事業人材の求人票の書き方で整理しています。現金報酬を抑えてストックオプションを組み合わせる場合は、付与の時期や退職時の扱いを説明できるようにしておきます。

最初のエンジニアは、その後のエンジニア採用で「この人と働きたい」と思ってもらえるかどうかも左右します。採用の担当や技術の方針決めにどこまで関わってもらうかも、入社前に話しておきます。

まとめ

最初のエンジニアの採用では、共同創業者か社員かを決め、今後半年で作るものから必要な力を逆算し、実際の課題で一緒に働いて見極めます。そして、書いたコードや発明の権利が会社に残るよう、雇用なら就業規則や職務発明規程、業務委託なら第27条・第28条の権利を含めた譲渡条項を、仕事を始める前に整えておきます。

法令は改正されます。契約の前に公式情報を確認し、弁護士や社会保険労務士などの専門家に相談してください。

参考資料

進め方に迷ったら、相談してください

起業家ポータル のメンバーが話を伺います。初回の相談は無料です。

相談する

同じ工程の記事