フィーチャーフラグのデメリット
ここまでフィーチャーフラグのメリットを説明してきましたが、導入する前に考慮すべきデメリットも存在します。
コード量の増加
フィーチャーフラグを導入すると、フラグの取得、判定のためにある程度のコードを記述する必要があります。またフィーチャーフラグシステムにはSDKを介して利用するものもあり、外部ライブラリのインストールや初期化のためのコードを記述する必要があります。
フラグの管理コスト
フィーチャーフラグをある程度の規模でしばらく運用していると、フラグの数がしだいに増えていき、管理が複雑になってきます。
フラグが使用されているかどうかの確認が必要
どのフラグがコードに含まれているか、どのフラグが実際に使用されているか等を組織内で明確に把握しておかないと、管理すべきフラグの数が増えていき運用ミスやバグの発生に繋がります。
フラグ同士が依存してしまう
さらにコード中のフラグ数が増えていくと、予期せぬ場合にフラグ同士が依存してしまい障害となる場合もあります。これはスコープが異なる場所で同じフラグを使用したり、ロジック内でフラグを入れ子にしたりした場合で多く発生します。たとえば、A、B、Cの3つのフィーチャーフラグが存在し、Aがある値の場合はBの値は特定の値になり、さらにBの値がCの値にも影響をあたえるように実装するといったケースです。こうしたフラグ同士の依存性は容易にバグの温床となり、アプリの予期せぬ振る舞いを誘発します。
学習コストやサービス導入のためのコスト
フィーチャーフラグを導入する際には少なからずコストが発生します。フィーチャーフラグを導入するには開発に関わるメンバーがしっかりとメリットとデメリットを把握しておくために学習コストを払う必要があります。また、すべてのシステムに言えることですがフィーチャーフラグ導入には時間とお金がかかります。
開発責任者は導入にあたり、プロダクトの未来を合理的視点から判断することが求められます。
内製か購入か
フィーチャーフラグを導入する際にもっとも重要な判断の1つはフィーチャーフラグを内製するか、それとも外部のサービスを購入するかです。
内製する場合は、自前でフィーチャーフラグシステムを開発する場合は自社プロダクトのニーズに柔軟に応えられたり、スケールするとコストが比較的抑えられたりといったメリットがあります。一方、インフラからSDKまで自分たちで用意する必要があるため、それなりの投資と専門知識が必要になります。
購入する場合は、既存のサードパーティーを購入する場合のメリットは、すぐに使い始めることができる点です。多くのサービスは管理画面の登録とアプリへのSDKの導入を行えばすぐにフィーチャーフラグを使い始められることができます。デメリットして大きな点は自社プロダクトのニーズに完璧には応えることができないということです。コスト面では、大規模かつ長期的に利用した場合に内製を超えることが考えられます。
内製か購入かの判断はROI（Return On Investment）の観点に基づき、各プロジェクトで慎重に決定すべきです。一般的に導入した後に変更することは期待していたより大変な作業になることが多く、これは筆者の経験からも概ね正しいです。外部のサービスを変更する場合もそれなりのコストを伴います。将来を見据えて、内製と購入のコストと変化する機能要件に照らし合わせて決定する必要があります。
内製か購入かの議論は本連載の次回以降でも詳細に解説する予定です。
まとめ
以上、本記事ではフィーチャーフラグの概要とユースケース、導入するメリットとデメリットを解説しました。
信頼性を保ちながら開発サイクルのスピード感を持って進めていくことが求められる現在のソフトウェア開発において、DevOpsと共にフィーチャーフラグの重要性は日に日に高まっており、多くの企業で採用されて効果を上げています。
フィーチャーフラグのアイデアはシンプルですが、開発プロセスの改善から本番環境におけるABテストまで、大きな可能性を開発者に与えます。もし自社プロダクトに導入していない場合は是非検討してみてください。
次回からはフィーチャーフラグについてより実践的で詳細な解説を行っていきます！
