開発速度UP⤴️！UX UP⤴️！利益⤴️！フィーチャーフラグはDevCycleで50ミリ秒以下の世界に 🚀

こんにちは、みなさん！今日は、開発サイクルのスピードの事業インパクトとフィーチャーフラグの重要性とその技術選定についてお話します。

DORA（FourKeys）と開発サイクルのスピード

最初に、Googleが実行しているDevOps Research and Assessment (DORA)という最大級リサーチプログラムの研究結果から始めましょう。
DORAの研究によると、開発サイクルのスピードが上がると、事業価値も上がるということが明らかになっていますね。これは、多くの開発者や事業者にとって非常に興味深い結果ではないでしょうか？

トランクベース開発の必要性

この高速な開発サイクルを実現するための一つの手段として、トランクベース開発が注目されています。しかし、トランクベース開発を導入するには、フィーチャーフラグの技術が必要不可欠です。なぜかというと、様々な理由があるのですが、その中でも特にフィーチャーフラグを活用することで、安全かつ迅速に新機能をリリースできるからです。

トランクベース開発を進めていくうちに、ユーザへの悪影響を最小限にするために、
「新機能」をフラグ化し動的に管理する必要性が出てくるので、フィーチャーフラグの出番ですね。

新機能B = true

if (新機能B == true)
  新しい機能Bを提供()
else 
  古い機能Aを提供()

フィーチャーフラグシステムの選択

現在、多くのフィーチャーフラグシステムが存在しています。弊社のOSS社内システムとして「Bucketeer」や、有名なSaaSとして「LaunchDarkly」など、様々な選択肢があります。これらを比較すると、以下の点が考慮されるでしょう。

• 価格: 高額なサービスが多いです。
• 使用環境: サーバーサイド、クライアントサイド、モバイルアプリなど、多様な環境での利用が可能か。
• SDKの豊富さ: チームでの導入を容易にするSDKの提供。
• パフォーマンス: 低レイテンシかどうか（エッジで処理）。

OpenFeature標準とは

フィーチャーフラグ管理のオープンなスタンダードです。特定のベンダー依存なしにAPIを定義したりSDKを提供します。フィーチャーフラグ界隈のエコシステムを堅牢に発展させることを目的としています。
この標準に順守しているベンダーはロックインを防ぎ、必要であればいつでも他のベンダーに乗り換えることが簡単になります。

世の中のフィーチャーフラグのベンダー比較 （2024年前半）

ベンダー	サーバー SDK	クライアント SDK	リアルタイム 更新	Edge処理	Open Feature	無料枠	席/月	1000 MAU	10万 MAU	100万 MAU
DevCycle	9	6	✅	✅	✅	1000 MAU	-	-	$60	$420
LaunchDarkly	25	12	✅	🔺	✅	❌	$16.67/席	-	問合せ	問合せ
ConfigCat	12	5	✅	🔺	✅	10機能	-	-	-	-
Split.io	8	9	❌	❌	✅	10席	$33~	-	-	問合せ
Optimizely	7	5	❌	🔺	❌	-	-	問合せ	問合せ	問合せ
VWO	7	6	❌	❌	❌	5万 MAU	-	-	$549	$3563
Statsig	10	9	❌	❌	❌	100万イベント数	-	-	-	$150~ / 100万イベント数
CloudBees	9	4	❌	❌	✅	15席	$1325 / 16席	-	-	問合せ
Apptimize	3	6	✅	❌	❌	問合せ	問合せ	問合せ	問合せ	問合せ
Molasses	4	3	❌	❌	❌	1000 MAU	-	-	$200 / 2.5万 MAU	問合せ
Harness	9	7	❌	❌	❌	2席 2.5万MAU	$12.5/席	-	-	問合せ
Firebase Remote Config	0	7	✅	❌	❌	-	-	-	-	-
Growthbook	7	5	✅	❌	❌	3席	$20/席	-	-	-
AWS Evidently	13	3	❌	❌	❌	-	-	-	-	$5 / 100万イベント数
Bugsnag	8	8	❌	❌	❌	1席	$65 / 5席	問合せ	問合せ	問合せ
PostHog	5	7	❌	❌	✅	機能制限	-	-	-	1$/1万DL
Flagsmith	8	4	✅	🔺	❌	1席	$200/5席	-	-	$200 / 500万DL
Unleash	20	11	❌	❌	❌	OSSセルフ	$80/5席	問合せ	問合せ	問合せ
Flipt	5	1	❌	❌	✅	OSSセルフ	-	-	-	-
Bucketeer	2	4	✅	❌	❌	OSSセルフ	-	-	-	-
Flargd	1	1	❌	✅	❌	OSSセルフ	-	-	-	-
TwoFlags	1	1	❌	✅	❌	OSSセルフ	-	-	-	-

※ それぞれ課金モデルが異なり、プランも複数存在するので比較が困難である。間違いや更新があった際にコメントをいただければ幸いです。

比較した所感

採用しても良いと思ったSaaS編

・DevCycle（パフォーマンス、DX、UXが最も優れている）
・LaunchDarkly（インテグレーションの数、熟成度高いが料金も）
・ConfigCat（シンプル、安価）
・Statsig（料金体系が魅力的）

メンテされているOSS編

セルフホストをする運用力の余裕がある企業なら、OSSも一つの選択肢。

• Unleash（OSSの中で勢いが最もあるが、SaaS版は高い）
• FlagSmith（SaaS版は良心的な料金）
• Bucketter（弊社から公開されたばかりで期待のOSS）
• Flipt（シンプル・SaaS版はない）

メンテされなくなったOSS編

両方OSSともCloudflare Workersを前提としたEdgeアーキテクチャですが、残念ながらメンテされなくなりました。

• Flargd
• TwoFlags

Google・Amazon編

• Google Firebase Remote Config
  「永久無料」という点はとても魅了的だが、レイテンシ及びサーバーSDKの有無など、
  シンプルすぎるので、採用はおすすめできないです。

• AWS CloudWatch Evidently
  一番酷い。ノーコメント。AWSは開発者向けの良いDXを提供できない企業体質にずっと変わりがない。PdMとデザイナー不在だそうで、エンジニア以外の職業の必要性を理解していないのか、軽視し続けている模様。非常に残念。
  FigがAWSに買収されたばかりなので、もはやAWSが諦めて、買収路線に走り出した点は評価できます。

UXとレイテンシの重要性

近年、エッジコンピューティングの時代が到来して、ユーザのUX体験がさらに重要となってきました。ドハティの閾値の指標によると、ユーザの生産性が落ちないためのレスポンスタイムの上限は400msとされています。しかし、最近の人気アプリ（LinearやCron等）の反応速度の動向を考慮すると、ユーザの期待値が常に上がってきて、もはや100ms以下になっています。マーケットが熟成している中で、これが最も差別化できるポイントであり、Googleが成功した理由でもある。

一般的なフィーチャーフラグシステムでは、システムのアーキテクチャ上この100msを実現するのは難しいでしょう。一部のSaaSはUXを考慮して、Edgeにキャッシュを載せますが、DBや処理自体はEdgeではないです。

そこで注目されるのが、エッジで実装されてるフィーチャーフラグシステムです。

DevCycleの登場

私たちが求めていた、クラウドエッジでの高速なフィーチャーフラグシステムを見つけたのが「DevCycle」です。DevCycleの利点は以下の通りです。

• 50ms以下のレイテンシ: 高速なレスポンス。
• SDKの豊富さ: 導入が容易。
• 料金体型: MAU課金ですが、価格面で良心的な料金。
• 使いやすさ: DX・UXが直感的。
• リアルタイム更新: SSE経由で
• OpenFeature対応: ロックインを防げる。
• IDEのExtension: VSCodeのExtensionを使うと管理画面を開かなくて良い。開発効率がさらに向上。
• Edge Flags: Edge DB機能の提供。更新あったデータ一部のみで、全データを送信する必要ない。
• Local Bucketing: Edgeよりも更に高速なローカル処理。

DevCycleの優れた技術戦略: Edge FirstとWASM

DevCycleを開発している企業はTaplytics社。
Taplytics社は2014年からTaplyticsというA/BテストのSaaSを開発してきたが、スケーラビリティ、レイテンシ及びDXを改善するために、DevCycleといプロダクトを開発することになりました。
すべてをEdgeで実行というアーキテクチャにしました。処理はCloudflare Workers、DBはMacrometa、SSEプッシュはAbly等と、思い切った高速やEdge Firstな技術選定の決断を下しています。

クロスプラットフォームのSDKのパフォーマンスを最大限にするためにも殆どWASM（AssemblyScript）で実装されています。GoのSDKだけはWebAssemblyではなく、更に高度なマルチスレッド処理のパフォーマンスを発揮できるためにネイティブGoで実装されています。

コンテナRuntime → WASM Runtimeの世界になりつつある

Jonathan Norris（DevCycleのCTO）は「2030年までに、WebAssemblyのランタイムはコンテナベースのランタイムを置き換える」と予測しています。

内容を簡単にまとめると、

WebAssemblyの技術メリット

1. 厳格なセキュリティモデル
2. 非常に高速な起動時間
3. エッジでのスケーラビリティ
4. 非常に軽量
5. 環境間の移植性
6. クロス言語対応
7. パフォーマンス

WebAssemblyのコストメリット

1. Cloudflare WorkersやFastly、Netlifyなどのエッジランタイムでのワークロードは、起動時間やバイナリのサイズが小さいため、AWS Lambdaよりもコストが低い。
2. エッジランタイムはミリ秒以内に高速に起動できるが、Lambdaなどのコンテナ化されたサービスは起動に時間がかかり、メモリ使用量も多い。
3. これらのエッジランタイムに移行することで、DevCycleは大きなコスト削減を実現した。エッジで大規模なAPIも実行している。

DevCycleのサポート

余談ですが、私自身はまだDevCycleに課金したことがないにもかかわらず、
質問・要望があったので、Discordで投げてみたら、数時間内にHead of Product（PdM）から直接回答を頂き、更に直近の公開ロードマップにすでに載っていると教えていただいたので、神速な対応で好感を持ちました。

ProductBoardで優先度とロードマップを

因みにDevCycleのロードマップのHTMLを除いでみたのですが、ProductBoardで顧客の声とロードマップを公開されていました。
世の中の全プロダクトマネジャーに真似していただきたいです。
もしかして、君のPdMがまだ優先度決定でExcel、Miro、Notionで消耗していますか？

まとめ

開発サイクルのスピードアップは事業価値の向上に繋がります。そのための技術としてトランクベース開発とフィーチャーフラグは欠かせません。そして、高まるユーザの期待に応えるためには、DevCycleのような高速なフィーチャーフラグシステムの導入が鍵となります。これからDevCycleを活用して、より良い開発環境とUXを追求していきます！

---

以上、今回の記事となります。次回もお楽しみに！