システム開発の内製化はどこまで？ 自社に残す判断と外注の境界

見積もりの回答を待つ間に、事業の予定が変わる。修正を頼むたびに追加費用がかかる。そんな経験が続けば、「開発者を自社で雇えば解決するのでは」と考えたくなるでしょう。しかし、採用後も仕様を決められる人がいなければ、待ち時間の場所が社外から社内へ移るだけかもしれません。

内製と外注を選ぶとき、最初に分けたいのは、実装する仕事と、その実装が事業に必要かを判断する仕事です。両方を同じ会社が担う必要はありません。誰が要求を決め、出来上がったものを確かめ、次の変更を選べるのか。この三つの責任を曖昧にしたまま、エンジニアの所属だけを変えても、期待する自由度は手に入りません。

安い開発費より、変更を引き受けられる体制

外注費と社員の給与を並べるだけでは、比較の範囲がそろいません。内製には採用、育成、欠員時の代替、保守や障害対応を続けるための費用が要ります。外注にも、要求を伝える担当者、受入確認、仕様変更の調整、契約終了時の引継ぎが必要です。いずれにも残る仕事を、片方の見積もりから消してはいけません。

英国政府の『Sourcing Playbook』は、提供方式を内製・外注・混成で比較し、移行から運用までの費用と、能力やリスクを評価するよう求めています。これは英国の公共調達の実務指針であり、日本企業で内製化が何％安くなると示した研究ではありません。それでも、単価だけで方式を選ばないための比較枠組みにはなります。英国政府の提供方式評価

ここからの提案は、システム全体に一つのラベルを付ける前に、変更の種類ごとに境界を引くことです。頻繁に変える販売条件と、仕様が安定した帳票の出力では、求められる応答速度も専門性も違います。社外で十分な品質を確保できる機能まで抱え込むと、本来育てたかった能力に人を割けなくなる可能性があります。

外注すれば、発注者の能力も不要になるのか

Lacityらの2010年のレビューは、1992〜2010年に公表されたITアウトソーシングの実証研究164本を整理しています。成果を扱うモデルには、発注側と供給側の能力、関係、契約による管理などが含まれます。外注の成果を、委託先の技術力だけで説明していない点に注目したいところです。論文の公開要旨

このレビューは既存の実証研究の整理で、企業を内製と外注に無作為に振り分けた実験ではありません。また、対象期間は現在のクラウドや生成AIの普及より前です。今の費用差や最適な内製比率を、この件数から推定することはできません。

内製へ戻すほど成果が上がる、とも決められません。LacityとWillcocksの1998年の研究では、米英40組織の意思決定を扱い、期待した費用削減の達成という指標で、選択的な外注が全面内製より成功率の高い結果でした。ただし観察された事例の比較で、方式だけの因果効果ではありません。費用上の成功を、品質や事業競争力のすべてへ広げることもできません。原論文の公開要旨

そのうえで編集部が重視するのは、「任せる側にも、任せた結果を評価する能力を置く」という境界です。顧客への約束、許容できない失敗、優先順位まで委託先任せにすると、納品物が契約どおりかは判断できても、事業として適切かを決める主体が空席になります。反対に、実装を外部へ委ねても、その判断を自社が担えるなら、外注は能力の放棄とは限りません。

値付けは自社、請求機能は外部。その境界が逆転するとき

例えば、法人向けの販売会社を考えます。以下は実在企業の事例ではなく、選び方を具体化する仮想例です。顧客ごとの値付けが競争力に直結し、営業部門が頻繁に条件を変えています。一方、請求書の発行は比較的安定しており、市場に自社の要件を満たすサービスがあります。

この場合の候補は、値付けのルールと変更の優先順位を自社で持ち、請求機能には外部サービスを使う構成です。ただし、「値付けが重要だから、初日から全コードを社員が書く」とはしません。社内の実装能力が不足している間は、外部と共同で作り、自社担当者が変更内容と検証方法を説明できる状態を先に作る道があります。

条件が変われば、結論も変わります。値付けの例外が減り、成熟した製品で十分に対応できるなら、独自開発を維持する理由は弱まります。逆に請求が特殊な契約条件と深く結び付き、製品の制約が事業の変更を繰り返し妨げるなら、接続部分や計算規則を自社管理へ移す検討が必要です。機能の名前ではなく、実際に失っている選択肢から境界を引き直します。

さらに、需要が季節的に大きく変わり、通年で専門家を配置する仕事量がないなら、外部の能力を利用する理由が強くなります。一方、毎週変更があり、説明や契約調整のたびに商機を逃しているなら、内部に継続的な実装能力を育てる価値が増します。ただし、忙しさだけでなく、継続して人を育てられる管理者と仕事の量があることも条件です。

見積もりを依頼する前に、比較する仕事をそろえる

同じ「保守付き」でも、問い合わせへの回答、修正、検証、本番反映のどこまで含むかで内容は変わります。比較表には金額の横へ、対象業務と含まれない仕事を書きます。特に、障害時の切分けを自社と委託先のどちらが始めるか、他社製品との接続不良を誰が追うかは、空白になりやすい部分です。

そのうえで、次のように証拠をそろえることを提案します。

これは点数を合計して機械的に勝敗を決める表ではありません。例えば、安くても必要な運用を続けられない案は、価格を比較する前に作り直す必要があります。評価項目に重みを付けるなら、その根拠は経営側が説明すべきです。「一般的には内製が先進的だから」という理由では、現場の不足を埋められません。

費用の対象をそろえたら、期間も合わせます。内製が初期300万円と年100万円、委託が初期150万円と年180万円という仮定なら、三年間でそれぞれ600万円と690万円です。採用、追加変更、障害対応の範囲が違えば、90万円の差だけでは選べません。納品後に次の担当者が仕様変更を判断し、完了できる条件まで比較します。

最初の試行で確かめるのは、作れたかより引き継げたか

全面移行を決める前に、小さな変更を一件、要求から運用まで通してみます。研究が実証した万能な試行手順ではなく、境界の欠落を見つけるための編集上の提案です。要望を出した人が受入条件を説明し、実装担当が変更し、別の人が期待した動作を確かめ、運用担当へ渡します。

見るべきものは開発時間だけではありません。どこで回答待ちになったか、何度説明し直したか、担当者を替えても変更理由をたどれるかを記録します。外注案で発注側の判断待ちが多いなら、内製化の前に要求を決める体制を直す余地があります。内製案で一人の専門家にすべての確認が集中するなら、所属は社内でも継続性は弱いままです。

試行がうまくいっても、容易な機能だけで結論を出さないことが大切です。実際に悩んでいる変更頻度や接続の難しさを含む仕事を選び、次の更新時に何を確かめ直すかまで残します。外部へ渡した成果物を受け取れることと、別の担当者が運用できることも別です。文書の有無ではなく、引継ぎ先が説明し、操作できる範囲を確かめます。

内製化の目標を「社員が書いたコードの割合」に置くと、標準機能まで作り直すことが成果になりかねません。目標は、必要な変更を選び、品質を確かめ、運用を続けられることです。頻繁に変える能力を社内で育てる条件がそろうなら内製へ進む。安定した機能に外部の専門性が適するなら委ねる。そのどちらでも、何を作るかを決める責任は自社に残す。この境界から、開発体制を選び直せます。