「アイデアはある。でも自分では作れない。どこから始めればいいのか」
非エンジニアとして起業を考えたとき、多くの人が最初にぶつかる壁だ。
エンジニアでないことは、起業において致命的な欠点ではない。ビジネスの構想力・ユーザーへの共感力・営業や交渉の力は、技術とは別の、事業を成立させる上で不可欠な能力だ。しかしその強みを活かすには、正しい順序で動く必要がある。
この記事では、技術を持たない起業志望者が最初の仲間を集めるフェーズまでに何をすべきかを具体的に整理する。
「アイデア」は出発点に過ぎない
非エンジニアが起業を考えるとき、手元にあるのはほとんどの場合「アイデア」だけだ。そしてそのアイデアへの確信が強いほど、「早く形にしたい」「誰かに作ってもらいたい」という焦りが生まれる。
しかしここで急いではいけない。
スタートアップの世界では、アイデアそのものの価値は限りなく低いとされている。似たようなアイデアを持っている人間は、今この瞬間にも世界中に複数いる。差がつくのはアイデアの独自性ではなく、誰が・どう実行したかだ。
つまりエンジニアを探す前に、アイデアを「実行できる状態」に育てることが先決だ。その状態とは何か。「誰のどんな課題を解くのか」が具体的に言語化されており、「需要が実在する証拠」が手元にある状態のことだ。この二つが揃って初めて、エンジニアに「一緒にやりませんか」と声をかける資格が生まれる。
ステップ1：解くべき課題を一つに絞る
最初にやるべきことはプロダクトの仕様を考えることではない。「誰が・何に・なぜ困っているか」を一つに絞ることだ。
課題の見つけ方として最も有効なのは、自分自身の体験を掘り下げることだ。「なぜこれはこんなに不便なのか」「なぜこの作業をいまだに手動でやっているのか」という疑問は、課題の入り口になる。あるいは身近な
家族・友人・前職の同僚が日常的に抱えている非効率を観察することも有効だ。
ここで重要なのは、その課題が「自分だけが感じていること」ではなく「同じように困っている人が一定数いること」を確認することだ。この確認を怠ると、需要のないプロダクトをエンジニアに作らせるという最悪のパターンに陥る。
また、課題は広く設定しすぎないことが重要だ。「意思決定を支援する」「情報格差をなくす」といった大きな課題設定は聞こえがいいが、具体性がなさすぎて検証できない。「30代の共働き夫婦が週末の食材購入で毎回30分以上迷っている」くらいの粒度まで絞り込むことで、次のステップに進める。
ステップ2：作る前にユーザーに話を聞く
課題の仮説が立ったら、すぐにプロダクトを考え始めてはいけない。まずターゲットとなるユーザーに直接話を聞く。
このステップを飛ばして「エンジニアを探しながら並行してヒアリングする」という動き方をする人がいるが、順序としては誤りだ。ヒアリングの結果によってプロダクトの方向性が大きく変わることがあるため、エンジニアを巻き込む前に仮説の精度を上げておく必要がある。
インタビューで避けるべき質問がある。「こういうサービスがあったら使いますか？」だ。この質問は相手が「使います」と答えやすい構造になっており、実際の需要を測れない。
代わりに使うべき質問はこうだ。
- 「今その問題にどう対処していますか？」
- 「それを解決するために過去にお金を払ったことはありますか？」
- 「一番困る瞬間はどんなときですか？」
現在の行動と過去の事実を引き出す質問をすることで、本物の需要と表面的な興味を区別できる。
10〜15人に話を聞けば、一定のパターンが見えてくる。そのパターンが自分の仮説と一致していれば次に進む。大きくズレていれば仮説を修正する。このサイクルをプロダクトを作る前に回すことが、後の大きな手戻りを防ぐ。
ステップ3：自分でできる範囲で「見せられるもの」を作る
ユーザーインタビューで手応えが得られたら、プロダクトの原型を自分の手で作る。
「自分はエンジニアではないから作れない」と思う人が多いが、今の時代においてこれは言い訳にならない。完成したプロダクトを作る必要はない。「見せて、反応をもらえる状態」にすることが目標だ。
使えるツールはいくつかある。
Figmaはデザインツールだが、画面遷移を再現したプロトタイプを作ることができる。コードは一切不要で、クリックして動くデモを数時間で作れる。ユーザーに「実際に触ってもらう」体験を提供できるため、フィードバックの質が上がる。
Googleフォームとスプレッドシートの組み合わせは、情報収集・マッチング・申し込み受付といった機能を疑似的に再現できる。見た目はシンプルだが、「需要があるかどうか」を検証するには十分だ。
Notionはページとデータベースを組み合わせることで、簡易的なサービスのように見せることができる。特にBtoB向けのサービスであれば、Notionで作ったものを「ベータ版」として見せることも現実的だ。
Bubble・Glide・STUDIOといったノーコードツールは、より本格的な画面と機能を持つプロダクトをコードなしで作れる。学習コストはあるが、YouTubeなどで日本語の解説動画も多く公開されている。
完成度よりスピードを優先する。粗くても動くものを2週間以内に作ることを目標にする。
ステップ4：最初の10人に使ってもらう
見せられるものができたら、すぐに広く公開するのではなく、まず知り合いに直接声をかけて使ってもらう。
見知らぬユーザーは一度悪い体験をすると二度と戻ってこない。しかし知り合いは荒削りなプロダクトにも付き合ってくれるし、率直なフィードバックをくれる。この段階では量より質を優先する。
使ってもらった後に必ず聞くべきことは三つだ。
- 「使っていて一番困った場面はどこですか？」
- 「これを使い続けるとしたら、何があれば使い続けますか？」
- 「同じ課題を抱えていそうな人を一人紹介してもらえますか？」
最後の質問が重要だ。この紹介の連鎖で10人を目指す。紹介してもらえるということは、それ自体がプロダクトへの一定の評価を意味する。
10人のアクティブユーザーを獲得できたプロダクトは、0人のプロダクトとは全く異なる説得力を持つ。この差はエンジニアに対してだけでなく、将来的な投資家や採用候補者に対しても同様だ。
ステップ5：手元の事実を言語化する
10人のユーザーが集まり、フィードバックが蓄積されてきたら、その状況を言葉と数字で整理する。これが仲間を集めるフェーズの直前に必ずやっておくべき準備だ。
整理すべき内容は以下の四点だ。
課題について 誰の・どんな課題を解いているか。その課題がどれだけ切実か。代替手段はあるか、あるとしたらなぜ不十分か。
プロダクトについて 今何ができるか。今後何を作ろうとしているか。技術的な詳細は不要で、ユーザー視点で「何が解決されるか」を説明できれば十分だ。
ユーザーについて 何人が使っているか。継続して使っているか。どんな反応が得られているか。可能であれば具体的なコメントを引用できると強い。
自分について なぜ自分がこれをやるのか。どんなバックグラウンドを持っているか。どれだけの時間をこのプロジェクトに使えるか。
この四点が明確になっていれば、仲間を集める場面での説得力が格段に上がる。逆に言えば、これが言語化できていない状態で「一緒にやりませんか」と声をかけても、相手は判断材料がなくて困る。
ステップ6：仲間を集める
ここまで来て初めて、最初の仲間『特に共同創業エンジニア』を集めるフェーズに入る。
どこで探すか
最も効果的なのは、すでに接点のあるコミュニティの中から探すことだ。スタートアップ系の勉強会・ハッカソン・オンラインコミュニティ・前職の同僚・大学時代の知人など、すでに一定の信頼関係がある人間の中から探す方が、見知らぬ人を公募するより圧倒的にうまくいきやすい。
Xやnoteでプロジェクトのことをこまめに発信し続けることも有効だ。「こんな課題を解こうとしている」「こんな反応があった」という発信を続けることで、同じ問題意識を持つ人間が引き寄せられてくる。開発の過程をオープンに発信するこのアプローチは、仲間と初期ユーザーを同時に集める効果がある。
何を伝えるか
声をかける際に伝えるべき内容はシンプルだ。
- 誰のどんな課題を解こうとしているか
- すでに何人が使っていて、どんな反応が出ているか
- 自分はどんな役割を担っていて、相手に何を期待するか
- リターンの設計（持分・役割・離脱した場合の条件）
ステップ5で整理した内容がそのまま使える。数字と事実を示せれば、「アイデアだけの募集」との差は一目瞭然だ。
条件の設計について
報酬を出せない段階で仲間を集める場合、持分の設計が非常に重要になる。曖昧なまま「将来折半しましょう」で進めることは後のトラブルの主因になる。
最低限決めておくべき事項は以下だ。
- 持分の比率と付与の条件
- どちらかが離脱した場合のルール
- 開発したプロダクトの知的財産権の帰属先
- プロジェクト中止を判断する基準とタイミング
これらを曖昧にしたまま進めることは、どれだけ良い関係であっても後で必ず問題になる。スタートアップに詳しい弁護士や司法書士に一度相談した上で、最低限の取り決めを文書化しておくことを強く勧める。費用を惜しんでここを飛ばした結果として、後に取り返しのつかない損害が生じたケースは少なくない。
順序が全て
非エンジニアが起業して最初の仲間を集めるまでのプロセスを整理すると、以下の順序になる。
- 解くべき課題を一つに絞る
- 作る前にユーザーに話を聞く
- 自分でできる範囲で「見せられるもの」を作る
- 最初の10人に使ってもらう
- 手元の事実を言語化する
- 仲間を集める
この順序を守ることが全てだ。多くの失敗は、この順序を飛ばしたり逆にしたりすることで起きる。特に「エンジニアを探すこと」を最初のステップにしてしまう人が多いが、それは最後のステップだ。
エンジニアに「一緒にやりましょう」と声をかけるとき、相手が「なぜYESと言うのか」を合理的に説明できる状態を先に作ること、それが非エンジニア起業家の最初の仕事だ。
コメント