内製と外注の分岐点

システムを自社で作るか、外に頼むか。この判断を「コストが安いほう」で決めると、多くの場合3年後に作り直しが発生します。 分岐点は費用ではなく、業務理解・保守の継続性・法改正への追随という3つの論点にあります。この記事では、その判断基準を整理します。

現場で起きていること

内製と外注のどちらを選んでも、うまくいかない会社には共通の症状があります。

内製を選んだ場合：

• 詳しい社員が1人で作り、その人が異動・退職した後、誰も触れなくなった
• 動いてはいるが、仕様書がなく、どこを直すと何が壊れるか分からない
• 本業の合間に開発しているため、いつまでも完成しない
• 法改正のたびに「あれ、うちのシステム対応してたっけ」と確認に追われる

外注を選んだ場合：

• 発注時の要件どおりには動くが、現場が実際にやりたかったことと少しずれている
• 小さな仕様変更を頼むたびに見積もりと稟議が必要で、現場が使わなくなった
• 納品後に開発会社との関係が切れ、不具合が出ても対応してもらえない
• 法改正への対応が、そのつど追加発注になる

症状は違いますが、原因はどちらも同じ場所にあります。

なぜこうなるのか

内製と外注は、「業務理解」と「技術力」のどちらを外から調達するかという選択です。

内製は業務理解が手元にあります。現場の担当者が自分で作るので、「この帳票のこの欄は取引先によって意味が違う」といった細かい事情が最初から反映されます。一方で、技術力は社内にあるぶんだけしかありません。設計の作法や保守しやすい構造の知識が不足すると、動くけれど直せないものができあがります。

外注は技術力が調達できます。設計・実装・テストの型を持ったチームが作るので、構造としては健全なものができます。一方で、業務理解は伝えた分しか届きません。「言わなくても分かるはず」の部分が、そのまま抜け落ちます。

つまり分岐点は「どちらが優れているか」ではなく、自社の業務のどこが言語化できていて、どこが暗黙知のまま残っているかで決まります。ここを見ずに費用だけで選ぶと、内製なら保守で詰まり、外注なら要件で詰まります。

3つの論点で判断する

論点1：業務理解の深さ — 誰が「なぜそうするか」を持っているか

システム開発でつまずくのは、機能の実装ではなく業務の例外です。

「基本はこの流れですが、この取引先だけは請求書を月2回に分けます」「この商品は在庫があっても、出荷前に必ず担当者確認を入れます」——こうした例外は、業務フロー図には書かれていません。現場の頭の中にあります。

この暗黙知が多い業務ほど、外注先に丸投げすると失敗します。 逆に、業務フローが標準化されていて、例外が少ない領域なら、外注でも精度の高いものが作れます。

判断の目安はこうです。

• 例外が少なく、手順が文書化できている業務 → 外注が有利
• 例外が多く、担当者の判断に依存している業務 → 内製、または業務理解を共有しながら進める外注

なお、3つ目の選択肢として、外注先と一緒に業務を言語化しながら作る進め方があります。これは丸投げでも内製でもなく、業務理解を共同で作っていく形です。例外の多い中小企業の業務では、この形が現実的な場面が多くあります。

論点2：保守の継続性 — 5年後に誰が直すか

システムは作って終わりではありません。動き続けるかぎり、直し続ける必要があります。

内製の最大のリスクは、属人化です。1人の社員が作ったシステムは、その人が辞めた瞬間にブラックボックスになります。中小企業では開発できる人材が複数いることは稀なので、このリスクは高く見積もる必要があります。

外注の最大のリスクは、関係の断絶です。開発会社が対応をやめる、担当者が変わって経緯を知る人がいなくなる、といった事態は起こり得ます。

どちらのリスクも、対策は同じです。保守が誰の責任で、どういう体制で続くのかを、作り始める前に決めておくこと。 内製なら仕様と設計を文書として残す。外注なら保守の範囲と期間を契約で明確にする。ここを曖昧にしたまま進めると、内製・外注のどちらを選んでも同じ場所で詰まります。

論点3：法改正への追随 — 変わることが分かっているもの

インボイス制度、電子帳簿保存法、労働時間の管理義務——制度は変わります。 そして、システムがそれに追随できないと、業務が止まるか、手作業で埋めることになります。

ここは内製と外注で性質が大きく変わります。

内製の場合、法改正の情報収集から対応方針の決定、実装まで、すべて自社で担います。専門知識のキャッチアップが継続的に必要になり、本業の合間ではこれが重い負担になります。

外注の場合、開発会社が制度改正の情報を持っていれば、対応を任せられます。ただし、「法改正対応が保守契約に含まれるのか、都度の追加発注になるのか」は事前に確認が必要です。ここを確認せずに契約すると、改正のたびに想定外の費用が発生します。

制度改正の影響を受けやすい業務——会計、給与、労務、請求——ほど、追随体制を持つ相手に任せる価値が高くなります。

境界線：外注先に任せられるもの、自社にしか持てないもの

外注先に任せられるのは、技術と型に属する領域です。

• システムの構造設計（どう作れば後から直しやすいか）
• 実装とテスト（動くものを、壊れにくい形で作る）
• セキュリティ対策（不正アクセスやデータ漏洩への備え）
• インフラの構築と運用監視
• 制度改正に対する技術的な対応方法の設計

これらは経験の蓄積がものを言う領域で、社内で一から積み上げるより、持っている相手から調達するほうが早く確実です。

一方、自社にしか持てないのは、業務の意味と優先順位です。

• 「この処理は多少遅くても正確さを優先する」という判断
• 「この取引先には、規定と違ってもこう対応する」という商習慣の背景
• どの業務から手をつけるか、という優先順位づけ
• 現場の担当者が実際にどう使うか、というリアリティ
• 「この機能は不要だった」と気づいたときに、やめる決断をすること

外注先はこれらを推測できますが、決めることはできません。決めるのは常に自社です。 逆に言えば、ここさえ自社で持てていれば、技術は外から調達しても、システムは自社のものになります。

失敗する外注の多くは、技術を外注したのではなく、判断まで外注してしまったケースです。

分岐点の整理

見るべき点	内製が向く	外注が向く
業務の例外の多さ	例外が多く、言語化が難しい	手順が標準化されている
社内の開発人材	複数名おり、引き継ぎが可能	1名以下、または本業と兼務
保守の体制	文書化と引き継ぎの運用がある	継続的な保守契約を結べる
法改正の影響	影響が小さい業務	会計・労務など影響が大きい業務
求めるスピード	時間をかけられる	早期に立ち上げたい

実際には、すべてを内製かすべてを外注かの二択ではありません。 業務理解が要る部分は自社が握り、技術の型が要る部分を外に出す。この切り分けができれば、両方の利点を取れます。

まず何をすればいい

自社の場合どこが分岐点になるのかは、現在の業務の言語化度合いと、社内の保守体制によって変わります。ここは一般論では判断できません。

Guidaでは、無料相談で現状の業務と社内体制を伺い、内製すべき領域と外注が有効な領域を切り分けたうえで、進め方をご提案しています。保守の範囲や法改正対応の扱いをどう設計するかも、無料相談でお伝えします。

「まだ内製か外注かも決めていない」という段階で構いません。判断材料を揃えるところからご相談ください。