顧客ごとのカスタマイズ要求への対応──機能フラグとテナント分離のコスト比較

「この顧客だけ別の仕様で」という要求が増えている

営業から「A社はこの機能が必要」「B社は逆にこれは不要」という相談を受けることが増えました。単一顧客向けシステムならまだしも、複数の顧客に同じプロダクトを提供している場合、こうした要求への対応方針は開発の持続性を左右します。

現場では大きく二つのアプローチが検討されます。一つは機能フラグ（フィーチャーフラグ）で本体コードの中で分岐させる方法。もう一つはテナント分離で顧客ごとに異なるシステム構成を持たせる方法です。どちらが正解かは、規模・顧客数・変更頻度によって大きく変わります。

機能フラグ：小回りは効くが、複雑性が潜む

機能フラグとは、コード内に条件分岐を埋め込み、設定値で機能のオン・オフを切り替える仕組みです。

if (featureFlags.enableAdvancedReporting) {
  // A社向けの高度なレポート機能
  renderAdvancedDashboard();
} else {
  // 標準レポート
  renderBasicDashboard();
}

メリットは明確です。デプロイは一度で済み、顧客ごとの設定変更は管理画面やデータベースで完結します。新しい顧客が増えても、既存のコードベースに新しいフラグを追加するだけです。開発チームが小さい場合や、顧客数が少ないうちは、この柔軟性は非常に価値があります。

しかし実装が進むと問題が顕在化します。

まず、テストケースが指数関数的に増えます。フラグが3つあれば2³＝8パターン、5つあれば32パターンです。全パターンの組み合わせをテストするのは現実的ではなく、結果として「よく使われるパターンだけ」が検証されるようになります。すると、ある顧客だけで起こるバグが本番で発見されるという事態が生まれやすくなります。

次に、コードが読みにくくなります。あちこちに分岐が散らばり、「この処理はどの顧客向けか」を追うのに時間がかかります。新しいエンジニアが参画する際の学習コストも増します。

さらに、フラグが増えると削除のタイミングが曖昧になります。「この機能フラグはもう使われていないのか」を確認するのに手間がかかり、結果として古いフラグがコードに残ったままになることが多いです。これが技術債として蓄積していきます。

現場では、機能フラグは「短期間の試験的機能」「段階的なロールアウト」に向いており、「顧客ごとの永続的な仕様違い」には向きにくいという判断が増えています。

テナント分離：責任が明確だが、運用負荷が重い

テナント分離とは、顧客ごとに異なるデータベース、異なるアプリケーション構成、あるいは異なるマイクロサービスのセットを持たせるアプローチです。

顧客A → DB_A + App_A (カスタマイズ版)
顧客B → DB_B + App_B (カスタマイズ版)

メリットは、顧客ごとの仕様を独立した形で実装できることです。A社向けの変更がB社に影響しません。テストも顧客ごとに完結でき、複雑な組み合わせを考える必要がありません。また、パフォーマンス調整も顧客ごとに最適化できます。

しかし運用コストが急速に増えます。

デプロイが複数回になります。共通部分を更新する際、全テナントへのデプロイが必要です。顧客が10社いれば、検証も本番反映も10回です。一つのテナントでリリース失敗が起きると、その顧客への対応に時間を割かれ、他の顧客のデプロイが遅延します。

データベース管理の負担も増します。バックアップ戦略、ディザスタリカバリ、アップグレード計画を顧客ごとに考える必要があります。ある顧客のDBスキーマ変更が他の顧客に影響しないよう注意する必要があり、これは予想以上に手間がかかります。

実装の重複も避けられません。共通機能であっても、各テナントで同じコードを保持する必要があり、バグ修正時は複数のテナントに同じパッチを当てる作業が発生します。

中小規模の開発組織では、こうした運用負荷を担う人員が限られているため、テナント分離は「顧客数が本当に多い」「顧客ごとの仕様差が本質的で大きい」という確信がある場合に限定すべきです。

現場で現実的な判断基準

実務では、次のような軸で判断することが多いです。

顧客数が3社以下なら、テナント分離を検討する価値があります。 顧客ごとのカスタマイズが本質的に異なり、共通部分を無理に抽出することが逆にコストになるためです。

顧客数が5社以上で、かつ顧客ごとの仕様差が限定的（特定の機能のオン・オフ程度）なら、機能フラグの方が現実的です。 ただし、フラグの数を意識的に制限し、3ヶ月ごとに使われていないフラグを削除するルールを決めておくべきです。

顧客数が10社を超えた場合は、より構造的なアプローチが必要です。 テナント分離の一種である「マルチテナント SaaS」の仕組み（共通のアプリケーション、顧客ごとのデータ分離、設定駆動の機能制御）を検討する段階です。

実装する際の注意点としては、どのアプローチを選ぶにせよ、顧客ごとの仕様差を「設定」として明示的に管理する仕組みが必須です。コード内に散らばった分岐ではなく、顧客マスタに紐付けた設定テーブルで「この顧客はこの機能が有効」を一元管理することで、後々の保守性が大きく向上します。

まとめ：スケールを見据えた早期判断

カスタマイズ要求への対応方針は、現在の顧客数だけでなく、今後の成長見込みを踏まえて決める必要があります。「今は機能フラグで対応」という判断も、顧客が増えるタイミングで設計を見直す覚悟があれば、悪くない選択肢です。重要なのは、その時点での判断根拠を記録しておき、状況が変わったときに軌道修正できる柔軟性を持つことです。