トランクベース開発とフィーチャーフラグを使ったエンプラSaaS開発の実際
こんにちは、株式会社AcompanyでフルスタックエンジニアをしているHideです。
本記事ではプライバシーテックのスタートアップで、トランクベース開発とフィーチャーフラグを導入して爆速開発した際の運用と感想についてお話ししていきます。
はじめに：スタートアップの0→1フェーズで求められる素早い開発
スタートアップや新規プロジェクトの初期段階、いわゆる0→1フェーズでは、迅速な開発と市場投入が求められます。このフェーズでは開発チームとBizdevチームと密接に連携し、顧客の声を反映させることが重要です。競合に遅れを取らないためにも、デモ開発→顧客の声を聴く→改善施策のループを高速に回す必要があります。
私のチームではエンプラ向けのSaaSを開発しており、トランクベース開発の体制を採用して迅速な機能追加を実現しています。
トランクベース開発とは
トランクベース開発（Trunk-Based Development）は、短いブランチサイクルと頻繁なマージを特徴とする開発手法です。この手法により、継続的インテグレーション（CI）と高いコード品質が維持されます。
トランクベース開発の図解(dora.devより)
弊社では以下のルールで運用を行なっています。
運用時のルール
- 自分の書いたコードは十分なテストを行い、安定的に動作することを保証する[MUST]
- 自分の書いたコードにバグが見つかったら迅速にrevertもしくは修正を行い、mainブランチからバグを取り除く[MUST]
- レビューは原則最優先タスクとして行う[MUST]
- レビューは特定のメンバー、グループを指名して依頼する[MUST]
- レビューコストを下げるためにfeatureブランチは最小限(数時間-数日程度)の変更でPRを送るべき[SHOULD]
- セルフマージをOKにし、リスク分散上必要だと判断したら他者にレビューを依頼すべき[SHOULD]
このように運用することで１日に2,3回くらい機能追加をしてトランク(mainブランチ)にマージしていました。
## シチュエーションごとの機能要件
エンプラ向けSaaSのデモ開発をして仮説検証を繰り返す中で、当たり前ですが、顧客ごとにニーズは若干異なる場面がありました。バックエンドも繋ぎ込みでデモ提供する中で、ある場面では要らないが、他の場面では欲しい機能があるシチュエーションが出てきたり、バックエンドは出来上がってないがデモとしては画面イメージを見たい場合が出てきたり。
デモ開発を進めていくうちに機能やUIの分岐が必要になってきたため、機能やUIの分岐を効率的に行うためにチームでフィーチャーフラグを導入しました。
フィーチャーフラグとは？
フィーチャーフラグは、ソースコードを変更することなく、特定の機能やコードパスの動作を有効化、無効化、変更することを可能にするソフトウェア開発手法です。
これにより、長期に渡る機能ブランチの必要性が減り、作業中の機能をエンドユーザーから隠しつつ、内部テストには露出させることができます。これは、トランクベース開発を実現するために非常に重要です。
環境変数管理やfirebaseなどいくつか候補はありましたが、以下の観点で考えた結果devcycleというツールを採用しました。
- true, falseだけではなく文字列や数値、オブジェクトを切り替えたい。
- ユーザーのメタデータ（年齢,IPアドレス,使用しているアプリバージョン...）によってフィーチャーフラグの値を変えたい。
- 複数のフィーチャーフラグを管理するための管理画面が欲しい。
- ユーザー群をランダムに分割し、フィーチャーフラグの値を使ってA/Bテストをしたい。
- 無料（←デカい）
devcycleのサービストップ画面
devcycle上でユーザのメールアドレスで出し分けるフラグ
devcycleの料金表
フィーチャーフラグのメリット
フィーチャーフラグを使用することで得られる主なメリットは以下の通りです：
-
リリースの柔軟性
開発チームは新機能をコードベースに統合しつつも、特定のユーザーグループや環境にのみその機能を有効にすることができます。 -
デプロイの安定性
フィーチャーフラグを使用することで、デプロイの際に新機能がシステム全体に影響を与えるリスクを減らせます。問題が発生した場合でも、フィーチャーフラグをオフにするだけで、元の状態に戻すことができます。 -
開発メンバー間の協調
開発メンバーが並行して異なる機能を開発している場合、フィーチャーフラグを使用することで、各々が独立して機能を開発し、必要に応じて個別にリリースできます。これにより、リリースの調整が簡単になります。
フィーチャーフラグのデメリット
フィーチャーフラグの導入には以下のデメリットも存在します：
-
複雑性の増加
フィーチャーフラグの導入は、コードベースに複雑性をもたらします。複数のフィーチャーフラグが同時に存在する場合、コードの読みやすさやメンテナンス性が低下します。例えばフラグが存在する層がバラバラに管理されている場合、あるフラグをオフにした時にその下の層のフラグも誤ってオフになる可能性があります。 -
技術的負債のリスク
フィーチャーフラグを長期間放置すると、古いコードや不要な機能が残り、技術的負債となるリスクがあります。実際に、すでにリリース済みの機能に対して不要なフラグが残っていたことがあり、削除することもありました。
運用ルール
-
明確な目的と範囲
- フィーチャーフラグは、新機能のリリース管理、A/Bテスト、段階的な展開など、明確な目的のためにのみ使用する。
- そのフラグが解決しようとしている具体的な課題や目標に直結している必要があり、無計画な使用や目的外の使用は避けるべき。
-
限定的な責務
- フィーチャーフラグは、ビジネスロジックや認可処理など、DevOps以外の責務を負わない(👈ココ大事) 。
- 不必要な複雑性や管理の負担を避けるため、フィーチャーフラグは単純かつ明瞭であるべき。
- 導入の判断基準
- 限定的な責務であるかはどうかは、そのフラグがアプリケーションロジックに及ぼす影響により判断する。
-
定期的なレビューと廃止
- フィーチャーフラグは定期的にレビューし、その目的が果たされたら速やかに廃止する。
- あらかじめ、フィーチャーフラグの生存期間については明確に取り決めを行うなどし、維持管理の負担を軽減する。
フィーチャーフラグ導入の感想
控えめに言って最高でした。
devcycle自体の使いやすさ、導入のしやすさはもちろんですが、フィーチャーフラグという仕組みが、爆速開発を必要とする今のフェーズにピッタリでした。
現状は使用しているフラグ数が多くないので管理の問題は起きていませんが、大規模になってくると管理に力を入れる必要があると感じています。
おわりに
株式会社Acompanyでは、我々と一緒にプライバシーテックの領域で世界を目指してくれるメンバーを募集しています。まずは、カジュアル面談でAcompanyと互いに理解を深めましょう。ページ半ばに申し込みフォームがあります。
また、弊社メンバーの他のブログは以下エンジニアブログハブにまとめてあります。
代表がプライバシーテックスタートアップについて深掘りするpodcastもありますのでぜひ（いつも歯磨きしながら聴いてます）
Discussion