エンジニアリング文化にフィーチャーフラグを埋め込み、悪習慣を防ぐ

このブログでは、開発チームのカルチャーシフトとしてフィーチャーフラグを取り入れることの重要性と、その導入に関するよくある誤解について説明します。

エンジニアリングリーダーは、チームが常に出荷を行い、可能な限り迅速に変更をデプロイすることを望んでいますが、一方で、顧客からのフィードバックや生産上の問題にリアルタイムで対応できるように、変更が完了したときのみ起動することを望んでいます。フィーチャーフラグを使うと、ユーザーが機能のオン・オフを切り替えることで、新しいコードをデプロイすることなく、ソフトウェアの機能を変更できます。また、フィーチャーフラグは、未試験の作業、時期尚早な機能、一部のユーザーベースのみを対象とした機能の起動を防ぐことができます。しかし、チームがフラグを使用する際の文化やプロセスは、このような成果をサポートするものでなければなりません。

フィーチャーフラグに基づく最新の生産管理による開発の素晴らしい点は、リスクなしに未完成の機能を安全にコミットし、プロダクションにデプロイできることですが、時には経営陣がこんなことを耳にするかもしれません。「フィーチャーフラグは、壊れたコードをコミットし、準備が整う前の本番投入を進めるものだ！」。私たちは、フィーチャーフラグが、既に根付いたエンジニアリングの悪習慣を解決するのではなく、誤って悪化させるかもしれないと考えている複数のエンジニアリングリーダーに会いました。しかし、もっとニュアンスが違うんです。このブログでは、開発チームのカルチャーシフトとしてフィーチャーフラグを取り入れることの重要性と、その導入に関するよくある誤解について説明します。

エンジニアリング文化にフィーチャーフラグを埋め込む

私たちは、「フィーチャーフラグはツールであると同時に、仕事のやり方である」とよく言います。継続的インテグレーションとデリバリー（CI/CD）はエンジニアリングチームの運営方法を恒久的に変えますが、フィーチャーフラグもまた同様です。フラグがあれば、チームはより多くのコラボレーションし、より頻繁にコードをマージしてテストし、より速くデプロイして、素早く機能を提供できます。チームの運用リズムを向上するこの効率性は、当然に部門間のコラボレーションを促しサイロ化を軽減します。

しかし、ソフトウェアデリバリーライフサイクル（SDLC）におけるフィーチャーフラグの役割は、しばしば誤解されています。フィーチャーフラグは、エンジニアリング文化の一部に過ぎません。フィーチャーフラグはチームが迅速かつ高速にデータに基づいた開発スタイルに変わるためには重要ですが、安定し、信頼できるソフトウェアを生むために必要な、他のチェックとバランスに代わるものではありません。これは、フィーチャーフラグでできること（できないこと）についてよくある誤解の1つです。

フィーチャーフラグに関する４つのよくある誤解

機能フラグに関する4つのよくある誤解と、その背後にある真実について詳しく見ていきましょう。

誤解1：フィーチャーフラグはテストを難しくし、結果として生産現場での未テストのコードパスを増やすことになる

現実：これは、みなさんの文化が適切なテストを歓迎していない場合にのみ当てはまります。実際にフィーチャーフラグを使うと、チームが段階的にリリースし、日々進歩できるようになるため、チームが品質に集中しやすくなります。しかしテストの規律を欠く文化では、多くのフラグを組み合わせると、多くのリスクを生み出す可能性があることは事実です。ただし、開発者が本番環境への投入の承認を得るためにコードをテストすることが当然とされている場合、フィーチャーフラグは新しいリスクの芽になることはありません。フィーチャーフラグはテストの代わりにはなりません。フラグで明示できるコードパスは、通常通りテストも行う必要があります。

誤解2：本番で間違った機能を簡単に有効化したり無効化したりできてしまう

現実：確かに、「本番で素早く変更しやすい」という超便利なメリットの弊害はあります。Harnessでは、パイプライン、ガバナンスポリシー、堅牢なロールベースのアクセス制御（RBAC）を構築して、誰がいつフラグを変更できるのか、変更したときに何が必要なのかを、チームがコントロールできるようにします。適切なコントロールを活用するチームは、迅速かつ安全に動けます。

誤解3：フラグは混乱と技術的負債を増やすだけ

現実：実際にはその逆で、フィーチャーフラグは技術的負債と、本番で有効になるものを明確にするものです。「測定できないものは管理できない」のと同様に、フィーチャーフラグはリリースや現在の設定を可視化し、長期的に追跡できます。この可視性により、非推奨とすべき古びたコードが特定され、どんな環境で何が設定されているか、いつ変更された可能性があるかを常に確認できます。

誤解4：チームがベストプラクティスを活用し、世界レベルの仕事をしているのであれば、フィーチャーフラグは必要ない

現実：私たちはフィーチャーフラグがいかにチームの高速なベストプラクティスの実現に役立つかを話し続けていますが、一方で、フィーチャーフラグは松葉杖であり、チームが進化すれば必要ないものだ、という印象を与えるかもしれません。現実には、リリースとデプロイを切り離さなければ、リスクを抑えて高い速度を維持することはできません。あなたがたの開発サイクルが常にあなたがた自身のデプロイメントサイクルに依存し、それがあなたのチームの新機能の立ち上げや変更のロールバックの方法となっているのであれば、今後も常に本質的にリスクが高く、非効率なままでしょう。

あなたの組織、アプリケーション、デプロイの規模がどんどん大きくなり、遅くなり、リスクが高まったとき、どうすればいいのでしょうか。答えは明白かもしれませんが、より速く動き、同時にリスクを軽減する方法を見つけることです。特にフィーチャーフラグは、自らのCI/CDの実装でこうした制限に直面している組織が選択すべき技術です。フィーチャーフラグは、チームの迅速かつ安全な活動を支援する技術であり、だからこそ、悪しき慣習ではなく、技術を採用することが重要なのです。

悪い慣行をやめ、フィーチャーフラグを導入しよう

ほとんどのチームが、フィーチャーフラグを導入した後、品質、信頼性、テスト効率、信頼性が大幅に向上しています。しかし、変化を促すにはチーム文化やベストプラクティスも必要です。フィーチャーフラグを責任を持って使う文化を取り入れて、適切なプロセスとツールに投資することで、エンジニアリングチームはフィーチャーフラグの潜在能力を最大限に引き出し、高品質のソフトウェアを高い速度で提供できます。

フィーチャーフラグを安全に活用し、こうした悪い習慣ではなく、良い習慣を取り入れる方法を知りたい方は、Harness Feature Flagsで詳しくご紹介しています。デモをリクエストするかサインアップして、今すぐ機能フラグを正しい方法で使用してください。

この記事はHarness社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。