フィーチャーフラグのオープンスタンダードを実現する

Harnessは、フィーチャーフラグ管理のスタンダードを策定する新しいオープンソースプロジェクトであるOpenFeatureへの参加を発表します。

Harnessは、フィーチャーフラグ管理のスタンダードを確立する新しいオープンソースプロジェクトであるOpenFeatureへの参加を発表します。OpenFeatureは、クラウドネイティブテクノロジーを用いた堅牢なフィーチャーフラグエコシステムをサポートするために作成され、このほど、Cloud Native Computing Foundation（CNCF）によりサンドボックスプロジェクトとして承認されました。

フィーチャーフラグには、A/Bテスト、本番環境でのテスト、新機能の本番へのリリースをシンプルにコントロールできるなど多くの利点があります。

OpenFeatureの設立は、エンジニアリング業界がそれらの利点を認めている証しと言えます。フィーチャーフラグの人気の高まりにより、今日、フィーチャーフラグソリューションを独自に構築したり、購入したりする企業が増えています。一方で、フィーチャーフラグツールを採用しようとする場合、カスタマイズされた特注のアーキテクチャが一般的であるため、チーム（特に企業）は特定のベンダーに依存することに懸念もあるでしょう。OpenFeatureは、フィーチャーフラグのオープンスタンダードでこれらの課題に対処することを目指しています。

新しい規格であるOpenFeatureは、既存のベンダーから支持されることが重要です。Harness は、このオープンスタンダードに貢献するベンダーの一員となったことを大変うれしく思います。

OpenFeatureとは？

OpenFeatureが策定する仕様によって、フィーチャーフラグを特定のベンダーに依存しないよう実装できるようになります。ウェブサイトに記載されているように、「OpenFeature は、オープンソースと商用製品に対応した拡張性を備え、統一された API 、SDK、および開発者優先のクラウドネイティブな実装」を提供します。

OpenFeatureは、さまざまなサードパーティーーのフィーチャーフラグプロバイダーにプラグインできるよう、共有化され、標準化されたフィーチャーフラグクライアントであるSDKを提供します。また、オープンソースのシステムか商用製品か、セルフホスティングかクラウドホスティングかにかかわらず、開発者がフィーチャーフラグを使用してアプリケーションを開発するための一貫性のある統一APIを提供します。

つまり、OpenFeatureを採用する企業は、特定のベンダーに依存することなく安心して利用することができるのです。さらに、フィーチャーフラグを使い始めたばかりの企業は、環境変数に基づく非常に基本的な実装（構成管理とも呼ばれる）を採用し、要件が高度化するにつれ、より多くのコントロールと機能を提供するベンダーに移行することができます。

OpenFeatureの実装方法

現在、OpenFeature SDK は多くの主要なプログラミング言語に対応しています。技術的なレベルでは、SDKはコンシューマーがフィーチャーフラグの値を取得する時に使用できる評価APIを提供します。このAPIの要は、以下のような異なるフラグタイプを評価するための呼び出しです。

• getBooleanValue
• getStringValue
• getNumberValue
• getObjectValue

各ベンダーは、独自のSDKをラップするプロバイダーAPIを実装できます。OpenFeature SDKは、これらのプロバイダーをロードして使用することができ、評価APIを介してプロバイダーを呼び出せます。

下の図はその例で、アプリケーションコードがOpenFeature SDKのgetBooleanValue()を呼び出すところです。OpenFeature SDKは、プロバイダ ーAPIを呼び出します。 どのプロバイダーがロードされたかによって、ベンダー固有のSDKコードが呼び出されます。

HarnessがOpenFeatureに参加する理由

Harnessは、ソフトウェアデリバリーライフサイクル全体をサポートし、向上させるために、オープンなエコシステムを構築することをお約束します。2021年には、Feature Flag SDKを含む自社製品をオープンソースで提供することを開始しました。OpenFeatureに貢献することで、お客様に利益をもたらすオープンソースプロジェクトを支援し続け、開発者の働き方を改善することにより業界の発展に尽くします。

ソフトウェアエンジニアリングやDevOpsのリーダーたちに話を聞くと、自社製のソリューションを構築したものの、メンテナンスやサポートに時間がかかりすぎるほど肥大化してしまうことが多い、とういことをよく耳にします。その結果、新しい機能を大規模に追加することがほとんど不可能になります。より優れた商用ツールの導入を検討する際、単一のベンダーに縛られることや、移行や移植が容易でないことは懸念事項です。

OpenFeatureでは、チームや企業が自分たちで何かを作ることからフィーチャーフラグに取り組み始めたい場合、自分たちのニーズに合った、オープンスタンダードに準拠したシンプルなソリューションの構築から始めることができます。ニーズが高度になれば、Harness Feature FlagsのようなOpenFeatureをサポートするベンダーのソリューションを簡単に採用することができます。

Harnessでは、お客様に最適なモジュールを選んでいただくことが重要だと考えており、OpenFeatureはまさにその精神に沿ったものです。なぜなら、お客様のフィーチャーフラグへのニーズが基本的なものから高度になったとき、アプリケーションとHarness Feature Flagsの統合方法を変更することなく、必要な追加機能を提供できるよう保証するからです。業界全体でフィーチャーフラグの基本的な実装の標準化が進めば、お客様は、フィーチャーフラグの概念にイノベーションと新しい価値を加えることに一層集中できるようになります。ベンダーそれぞれが複数の標準を作成するよりも、フィーチャーフラグの導入の簡素化に重点を置き、基礎の上にどう価値を付加できるかで革新性を示せるようになるのです。

これからの取り組み

HarnessはOpenFeatureの支援に尽力しています。当初はGolang SDKに対して貢献しましたが、今後は各フィーチャーフラグのSDKに対してOpenFeatureプロバイダーを開発する予定です。また、ユーザーがフィーチャーフラグプロセスを最大限に活用できるように、フィーチャーフラグのベストプラクティスの紹介に力をいれます。

私たちは、このイニシアチブを推進し、フィーチャーフラグコミュニティー全体と協力して私たちの業界にとって最善の道であるOpenFeatureに貢献できることを大変うれしく思っています。

ソフトウェアデリバリーにおいて、ソフトウェアエンジニアリングやDevOpsチームが、Harness Feature Flagsの支援を受けコントロールを実現できるようになる様子を実際に確認したいお客様は、こちらから無料でサインアップして、Harness Feature Flagsを今すぐ使い始めてください。

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