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

最初の分岐：標準業務か、自社の強みか

標準的な作業では、まず製品が実際に対応できる範囲を試します。会計やCRMという名称だけでは、権限・帳票・連携が業務に合うとは限りません。

独自の業務でも個別開発が必須とは限りません。設定やAPIで一連のケースを試し、ブランドや差別化の印象ではなく、満たせない必須要件に基づいて判断します。

実用的な 4 つの問い

1）必要な入力・出力・例外処理は何か。 2）誰がデータにアクセスし、どう出力できるか。 3）件数や業務ルールが変わると、どこを変えるか。 4）停止時に誰が対応し、どう元の状態に戻すか。

各案に同じ受け入れテストを実施します。必須条件を満たさない案を除き、費用・保守・使いやすさを比較します。

併用が適するのはどんな場合？

既製CRMと独自の顧客ポータルは連携できます。ただしAPI利用権、上限、ライセンス、エラー処理を先に確認します。

正本となるシステム、重複処理の防止、同期失敗の担当を決めます。併用が必ず安価・安全になるわけではなく、連携全体の運用負担も含めます。

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

ライセンス・開発費に加え、設定、データ整理と移行、研修、連携、インフラ、監視、サポート、撤退費を列挙します。同じ範囲と期間で比較します。

見積もりを想定ユーザー数・処理件数で計算し、少量・大量の場合を分けます。固定保守率、一般的な倍率、確実な回収年数は仮定しません。不明な費用はゼロではなく、見積もり確認事項です。

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

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

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

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