あるクライアントが2021年に電話をくれた。声には本当の恐慌が響いていた。カスタム請求書プラットフォームの構築に14ヶ月間で£140,000を費やしていた。彼の開発チームは仕様の約60%しか実装できていなかった。そして11ヶ月目頃に、Invoice Ninjaが存在し、オープンソースで、必要な機能の90%がそのままで無料で利用できることに気づいた。Invoice Ninjaexisted, was open-source, and did 90% of what he needed out of the box. For free.
その通話は今でも少し頭に残っている。というのは、正直なところ、私は逆の間違いも犯しているからだ。Seahawk は2019年に5つの異なる SaaS ツール — Airtable、Zapier、Typeform、HubSpot、そしてカスタム Webflow CMS — をつなぎ合わせて、クライアントワークフローを管理するのに8ヶ月を費やすプロジェクトがあった。振り返ってみると、£15,000のカスタム構築がシンプルで永続的に解決していただろう。最終的に、組み合わせたサブスクリプション料金は月々約£900だった。3年間の支払いを計算してみてほしい。
どちらの極端も自動的に正しいわけではない。そして「常に構築しろ」「決して構築するな」というクリーンなルールを売りにしている人は、何かを売ろうとしている。というわけで、創業者が私のもとに座ってこの質問をしてくるときに、私が使う実際のフレームワークがここにある。
---
まず、実際に何を決めているのかを認識する
これは技術的な決定ではない。正直に言えば、違う。技術の服を着た経営判断だ。
「自分たちで作るべきか、買うべきか」と問う時、実は「差別化はどこにあるのか」と問うている。検討している機能が競争優位の中核であり、ユーザーが他のタブではなくお前たちを選ぶ理由なら、自分たちで作る価値がある。インフラ、管理、汎用的な機能なら、買う方がほぼ確実に実質的に安い。reasoncustomers will choose you over the next tab in their browser — then building probably makes sense. If it's infrastructure, admin, or commodity functionality, buying is almost certainly cheaper in real terms.
ファウンダーには最初にこう聞く。「ユーザーはこれを目にするか」。答えが yes で、その体験に実質的な影響を与えるなら、作る価値があるかもしれない。バックオフィス、運用、社内向けなら、作る際のハードルは非常に高くするべきだ。Will your users ever see this thing?If the answer is yes and it shapes their experience in a meaningful way, it might be worth building. If it's back-office, operational, or internal, the bar for building should be very high.
---
自分たちで作る実コスト（驚くほど過小評価されている）
ぶっちゃけ言う。カスタム開発は思ったより高くつき、言われるより時間がかかり、誰も予算を組まない継続的な保守が必要だ。
ファウンダーが価格計算に入れ忘れるもの
- 保守とホスティング。一度限りではない。その機能をやめるまで、ずっと責任を負う。Not a one-off. You're on the hook forever unless you sunset the thing.
- セキュリティパッチ。SaaS ベンダーはこれをやってくれる。自分たちで作れば、深夜の 2 時のアラートを含め、全部自分のものだ。A SaaS vendor handles this for you. You build it, you own it, including the 2am alerts.
- 新しい開発者のオンボーディング。リード エンジニアが去れば、次の人はお前たちのコードベースを学ぶ必要がある。それは何週間分もの請求対象時間だ。If your lead engineer leaves, the next person needs to learn your codebase. That's weeks of billable time.
- スコープクリープ。ステークホルダーはカスタムツールを見ると、それが何でもできると思い込む。スコープが拡大する。コストがそれに続く。Stakeholders see a custom tool and assume it can do everything. Scope expands. Costs follow.
私が使う大まかなルール：初期の開発見積もりを取り、現実的な納期のために1.6倍にして、その数字の年間保守費用として20%を加える。それらの数字でもビジネスケースが成り立つなら、素晴らしい。そうでなければ、答えが出ている。
正直なところ、Standish GroupのCHAOS Reportは数十年間、ソフトウェアプロジェクトが予算を驚くほどのペースで超過していることを示し続けている。「課題がある」か完全に失敗するプロジェクトは45～50%だ。これは決して構築しない理由ではない。冷徹な目で臨む理由だ。Standish Group's CHAOS Reporthas been showing for decades that software projects overrun their budgets at an alarming rate. The number sits around 45-50% of projects being "challenged" or outright failing. That's not a reason to never build — it's a reason to go in clear-eyed.
---
SaaSの本当のコスト（やはり過小評価されているが、理由は異なる）
SaaSは安く見えるが、そうでなくなる時点までだ。
年の初めに妥当に思えた£49/月のプランは、3年目までに£490/月になる傾向がある。より高いティアに移行すれば、シート数が増え、ベンダーは「料金体系の再構築」（つまり値上げ）をやる。SalesforceやIntercom、Mixpanelのクライアントでこれを見てきた。悪意があるわけではない。ただSaaS経済学の仕組みがそうなっているだけだ。
ファウンダーが陥るSaaSの3つの罠
- ベンダーロックイン。データは彼らのフォーマット、スキーマ、エクスポートフローにある。抜け出すのは苦しく、時には大規模なデータエンジニアリング作業なしでは事実上不可能だ。Your data is in their format, their schema, their export flow. Leaving is painful and sometimes effectively impossible without significant data engineering work.
- フランケンスタック複雑性。Zapierで「何とか統合」する5つのツールはシステムではない。それはリスクだ。1つのAPI廃止で物事が崩れ始める。Five tools that sort-of integrate via Zapier is not a system. It's a liability. One API deprecation and things start falling apart.
- サブスクリプションの蔓延。ツールスタックを年に一度監査する人はいない。監査すべきだ。去年12人のエージェンシーの監査を実施したところ、月額£3,200分のSaaSが使われなくなっていたか、各々1つの機能だけに使われていた。Nobody audits their tool stack annually. They should. I ran an audit for a 12-person agency last year and found £3,200/month in SaaS they'd either stopped using or were using for one feature each.
とはいえ——商用機能については、SaaSがほぼ常に正しい選択だ。メール配信？PostmarkかSendGrid。支払い？Stripe、当然。認証？Auth0かClerk。2024年に誰も自分たちの決済プロセッサーを構築すべきではない。Postmarkor SendGrid. Payments? Stripe, obviously. Auth? Auth0 or Clerk. Nobody should be building their own payment processor in 2024.
---
実際に機能するフレームワーク
さて。ここが私の考え方だ。4つの質問を順番に。
質問1：これは競争上の差別化要因か？
はいなら——これがあなたの製品を本当に異なるものにする要素なら——構築を本気で検討する価値がある。いいえなら、ここで止める。買う。
質問2：十分なSaaS代替案は存在するか？
完璧ではなく、十分なもの。創業者たちは「我々に必要なことを正確にこなすものが何もない」という理由で構築することがよくある。時にそれは本当だ。多くの場合、それは彼らが十分に探していない、または「これをよく設定する必要がある」を「何か新しい構築が必要」と混同していることを意味している。
カスタム構築を勧める前に、SaaS市場を少なくとも2時間は調査する。Product HuntとG2はここで本当に役立つ——聖書としてではなく、初期の候補リストとして。Product Huntand G2 are genuinely useful here — not as gospel but as a starting inventory.
質問3:現実的な価値実現までの期間はどのくらいか？
SaaSツールは今日にでも運用開始できます。カスタム開発は最短でも数週間、通常は数ヶ月かかります。スピードが重要な場合——初期段階の企業ではほぼ常にそうですが——購入することで、実装前に本当に必要なものを学ぶ時間を買うことができます。
2022年、Seahawk Mediaはルート最適化ダッシュボードのカスタム開発を希望していたロジスティクススタートアップと協力しました。まずホワイトラベルAPI層を使うよう説得しました（Route4Meをスタート地点として使用）。6ヶ月後、彼らは顧客が本当に必要とする3つの機能が正確に何かを知っていました。最終的に依頼したカスタム開発は、スコープが半分で——2倍優れていました——なぜなら彼らは仕様書ではなく実装環境で学んでいたからです。Route4Meas a starting point). Six months later, they knew exactly which three features their customers actually cared about. The custom build they eventually commissioned was half the scope — and twice as good — because they'd learned in production rather than in a spec document.
質問4:これが破損したらどうなるのか？
必ず破損します。問題は誰が直すのか、どのくらい早く直すのかということです。SaaSなら、サポートチケットを送信してTwitterで文句を言います。カスタムソフトウェアなら、開発チームに電話します。開発チームを確保していない場合、問題が生じます。これは仮定の話ではありません——フリーランサー開発者が休暇に行ったため、創業者がカスタムソフトウェアの不具合で数週間立ち往生するケースを何度も見てきました。
---
構築が明らかに正解である場合
カスタム開発が明らかに正しい状況があります。明確に名前を挙げましょう。
- 中核的なIPがソフトウェア自体である。SaaSプロダクトを売っている場合、売っているものをアウトソースすることはできません。If you're selling a SaaS product, you can't outsource the thing you're selling.
- 規制要件があり、既成品では対応できない。特定のフィンテック、ヘルスケア、法務アプリケーションには、ほとんどのSaaSツールが満たすように構築されていないコンプライアンス制約があります。Certain fintech, healthcare, and legal applications have compliance constraints that most SaaS tools aren't built to satisfy.
- すでにSaaSツールで検証済みで、必要なものが正確にわかっている。カスタム構築を発注する前のベストポジションだ。This is the best possible position to be in before commissioning a custom build.
- SaaSの料金は規模が大きくなると、オーナーシップより本当に高くなる。3年目の予想使用量で計算してみてほしい。カスタムが純粋な経済性で勝つこともある。Do the maths at your projected Year 3 usage. Sometimes custom wins on pure economics.
---
購入が明らかに正解な場合
同様に、購入が明白な状況もある。
- 売上がないか、プロダクト・マーケット・フィットに達していない。それだけだ。
- その機能はメール、決済、認証、ストレージ、分析といったコモディティインフラだ。
- 来年ではなく今四半期に機能させる必要がある。
- チームに社内エンジニアリング能力がなく、適切に人を雇う余裕がない。
付け加えるなら、より困難なビジネス判断から目をそらすためにファウンダーとして構築しているなら、それは検討する価値がある。カスタム構築は非常に高くつく先延ばしになり得る。to avoid making a harder business decision, that's worth examining. Custom builds can be a very expensive form of procrastination.
ハイブリッドアプローチ（多くの場合、最善の選択肢）
ハイブリッドアプローチ（多くの場合、最善の選択肢）
誰もが十分に話さないことがある。構築と購入は相互排他的ではないということだ。
何度も成功してきた最も現実的なアプローチはこうだ。商品化可能な部分は積極的に購入し、その上に差別化されたロジックの薄い層を構築する。CRMはHubSpot。サポートデスクはIntercom。だが、それらを繋ぎ、お前の特定のプロセスを自動化するカスタムワークフローエンジン？それは6ヶ月ではなく、2週間のカスタム開発だ。
Seahawk Mediaでは、購入したプラットフォーム——WordPressの上に、本当に新規性のあることをするカスタムプラグインを何百もの実装をしてきた。プラットフォームが80%を担当する。我々が構築するのは重要な20%だ。つまらないアドバイスに聞こえるかもしれない。だが、最も頻繁に成功したアドバイスでもある。
---
よくある質問
自分のユースケースがカスタム構築を正当化するほど本当にユニークかどうか、どうやって判断すればいいのか？
正直な答え。ほとんどはそうではない。まず真剣に午後を費やしてほしい。20分ではなく4～5時間だ。お前のカテゴリーのSaaSプロダクトをすべてマッピングすること。それをやった上で何もお前の中核要件をカバーしていなければ、その要件が本当に今すぐ必要なのか、それとも単にお前が優先度を上げて実装の阻害要因に変えてしまった気持ちいい機能なのかを問い直してほしい。本当に必要で、本当に対応されていなければ、それは真摯に受け止める価値のあるシグナルだ。necessary right nowor whether it's a nice-to-have you've elevated into a blocker. If it's truly necessary and truly unserved, that's a signal worth taking seriously.
カスタムソフトウェアを責任を持って保有するのに必要な最小限のチームサイズはどのくらいか？
最低限として必要なのは、コードベースを深く理解している開発者1名と、その人が対応できない時にカバーできる2番目の開発者か契約している代理店です。カスタムソフトウェアを単一のフリーランサーで、バックアップなしで運営することは非常に脆弱です。その1人が対応できなくなった時 — 休暇、病気、より良い転職オファー — に実際の業務ダメージが発生するのを何度も見てきました。
社内で構築すべきか、それとも代理店に構築させるべきか？
ほぼ完全に、ソフトウェアがあなたのコア事業かどうかで決まります。ソフトウェア企業であれば、最初は代理店を使うにしても、最終的にはほぼ確実に社内開発を望むことになります。ソフトウェアが事業そのものではなく、事業をサポートするツールであれば、適切なSLAを備えた代理店関係は、通常、エンジニアをフルタイムで雇うよりもコスト効率が高いです。
オープンソースは構築と購入の間の中間的な道か？
そうです。そしてそれは過小利用されています。分析用のMetabase、ヘッドレスCMSのDirectus、運用用のERPNextのようなツールは、カスタムソフトウェアの柔軟性を提供しながら、初期構築コストを大幅に削減します。ただし注意点として、インフラストラクチャの所有はあなたのままであり、それを管理できる技術者は必要です。無料ではありません — 単に開始が安いだけです。Metabasefor analytics, Directus for headless CMS, or ERPNext for operations give you the flexibility of custom software with significantly lower initial build cost. The catch: you're still owning infrastructure and you still need someone technical to manage it. It's not free — it's just cheaper to start.
---
最後に
構築対購入の質問には、唯一の答えがあるのではなく、あなたの答えがあります。それはあなたの段階、チーム、競争ポジション、そしてこれまでに実際に検証したものに固有のものです。youranswer, specific to your stage, your team, your competitive position, and what you've actually validated so far.
私が異議を唱えたいのは、構築についてのロマンティシズムです。カスタムソフトウェアが、よく設定されたSaaSスタックより、本来的にもっと真摯で、もっとスケーラブルで、もっと印象的なわけではありません。最初に言及した請求書関連の創業者ですか？彼は最終的に本当にカスタムなものを構築しました — ただし、Invoice Ninjaを18か月間使用して、顧客が実際に何を必要としているのかを正確に学んだ後です。待った分、その構築はより優れていました。
つまらない選択肢で始めましょう。新しいものを構築する権利を勝ち取ってください。