「とりあえず知り合いのエンジニアに頼む」が、スタートアップ最大の失敗である理由
「知り合いにエンジニアがいるから、ちょっと頼んでみよう」—— その判断が命取りに
「ちょうど友達にエンジニアがいるから、安くやってもらえそう」
「知り合いなら、こちらの要望もわかってくれるはず」
「まずは知り合いに頼んで、うまくいったら本格的に開発会社を探そう」
スタートアップを始めようとする非エンジニアの創業者から、この言葉を何度聞いたことでしょう。
気持ちは痛いほどわかります。開発の相場もわからない。どんなエンジニアが優秀なのかもわからない。そんな中で、「知り合いのエンジニア」は最も手を伸ばしやすい選択肢に見えます。
しかし断言します。
「とりあえず知り合いに頼む」という判断は、スタートアップ失敗の最大の原因の一つです。
私たちは、この選択をして後悔した創業者を、数えきれないほど見てきました。
- 半年かけて作ったMVPが、技術的に破綻していて作り直し
- 「友達価格」のはずが、結局300万円以上かかった
- 開発が遅延し続け、友人関係も崩壊
- コードの品質が低すぎて、他のエンジニアが引き継げない
これらは決して珍しいケースではありません。むしろ、「知り合いへの依頼」の典型的な結末です。
なぜ「知り合い」に頼んでしまうのか —— その心理を理解する
批判する前に、まずは「なぜ知り合いに頼みたくなるのか」を理解しましょう。
私自身、建築の世界から技術の世界に入ったとき、同じ気持ちを抱えていました。
- 開発会社は怖い：専門用語を並べられて、言いなりになりそう
- 相場がわからない：100万円が安いのか高いのか判断できない
- 騙されそう：必要ない機能を押し付けられそう
- 知り合いなら安心：少なくとも悪意はないはず
この心理は完全に理解できます。未知の領域に飛び込むとき、「知っている人」に頼りたくなるのは人間として自然なことです。
しかし、この「安心感」こそが最大の罠なのです。
知り合いだからといって、その人があなたのビジネスに最適なエンジニアとは限りません。むしろ、知り合いという関係性が、ビジネスとして健全な判断を曇らせてしまうのです。
この記事でわかること：知り合いへの依頼が失敗する構造と、正しい選択肢
知り合いエンジニアへの依頼が失敗する理由
この記事では、以下のことをお伝えします。
- なぜ「知り合いへの依頼」が構造的に失敗するのか：5つの致命的なリスク
- 実際に起きた失敗事例：300万円と1年を無駄にしたケース
- 正しいエンジニア選びの基準：プロに依頼すべき理由
- 今日からできる具体的なアクション：失敗を回避する方法
「知り合いに頼もうかな」と思っているあなたに、この記事が踏みとどまるきっかけになれば幸いです。
「知り合いエンジニア」への依頼が失敗する5つの理由
理由1：スキルセットのミスマッチ
「エンジニア」と一口に言っても、その専門領域は多岐にわたります。
- フロントエンド（見た目・UI）
- バックエンド（サーバー・データベース）
- インフラ（サーバー構築・運用）
- モバイル（iOS / Android）
- 機械学習・AI
あなたの知り合いのエンジニアは、何が専門ですか？
多くの場合、「Webアプリを作りたい」という要望に対して、「実はゲーム開発が専門」「普段は社内システムの保守をしている」といったミスマッチが起きます。
プログラミングができる＝なんでも作れる、ではありません。
料理人に例えるなら、「フレンチのシェフに和食を頼む」ようなものです。できなくはないかもしれませんが、本業の和食料理人には到底かないません。
しかし、非エンジニアの創業者には、このミスマッチを見抜くことができません。そして知り合いのエンジニアも、「できません」とは言いづらい。結果、中途半端な成果物ができあがります。
理由2：本業との両立問題
知り合いのエンジニアには、当然ながら本業があります。
「空いた時間でやるから」という約束は、ほぼ確実に守られません。
- 本業が忙しくなれば、あなたの案件は後回し
- 週末にやると言っていたのに、プライベートの予定が入る
- 進捗報告がなく、何週間も音信不通に
そしてあなたは、「友達だから催促しづらい」という状況に陥ります。
プロの開発者や開発会社であれば、契約に基づいて進捗を管理できます。遅延があれば契約違反として指摘できます。しかし知り合いへの依頼では、この「ビジネスとしての緊張感」が完全に欠如します。
結果、当初3ヶ月の予定が半年、1年と延び続けるケースが後を絶ちません。
理由3：要件定義の甘さ
プロの開発者や開発会社は、まず「何を作るか」を明確にする要件定義のプロセスを踏みます。
- ユーザーは誰か
- どんな機能が必要か
- 優先順位はどうか
- 予算と期間は
この工程を経ることで、開発中のスコープクリープ（要件の肥大化）を防ぎ、認識の齟齬を減らせます。
しかし知り合いへの依頼では、この工程がほぼ省略されます。
「だいたいこんな感じで」「あとはよろしく」「やりながら決めよう」
こんなふわっとした依頼が通ってしまうのです。
その結果、開発が進むにつれて「思っていたのと違う」が頻発。修正の修正が重なり、時間もコストも際限なく膨らんでいきます。
理由4：技術的負債の蓄積
「技術的負債」という言葉をご存知ですか？
これは、短期的な解決策を選んだ結果、将来的に払わなければならない「ツケ」のことです。
- 急いで書いた汚いコード → 後から修正が困難に
- テストを書かない → バグが発見しづらい
- ドキュメントがない → 他の人が理解できない
- 古い技術を使う → 将来のメンテナンスが困難
知り合いのエンジニアは、多くの場合「とりあえず動くもの」を作ることを優先します。プロとしての品質基準や、将来のメンテナンス性を考慮する余裕がありません。
結果として、MVPは完成したものの：
- バグだらけで使い物にならない
- 機能追加しようとすると全体が壊れる
- 他のエンジニアに見せたら「作り直した方が早い」と言われる
こんな事態に陥ります。
「友達価格で50万円で作ってもらったけど、作り直しに300万円かかった」
これは珍しくないパターンです。
理由5：関係性の崩壊
そして最も悲しいのが、友人関係・知人関係の崩壊です。
- 進捗の遅れに苛立つあなた
- 「タダ同然でやってるのに」と不満を抱えるエンジニア
- お互いに言いたいことが言えない微妙な空気
- 最終的に連絡を取らなくなる
ビジネスの失敗だけでなく、大切な人間関係まで失う。これが「知り合いへの依頼」の最悪のシナリオです。
お金は取り戻せても、壊れた関係は簡単には修復できません。
実際に起きた失敗事例：300万円と1年を失ったAさんの話
具体的な事例をお話しします（ご本人の了承を得て、一部改変しています）。
Aさんは、飲食業界向けのマッチングアプリを作ろうとしていました。大学時代の友人Bさんがエンジニアだったため、「とりあえず相談してみよう」と声をかけました。
最初の約束
- 期間：3ヶ月
- 費用：友達価格で80万円
- 範囲：MVP（最小限の機能）
Bさんは「余裕だよ」と快諾。Aさんは安心しました。
3ヶ月後 進捗は50%程度。Bさんの本業が繁忙期に入り、ほとんど手がつけられていませんでした。
「あと2ヶ月あればできる」とBさん。Aさんは待つことにしました。
6ヶ月後 ようやく「完成した」と連絡が。しかし、実際に触ってみると：
- 動作が極端に遅い
- エラーが頻発する
- 当初の要件と違う機能がある（勝手に解釈された）
- スマホで見ると表示が崩れる
Aさんは修正を依頼しましたが、Bさんは「そこまでは聞いていない」「追加費用がかかる」と主張。
9ヶ月後 追加で50万円を払い、修正を依頼。しかし、根本的な問題は解決せず、むしろ新しいバグが増える状況に。
Aさんは限界を感じ、別の開発会社に相談しました。
開発会社の診断 「このコードは構造的に問題があり、修正するより作り直した方が早いです。見積もりは250万円、期間は4ヶ月です」
結果
- 総額：80万円 + 50万円 + 250万円 = 380万円
- 期間：9ヶ月 + 4ヶ月 = 13ヶ月
- さらに、Bさんとは気まずくなり、連絡を取ることもなくなった
もし最初から適切な開発会社に依頼していれば、250万円・4ヶ月で済んだ案件です。
「友達価格」の80万円を節約しようとした結果、130万円と9ヶ月を余分に失った計算になります。
正しいエンジニア選びのステップ
正しいエンジニア選びの3つの基準
では、どうすれば失敗を避けられるのでしょうか？
基準1：実績とポートフォリオを確認する
「エンジニアです」という自己申告だけでは不十分です。
- 過去に作ったプロダクトを見せてもらう
- どんな技術を使ったか説明してもらう
- 可能であれば、過去のクライアントに話を聞く
知り合いへの依頼でこれをやると、「信用してないの？」という空気になりがちです。しかしプロであれば、当然のプロセスとして受け入れてくれます。
基準2：契約と要件を明確にする
口約束は禁物です。
- 契約書を交わす
- 要件定義書を作成する
- マイルストーンと支払い条件を明確にする
- 遅延時の対応を決めておく
「友達だから契約なんて」と思うかもしれません。しかし、契約があるからこそ、お互いの期待値が揃い、トラブルを防げるのです。
基準3：技術力を客観的に評価する
これが最も難しいポイントです。非エンジニアが、エンジニアの技術力を評価するのは至難の業です。
だからこそ、第三者の目が必要になります。
- 技術顧問を入れて、コードレビューをしてもらう
- 複数のエンジニアに意見を聞く
- 技術力を評価できる人に面接に同席してもらう
この「技術の目利き」がいるかいないかで、結果は大きく変わります。
私たちatelier binaryでは、まさにこの「技術の目利き」として、非エンジニア起業家をサポートしています。開発会社の見積もり精査、エンジニアの技術力評価、プロダクト設計のレビューなど、「技術がわからない」ことで不利な立場に立たされないよう、あなたの側に立って判断をお手伝いします。
こんな方に、この記事を届けたい
- 「知り合いにエンジニアがいるから頼もうかな」と考えている方
- すでに知り合いに依頼して、うまくいっていない方
- 開発の相場感がわからず、判断に困っている方
- エンジニアの技術力を評価する方法がわからない方
- MVP開発で失敗したくない方
「知り合いだから大丈夫」という考えは、今すぐ捨ててください。
ビジネスはビジネスです。友人関係と混同すると、両方を失います。
適切な距離感で、適切なプロに依頼する。それが、最も確実に、最も安く、最も早く、目的を達成する方法です。
まとめ：「安く済ませたい」が最も高くつく
知り合いエンジニアへの依頼を避けるべき理由まとめ
「知り合いに頼めば安く済む」
この発想が、結果的に最も高くつきます。
- スキルミスマッチによる作り直し
- 本業優先による遅延
- 要件定義の甘さによるスコープクリープ
- 技術的負債による将来のコスト増
- 人間関係の崩壊
これらのリスクを考えると、最初からプロに依頼する方が、トータルでは安く、早く、確実です。
今日からできるアクション：
- 知り合いへの依頼を一旦保留する：感情ではなく、ビジネスとして判断する
- 複数の開発会社から見積もりを取る：相場観を養う
- 技術の目利きを見つける：判断を任せられるパートナーを探す
「技術がわからない」ことは、決して恥ずかしいことではありません。
しかし、「わからないまま、なんとなくで判断する」ことは、取り返しのつかない失敗につながります。
わからないなら、わかる人を味方につける。それが最も賢い選択です。
技術のことで悩んでいるなら、まずは相談してみませんか？
私たちatelier binaryは、「技術がわからないことで挑戦を諦める起業家をゼロにする」というビジョンのもと、非エンジニア起業家の技術参謀を務めています。
- 知り合いのエンジニアに頼むべきか判断したい
- 開発会社の見積もりが適正か確認したい
- そもそも何から始めればいいかわからない
こんな悩みがあれば、初回相談は無料でお受けしています。
