READ
~/eforce-tec/blog/posts/build-or-buy-business-system.md
markdown
4 min

業務システムは内製か外注か、既製品か

date2026-09-08author難波 優毅(Masataka Namba)marketing業務システム内製外注SaaS判断基準4 min

社内の管理業務が手作業で回らなくなったとき、選択肢は3つある。

  1. 既製のサービス(SaaS)を契約する
  2. 社内で作る(内製)
  3. 外に頼む(外注)

多くの場合、初期費用の安い順に 1 → 2 → 3 と並ぶ。ただしこの順で選ぶと、後から高くつくことがある。判断の基準を整理する。

まず既製品を探す。これが最優先

順番として、最初にやるべきは既にあるものを探すことだ。

勤怠管理、会計、名刺管理、顧客管理といった「どの会社にもある業務」は、すでに専門のサービスが存在する。月数千円から使えて、法改正への対応もサービス側がやってくれる。これを自作するのは、ほぼ確実に損になる。

作る側の立場で言えば「作らないほうがいい」と言うのは仕事を減らす話だが、使われないシステムを作っても保守費用が増えるだけで、双方に得がない。

既製品を諦めるのは、次のどれかに当てはまるときだけでいい。

  • 業務の流れが業界特有で、既製品に合わせると現場の手間が増える
  • 複数のサービスにまたがっていて、データの行き来が手作業になっている
  • 使いたい機能のために、不要な上位プランを契約せざるを得ない

内製が向いているケース

社内にコードを書ける人がいるなら、内製は有力な選択肢になる。向いているのは次のような場合。

  • 仕様が頻繁に変わる。現場の運用に合わせて毎月のように直したい
  • 小さく作って試したい。まず1機能だけ動かして反応を見たい
  • 社内だけで完結する。外部に公開せず、社員しか使わない

逆に、内製で失敗しやすいのは属人化だ。作った本人が異動・退職すると、誰も触れないシステムが残る。内製する場合は、最低限「どう動いているか」の文書と、他の人が読めるコードであることを条件にしたほうがいい。

NOTE

「社内の詳しい人が片手間で作る」という形は、いちばん危険な内製になりやすい。その人の本来の業務が圧迫され、しかも完成後の保守も同じ人に乗る。内製するなら、その工数を正式に業務として確保すること。

外注が向いているケース

外に頼む価値が出るのは、次のような場合。

  • 外部に公開する。取引先や一般利用者が触るので、セキュリティと安定性の責任が重い
  • お金やデータの正確さが求められる。決済、請求、個人情報を扱う
  • 社内に手が空いている人がいない
  • 数年単位で使い続ける。作り逃げではなく、直し続けられる相手が必要

外注の本当の価値は「作ってもらえること」より、動かなくなったときに直してもらえることにある。だから選ぶときは、作る能力より「連絡が取れ続けるか」を見たほうがいい。

費用の比べ方を間違えない

3つを比べるとき、初期費用だけを並べると必ず既製品が勝つ。5年で見るとこうなる。

初期 毎月 5年総額の傾向
既製品 小 中〜大(人数課金で増える) 人数が増えると膨らむ
内製 小 小(ただし社内工数) 担当者が抜けると一気に増える
外注 大 小〜中(保守費) 読みやすい

見落とされやすいのが、既製品の人数課金と、内製の社内工数だ。前者は事業が伸びるほど増え、後者は最初から金額として見えない。

実際には組み合わせになることが多い

現実的な答えは「全部どれか1つ」ではない。

会計や勤怠は既製品を使い、自社特有の申込受付だけを作る。作った部分と既製品の間を、データ連携でつなぐ。この形が、費用と柔軟性のバランスが取りやすい。

当社でご相談を受けるときも、まずいま何にどれだけ時間がかかっているかを洗い出すところから始めます。作らずに済むなら、そう申し上げます。時間を食っている上位のいくつかを削るだけで、体感が大きく変わることがほとんどです。

判断に迷っている段階でのご相談で構いません。要件が固まっていなくても、現状をうかがえば選択肢を並べてお出しできます。

$contact --subject "相談"

こうした実装を、仕事としてお引き受けしています。

記事で書いているような設計・実装を、受託でも行っています。Webサイトの制作から、業務の仕組み化、決済まわりの実装まで。要件が固まっていない段階のご相談で構いません。