フィーチャーフラグのハードコーディングは問題ない（2025年）

フィーチャーフラグのハードコーディングは問題ない

フィーチャーフラグ（またはトグル）は、製品の新機能の可視性を制御するためによく使用されます。実装方法にはいくつか種類がありますが、最も話題になりマーケティングされているのは、フィーチャーフラグ管理ソフトウェアを使用する方法です。もちろん、最もシンプルな方法はハードコーディングですが、これについてはあまり書かれていません。

フィーチャーフラグ管理ソフトウェアは強力になり得ますが、同時に複雑さとリスクの原因にもなります。それらの背後にあるブログスパム的なマーケティングは非常に強力で、それらが不要であることを認めることは、技術的な無力感を告白するようなものです。私たちは、単にいくつかのフィーチャーフラグが必要なだけでなく、数千ものフィーチャーフラグにスケールする必要があると確信させられています。それだけでなく、実行時に機能を変更する必要があり、デプロイ、再起動、キャッシュフラッシュ、データベースマイグレーション、レビュー、テストなしでそれを実行しなければならない、なぜならビジネスが炎上しており、それを消火する唯一の方法はホームページのボタンの色を変更することだからです。

そのようなシステムの機能がもたらすべきフラグは、#ff0000 の種類のものだけです。アーキテクチャの観点からは、それらは独立したプロセスで管理される、飾り立てられた if 文にすぎません。多くの場合、独自のインフラストラクチャ、ホスティング、監視、およびそれに伴うすべての責任が必要となります。

開発ライフサイクルの観点からは、非決定的な動作を導入し、コードの理解を困難にします。長期にわたるフィーチャーフラグは、当初は善意で設定されても、コードベースを硬直化させる技術的負債につながります。このリスクはハードコーディングされたフラグでも存在しますが、はるかに見やすく管理しやすいです。

セキュリティの観点からは、攻撃や脆弱性の表面積が増加するため、リスクとなります。

いずれにしても、ソフトウェアシステムにさらに多くの可動部品を追加する際には、それが実際に必要かどうか、そしてそれが解決しようとしている問題に見合うリスクをもたらすかどうかを常に精査する必要があります。

ハードコーディングされたフィーチャーフラグは、これらの問題の多くを解決します。それらはシンプルで、信頼性が高く、安全です。それらは最も退屈な方法であり、だからこそ最良の方法なのです。

単純なJSONファイルから始め、アプリケーション起動時に読み込み、機能の可視性を制御するために使用します。フラグを常に把握し、不要になったら削除します。もしフラグが長期間存続する場合は、それを実際の動作にし、フラグを削除します。通常の開発プロセスを通じて値を変更し、レビュー、テスト、デプロイを行います。

ほとんどのチームや製品にとって、これは十分であり、多くの場面で役立つでしょう。チームが実際に大規模な実行時機能変更の必要性に直面したとき、SPAの状態管理と同様に、それが必要であることを知るでしょう。

時期尚早な最適化は進むべき道ではありません。それは悪い設計であり、悪いエンジニアリングであり、テックカンファレンスで、セールススピーカーが誰か使用しているか尋ねたときに、短い自己満足の瞬間を提供するだけです。