この記事で分かること
- 内製で技術選定を誤ると何が起きるか(自社の実例)
- 複数のAI導入を同時に進めることの実際のコスト
- 内製と外注、どちらを選ぶかの判断材料
この記事で分からないこと(正直に書く)
- 外注した場合の費用相場(本記事では扱わない)
- 業種ごとの内製・外注の比率の統計
内製で最初につまずいた所
自社は2026年9月、新規プロダクトの技術選定で、既存の本番構成を確認しないままローカル環境に固定される構成で実装を進めた(出所: 自社の運用記録、確認日2026-09-06)。この構成には欠陥があった。公開URLが無いと、想定していたKPI(利用開始から登録に至る件数)がそもそも測れないという事業要件を満たせなかったのである。
なぜ見落とされたか
見落としの原因は、技術選定を「何が最適か」という技術的な問いから始めたことにあった。自社の本番標準は既にクラウド基盤に統一されており、他の複数のプロジェクトも同種の構成で稼働していた。にもかかわらず、新規プロダクトの選定時にはその構成を確認せず、ゼロから最適解を検討してしまった。「ローカルで動く」ことを完成のように扱い、その成果物が誰にどう届くか(公開URL・計測・課金)という事業側の要件確認が後回しになっていた(出所: 自社の運用記録、確認日2026-09-06)。
どう直したか
指摘を受けて、既存の本番構成に合わせて実行基盤を移植した。移植に際しては、救えるものと失うものを分けて数えている。データベース部分は互換性があったためスキーマとSQLは無傷で移行でき、静的なフロント・仕様書・データ定義も無傷だった。失ったのは実行基盤の層だけであり、副産物として、従来2つの言語で二重実装していたロジックが1本化される効果もあった(出所: 自社の運用記録、確認日2026-09-06)。新規プロダクトの技術選定では、ゼロから最適解を探す前に、既存の本番構成を1つ確認する工程を先に置くことにしている。
内製の余力があるかどうかの判断材料
内製と外注の分岐点のもう一つの軸は、複数のプロダクトを同時に進める余力があるかどうかである。自社では2026年9月、複数のプロダクトが同じ地点(立ち上げ後・外部利用ゼロ)で止まっている状態を確認し、並行して進めることをやめ、1つずつ作り切る方針に切り替えた(出所: 自社の運用記録、確認日2026-09-06)。足りなかったのはコードではなく、外部の利用者が最後まで通るところを見て直すという、並行しにくい種類の注意だった。内製を選ぶ場合、技術力だけでなく、この「見て直す」作業に充てられる時間が複数プロダクト分あるかどうかが、実質的な制約になる。
内製と外注、どちらを選ぶかの分岐点
まとめると、内製を選ぶ判断が成立するのは、既存の本番構成に合わせる規律が組織にあり、かつ並行させず1つずつ検証を通し切る体制がある場合である。どちらかが欠けると、内製は「ローカルで動くが誰にも届かない」状態、あるいは「複数が同じ地点で止まる」状態に陥りやすい。外注を検討する場合も、依頼先がこの2点を確認する運用を持っているかどうかを、判断材料にするとよい。
規模によって内製・外注の分岐点がどう変わるかは従業員規模で始め方が変わる記事で扱っている。検証をどこで打ち切るかの判断についてはPoCが終わる理由の記事を、最初に着手する業務そのものの選び方は有界かどうかを軸にした選び方の記事を参照してほしい。内製・外注の判断について相談したい場合は、お問い合わせから編集部まで連絡してほしい。
よくある質問
Q1. 内製の技術選定で最初に確認すべきことは何か
既存の本番構成を1つ確認することである。自社では、これを確認せずローカル環境に固定される構成で実装を進め、公開URLが無いためKPIが測れないという事業要件の不足に後から気づいた。
Q2. 「ローカルで動く」ことは完成と言えるか
言えない。成果物が誰にどう届くか、公開URL・計測・課金の仕組みが揃って初めて、事業として測れる状態になる。
Q3. 内製の余力はどう判断すればよいか
複数のプロダクトを同時に進める余力があるかで判断する。自社では複数のプロダクトが同じ地点で止まっている状態を確認し、並行をやめて1つずつ作り切る方針に切り替えた。
Q4. 外注を検討する際に確認すべき点は何か
依頼先が、既存の本番構成に合わせる規律と、複数案件を並行させず検証を通し切る体制を持っているかどうかである。