MVPを内製するときの注意点

社内のエンジニアや担当者がMVPを作る内製は、スピードとコストの面で魅力的に見えます。しかし、規模が大きくなったときに外注へ引き継ぐことが難しくなるリスクがあります。

内製MVPのメリット

スピードが出やすい：外部への依頼・調整・発注のプロセスが不要で、思い立ったらすぐ動けます。小さな修正もすぐに反映できます。

業務知識がそのまま活かせる：社内の担当者が作るため、業務の細かい要件や現場の事情を理解した上で設計できます。外部に一から説明するコストがかかりません。

コストが抑えられる：外注費が発生しないため、初期コストは低くなります。

担当者への負荷集中

内製MVPは多くの場合、特定の担当者1〜2人が中心になって開発を進めます。最初は小規模で問題なくても、機能が増え・ユーザーが増えると対応量が増加します。

本来の業務と並行してシステムの開発・保守・問い合わせ対応を続けると、担当者の負荷は想定以上に大きくなります。「少し手伝うつもりが、いつのまにかメインの仕事になっていた」という状況はよく起きます。

引き継ぎが難しくなる

内製で作ったシステムは、ドキュメントが整っていないことが多いです。「作った担当者が全部把握している」状態になりやすく、その担当者が異動・退職した場合や、外注に切り替えようとした場合に、引き継ぎが困難になります。

外注会社にコードを渡しても、「設計の経緯がわからない」「なぜこういう実装になっているかが不明」という状態では、継続開発の見積もりが高くなり、引き受けを断られるケースもあります。

品質のばらつき

内製担当者のスキル・経験によって、コードの品質・セキュリティ対策・パフォーマンスへの配慮にばらつきが出ます。MVPの段階では許容できても、本番運用として本格展開するタイミングで問題が表面化することがあります。

「内製で始めて、規模が大きくなったら外注に切り替える」という計画を持つケースがありますが、これは現実には難しいです。

他社が作ったコードをそのまま引き継いで継続開発を行う会社は、ほとんどありません。引き受けたとしても「現状のコードは使わず、改めて要件を整理した上で作り直し」を提案されるケースが大半です。つまり、内製で積み上げた資産はほぼ活かせません。

引き取りを断られる理由は、コードの可読性や設計の問題だけではありません。「誰がどういう意図で作ったかわからないシステムに責任を持てない」という判断もあります。外注会社にとって、他者が作ったシステムの継続保守はリスクが大きく、受注するインセンティブが低いです。

担当者の負荷が限界に達しても、外注への切り替えが難しいとなると、選択肢は限られます。

担当者が限界まで対応し続ける：よくある結末ですが、担当者の離職リスクが上がります。

システムの利用をやめる：積み上げたデータや業務フローを捨てることになります。

作り直す：内製で作ったものをゼロベースで再開発します。内製の資産は使えず、最初からやり直しに近い状態になります。

どの選択肢も、内製を始める前に想定していなかったコストが発生します。

内製でMVPを作ること自体は合理的な選択です。ただし、最初から「この範囲・この規模まで」という上限を決めておくことが重要です。

上限を超えたときに「外注に引き継ぐ」ではなく、「新たにスクラッチ開発を発注する」という前提で計画する方が現実的です。内製MVPは「本番システムへの橋渡し」として使い、本番は改めて外注する、という位置づけで考えると、期待値のズレが生じにくくなります。