BtoB開発における「システム設定」の功罪と、持続可能なプロダクトへの道

BtoBソフトウェア開発において、顧客ごとの細かな要望に応える「システム設定」。それは多様なニーズに対応できる強力な武器であると同時に、開発チームを際限ない複雑さの沼に引きずり込む、諸刃の剣でもあります。

本記事では、多くの開発者が一度は直面するであろう、この「システム設定」がもたらすカオスな世界と、その中で生き抜くための設計と思想について探求します。

1. システム設定とは何か？

システム設定とは、アプリケーションの挙動をソースコードの変更なしに動的に切り替えるための仕組みです。特にBtoBの領域では、顧客の独自の業務フローや商習慣、社内ルールに対応するために、これらの設定が多用されます。

具体的な設定の例：

• UIのカスタマイズ: 企業のロゴやテーマカラーの変更、ダッシュボードに表示するウィジェットの選択。
• 業務ロジックの分岐:
  • 承認フローのステップ数（3段階承認か、5段階承認か）。
  • 消費税の計算ロジック（切り捨て、切り上げ、四捨五入）。
  • 特定の条件下でのアラート通知のON/OFF。
• 機能の有効化/無効化: 特定の顧客にのみ高度な分析機能や連携モジュールを提供する場合の切り替え。
• 文言の変更: 画面に表示されるラベルやメッセージを顧客の業界用語に合わせる。

2. なぜ「カオスなシステム設定」は生まれるのか

BtoBビジネスの宿命とも言える構造が、複雑なシステム設定を生み出す土壌となっています。

• 顧客は「自社の業務」のシステム化を望む: 多くの企業は、システムに業務を合わせるのではなく、自社の既存のやり方をそのままシステムでトレースしたいと考えます。この「個別最適」の要求が、カスタマイズの源泉となります。
• 業務とシステムの混同からくる安全要求: 特に製造業などで顕著ですが、顧客がシステムと実際の業務プロセスを同一視し、「より安全に」「万が一に備えて」といったフェールセーフ思想をシステムに強く求めることがあります。これが、標準パッケージの挙動を変更するためのカスタマイズ要求につながります。
• 営業的な判断: 「その機能、設定で対応できます」という一言が、大型契約の決め手になることがあります。目の前のビジネスチャンスを逃さないために、将来の技術的負債を承知で安易な設定追加を約束してしまうケースは後を絶ちません。
• 「汎用化」という名の妥協: 一つの製品（ワンソース）で多様な顧客をカバーしようとすると、それぞれの違いを吸収するために、どうしても設定項目が増えていきます。

3. システム設定がもたらす光（メリット）

もちろん、システム設定はビジネス上の強力な武器となります。

• 柔軟な顧客対応: 一つの製品で、多様な顧客ニーズや業界特有の要件をカバーできます。
• 市場拡大: 対応できる顧客セグメントが広がり、ビジネスチャンスが増大します。
• 顧客満足度の向上: 「自分たちの業務にフィットしたシステムだ」という感覚を提供でき、顧客ロイヤリティを高めます。

4. システム設定がもたらす闇（デメリット）

しかし、その裏側では開発現場に深刻な「闇」をもたらします。

• コードの複雑化と分岐地獄:
  ソースコードは無数の if 文で埋め尽くされます。

  // 典型的な設定地獄のコード
  public void executeProcess(Data data) {
      if (customerSetting.isOptionAEnabled()) {
          // Aの処理
          if (customerSetting.isSubOptionXEnabled()) {
              // A-Xの特殊処理
          }
      } else {
          // 標準処理
      }
  
      if (customerSetting.getProcessMode() == ProcessMode.MODE_B) {
          // Bモードの処理
      }
      // ... 無限に続く設定の分岐
  }
  

  このようなコードは可読性が著しく低く、機能追加や修正を困難にします。

• テストの組み合わせ爆発:
  設定項目が10個あるだけで、理論上の組み合わせは 2^10 = 1024 通りになります。すべての組み合わせをテストすることは非現実的です。結果として、「設定Aと設定Bを同時に有効にした場合にのみ発生する」 といった、再現困難なバグの温床となります。単体テストのカバレッジが100%であっても、全く安心できません。

• 著しい保守性の低下:

  • 影響範囲の不明瞭化: ある設定を変更した場合、どの顧客のどの機能に影響が出るのかを正確に把握することが極めて困難になります。
  • 学習コストの増大: 新規参画した開発者は、膨大な設定項目とその意味、そしてそれらがコードのどこに影響するのかを理解するだけで多大な時間を要します。
  • 「死んだ設定」の発生: かつて特定の顧客のために作られたものの、今では誰も使っていない設定が残り続け、コードを複雑化させます。

コラム：現場の攻防 —「編集不可」という幻想

この記事で解説した「闇」を具体的に示す、現場で実際にあった議論を紹介します。ある顧客から、こんな要望が上がりました。

「一度登録した検査結果は、あとから編集できないようにしてほしい」

一見すると、データの改ざんを防ぎ、信頼性を担保するための正当な要求に聞こえます。顧客が求めるのは「不正ができない」という安心感です。

しかし、開発チームはこの要求に警鐘を鳴らします。

• 運用上の現実: 人間である以上、入力ミスは必ず発生します。その度に管理者に連絡して修正を依頼するフローは、現場の業務を著しく滞らせます。結果として、現場のユーザーに管理者権限を委譲するようになり、元の木阿弥です。
• 真の解決策は「追跡可能性」: データを「編集不可」にするのではなく、「誰が、いつ、何を、どのように変更したか」をすべて記録する**トレーサビリティ（追跡可能性）**を確保することこそが、柔軟な運用と統制を両立させる最善策です。不正な操作が行われたとしても、その記録が残るため、強い抑止力として機能します。
• 問題の根本原因: そもそも、検査データの不正はなぜ起きるのでしょうか。多くの場合、検査員個人の意思ではなく、納期や品質目標のプレッシャーといった組織的な問題が背景にあります。システムの入り口を固めるだけでは、根本的な解決にはなりません。

この議論の核心は、「思想レベルの重要な分岐を、安易なシステム設定にしてはいけない」という点にあります。

もし「編集可／不可」をシステム設定で切り替えられるようにした場合、それは実質的に思想の異なる2つのプロダクトを内包するのと同じです。この設定は、将来追加されるあらゆる機能（承認ワークフロー、データ集計など）と複雑に絡み合い、確実にバグの温床となります。

営業担当者は「運用でカバーできます」という提案が顧客に響きにくいことを知っているため、「設定で対応できます」と安易に約束してしまいがちです。しかし、その一言がプロダクトを死に至らしめる毒となりうることを、開発者は知っています。

この事例は、目先の要求とプロダクトの長期的な健全性との間で、開発チームがいかに難しい舵取りを迫られているかを示しています。

5. システム設定地獄に陥らないための処方箋

では、どうすればこの地獄を避けられるのでしょうか。

• 原則1: 安易な設定追加を許容しない文化を作る
  「設定で対応します」と言う前に、その要求が本当に多くの顧客にとって価値があるのか、標準機能として実装すべきではないかをチームで議論することが重要です。特定の1社のためだけであれば、個別開発として切り分ける勇気も必要です。

• 原則2: 設定の影響範囲を限定する
  アーキテクチャレベルで、設定が影響を及ぼす範囲を局所化する工夫が求められます。例えば、設定のON/OFFでロジックの大部分が入れ替わるような場合は、if文で分岐させるのではなく、Strategyパターンなどを利用して、振る舞いそのものを注入する設計を検討します。

  // Strategyパターンによる改善例
  // Contextクラスが、設定に応じたStrategy（実装）を注入して実行する
  IProcessStrategy strategy = strategyFactory.create(customerSetting);
  strategy.execute(data);
  

• 原則3: 設定を管理する台帳を必ず作る
  どの設定が、どの顧客で、どのような値で、なぜ使われているのかを記録したドキュメントは必須です。これがなければ、設定の棚卸しや影響調査は不可能になります。

• 原則4: 設定の追加・変更に厳格なレビュープロセスを設ける
  新しい設定を追加することが、将来どれだけの技術的負債を生む可能性があるかを評価し、ビジネスサイドと開発サイドが合意の上で決定するプロセスを確立すべきです。

• 原則5: デフォルトは緩やかに、導入ハードルを徹底的に下げる
  BtoBソフトウェア導入時の最大の壁は、初期設定とマスタ登録の煩雑さです。そのため、製品の標準動作（デフォルト）は、制約を可能な限り緩く設計することが極めて重要です。例えば、必須項目を最小限にしたマスタ登録、柔軟なデータ編集を許容する設定などをデフォルトとします。最初の導入ハードルを徹底的に下げることで、顧客はすぐに製品を試し、価値を実感し始めることができます。厳格な制約や統制は、あくまで顧客が必要とした場合にのみ有効化できる「オプトイン」のオプションとして提供するべきです。

究極の理想形：カスタマイズをしないという選択

システム設定地獄を回避する最も根本的な方法は、そもそもカスタマイズや設定に頼らないプロダクトを作ることです。これは、**「私たちの製品が、この業務のベストプラクティスです」**という強い思想（Opinionated Software）を掲げ、その思想に共感する多くの顧客に届ける戦略です。

では、その「ベストプラクティス」は誰が定義するのでしょうか。ここで有効なのが、外部の専門家、すなわち経営コンサルタントや業務コンサルタントの活用です。彼らは多くの企業の業務を見てきた知見を活かし、特定の業界における標準的で、かつ最も効率的な業務フローを客観的に設計することができます。

そのコンサルティングによって定義された「理想の業務フロー」を、そのままソフトウェアとして具現化するのです。このアプローチでは、顧客は単なるツールではなく、専門家によって検証された業務改善パッケージを手に入れることになります。これにより、「自社のやり方を変えてでも、この製品を導入したい」という強い動機付けが生まれます。

このアプローチのメリットは絶大です。

• 開発のシンプルさ: 複雑な分岐がなく、単一のコードベースを磨き込むことに集中できます。
• 圧倒的な開発スピード: 全ての改善が、全顧客への価値提供に直結します。
• 強力なプロダクトブランド: 「〇〇するなら、この製品」という確固たる地位を築きやすくなります。

もちろん、これは簡単な道ではありません。自社の思想に合わない顧客を「断る勇気」や、営業・マーケティングを含めた会社全体での強い意志が不可欠です。しかし、システム設定という名の魔境に足を踏み入れないための、最も確実で理想的な道筋と言えるでしょう。

結論: BtoBにおける汎化の難しさと、それでも前に進むために

BtoBソフトウェア開発において、システム設定を完全になくすことはおそらく不可能です。ビジネスの要求と開発の健全性の間で、常にバランスを取り続ける必要があります。

重要なのは、システム設定を「魔法の杖」ではなく「管理すべき負債」として認識することです。一つ一つの設定がもたらす価値とコストを天秤にかけ、戦略的に導入し、そして勇気を持って廃止する。その規律こそが、持続可能で健全なプロダクト開発の鍵となるのです。