システム開発を内製か外注かで迷うとき——先に答えるべき3つの問い

「内製か外注か」という問いを立てるとき、多くの発注側は最初にコスト比較を始める。外注のほうが安い、内製のほうが長期的に得——そう判断しても、後から「こんなはずではなかった」に変わることは少なくない。

判断がずれる理由は、コストを比べる前に答えるべき問いをとばしているからだ。業務の変化速度・社内に残す知識の範囲・要員確保の現実——この3軸を先に整理してから選択すると、根拠のある判断になる。

変化が速い業務を外注すると、何が起きるか

業務の変化が頻繁なほど、外注は割高になる。

仕様変更のたびに発注・見積・確認のプロセスが発生する。変更を依頼するコストが小さくないため、変化を後回しにする判断が増える。気づいたときには、システムが現場の実態より半歩遅れている状態が常態化する。

逆に、業務仕様がほぼ変わらない領域——たとえば法定帳票の出力や特定の届出業務——は外注のほうが管理コストを抑えやすい。「この業務は今後どれだけ仕様が変わるか」という問いが、最初の切り口になる。

業務変化の見立てに自信がないときは、部署を横断して課題を整理するプロセスが役に立つ。単一部門の視点だけで判断すると、変化の根拠が浅くなりやすい（参考：当事者だけで考えると改善が止まる理由）。

知識を社内に残すかどうかは、先に決める

外注した業務の知識は、外注先に蓄積される。

取引関係が続く間は問題にならない。しかし、ベンダーが変わるとき・内製に戻すとき・担当者が交代するときに、知識の空白が露出する。

社内に残すべき知識の目安は次の3つだ。

• 競合優位につながる判断ロジック
• 現場の例外処理の蓄積
• データの定義・管理の方針

この3つが含まれる業務を外注するなら、ドキュメント整備・ソースコードの開示・定期的な技術共有を契約に明記する必要がある。それが難しい条件であれば、内製を選ぶ根拠になる。

要員確保の現実も同時に問わなければならない。内製に必要なスキルセットを持つ人員が今すぐ確保できるかどうかは、方針の善し悪しより実行可能性に直結する。採用・育成コストを含めた試算を持っておかないと、方針だけが先行して実態が追いつかない事態になる。

「外注したから分からない」という状態は、意思決定の速度を下げる。知識の在り処を決めることは、開発方針より先の問いだ。

内製と外注を混在させるときの注意点

内製と外注を組み合わせること自体は珍しくない。しかし、混在させると管理コストが増える。主な発生箇所は次のとおりだ。

1. 仕様認識のズレ：内製側と外注側が別々に動くと、同じ用語・同じ機能の解釈が食い違う
2. 進捗管理の二重化：社内と外注先それぞれに確認フローが必要になる
3. 責任境界の曖昧さ：問題が起きたとき、原因の特定と対応の開始が遅れる

混在を選ぶなら、先に責任範囲を文書で定めることが有効だ。「どこまでが社内の仕事で、どこからが外注先の仕事か」を契約前に決める——外注先を選ぶ評価基準と並走させて設計しておくとよい（参考：ベンダー選定の基準は比較表より先に決まる）。

混在の管理に不安がある場合、DXの伴走支援（しぼる：DX伴走支援）を検討する価値がある。内製と外注の境界設計から関与する支援は、後から発生する管理コストの予防につながる。

---

「内製か外注か」に正解はない。変化速度・知識の所在・要員の現実を3軸で整理したとき、自社の状況から答えが浮かび上がる。判断の順番を変えることが、後悔のない選択への近道だ。