フィーチャーフラグはどう使い始めればよいですか?

チームがソフトウェア配信ライフサイクルにフィーチャーフラグの実装を始める良い方法を詳しく見てみましょう。

ソフトウェアエンジニアリングやソフトウェア開発に携わっている人なら、フィーチャーフラグについての会話でよくある、次のやり取りに聞き覚えがあるかもしれません。

「私はチームに、有効期間の短いブランチと継続的なマージを備えたトランクベースの開発手法を使ってもらいたいと考えています。あらゆる変更に関するフィーチャーフラグがそれを実現するための鍵となります。そこで、フィーチャーフラグツールを購入し、全員にアクセスを許可しました...でもなぜそれが使われないのでしょうか？」

聞き覚えがあるかもしれませんが、心配しないでください。フィーチャーフラグや、トランクベース開発などの新しいコード開発方法に関しては、多くの場合、目標を決めることは、そこに到達するプロセスよりもはるかに明確です。ツールはあるかもしれませんが、毎日重要な仕事をしているエンジニアもたくさんいるので、人々にペースを緩めて新しい方法を採用してもらうのは困難な作業になる可能性があります。

この質問に対する唯一の魔法の答えはありません。そこで、私たちが常に推奨するアプローチが１つあります。とてもシンプルなので冗談のように聞こえるでしょうが、うまくいくことを約束します。これは２段階のプロセスです。

ステップ1：試してくれるチームを探す。

ステップ2：フラグを追加します！

終わり！冗談ではありません。掘り下げてみましょう。

チームを探す

フィーチャーフラグのような優れた最新の開発プラクティスを望んでから実際に導入するまでのキャズムを越える際の最大の課題の１つは、誰が最初に行動するかを決定することです。フィーチャーフラグツールの導入を率先して取り組んでくれるチーム、または個人の開発者を見つけることをお勧めします。どこを見るべきかを知るのに役立ついくつかのヒントを次に示します。

• フロントエンドフラグは、おそらくバックエンドよりも実装が簡単です（組織的に他に優先事項がない場合）。
• 現在何かをリリースしているチームを探してみてください。グリーンフィールド型のプロジェクトは素晴らしいものですが、実際には、積極的に使われているソフトウェアから始めるよりも、新しい実践や良い習慣の普及が遅くなる可能性があります。
• 大規模なイニシアチブを開始する必要はありません。ドキュメントを読んで参加したい人なら誰でも大丈夫です。詳細については以下をご覧ください。

上記のアプローチがうまく行く理由は、多くのDevOpsツールとは異なり、フィーチャーフラグは必ずしも最初に一元的に調整して計画する必要がないためです。誰でもコードをフラグで囲むことができ、便利です。

時間が経つにつれて、標準化とガバナンスが絶対に必要になりますが、初期段階では、勢いをつけることが重要です。フラグを使っていないチームの影響が及ぶ範囲はまだないため、一部のチームが他の開発者に影響を与えないツールを使って新しいプロセスを開始できるようにしても安全です。

フラグを追加

先導して協力してくれるチームを見つけたら、次のステップはフラグを追加するだけです。

一見簡単そうに見えますが、実際には、新しいことを始めるには内なる動機が必要なので、フラグを追加するだけでも実際には非常に難しい場合があります。ただし、これに向き合うのに役立つ方法があります。フラグを使って何をするかを知る必要はありません。実際、フラグは特に何もする必要はありません。

特定のターゲティングにフラグを使う場合でも、全ユーザーに対してフラグをすぐに使えるようにする場合でも、超えるのが一番難しい障害は、多くの場合、始めたばかりの段階です。場合によっては、チームが開発カレンダー上の次の大きな取り組みに基づいて、フラグを使う最初の最適なシナリオが何かを理解するのに時間を費やすことがありますが、効果的な変更は、一気に全てを行うのではなく、練習を重ねることで実現します。コード内に何かフラグを立てて変更を保護するのが早ければ早いほど、目標に近づくことができます。

私たちのお客様から寄せられた上手い最初のステップとしては、次のものが挙げられます：

• 修正が保留されているバグを見つけて、エンジニアにそのバグにフラグを立てるように依頼します。フラグをグローバルに有効にすると、新しいカスタムリリースやターゲティングが必要なくなり、システム内でフラグが環境を通過する際にどう見えるかを観察できます。
• 次のリリースに戻り、メジャーまたはマイナーの変更にフラグを追加して、フラグを使って何かを切り替える経験を積んでください。機能がほぼ完成したからといって、フラグを追加できないというわけではありません。
• フラグの背後にバックエンドロギングを追加し、フラグが変化していることを確認するだけで、プロモーションサイクルを通じて送信します。

チームが画面の周りに座って練習中にフラグを見られるようになるとすぐに、次のステップの多くがすぐにまとまり始めることが分かりました。実際のフラグを使ってみれば、どのチームもすぐにフラグをどんどん活用し始めることができます。プロセスの次のステップでは通常、次のような質問に答えることにフォーカスすることになります。

• ターゲットを絞るには何をする必要があるでしょうか？
• フラグを変更できる人をどう管理すればよいでしょうか？
• QAでフラグをテストするにはどうすればよいでしょうか？

この類いの議論が、フラグを設定する前に交わされます。そしてアプリケーションにフラグを設定してチームとしてレビューできるようにすると、生産性が大幅に向上し、次のステップを推進するための実用的なフィードバックのループが作られます。

今すぐフィーチャーフラグの利用を始めましょう

開発チームの働き方を変えることは一夜にしてできることではありませんし、そうすべきではありません。各チームは、砂上で大きな変更を加えようとして、どうやって目的地に到達するかという問題を深く考えすぎることがあります。多くの場合、最初の一歩がそこに達する勢いを生み出します。フィーチャーフラグでは、単純にフラグを追加してそれを試してみること以上に優れた最初の一歩はありません。たとえ本番環境であっても、それがフラグの要点です。リスクはありません！

Harness Feature Flagsは、CI/CDとフィーチャーフラグをネイティブに統合し、ビルドからデプロイ、リリースまでのエンドツーエンドのガバナンス、可視性、制御を備えた、ユニークで強力な統合ソフトウェア配信エクスペリエンスを作成します。フィーチャーフラグの利用を始める方法が分からない場合や、フィーチャーフラグをすぐに実装したい場合は、 Harness Feature Flagsに無料でサインアップしていただければ、今日からチームで使い始められます！

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