カスタム開発かパッケージ製品か？ B2B の意思決定ガイド

まずの分岐：標準か、御社の差別化要因か。

経理、メール、給与 — これらは標準業務で、数千社が同じように回します。パッケージ製品（SAP、QuickBooks、Workday など）は成熟・安全・安価で、ここで自作するのはたいてい無駄です。

しかし、御社を競合と分けている部分 — 独自の価格算定ロジック、特定顧客との専用連携、独自の業務フロー — は、パッケージに押し込んだ瞬間に没個性になります。実際に価値を生んでいる 20 % がゼロ % へと落ちます。ここではカスタム開発が不可欠です。競合と同じ道具を使う者は、同じ結果しか出せません。

実用的な 4 つの問い

結論を出す前に、次の 4 つに答えてください。

1）その業務は業界標準か、貴社固有か。 2）データモデルは外部（請求、連携）と共に変わるか。はい → パッケージや API が開いた SaaS で十分。 3）この業務を取り巻くビジネスモデルは 24 か月以内に変わるか。はい → パッケージの設定上限がボトルネックになる。 4）競争優位はこの業務の中に隠れているか。「なぜお客様が私たちを選ぶのか」を説明するとき、この業務に言及するなら、カスタム開発は必須。

「差別化」に当たる回答が 2 つ以上（独自性・隠れた競争優位）あれば、カスタムが正解。なければ、まずパッケージから始めて、天井に当たったら移行する。これが最も費用対効果が高い戦略です。

ハイブリッド戦略：もっとも現実的な選択

実務では、B2B の判断の多くは「全部カスタム」でも「全部パッケージ」でもなく、両者を賢く組み合わせた形になります。定石：標準レイヤ（経理、人事、CRM の背骨、メール）は業界最高のパッケージで回し、差別化レイヤ（価格エンジン、顧客ポータル、業務フロー、データ変換）をカスタム開発し、API でパッケージと連携させます。

これにより三つの利点が得られます。(1) コモディティ層でベンダーの安全性と低い TCO、(2) 差別化層での完全な統制と高速な反復、(3) 各層が独自のペースで進化する。実装形態はたいてい「SaaS + API + 薄いカスタムアプリケーション層」に落ち着きます。成長とともにカスタム層は広がり、パッケージ層は安定したままです。Setviva ではおよそ 70 % のお客様がハイブリッドで始めます — 完全カスタムを希望される方も、業務フローを整理するとパッケージへ標準業務を移す選択を取られることが多いです。

移行コストを正しく見積もる

B2B 意思決定者がもっともよく犯す誤り：ライセンス料やプロジェクト価格だけを比較してしまうこと。本当のコストは水面下にあります。パッケージに移行する場合は次を加算してください：データ移行とクレンジング、研修、移行期間中の生産性低下、連携開発、レポートのカスタマイズ、業務プロセスの再設計。通常これらの合計はライセンス料の 3〜5 倍になります。カスタムに移行する場合は次を加算してください：設計と discovery、開発、テスト、研修、保守と継続的な反復、インフラ（サーバー、監視、バックアップ）、所有リスク（チームが離れても誰が運用するか）。通常これらの合計は開発費の 1.5〜2 倍になります。

公平な比較のために、24〜36 か月の総所有コスト（TCO）を書き出し、両方を同じ土俵で並べてください。Setviva のご提案ではこの項目別 TCO を最初から提示し、判断を「本当に安い」に根ざさせ、「安く見える」に寄りかからないようにしています。移行コストを正しく見積もることは、選択そのものよりも重要になり得ます。

ロックインのリスクは双方向に働く

意思決定者の誰もが「今いくらかかるか」を尋ねますが、「3年後、誰が自分に対して主導権を握っているか」を尋ねる人はほとんどいません。SaaSでは、ロードマップを書くのは自社ではなくベンダーです。契約が更新されるたびに値上げされ、そのツールが日々の業務に組み込まれるほど値上げ幅は急激になり得ます。機能は廃止されたり上位プランに移されたりし、ベンダーが買収されて、自社が選んだわけでもないスケジュールで製品が終了することもあります。これはどれも仮定の話ではなく、ソフトウェアベンダーのごく普通のライフサイクルです。そして、あるツールが業務に深く組み込まれるほど、たとえ価格が3倍になったとしても、離れることは高くつくようになります。だからといってSaaSを避けるべきだという話ではありません——標準的な業務であれば、それでも多くの場合正しい選択です——しかし「月額料金」の比較は、本当に問われるべき問いを隠してしまいます。自社とは利害が一致しない相手に、どれだけの主導権を渡そうとしているのか、ということです。

カスタムソフトウェアは、この主導権の問題を内側に向けます。リスクはもはやベンダーのロードマップではなく、自社チームのバス因子（特定の人物への依存度）になります。システムを構築した開発者が離れ、その背後にある意思決定が文書化されていなければ、そのシステムは誰も触りたがらないブラックボックスへと静かに変わっていきます。保守されないまま放置されれば、依存関係は古くなり、セキュリティパッチは当たらなくなり、やがて「カスタム」は、本来避けたかったはずのもの——脆弱でレガシーなシステム——そのものになってしまいます。ここでのロックインは契約条項ではなく、知識の集中ですが、効果は同じです。高い代償を払わなければ離れられないのです。

対策は、初日から双方について「離脱コスト」を判断基準として扱うことです。SaaSであれば、契約前にどのデータをどの形式でエクスポートできるか、契約が値上げに上限を設けているか、実際に解約するとどれほど困難になるかを確認してください。カスタムであれば、ソースコードの所有権、インフラへのアクセス権、最新のドキュメントを、好意ではなく契約上の成果物として求めてください。そして、デモのためだけでなく、次にシステムを引き継ぐ人のためにコードを書くパートナーを選んでください。どちらの道を選ぶにせよ、購入の問いより先に、離脱の問いを立ててください。今日いちばん安く見える選択肢よりも、いつでも離れられる選択肢のほうが価値があります。