Skip to content

Instantly share code, notes, and snippets.

@neon-izm
Last active November 26, 2023 10:56
Show Gist options
  • Save neon-izm/467e9d0cc0af3c25c7dcc1094b0c4318 to your computer and use it in GitHub Desktop.
Save neon-izm/467e9d0cc0af3c25c7dcc1094b0c4318 to your computer and use it in GitHub Desktop.
内製するかSaaSに逃がすか

概要

アプリやサービスをソフトウェアエンジニアが作るときに「ここはSaaSで賄いましょう」「ここは自作しましょう」みたいな判断を迫られがちです。
プロダクトごとに背景が違うので一般論は述べにくいですが、最近の僕の気持ちはこんな感じ、というのをまとめておきます。

// 極論すると、99%くらいのソフトウェアはSaaSを使ったから(勝った|負けた)みたいな短絡的な要素は無くて、それ以外のところで勝敗が決まることが多いです。なので好きにしたら良いという気もする。

  • ふつうの人間は、内製した方がえらい、というバイアスがある
  • 要はバランス、ではあるが僕は内製箇所を少なくする方を提案することが多い

SaaS導入のメリットデメリット

何を今更、ですが一応書いておきます。

メリット

  • SaaSを作ってるのは賢い(?)人たちなので、内製するよりも競争力があるSaaSになっている(はず、たぶん…)
  • メンテコストを外部に押しつけることが出来る
  • 該当箇所の開発期間を短く出来る(事が多い)

デメリット

  • SaaSを作ってるのは賢い(?)人なので、彼らが儲からないって気付いたらサービスが値上げしたり閉鎖されたりする
  • 実は無限にSaaSのアップデートに対応するメンテコストが発生しがち
  • 他社がパクりサービス作るときにハードルが下がってそう(?)

ソフトウェアを開発する時のSaaSロックインを受け入れるかの話

そもそも今から作るのがチームメンバーもいっぱいいて、予算もあるぞ!! みたいな時はSaaSをあまり使わずに内製でキッチリ作った方が良い、ような気もします。

一方で「売上が出るのか分からん、バクチだ!!!」みたいなプロダクトも世の中には多くあります。
(というか外部向けの話とは別に、中の人的にはバクチだってことは結構多いよね…)

こういうときに例えば

  • 認証系をFirebase Authに逃がすか
  • 課金系をRevenue Catに逃がすか
  • エラー監視をSentryに逃がすか

みたいな判断を無限に迫られます。はい。

内製したい人たちは一定いまして

  • 「ここはコア機能だし、SaaSにするとサービスクローズされて詰みますよ!」
  • 「SaaSの料金はスケールで掛かってくるから、この想定ユーザ規模だと内製した方がお得ですよ」

みたいなことを言ってきます。(それは確かにその通りなんですが)

ここで一個邪悪な論点があります。
エンジニア的には「認証基盤を内製しました」とか「課金基盤を内製しました」とか「エラー監視機構を内製しました」みたいな事が言えると、SaaSを使ったって言うより将来のキャリア形成で有利と言うのがあります。
さらにCTOやCEOにとっても「わが社はここを内製しました」みたいなアピールをするのは「SaaSを組み合わせてペペッと作りました」よりかっこいいという問題があります。

なので、普通の新規事業(?)は何もなければ SaaSを使わない方向、つまり内製したがる、という妙なバイアスがある、ということだけを覚えて今日は帰ってください。

(僕は、プロダクトが動いて売上を建てるまでが短く安く検証できた方が嬉しいのでSaaSを提案する方が多いです)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment