フィーチャーフラグをより安心して導入するために - Swift Macros × Build tool pluginを駆使した安全設計 by scenee

フィーチャーフラグは新機能の段階的リリースやA/Bテストを可能にする強力な手段ですが、一方で乱立・肥大化すると管理が複雑化しやすく予期せぬバグやインシデントが発生しやすくなります。

今回、私は株式会社ヤプリが提供するノーコードアプリプラットフォームのiOS基盤に、長期ブランチの滞留やインシデントの復旧遅延を解消するためにフィーチャーフラグを導入しました。

しかし、その導入は容易ではなくノーコードアプリプラットフォームならではの課題に直面しました。

まず、一つのコードベースから多数のアプリをビルドするために、従来のフィーチャーフラグ手法ではアプリごとの条件分岐や設定管理が膨れ上がり現実的な運用が難しくなってしまいます。

次に、1つの不具合が多数のアプリ全体に波及するインシデントへと直結するため、リリースコードに少しでも変更があればQAの実施が必須となっています。

最後に、開発チームでは過去に何度か検討されながら「すでにあるアプリ編集機能で十分では？」という意見も多く、導入意義をチームで合意する必要がありました。

このような課題に対して、私は丁寧に「フィーチャーフラグ」についてチームのコンセンサスをとりながら、安全に導入するためにSwift MacrosとBuild tool pluginを用いた仕組みを設計しました。

1. 宣言的なフラグ定義により全体のフラグ状態を静的に把握
2. Swift MacrosとユニットテストでQA工数を抑制しながら「動かないコード」を撲滅
3. コード自動生成で対象外フラグをビルド時に無効化する仕組みを構築

例えば、この設計でコード内で個別アプリごとの条件分岐が不要になっています。

このトークではこれらのアーキテクチャとワークフローを具体的なコードとともに紹介しながら、導入に伴う成功と失敗の両面から皆さんに共有します。