Feature Toggleは、アプリケーションの機能を実行時にオン/オフする仕組みであり、開発者がコードを変更したり再デプロイしたりせずに機能の利用可能性を管理できるようにします。条件付きコンパイル(ifdef)とは異なり、toggleはランタイムレベルで動作し、動的に変更できます。Martin Fowler(2024年)によると、feature togglesはtrunk-based developmentと継続的デリバリーの重要な要素です。Feature toggleは、チームにリリースと実験の管理における柔軟性を提供します。
重要ポイント
Feature Toggleは、新しい機能のコードを条件構文でラップし、設定パラメータの値をチェックするテクニックです。パラメータがtrueの場合は新機能がアクティブになり、falseの場合は古いコードが実行されます。フィーチャーフラグとの主な違いは、toggleが複雑なターゲティングルールやトラフィック分散なしでオン/オフの原則で動作するバイナリスイッチであることです。
フィーチャートグルは、新しい機能の周りに単純なif構文として実装されます。Toggleの値はアプリケーション設定—環境変数、JSONファイル、またはデータベースに保存されます。アプリケーションの起動時に設定をロードし、機能の可視性に関する決定に使用します。最も単純なケースでは、toggleの値を変更するにはアプリケーションの再起動が必要ですが、本番システムでは通常、外部設定サーバーまたはAPIを介してホットリロードをサポートしています。
JavaScript(Node.js)でのフィーチャートグルの実装を見てみましょう。ToggleはJSON設定に保存され、サーバー起動時にロードされます。Middlewareは、リクエストを新しいハンドラーまたは古いハンドラーにルーティングする前にtoggleの値をチェックします。この実装により、現在のAPIバージョンを壊すことなく、メインコードブランチに新しい機能を追加できます。
const config = require("./config.json");
const toggles = {
get(name) {
return config.features[name] ?? false;
},
isEnabled(name, context) {
const toggle = config.features[name];
if (!toggle) return false;
if (toggle.enabled === true) return true;
if (toggle.percentage && context.userId) {
return hashCode(context.userId) % 100 < toggle.percentage;
}
return false;
}
};
const app = express();
app.use("/api/checkout", (req, res, next) => {
if (toggles.isEnabled("new_checkout", req)) {
return newCheckoutHandler(req, res);
}
return legacyCheckoutHandler(req, res);
});
ThoughtWorksのPete Hodgsonは、フィーチャートグルをライフスパンと目的によって分類し、3つの主要なタイプを挙げています。Toggleのタイプを正しく特定することで、適切なストレージメカニズムと管理プロセスを選択できます。モバイル開発のコンテキストで各タイプを見てみましょう。
Business togglesは最も長期間存続するスイッチです。特定のユーザーカテゴリ(プレミアム機能、地域固有の機能)のみが利用できるビジネスルールを管理します。このようなtogglesは何年も存続する可能性があり、通常はバイナリのオン/オフよりも複雑なロジックを持ちます。Release togglesは、未完了の機能を隠すための一時的なスイッチです。そのライフサイクルは数日から数週間です。機能が完了すると、release toggleはコードから削除されます。これらのtogglesはtrunk-based developmentの基盤であり、開発者がすべての機能の完了を待たずにメインブランチにコミットできるようにします。
Experiment togglesはA/Bテストと段階的ロールアウトに使用されます。Release togglesとは異なり、experiment togglesはパーセンテージベースのユーザー配分と分析システムとの統合をサポートします。Release togglesよりも長く(最大数ヶ月)存続できますが、実験終了後は削除する必要があります。Infrastructure togglesは、インフラストラクチャの変更を管理するためのスイッチです:データベース移行、新しいAPIプロバイダーへの切り替え、キャッシュアルゴリズムの変更。これらのtogglesは、その切り替えがサービス全体の安定性に影響を与えるため、テストに特別な注意が必要です。
| Toggleの種類 | 期間 | 対象 | 例 |
|---|---|---|---|
| Business | 数ヶ月〜数年 | 役割/地域別 | プレミアム機能 |
| Release | 数日〜数週間 | 開発者/QA | 未完了画面 |
| Experiment | 数週間〜数ヶ月 | ユーザーの% | インターフェースA/Bテスト |
| Infrastructure | 数日〜数週間 | 内部 | DB移行 |
“feature toggle”と“feature flag”という用語はしばしば互換的に使用されますが、それらの間には概念的な違いがあります。これらの違いを理解することで、特定のタスクに適切なツールを選択し、チーム内の混乱を避けることができます。各アプローチの主な違いと使用例を見てみましょう。
Feature toggleは主に技術的なメカニズムです:アプリケーションコードに組み込まれたバイナリスイッチです。Toggleは設定を通じて管理され、外部インフラストラクチャを必要としません。Feature flagはより広い概念であり、管理プラットフォーム(設定用UI、統合用SDK、使用状況監視、分析、監査)を含みます。Flagsは複雑なターゲティングルール(地域、バージョン、デバイス別)、A/B実験、自動削除をサポートします。フィーチャーフラグはフィーチャートグルの進化形と言えるでしょう:チームは単純な設定スイッチから始め、成長に伴って専門プラットフォームに移行します。
小規模チームや単一サービスまたはモノリスを扱うプロジェクトでは、単純な設定togglesで十分です。5〜10人の開発者と同時に1〜2つのアクティブなtogglesがある場合、外部プラットフォームは過剰です。フィーチャーフラグプラットフォーム(LaunchDarkly、Unleash)は、アクティブなフラグが20〜30を超える場合、チームに20人以上の開発者がいる場合、または異なるユーザーセグメントに対して細かいアクセス制御が必要な場合に必要になります。クライアントのアップデートに日数を要するモバイルアプリケーションでは、フィーチャーフラグプラットフォームは追加の利点—新しいバージョンを公開せずにアプリケーションの動作を変更できる機能—を提供します。
フィーチャートグル管理ツールの選択は、チームの規模、技術スタック、セキュリティ要件によって異なります。単純な設定ファイルからエンタープライズグレードの管理プラットフォームまで、オープンソースの代替案も含めてオプションを見てみましょう。
フィーチャートグルはCI/CDパイプラインの第一級市民であるべきです。ビルド段階では、パイプラインは現在のスプリントで削除予定のすべてのrelease togglesが実際にコードから削除されたかをチェックします。テスト段階では、異なるtoggleの組み合わせでマトリックステストが実行されます。デプロイ段階では、システムが自動的に本番環境とtoggle設定を同期します。PagerDutyやOpsgenieとの統合により、stale togglesが検出された場合やアクティブなtogglesの許容数を超えた場合にアラートを作成できます。
単純なシナリオでは、変更に対するコードレビュー付きのGit上のJSON設定で十分です。より高度なオプションは、Togglz(Java)やGofeature(Go)—toggle管理用の最小限のUIを追加するライブラリです。本番システムには、すべての言語に対応したSDKとアクティベーション戦略をサポートするUnleash(オープンソース)、またはA/Bテストが組み込まれたFlagsmithが推奨されます。LaunchDarklyは、高い監査とコンプライアンス要件を持つエンタープライズプロジェクトの標準であり続けています。モバイルアプリケーションには、すべてのソリューションがキャッシュとオフラインモードを備えたネイティブSDKを提供しています。
フィーチャートグルは諸刃の剣です。管理の規律がなければ、開発を遅らせコードの複雑さを増す技術的負債に変わります。CodeSceneの調査(2024年)によると、35〜50%のコードベースにstale toggles—ロールアウト完了後もコードに残るスイッチ—が含まれています。そのような負債を防止および排除するための戦略を見てみましょう。
フィーチャートグルの削除プロセスは4つのステップで構成されます。第一:toggleが100%のユーザーに対して有効、または0%に対して無効であることを確認します(どのコードブランチを残すべきかに応じて)。第二:コードからすべての条件付きtoggleチェックを削除し、本番動作となるべきブランチのみを残します。第三:ストレージシステム(設定、データベース、またはプラットフォーム)からtoggle定義を削除します。第四:削除によって機能が壊れていないことを確認するテストを実行します。各toggleには、スイッチ作成時に記録された所有者と計画削除日が必要です。
手動のtoggle監査は50スイッチを超える規模では非効率的です。自動化は3つの原則に基づいています:CIチェック(stale togglesはマージをブロック)、監視(各toggleの経過時間とステータスを示すダッシュボード)、アラート(toggleがN日間変更されていない場合に所有者に通知)。静的コード分析ツール(SonarQube、ESLintプラグイン)は、コード内で常にオンまたは常にオフになっているtoggles—stale toggleの明確な兆候—を検出できます。最終チェックはコードレビューであり、レビューアは新しいtoggleが本当に必要であり、古いコードブランチが削除されることを確認する必要があります。
package toggles
type Toggle struct {
Name string
Enabled bool
Owner string
CreatedAt time.Time
TTL time.Duration
}
type ToggleManager struct {
store map[string]*Toggle
}
func NewToggleManager() *ToggleManager {
return &ToggleManager{store: make(map[string]*Toggle)}
}
func (m *ToggleManager) IsEnabled(name string) bool {
t, ok := m.store[name]
if !ok {
return false
}
return t.Enabled
}
func (m *ToggleManager) GetStaleToggles() []string {
var stale []string
for name, t := range m.store {
if t.Enabled && time.Since(t.CreatedAt) > t.TTL {
stale = append(stale, name)
}
}
return stale
}
よくある質問
これらの用語はしばしば互換的に使用されますが、技術的にはfeature toggleはコード内のバイナリスイッチ(設定値をチェックするif条件)です。Feature flagはより広い概念であり、UI、SDK、分析、複雑なターゲティングルールを含む管理プラットフォームを含みます。Toggleは外部インフラを必要としませんが、flagは通常必要とします。
Release togglesはロールアウト完了後1〜2週間以内に削除する必要があります。Experiment togglesはA/Bテスト終了後すぐに削除します。Business togglesは定期的な監査(四半期ごと)が必要です。タストラッカーに削除タスクのない新しいtoggleをPRが追加した場合にマージをブロックするCIチェックを設定することをお勧めします。
はい、フィーチャートグルはモバイル開発で積極的に使用されています。主要なツールはFirebase Remote Configで、アプリケーションの新しいバージョンを公開せずにスイッチを動的に管理できます。代替案:iOS/Android向けLaunchDarkly SDK、Unleash SDK、REST APIを備えたカスタムtoggleサーバー。オフラインモードで動作するための値のキャッシュを実装することが重要です。
主な方法はマトリックステストです:toggleがオンとオフの両方の状態ですべてのテストを実行します。N個のtogglesの場合、完全なマトリックステストには2^n回の実行が必要なため、実際には重要な組み合わせが選択されます。単体テストではtoggleの値をモックする必要があります。統合テストでは特定のシナリオを検証します。予期しない相互作用を検出するために、ランダムなtoggleの組み合わせでテストを実行するステップがCIに追加されます。
主なリスク:1) stale toggles—両方のブランチ(オン/オフ)を持つコードは複雑になり保守が困難になります。2) テストの組み合わせ爆発—各toggleが状態数を倍にします。3) デッドコード—toggleが永久に有効になった後も古いブランチがコードに残ります。4) セキュリティ—アクセスを制御するスイッチは、誤った設定で脆弱性を生み出します。すべてのリスクは規律と自動化によって管理可能です。
まとめ
ターンキー方式のモバイルアプリケーションを開発します
IT Sectrは2017年からスタートアップや企業向けにiOS・Androidアプリケーションを開発しています。私たちがご相談に乗り、最適なソリューションをご提案します。