直近に何度か、「社内にエンジニアがいないので受託で新規プロダクトを作っていこうと思うんですけど、どう思いますか？」という相談を何度か受けたので書いてみる。

僕の回答は「ビジネスの難易度を圧倒的に上げる意思決定なのでやめたほうがいい」です。

なぜ受託開発でプロダクト開発は難しいのか

僕も過去に何度か受託開発の現場を見てきたし、実際に関わったこともある。その経験から言えるのは、受託開発と自社でのプロダクト開発は根本的に異なるということ。

受託開発にて受託側は納品したらゴールだが、発注側にとってはそこからがスタートになる。
この違いは想像以上に大きい。

インセンティブの問題

まず、受託開発会社は契約通りの機能を作ることにフォーカスする。それ以上でもそれ以下でもない。ユーザーフィードバックを受けて素早く改善したいと思っても、それは「追加開発」として別途見積もりが必要になる。

受託開発のエンジニアにとって、あなたのプロジェクトは数あるプロジェクトの一つでしかなくて、納品が完了したら次のプロジェクトに移るだけでより良いものを作ろうというインセンティブはほぼ存在しない。当たり障りなく文句を言われないように納品することが重要になってくる。

開発サイクルの問題

自社開発だと「ユーザーフィードバック → 修正 → リリース」という工程になるが
受託開発だと「ユーザーフィードバック → 見積 → 検討 → 修正 → リリース」というサイクルになる。
見積を取るためには要件を整理するコスト、見積書を作成するコストなども当然乗っかってくる。
不確実性が高い機能であればそのリスク部分の費用も乗せることになるので割高かつ納期も長くなりやすくなる

なにを作っていくのかが曖昧

「なにを作っていくか明確なので受託に発注する」と言っている方に
「このプロダクトはどんな人のどの課題を解決するものですか？」と聞いたり、細かい話を聞いていくとそこまで具象化できていないケースやユーザーに対しての解像度がそこまで高くないケースが非常に多いです。

解像度が高くないので顧客に刺さらなかったり、刺さったとしてもごく少数のユーザーにしか刺さらないのでスケーラビリティが低くなってしまったみたいな問題が発生します。
自社開発であればやっているうちに止めたり、巻き戻したりすることがやりやすいのですが受託開発ではそううまくはいきません。

実際に見てきた失敗パターン

僕が実際に見てきた失敗パターンをいくつか紹介してみます。
※具体的な会社名などは書けません

実例1：改修コストで身動きが取れなくなったケース

開発を受託に出し、MVPはなんとか完成したが、その後の改修が高額になりすぎて身動きが取れなくなった。
プロダクトの改善が進まず、プロダクト自体を畳むことになった。

実例2：受託会社に依存して意思決定できなくなったケース

受託開発会社に依存しすぎて、仕様的な意思決定や技術的な意思決定ができなくなっていた。「これは受託会社に聞かないとわからない」という状態が続き、スピード感のある開発ができなくなっていた。
結果、競合に機能面で追いつけなくなってユーザーも離れていった。

実例3：技術的負債で作り直すことになったケース

MVPを作り、クライアントを獲得できた。しかし自社開発に切り替えた際、大きな問題が発覚した。
独特なフレームワークが使われており、テストも書かれていなかった。
この技術的負債により開発速度は著しく低下し、エンジニア採用も困難になった。

運良く優秀なエンジニアを採用できたが、ほぼ作り直すことになり、結局3年以上を費やしてしまった。

受託開発の構造的な問題

実際に見てきたケースから、受託開発には以下のような構造的な問題があります。

受託開発会社は自社の得意な技術スタックを使いたがり、それがプロダクトにとって最適かどうかは二の次になりやすい。自動テストやCIなど継続的に改善するために必要なプラクティスが行われていないケースが多い。

さらに深刻なのは、将来的に社内エンジニアを採用したときに、その技術スタックで開発を続けられるかは考慮されないという点。技術スタックが固定化されているのと固定化されていないのだとエンジニアの採用難易度がまったく変わってくる。
また、技術的負債が積み上がった状態で開発してくれる優秀なエンジニアは非常に少ないと思ったほうがいい。（成果が出しづらい環境、認められない環境で誰がやりたいのかという話に近い）

どうすればいいのか

僕がお勧めするのは以下の3つのアプローチ

1. コードを書かずに仮説を検証する

例えば、LayerXの福島さんは「紙芝居を使ったヒアリング」から始めます。
と下記の記事で話しています。
※　「紙芝居」とは、サービス内容や流れが分かる絵面を切り取り、パワーポイントに当てはめた資料のこと。

SmartHRの宮田さんは「LP（ランディングページ）を作り事前登録数を稼ぐことでトラクションを実証することにした。」
と言っています。

つまり、プロダクトを作る前にニーズ検証できるならば検証するべきということであります。

必要のないプロダクトや必要のない機能を作る可能性を減らすことができます。
少なくとも作ったけどうまくいかなかったみたいなリスクを減らすことができます。

2. ノーコード・ローコードツールでMVPを作る

どうしても作らないといけないという話であれば、ノーコード・ローコードツールでMVPを作るというのも有力な手段の1つになります。
最近はノーコードツールも進化している。bolt.new、Bubbleなどを使えばかなり本格的なMVPが作れる。
まずはこれらのツールで仮説検証をしてから、本格的な開発に移るというのはどうでしょうか。

リモートHQではノーコードから始めたという話が下記のnoteに書いてあります。

最近は生成AIを使ってプロダクトを作りたいという話をされたりもするので Difyやn8nを利用してAIエージェントを作りながら検証するというのも良いと考えられると思います。

3. 自分でコードを書いてみる

Claude CodeやCursorなどを利用し、AIを使ってコードを書きながら実装していくという方法もあります。
僕自身はClaude Codeを使い倒していますがコードの保守性は置いておいて、非エンジニアでも基本的なプロダクト開発ができるようになってきていると思っています。
実際に運用するとなると難しいかもしれないですがプロトタイプ作成やMVP開発には十分使えます。
フルコミットでなくてもエンジニアの支援があれば充分、初期の本番運用に耐えられるようなものも作れるでしょう。

創業者が作ったものが技術的負債になってしまうという可能性は存在しますが優秀なエンジニアに副業などで継続的に相談に乗ってもらったり、手伝ってもらうことである程度抑えることは充分可能だと思います。

この記事を見て、困っているという話があるのであれば僕が話を聞いたり、僕の知っている優秀なエンジニアを紹介します。

まとめ

受託開発でプロダクトを作ることは、成功確率を極端に下げる施策になるかつ、短期的には楽に見えるが、長期的には大きな負債になるのでやめた方がいいです。

受託開発でプロダクトを作ってもビジネスとして成功しづらい、
例え、成功したとしてもその後、ビジネスを継続するのは圧倒的に難しくするので受託開発に依頼するということはビジネスの難易度を圧倒的に上げているという理解をしてほしい

受託開発は「作ってもらう」という発想ですが、プロダクト開発は「一緒に作る」という発想が必要です。この違いを理解した上で、最適な選択をしてほしいなと思います。

もしこの記事を読んで、プロダクト開発の進め方で困っているという方がいれば、僕が話を聞いたり、僕の知っている優秀なエンジニアを紹介することもできます。受託開発に頼る前に、まずは相談いただけると。

※受託開発が悪いという話ではなくて、受託をするべきところ、場面というのは存在するので要望あればnoteを書く予定

ご相談あれば問い合わせいただけると幸いです。