弊社ではクラウド型のWebアプリケーションパッケージシステムを開発しています。 基本的にはパッケージに搭載した機能のみを顧客に使用してもらいたいのですが、当然のようにカスタマイズ要望が生まれます。
カスタマイズ要望は、企業に特化した要件が多く、抽象的というよりは具体的な内容です。
具体的な要望でも、要件を整理して抽象度の高い汎用性のある機能に落とし込めればよいのですが、あまりにも特化した要望の場合はそれが出来ないことがあります。
とはいえ、これらを全て切り捨ててしまうと業務が回らないという自体になりますので、パッケージに影響の少ない方法で機能を提供できないかという課題が生まれます。
そのような場合にどのような開発手法的アプローチがあるのか考えてみたいと思います。
顧客ごとにブランチを分ける
パッケージとしての本ブランチ(master)と顧客ごとにブランチを作成する方法です。
- メリット：他顧客に影響ないのでカスタマイズを好き放題できる
- デメリット： ブランチの管理が大変。masterへのマージ、各ブランチへのマージなどの業務が発生して煩雑になる
マイクロサービス化する
カスタマイズ機能をマイクロサービス化する方法です。パッケージとはコードベースが別になります。アプリサーバーなども別に用意します。
- メリット：パッケージのコードベースの煩雑化を防げる。影響範囲が絞られるのでメンテナンス性が高い
- デメリット：マイクロサービスとして切り出す上で、アーキテクチャの見直しをしなければならない。複数コードベースを横断して開発する必要がある。
フラグで分岐させる
機能を使用するかどうかのフラグで処理を強引に分岐させる方法です。
- メリット：一番手っ取り早い、コードベースが小規模段階ではスピードをもって開発することが可能
- デメリット：コードベースが肥大化し、分岐処理によって複雑化する。しっかりテストを書かないと品質担保が難しい
我々の結論
我々の結論としては「フラグで分岐させる」を採用することにしました。
弊社のパッケージシステムの場合、まだ完全にはPMF(プロダクトマーケットフィット)していないプロダクトなので、スピードを重視したいためです。
メンテナンス性やデグレードの懸念については自動テストである程度担保できると判断しました。 理想は「マイクロサービス化する」ですが、現状ではそれを構築するほどのリソース確保ができていないので今回は見送りしました。
