「アイデアがある、でも自分では作れない」——そう思ってエンジニアを無報酬で募集しようとする非エンジニア創業者は後を絶たない。実際によく見かける募集パターンをもとに、よくある失敗の構造と正しい動き方を整理する。
よくある募集の典型例
こんな募集を見かけたことはないだろうか。
「画期的なサービスを考えている。一緒に作ってくれるエンジニアを探している。今は報酬を出せないが、将来の利益は折半する。共同創業者として迎えたい」
善意からの呼びかけであることは疑わない。熱量も本物だろう。しかしこの数行には、非エンジニア創業者が陥りがちな問題がほぼすべて凝縮されている。
こうした募集に対してエンジニア側からよく返ってくる反応はこうだ。「アイデアへの確信はわかった。でも私が差し出すのは数百時間の専門技術労働であり、その期間の機会費用だ。それに見合うリターンが見えない」。
この指摘を「エンジニアが冷たい」と受け取るか、「自分の設計に問題がある」と受け取るかで、その後の動き方が大きく変わる。以下、具体的な落とし穴を順番に見ていく。
① アイデアの価値を過大評価している
スタートアップの世界では「アイデアはただの出発点」という認識が共通認識だ。価値を生むのはアイデアそのものではなく、実行・検証・改善のサイクルである。
にもかかわらず、「このアイデアには将来大きな価値がある」という確信を、エンジニアへの報酬の代替にしようとする人がいる。確信はエンジニアの家賃を払わない。確信は生活費を補填しない。確信はキャリアリスクを肩代わりしない。
また「表面的な仕組みを模倣されても、思想や設計までは真似できない」という主張をする人もいる。一定の正しさはある。しかしその論理が成立するのは、実装・展開のスピードが伴っている場合に限る。アイデアを守ることよりも先に、アイデアを動くプロダクトにする必要がある。思想を守りたいなら、まず形にすることだ。
さらに言えば、アイデアは誰でも思いつく。似たようなアイデアを持っている人間は、今この瞬間にも世界中に複数いる。差がつくのはアイデアの独自性ではなく、誰が先に・どう実行したかだ。
② エンジニアの工数コストを理解していない
これが最も根本的な問題だ。
月80時間稼働・時給5,000円という控えめな試算でも、1〜2年活動すれば480〜960万円相当の労働になる。これはあくまで最低ラインであり、設計・実装・テスト・インフラ構築を一人でこなすシニアエンジニアなら、同期間に他で稼げる額はさらに大きくなる。
つまり「無報酬で参加してください」という呼びかけは、実態として「数百〜1,000万円規模の労働を無償で提供してください」と同義だ。これを「共同創業者として迎える」という言葉でくるんでも、経済的な構造は変わらない。
エンジニアはこの計算を瞬時にする。だから反応が鈍い。冷たいのではなく、合理的に判断しているだけだ。
もう一点、非エンジニアが見落としがちなのは「機会費用」という概念だ。エンジニアにとって、あなたのプロジェクトに費やす時間は「他の選択肢を捨てる時間」でもある。転職・副業・自分のプロダクト開発・スキルアップ——それらをすべて後回しにして、見返りが不明確なプロジェクトに数百時間を投じることを求めているのだと自覚する必要がある。
③ 「契約・法的整備」で解決しようとする
アイデアへの不安から、NDAや身分証確認を持ち出す起業志望者がいる。「アイデアを守るために法的な整備をする」という発想自体は悪くない。しかしそれをエンジニア募集の文脈でまず持ち出すのは、論点がずれている。
エンジニアが懸念しているのは「アイデアを盗まれること」ではなく、「自分の時間と労働力が搾取されること」だ。NDAはその問題を一切解決しない。
むしろ、対価の提示なしに法的拘束力だけを強化しようとする姿勢は、相手からすると「縛ろうとしている」と映る可能性がある。信頼を得たいなら、契約の前に「相手にとって合理的な条件」を提示することが先だ。
エンジニアにとって必要なのは、「この人と組むことが自分にとってプラスになるか」という経済的・職業的な合理性だ。その合理性を示せないまま法的な書類を積み上げても、パートナーシップの質は上がらない。
④ リスクの非対称性に気づいていない
事業が失敗した場合を冷静に考えてみる。
アイデアを出した側が失うもの——構想に費やした時間と、おそらくは副業的な範囲での労力。 エンジニアが失うもの——数百〜千時間の専門技術労働、その期間の機会費用、場合によってはキャリアの一部。
「5:5の利益分配」は利益が出た場合にのみ意味を持つ。失敗すれば、エンジニアが投じた時間は戻ってこない。にもかかわらず、リスクの大きさはエンジニア側が圧倒的に重い。
この非対称な構造を相手に提示することは、意図せずとも「あなたが損をするリスクを引き受けてください」と言っているに等しい。それを「夢への共感」や「将来のリターンへの期待」でカバーしようとしても、合理的な判断をするエンジニアには通じない。
誠実な起業家であれば、この非対称性を自覚した上で「では自分は何を差し出せるか」を先に考えるべきだ。
⑤ 「熱意」で論理的判断を代替している
「確信がある」「絶対に形にしてみせる」「根気強く探し続ける」——こうした言葉は意欲として尊重できる。しかし熱意は、論理的な問題への反論にはならない。
よくあるパターンはこうだ。問題点を指摘される→「おっしゃる通りです、重く受け止めます」と返す→しかし内容は変わらない→また次の指摘が来る→また感謝する——このループを繰り返す。
これは問題を直視しているのではなく、熱意と誠実さのポーズで場をやり過ごしている状態だ。指摘を受けた後に「では条件のどこを変えるか」「自分が今できることは何か」という具体的なアクションが伴わなければ、誠実さは機能しない。
良い創業者は、反対意見や現実的な指摘を受けたとき「なぜそう言われているか」を構造的に理解し、自分の設計を修正できる。感謝だけでは何も変わらない。
⑥ 共同創業者の合意設計が甘い
「気軽に声をかけてください」でパートナーを募集する前に、最低限以下の点を自分の中で整理し、相手に提示できる状態にしておく必要がある。
役割と稼働について ・自分はどの領域を担うのか（事業企画・ユーザーリサーチ・営業・資金調達など） ・エンジニアに期待する稼働量（週何時間か）の目安
リターンの設計について ・持分の形態は何か（株式・ストックオプション・レベニューシェアなど） ・法人化のタイミングと計画
知的財産について ・開発したコードやアーキテクチャの権利はどこに帰属するか ・プロジェクト解散時、エンジニアが書いたコードの利用権はどうなるか
撤退・離脱条件について ・どちらかが途中で離脱する場合のルール ・離脱時、それまでの貢献に対する持分や補償の考え方 ・プロジェクト中止を判断する基準とタイミング
これらを曖昧なまま進めることは、後の紛争の温床になる。スタートアップの失敗原因として「共同創業者間のトラブル」が上位に来ることは、世界中の事例が示している。熱量が高い初期ほど、合意の甘さが後で大きな問題として表面化する。
「まず話してみてから決めましょう」という姿勢は柔軟に見えるが、判断材料を持たずに相手を巻き込もうとしているとも言える。エンジニアが上記のような質問を事前にしてきたとき、明確に答えられない状態で募集を出しているとすれば、準備が足りていない。
⑦ ノーコード・MVP検証を飛ばしている
「自分はエンジニアではないから、プロダクトを作ることができない」——この言葉を免罪符にしている起業志望者は多い。しかし2020年代において、これはもはや言い訳にならない。
今の時代、エンジニアリングの知識がなくても動く画面や簡易的な仕組みを作るツールは豊富にある。
プロトタイプ・デザインの段階であればFigmaを使えば、実際に画面遷移するデモを作ることができる。簡単なフォームやデータベースを使ったMVPであれば、NotionやGoogleフォーム、あるいはBubble・Glide・STUDIOといったノーコードツールで実装できる。ランディングページなら数時間で公開できる。
こうした手段を使って「市場の反応」という数字を先に出すことが、エンジニアへの最大の説得材料になる。「このアイデアへの確信があります」より「100人にプロトタイプを見せたところ、30人が使いたいと言いました」の方が、圧倒的に説得力がある。
エンジニアに「一緒に作ってほしい」と言う前に、自分でできる検証を最大限やり切ることが先だ。その過程で「やはり需要がなかった」とわかれば、エンジニアの貴重な時間を無駄にせずに済む。逆に手応えがあれば、それが資金調達や有償での依頼につながる根拠になる。
では、どうすればよかったか
落とし穴を整理してきたが、「非エンジニアには起業できない」と言いたいわけではない。ビジネス・マーケティング・ユーザーリサーチの観点で強みを持つ非エンジニア創業者は多く、それ自体は大きな武器になる。問題は順序と構造だ。
正しい動き方を整理すると、おおよそ以下の順序になる。
ステップ1：自分でできる範囲でMVPを作る ノーコードツールやプロトタイプで、動く形にする。完成度は問わない。「見せられるもの」があるかどうかが重要だ。
ステップ2：ユーザーインタビューで仮説を検証する 「こういうサービスがあったら使いますか？」という質問では意味がない。実際のユーザーが抱える課題や意思決定の場面を10〜20人から丁寧に聞き取り、ニーズの実在を確認する。
ステップ3：数字が出てから人を巻き込む 登録者数・インタビュー結果・ユーザーの声という「証拠」があって初めて、エンジニアに「一緒にやりましょう」と言える土台ができる。この順序を逆にしないことが重要だ。
ステップ4：資金調達または有償契約を検討する 事業への確信があるなら、その確信をもとに投資家やエンジェルから資金を調達し、エンジニアに正当な対価を払う構造を目指す。「確信があるから無報酬で手伝ってほしい」ではなく、「確信があるから資金を集めて対価を払う」——これが本当の意味でリスクをとっている姿だ。
ステップ5：合意事項を文書化してから動く 役割・持分・離脱条件・知的財産の帰属を明文化した上でパートナーシップを組む。この手間を惜しんだことで後に大きなトラブルになるケースは非常に多い。
おわりに
「自分が作れないから誰かに作ってもらう」という発想のまま、相手のコストを考えずに動いてしまうことが問題の本質だ。
エンジニアは「あなたの夢のために無償で投資してくれる人」ではない。対等なビジネスパートナーとして迎えるなら、相手が「なぜYESと言うのか」を合理的に説明できる状態を先に作ることが、起業家としての最初の仕事だ。
熱意は必要条件だが、十分条件ではない。熱意の上に、相手の立場に立った設計と具体的な行動を積み重ねることで、初めて人は動く。
コメント