こんにちは！ KEPPLE CREATORS LABでエンジニアをやっている丸山です。
最近、私たちのチームではフィーチャーフラグを取り入れて、リリースプロセスを見直しました。その結果、思っていた以上に開発がスムーズになり、チーム全体で多くの学びがありました。
この記事では、フィーチャーフラグを導入した背景や、その効果、そして直面した課題とその解決策について、私たちの実体験をもとにお話ししたいと思います。もし、同じような悩みを抱えているエンジニアやマネージャーの方がいらっしゃれば、ぜひ参考にしていただければ幸いです。
フィーチャーフラグ導入の背景と目的
リリースプロセスでの悩み
ケップルの開発チームはスクラム開発を採用しており、1週間ごとのスプリントでプロジェクトを進めています。しかし、ビジネスのニーズやプロダクトの方向性によっては、開発中の機能を一時中断し、別の高優先度のタスクに取り組む必要が出てくることがあります。
その際、未完成の機能をブランチで管理したままにしておくと、後々マージする際にコンフリクトが頻発し、その解消に時間と労力を費やすことが度々ありました。また、大規模な機能を一気にリリースする場合、万が一問題が発生するとコードをリバートする必要があり、その過程で他の開発中の機能まで巻き戻してしまうリスクもあります。
フィーチャーフラグ導入を決めた理由
これらの課題を解消するために、私たちはフィーチャーフラグの導入を検討しました。フィーチャーフラグを使えば、開発中の機能をコードベースに統合しつつ、ユーザーにはその機能を非表示にすることができます。つまり、コードがデプロイされても、機能のリリースタイミングを自由にコントロールできます。
具体的な目的は以下のとおりです。
- マージ作業の簡略化とコンフリクトの減少：開発途中のコードを早めにdevelopブランチにマージし、長期間ブランチを分けることで生じるコンフリクトを減らしたい。
- ユーザーへの影響を最小限に：ビジネスのスケジュールに合わせて、機能の公開タイミングを調整し、ユーザー体験を最適化したい。
- リリース時のリスク低減：リリースに問題があった場合でも、迅速に対応できるようにし、大規模なコードのリバートを避けたい。
- アジャイル開発のリズムとリリースの調和：スプリントごとのリズムに合わせて、機能のリリースを調整し、開発とリリースのサイクルを最適化したい。
フィーチャーフラグ導入してみた結果得られたメリット
マージ作業がスムーズに
フィーチャーフラグを活用することで、開発中の機能でも早い段階で develop ブランチにマージできるようになり、その結果、長期間ブランチが分岐したままになることを避けられ、コンフリクトの発生も減らすことができました。マージ作業にかかるコンフリクト解消の時間やコンフリクトを気にしなければいけないストレスが軽減され、結果的に開発のスピードが上がったのではないかと思います。
ユーザーへの影響をコントロール
新機能がコードベースに含まれていても、フィーチャーフラグによってユーザーには非表示にすることができます。これにより、ビジネスの戦略やマーケティングの都合に合わせて、最適なタイミングで機能をリリースできるようになり、ユーザー体験を損なうことなく、開発とビジネスの両面で柔軟性が向上しました。
リリース時の安心感
以前は大きな機能をリリースする際、チーム全体に緊張が走っていました。問題が起きたらどうしよう、と不安になることも。しかし、フィーチャーフラグを導入してからは、万が一問題が発生してもフラグをオフにするだけで即座に対応できます。そのおかげで、リリース時の精神的な負担がぐっと軽くなりました。
開発の柔軟性が向上
フィーチャーフラグを使うことで、タスクをより細かく分割することが可能になりました。開発中の機能が複数のスプリントにまたがる場合でも、ユーザーへの影響を気にせず開発を進められます。その結果、スプリント内でのタスク管理が効率化され、チーム全体の生産性が向上しました。
アジャイル開発のリズムとリリースの調和
フィーチャーフラグを導入することで、スプリントごとのリズムに合わせたリリースが可能になりました。これにより、開発とリリースのサイクルが調和し、チーム全体の作業効率が向上しました。スプリントの終わりに機能をリリースすることで、開発のリズムを崩さずに進めることができます。
フィーチャーフラグ導入で見えてきた課題と対策
コードが複雑になる問題
フィーチャーフラグを使うと、どうしても条件分岐が増えてコードが複雑化してしまいます。特に、フィーチャーフラグを削除する際にどの部分を消せばいいのか分かりづらくなることもありました。
対策として、フィーチャーフラグを導入する段階で、将来的に削除しやすいコード構成を意識するようにしました。具体的には、フラグによる条件分岐をブロックごとにまとめるなど、一目で分かるような工夫を取り入れています。
// 些細なことだけど削除する箇所が極力散らばらないように一箇所にまとめることでわかりやすく
if (!checkFeatureFlag('XXX_FEATURE_ENABLED')) {
/**
* 既存処理
*/
}
/**
* 新規処理
*/
テストケースの増加
フィーチャーフラグによって、フラグがオンの場合とオフの場合、両方のテストが必要になり、テストケースが増えてしまいました。機能がリリースされた後は消されるコードなので、一時的ですがテストコードが倍ぐらいに膨らみます。
リリースプロセスの改善とチームへの影響
リリース時の安心感
フィーチャーフラグの導入により、リリースに対する不安が大幅に減りました。いままでより大胆に機能を分割して段階的にリリースしていくことが増えたのですが、この安心感によりそういった判断もしやすくなったと感じています。
開発プロセスの効率化
タスクを細分化しやすくなったことで、スプリント内での計画と遂行がスムーズになりました。優先度の高いタスクにも柔軟に対応できるようになり、ビジネスのニーズに迅速に応えられる体制が整いました。
フィードバックの活用
フィーチャーフラグを使って機能を限定的にリリースし、ステークホルダーから早めにフィードバックをもらうことが可能になりました。それにより、開発途中で改善点を取り入れることができ、最終的なプロダクトの品質向上に役立っています。
今後の展望と取り組み
フィーチャーフラグ管理の高度化
現在は環境変数でフィーチャーフラグを管理していますが、これだとフラグの切り替えにビルドが必要で即時性に欠けます。そこで、UnleashやFlagsmithなどのフィーチャーフラグ管理ツールの導入などを検討しています。リアルタイムでフラグを切り替えられるようになれば、さらに柔軟なリリースが可能になると期待しています。
A/Bテストへの応用
フィーチャーフラグを活用してA/Bテストを行い、ユーザー体験の最適化にも取り組んでいきたいと考えています。実際のユーザーの反応を見ながら機能を改善することで、プロダクトの価値を高めていくことができます。
おわりに
フィーチャーフラグの導入により、開発プロセスが大きく変わりました。マージ作業の効率化やリリース時の安心感、開発の柔軟性向上など、多くのメリットを実感しています。一方で、コードの複雑化やテストケースの増加と付き合わなければいけない課題も見えてきました。
これからもフィーチャーフラグを有効に活用し、プロダクトの品質向上と開発プロセスの最適化を引き続きやっていきたいと思います。
Discussion