内製化とアウトソースの分岐点

「この業務、そろそろ社内で作れるようにしたほうがいいのでは」。外部の開発会社に見積もりを頼むたびに、そんな考えがよぎる担当者は少なくありません。改修のたびに数十万円の見積もりが届き、ちょっとした画面の文言修正でも「調査費用込みでご相談させてください」と言われる。一方で、社内に開発できる人材を置くという選択肢には、採用・教育・定着という別の重さがのしかかります。

この記事は、これまで外部の開発会社にすべてを委ねてきた会社が、「一部だけでも内製化すべきかどうか」を検討し始めた段階の担当者に向けたものです。似たテーマとして当メディアには「開発会社を変えたいのに変えられない理由」という記事がありますが、あちらは既存の委託先からの乗り換えを妨げる障害を分解した記事でした。この記事はその手前にある、より根本的な問いを扱います。すなわち、内製化とアウトソースをそもそもどう使い分けるべきか、という一般的な判断軸です。

• 内製化を検討し始める典型的なきっかけ: なぜ「そろそろ」と思うのか
• 内製化・アウトソース・中間形態の3つの選択肢: 二者択一ではない
• 業務を4象限に分けて判断する方法: 何を内製化し、何を外部に残すか
• 内製化を始める前に確認すべき5つの条件: 勢いだけで踏み出さないために
• 失敗しやすいパターンとその回避策: 中途半端な内製化が招く二重コスト
• 段階的に内製化を進める現実的な手順: いきなり全部を切り替えない

なお、この記事の運営元である株式会社ゼットリンカーはシステムの受託開発を事業としています。内製化を検討する記事を外注企業が書くこと自体に利益相反があると感じる方もいるかもしれません。そのため、この記事では「内製化したほうがよいケース」も「アウトソースを続けたほうがよいケース」も、どちらも同じ重さで扱います。結論を外注に誘導する意図では書いていません。

この記事で分かること

この記事は、これまで社内システムの開発・改修をすべて外部の開発会社に委託してきた会社が、「一部の業務を内製化すべきかどうか」を検討する段階で読むことを想定しています。内製化とアウトソースはどちらか一方を選ぶものではなく、業務の性質ごとに使い分けるのが実務上の現実的な解であるという前提に立ち、その判断軸を具体的に示します。

読み終えたときに持ち帰っていただきたいのは、「内製化すべきか」という漠然とした問いに対する一つの正解ではなく、自社の業務を分類し、どこから内製化を検討すべきかを判断するための具体的な物差しです。すでに一部の内製化を試みて挫折した経験がある方にも、何が原因だったのかを振り返る材料として読んでいただけます。

なぜ「内製化」を考え始めるのか

内製化を検討し始めるきっかけは、会社によって様々ですが、共通するパターンがいくつかあります。まず最も多いのが、外部委託のコストが積み重なることへの疑問です。小さな改修一つひとつは数万円から数十万円でも、年間を通じて発注し続けると、その総額が「専任担当者を1人雇える金額」に近づいていることに気づく瞬間があります。

次に多いのが、スピード感への不満です。業務側から「この画面にこの項目を追加してほしい」という要望が出ても、開発会社への発注、見積もり、契約、着手というプロセスを経るため、実際に反映されるまで数週間から数ヶ月かかることがあります。社内に開発できる人がいれば、その日のうちに直せるような変更でも、外部委託ではリードタイムが避けられません。

さらに、ベンダーロックインへの危機感も内製化を後押しする要因です。特定の開発会社にしか触れないシステムに依存し続けることへの不安から、「せめて一部だけでも自社でコントロールできる状態にしたい」という発想が生まれます。

• 外部委託の累計コストが、専任人材の人件費に近づいてきた
• ちょっとした変更のたびに、発注のリードタイムがボトルネックになっている
• 特定の開発会社への依存度が高まっていることへの不安がある
• 社内に「この程度ならできそう」と感じる人材が育ってきた
• 業務のデジタル化を継続的に進めたいが、都度発注では追いつかない

これらのきっかけ自体は正当なものですが、きっかけがあることと、実際に内製化に踏み切るべきかどうかは別の話です。次の章から、内製化とアウトソースを整理して検討するための枠組みを見ていきます。

内製化・アウトソース・中間形態という3つの選択肢

内製化とアウトソースは、しばしば「どちらか一方に全面的に切り替える」という二択で語られがちですが、実務ではその中間にいくつもの形態が存在します。まず選択肢を整理しておきましょう。

多くの中小企業にとって現実的な着地点は、両端の「全面アウトソース」と「全面内製化」ではなく、中間の「部分内製化」です。すべてを社内で賄おうとすると採用・育成コストが重すぎ、逆にすべてを外部に委ねると意思決定のたびにコストとリードタイムがかかります。どの業務を内製化し、どの業務を外部に残すかを見極める作業が、この判断の本質になります。

内製化の検討は「する/しない」の二択ではなく、「どの業務から、どの範囲まで」という配分の問題として捉えたほうが、現実的な結論にたどり着きやすくなります。

業務を4象限に分けて判断する

内製化すべき業務とアウトソースを続けるべき業務を見極めるために、「変更頻度」と「専門性の高さ」という2つの軸で業務を分類する方法が有効です。

変更頻度が高い業務とは、画面の文言修正、入力項目の追加、簡単な集計ロジックの調整など、日常的に「ちょっと直したい」という要望が発生する業務です。変更頻度が低い業務とは、一度作ればしばらく変更が発生しない業務、たとえば基幹システムの初期構築や、法改正対応のような単発の大規模改修を指します。

専門性が高い業務とは、セキュリティ設計、外部システムとの複雑な連携、大量データの処理基盤など、誤ると重大な損害につながりやすく、高度な技術知識を要する業務です。専門性が低い業務とは、既存の仕組みの上で完結する軽微な変更や、ノーコード・ローコードツールで対応できる範囲の業務を指します。

この2軸を掛け合わせると、次の4象限に整理できます。

• 変更頻度が高く専門性が低い: 内製化の最有力候補。社内担当者が学習しながら対応しやすく、リードタイム短縮の効果も大きい
• 変更頻度が高く専門性が高い: 内製化を目指す価値はあるが、育成に時間がかかる。まずは外部委託を続けながら、社内担当者を並走させて知見を移転する
• 変更頻度が低く専門性が低い: 内製化してもコストメリットが薄い。都度アウトソースで十分な領域
• 変更頻度が低く専門性が高い: 外部委託が適している。専門性の高い人材を社内に常駐させるコストが見合わない

この整理をもとに自社の業務を洗い出すと、「なんとなく全部内製化したい」という漠然とした願望が、「まずこの業務から着手すべきだ」という具体的な優先順位に変わります。すべての業務を一度に内製化しようとするのではなく、最有力候補の象限から着手するのが現実的な進め方です。

内製化を始める前に確認すべき5つの条件

業務の優先順位が見えてきたとしても、内製化に踏み切る前に確認しておくべき条件があります。これらを飛ばして勢いで内製化に着手すると、後述する失敗パターンに陥りやすくなります。

条件1: 継続的に業務を任せられる人材がいるか。内製化は一度きりの投資ではなく、継続的な人的リソースの確保を意味します。担当者を1人採用・育成しても、その人が異動・退職した瞬間に体制が崩れるようでは、属人化を新たに生み出すだけです。バックアップ体制まで見据えて検討する必要があります。

条件2: 学習・育成にかけられる時間があるか。特に専門性の高い業務を内製化しようとする場合、担当者が一人前になるまでには相応の時間がかかります。この期間は生産性が一時的に下がることを織り込んでおく必要があります。

条件3: 内製化後の運用体制を維持できるか。開発した本人だけが仕組みを理解している状態は、外部の開発会社に依存する構造を、社内の特定個人に依存する構造に置き換えただけです。ドキュメント化やレビュー体制など、属人化を防ぐ仕組みとセットで考える必要があります。

条件4: セキュリティ・品質の担保をどう行うか。プロの開発会社が担ってきた品質保証やセキュリティレビューの機能を、内製化後は誰が担うのかを明確にしておく必要があります。特に外部公開するシステムや個人情報を扱う業務では、この点を軽視できません。

条件5: 撤退の選択肢を残しているか。内製化を始めてみたものの、想定より負荷が大きく続けられないと判断した場合に、再び外部委託に戻す選択肢を残しておくことも重要です。内製化を「後戻りできない一大決心」として捉えると、条件が揃っていない段階でも無理に押し進めてしまうリスクが高まります。

• 継続的に任せられる人材(バックアップ含む)がいるか
• 育成にかけられる時間を確保できるか
• ドキュメント化など属人化防止の仕組みとセットで考えられているか
• セキュリティ・品質担保の担い手が明確か
• 内製化がうまくいかなかった場合に外部委託へ戻す選択肢が残っているか

この5条件のうち、いくつが「はい」と即答できるでしょうか。3つ以上が「分からない」「難しい」に該当する場合は、内製化に踏み切る前に、まず条件を整える期間を設けたほうが安全です。

失敗しやすいパターン: 中途半端な内製化が招く二重コスト

内製化の検討でよく見られる失敗パターンが、「中途半端な内製化」による二重コストです。これは、内製化の範囲や体制を十分に検討しないまま踏み切った結果、外部委託のコストと内製化の投資コストが両方発生してしまう状態を指します。

典型的な例を挙げます。

• 担当者を1人採用したものの、実際には既存システムの理解に時間を取られ、思うように改修が進まない。結局、緊急の改修は外部委託に頼らざるを得ず、人件費と委託費の両方がかかっている
• ノーコード・ローコードツールで内製化を進めたが、要件が複雑化するにつれてツールの限界に突き当たり、結局フルスクラッチでの作り直しを外部委託することになった
• 内製化した担当者が異動・退職し、後任がいないまま放置。結果的に外部の開発会社に「引き継ぎ資料がない状態からの立て直し」を依頼することになり、通常の委託より高い費用がかかった

これらの失敗に共通するのは、内製化を「コスト削減の手段」としてのみ捉え、育成期間・属人化対策・撤退条件といった前提を十分に検討しないまま着手してしまった点です。内製化は短期的にはコストが増える取り組みであり、その投資が回収できるかどうかは、前章で挙げた5条件がどれだけ満たされているかにかかっています。

内製化の初年度は、外部委託だけを続けていた場合と比べてコストが上振れすることが珍しくありません。これは失敗ではなく、育成投資として想定内に織り込んでおくべき性質のものです。

段階的に内製化を進める現実的な手順

内製化を検討する際、いきなり大規模な業務や基幹システムから着手するのはリスクが高い進め方です。現実的には、次のような段階を踏むことをおすすめします。

ステップ1: 小さく試す業務を1つ選ぶ。前章の4象限で「変更頻度が高く専門性が低い」に分類された業務の中から、失敗しても業務全体への影響が小さいものを1つ選びます。たとえば社内向けの簡易な集計ツールや、既存システムの表示項目の調整などが候補になります。

ステップ2: 期間と評価基準を決めてから着手する。「なんとなく続ける」のではなく、「3ヶ月試して、対応件数と担当者の負荷を評価する」のように、あらかじめ期間と評価の観点を決めておきます。評価基準を後から決めると、うまくいっていない状態でもずるずると続けてしまいがちです。

ステップ3: ドキュメント化を並行して行う。内製化した業務の仕様・手順は、担当者の頭の中だけに置かず、その都度簡単なメモでもよいので記録に残します。これは前章で触れた属人化対策そのものであり、後から始めようとすると余計な工数がかかります。

ステップ4: 評価し、範囲を広げるか見直すかを判断する。決めておいた期間が終わったら、実際に評価基準に照らして振り返ります。うまくいっていれば次に内製化する業務を検討し、うまくいっていなければ何が原因だったのかを明確にしたうえで、外部委託に戻すか、条件を整え直してから再挑戦するかを判断します。

• ステップ1: 影響範囲が小さい業務を1つ選んで試す
• ステップ2: 期間と評価基準を事前に決める
• ステップ3: 属人化させないためのドキュメント化を並行する
• ステップ4: 評価に基づいて範囲拡大か見直しかを判断する

この手順を踏むことで、「内製化するかどうか」という大きな決断を一度に迫られるのではなく、小さな検証を積み重ねながら自社にとっての適正な内製化の範囲を見つけていくことができます。

コストで比較するときの落とし穴

内製化とアウトソースを検討する際、多くの担当者がまず着目するのがコストの比較です。しかし、この比較は見た目以上に難しく、単純な数字の比較だけで判断すると誤った結論を導きやすい領域です。「年間の外注費と、採用予定者の年収を比べて、安いほうを選ぶ」という単純化した比較は、一見分かりやすいものの、実際には見落としている費用や効果が多く、判断を誤らせる原因になります。

まず、外部委託のコストは見積書に明記されるため把握しやすい一方、内製化のコストは見えにくい部分に分散しています。担当者の人件費だけでなく、次のような費用が内製化には伴います。

• 採用活動そのものにかかる費用と時間
• 育成期間中、担当者が本来の生産性を発揮できないことによる機会損失
• 開発に必要なツール・環境のライセンス費用
• セキュリティ研修や品質管理の仕組みを整えるための費用
• 担当者が退職した場合の再採用・引き継ぎコスト

これらは請求書として届くわけではないため、「内製化のほうが安く済む」という判断が、実は人件費の一部しか比較していない不完全な計算に基づいている場合があります。逆に、外部委託側のコストも「見積書の金額」だけで判断すると、発注のたびに発生する仕様調整の時間や、社内の他業務が止まることによる間接的なコストが見落とされがちです。

コスト比較を行う際は、「外部委託の見積金額」と「内製化した場合の人件費」という単純な対比ではなく、両者に共通して発生する間接コスト(調整の手間、リードタイムの遅れ、品質担保にかかる労力)まで含めて考える必要があります。

正確な金額の比較は会社ごとの条件によって大きく異なるため、この記事では具体的な相場には触れません。重要なのは、比較の土俵を揃えることです。少なくとも上記のような間接コストの存在を認識したうえで、自社にとっての実質的な比較を行うことをおすすめします。

また、コスト比較は単年度だけでなく複数年のスパンで見ることも重要です。内製化の初年度は採用・育成コストが先行して発生するため、外部委託と比べて割高に見えることが一般的です。しかし、育成が一段落した2年目・3年目以降にコストの構造がどう変わっていくかまで見通したうえで判断しないと、初年度だけを見て「内製化は割に合わない」と早計に結論づけてしまう恐れがあります。逆に、外部委託側も長期間にわたって同じ会社に発注し続けることで、保守費用が段階的に上がっていくケースがあるため、こちらも単年度の金額だけで判断しないほうが安全です。

組織の規模とフェーズによる向き不向き

内製化とアウトソースのどちらが適しているかは、会社の規模や成長フェーズによっても変わります。同じ業務内容であっても、組織の状況次第で最適な選択が変わることを踏まえておくと、判断の精度が上がります。

情シス担当者が1人、あるいは総務との兼任である場合、新たに開発人材を1人採用して内製化を進めるという判断は、現実的にハードルが高いことが多くなります。すでに手一杯の状態で新たな採用・育成の負荷を抱えることになるためです。この場合は、既存の担当者がノーコード・ローコードツールで対応できる範囲を見極め、それを超える部分は引き続き外部委託に頼るという配分が現実的です。

事業が拡大局面にあり、システムへの投資余力が増えている場合は、内製化を検討するタイミングとして適しています。開発人材への投資を、単なるコスト削減ではなく、事業成長を支える基盤への投資として位置づけられる段階だからです。

逆に、事業の先行きが不透明で、システムへの投資判断を慎重にすべき局面では、固定費化しやすい内製化よりも、必要な分だけ発注できるアウトソースのほうが柔軟性の面で優れています。

• 情シスが1人・兼任体制: ノーコード等でできる範囲に限定した部分内製化が現実的
• 拡大局面・投資余力あり: 内製化への投資を前向きに検討できるタイミング
• 先行き不透明・投資を絞りたい局面: 固定費化を避け、アウトソースの柔軟性を優先

自社が今どのフェーズにあるかを踏まえずに、他社の内製化成功事例だけを参考にして判断すると、自社の体力に見合わない体制を作ってしまうリスクがあります。判断の前提として、まず自社のフェーズを客観的に確認しておくことをおすすめします。

たとえば、総務と情シスを兼任する担当者が1人しかいない会社で、経営層から「もう外注費がかさむから内製化しよう」と号令がかかることがあります。しかし、実際にその担当者の日々の業務を分解してみると、すでに問い合わせ対応や既存システムの運用管理だけで手一杯であり、新たに開発業務を抱える余地がないというケースは珍しくありません。このような状態で無理に内製化を進めると、既存業務の品質が落ちるか、内製化そのものが中途半端に終わるかのいずれかに陥りがちです。フェーズの見極めは、経営層の意向だけでなく、現場の実際の稼働状況とあわせて行う必要があります。

アウトソースを続ける、という選択の正当性

ここまで内製化を検討する視点を中心に解説してきましたが、内製化が常に正しい選択とは限りません。むしろ、多くの中小企業にとっては、専門性の高い業務や変更頻度の低い業務については、アウトソースを続けるほうが合理的です。

アウトソースを続ける正当な理由には、次のようなものがあります。

• 開発を専業とする人材の採用・定着自体が容易ではなく、無理に採用しても定着しないリスクがある
• 専門性の高い領域(セキュリティ、大規模データ処理等)は、専任の担当者1人よりも、複数の専門家を抱える開発会社に委ねたほうが品質を担保しやすい
• 事業の中核が開発そのものではない会社にとって、開発人材のマネジメントに経営資源を割くこと自体が本業から目をそらす結果になりかねない
• 外部委託であれば、業務量の増減に応じて発注量を調整できる柔軟性がある。内製化した人材は、業務が少ない時期でも人件費が固定費として発生し続ける

内製化とアウトソースの比較は、「どちらが優れているか」という優劣の問題ではなく、「自社のどの業務に、どちらの体制が合っているか」という配分の問題です。この記事で示した4象限の整理や5条件のチェックは、内製化を推進するための材料としてだけでなく、「この業務はアウトソースを続けるべきだ」という判断を裏付ける材料としても使えます。

業務の棚卸しから始める: 具体的な進め方

ここまでの判断軸を実際に自社へ当てはめるには、まず自社が抱えている業務を一覧化する作業が欠かせません。「なんとなく改修依頼が多い」「なんとなくコストが気になる」という感覚だけで内製化を検討すると、判断の根拠が曖昧なまま進めてしまいます。

具体的な進め方として、次のような手順をおすすめします。

手順1: 直近1年間の外部委託の発注履歴を洗い出す。発注日、内容、金額、対応にかかった期間を一覧にします。すでに保守契約や個別発注の記録が残っていれば、それを整理するだけでも十分です。記録が散在している場合は、この機会に一箇所にまとめておくと、今後の判断材料としても使えます。

手順2: 発注内容を業務単位に分類する。「画面の表示調整」「新機能の追加」「外部システムとの連携」「セキュリティ対応」のように、内容ごとにグルーピングします。同じような依頼が繰り返し発生している業務があれば、それが内製化候補の手がかりになります。

手順3: 分類した業務を4象限に当てはめる。前章で示した「変更頻度」と「専門性」の2軸で、それぞれの業務がどこに位置するかを整理します。この段階で、意外と「変更頻度が高く専門性が低い」業務が特定の1〜2種類に集中していることに気づくケースが多くあります。

手順4: 最有力候補について5条件を確認する。人材、育成期間、属人化対策、品質担保、撤退の選択肢という5つの条件に照らして、その業務を内製化する準備がどこまで整っているかを確認します。

この一連の棚卸し作業は、慣れれば数時間から1日程度で一巡できます。感覚ではなく実際の発注履歴という一次情報に基づいて判断できる点が、この手順の強みです。棚卸しの結果、内製化候補が見つからなければ、それもまた一つの結論です。「今は外部委託を続けるのが合理的」という判断も、根拠を持って下せるようになります。

まとめ: 内製化は全か無かではなく配分の問題

内製化とアウトソースの分岐点は、一度きりの大きな決断ではなく、業務ごとに繰り返し検討する配分の問題として捉えることが、実務上もっとも現実的なアプローチです。

改めて、この記事で示した判断の流れを振り返ります。まず自社が内製化を検討し始めたきっかけを整理し、次に「変更頻度」と「専門性」という2軸で業務を4象限に分類します。そのうえで内製化を始める前の5条件を確認し、条件が整っている業務から小さく試し、期間と評価基準を決めて検証しながら範囲を見直していく。この一連の流れを踏むことで、中途半端な内製化による二重コストという失敗を避けやすくなります。

大切なのは、「内製化かアウトソースか」という二者択一の答えを急いで出すことではありません。自社が抱える業務を分類し、どの業務にはどちらの体制が向いているかを、根拠を持って説明できる状態を作ることが、この検討の本来の目的です。その状態さえ作れれば、経営層への説明も、担当者自身の納得感も、格段に得やすくなります。内製化を選ぶにせよ、アウトソースを続けるにせよ、その判断が「なんとなく」ではなく「整理した結果」であることが、後になって判断を見直す際にも重要な土台になります。

すでに一部の外部委託に不満があり、「変えたい」という具体的な段階に進んでいる方は、乗り換えの障害を分解した別記事もあわせてご覧ください。乗り換え先を外部の開発会社にするか、内製化にするかを検討する際にも、この記事で示した判断軸が役立つはずです。また、内製化を進める場合には、稟議書の書き方や社内システム管理台帳の整備方法など、体制づくりに関する記事もあわせて参考にしてください。