文化としてFeature Flagsについて考える

フィーチャーフラグをソフトウェアデリバリーチームの文化の一部と考えることで、フィーチャーフラグを単なるツールからプロセス、そしてチームの仕事の仕方へと変えることができます。

フィーチャーフラグについてじっくり調べてみると、フラグはさまざまな応用があることがわかります。

• フィーチャーフラグはCI/CDを拡張する。
• フィーチャーフラグは、運用チームにとってのキルスイッチである。
• フィーチャーフラグは、デプロイメントのリスクを取り除く。
• その他、多数。

これらは全て真実です。しかし、あまり語られていないことがあります。それは、フィーチャーフラグを使って１つ上のレベルの速さを引き出せるチームと、便利には使うが変革には至らないチームとの違いがあることが多いのです。

その違いは、フィーチャーフラグをソフトウェアデリバリーチームの文化の一部と見なすかどうかです。単なるツールや実装の詳細ではありません。フィーチャーフラグを最大限に活用したいのであれば、フィーチャーフラグはプロセスであり、チームの仕事のやり方でもあるのです。

フィーチャーフラグは、スタックの中の単なるツールの一つとして役立ちますが、チームの仕事のやり方を変えることができれば、それはゲームチェンジャーとなるのです。

よくある低調な使い方

まず、フィーチャーフラグを採用し、活用しているチームの事例を紹介します。

• 数人のエンジニアがフラグを使い始め、やがて組織内の他のチームもフラグを使うようになる。フラグを使うチームもあれば、使わないチームもある。
• フラグの使い方に一貫性がない。あるチームは機能全体にフラグを立て、あるチームは増分の変更にフラグを立て、ほとんどのチームはユーザー向けの変更にのみフラグを立てている。
• フィーチャーフラグは役立っているが、多くの機能がフラグなしでロールアウトされ、散発的にしか使われていない。

もし、これがあなたの組織における使い方の現状に見えるなら、あなたじゃありませんから大丈夫。この業界に長くいる人なら、テスト自動化、そして後にデプロイ自動化が標準的なエンジニアリングプラクティスとして業界全体に普及するまで、しばしばこのようなパッチワークのような状態にあったことを思い出すかもしれません。

文化としてのフィーチャーフラグ：他者を巻き込む

上記の状況を改善するために、私たちはいくつかの提案をしています。まず、組織内の全員がフィーチャーフラグにアクセスでき、それが何かを理解していることを確認します。PM、サポートチーム、セールスエンジニア、そしてエンジニアアリングの組織の全員（ops、DevOps、セキュリティー、その他誰でも）を招待してください。

認知度が低い場合は、トレーニングセッションを開催してください。フィーチャーフラグとは何ですか？何のために？何ができますか？ソフトウェア開発組織の全員が、これらの質問に答えられるようにしてください。

文化としてのフィーチャーフラグ：デフォルトフラグ

少なくともフラグ立ての概念を理解してもらえたら、実行チームが行うべき大きな変化は、デフォルトでフラグを立てることです。

多くの場合、チームは「適切なユースケース」を見つけるまで、フラグの使用を開始するのを控えます。例えば、今はリファクタリング中だからフラグは必要ないけれど、新しい機能を作ったら使ってみよう、ということです。あるいは、すでに進行中の機能があって、その次にはフラグを見ることになるかもしれません。あるいは、この機能は全員に配布する予定なので、フラグは必要ありません、とか。

このように、「正しいユースケース」を見つけるのが難しいという声を耳にします。だからこそ、私たちは正しいユースケースを待つ必要は全然ないと考えています。今すぐ、あなたが行う全ての変更にフラグを追加してください！
 

図：フラッグ・ザ・ワールド!

そして、「全ての変更」というと大変なことのように聞こえますが、文字通り全ての変更は意味しませんが、正直に言うと、ほとんどの変更を意味します。フロントエンド、バックエンド、API、ユーザー向け、技術的負債のリファクタリングなどなど。フラッグの後ろに全部書いてもいいんです。そして、フラグを何に使うか分かっているかどうか、心配する必要はありません。フラグは必要ないと思うかもしれませんが、ほとんど自由なレベルのオプションであり、後で持っていてよかったと思う可能性が非常に高いのです。

あなたが先月にロールバックやホットフィックスを行ったのであれば、フラグを使う機会がありました。なぜなら、その変更がフラグの背後にあれば、即座にオフにできたからです。最近、顧客に何かのフィードバックを求めたのであれば、フラグを使う機会があったはずです。

このようなシナリオを挙げるにしても、注意したいのは、変更がリリースされる直前まで、フラグを利用したくないと思うかもしれないということです。あるいは、リリースされた後であってもです。だからこそ、フラグを追加するタイミングは、たとえそれが不要に思えても、今なのです。なぜなら、選択肢があることは、常に良いことだからです。

文化としてのフィーチャーフラグ：フラグから考える

この投稿の冒頭で、フィーチャーフラグはエンジニアリング組織の文化を変える方法であると言いました。

CIが、チームが品質をどう管理するかという点でエンジニアリング文化を永久に変え、CDが、チームがリリースをどう調整するかという点で文化を変えたように、フィーチャーフラグは、リスクと変更管理についての考え方を変えるものなのです。

もしあなたがフィーチャーフラグをソフトウェアデリバリーの考え方の中核として採用すれば、リリースを計画する方法に微妙な、しかし重要な変化を発見できるでしょう。

• デプロイメントのリスクに対する懸念や、デプロイメントの複雑さに費やす時間は、ほとんどなくなります。
• あなたは、変更をテストするために何を学びたいかを、ほとんど常に考えるようになります。「いつなら安全？」、「どうやって分かるのか？」というように。
• リリースのオーナーシップは分散しています。あるリリースはエンジニアリングが、あるリリースはPMが、そしてあるリリースはサポートチームが所有します。その変更によって影響を受ける人がオーナーを決定します。全てエンジニアリングというわけではありません。
• 変更に関連するインシデントを即座に解決できることが、あなたとあなたの顧客の両方にとって期待されるようになります。つまり、バグフィックスや変更計画の取り入れ方です。なぜなら、問題をオフにすることができるからです。また、常に中断して修正するのではなく、優先順位をつけることもできます。

結論

これらを合わせると、エンジニアリングチームは、変更をリリースすることの意味、それを行う人、そしてリスクについて、これまでとはまったく異なる、より協力的で学習に重点を置いた、ストレスの少ない方法で考えることができるようになるのです。これらのことが実現し、フィーチャーフラグが本当に企業文化の一部となったとき、フィーチャーフラグは「あったらいいな」という存在から、ソフトウェアを提供する際の考え方の中核をなす存在になっていることに気づくことでしょう。

フィーチャーフラグを始める準備はできましたか？無料トライアルを開始して、最初のフラグを作るために遊んでみませんか？まだの方は、引き続き勉強してください。トランクベース開発におけるフィーチャーフラグの有用性の記事もお勧めです。

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