【Feature Flag 活用LT〜開発生産性を高めるトランクベース開発〜】 高い開発生産性を支える Feature Flags の活用テクニック 取締役CTO 丹羽健

● 自己紹介・プロダクト開発チームについて ● トランクベース開発をする意義 ● Feature Flags の実装・機能性 ○ Full TypeScript x モノレポ を活用した実装例 ○ Feature Flags での制御軸 ● Feature Flags の活用事例 ○ 利用シチュエーションの整理 ○ 利用パターンの紹介 ● 終わりに 2 Agenda 2

3 自己紹介 3 1990年生まれ 兵庫県出身 2016年 新卒でSIer NSSOLに入社 飲食業向けSaaS開発に従事 2020年 株式会社グラファーに転職。 行政向けの電子申請SaaSを開発 2021年 アセンド株式会社に取締役CTO就任 物流向け運送管理SaaSを開発 丹羽 健 Niwa Takeru 取締役CTO/TSKaigi運営メンバー

4 アセンド株式会社の紹介 4 物流業界の価値最大化 Our Mission アセンドが挑む物流の社会課題 中小企業中心で投資余力がなく デジタル化に取り残された運送業界 2030年に物流の供給力は35%不足 日本の経済損失は10兆円 一方で運送事業の市場規模は20兆円 SaaSを起点として事業が成り立ち 十分にユニコーンが狙える業界 TAM 20兆円 SAM 2兆円 2024年問題対策として、 政策パッケージが発表 解く意義の大きい社会課題を持ち エンジニアとして最大限の挑戦と 社会的インパクトを起こすこと ができる

5 5 高い開発生産性で ３ヶ月に１度プロダクトをリリース デプロイ頻度 変更リードタイム 5.67 deploys/day 2 hours 平均修復時間 変更失敗率 24 minutes 2.6 percent 運送業特化 All-in-One SaaS を開発

6 プロダクトエンジニアとしての開発 6 1エンジニアがソフトウェアの ライフサイクル全てにオーナーシップを 持ち開発できるよう開発環境を設計・投資 ユーザ課題を中心として機能検証の 開発サイクルを高速に進めることが可能 アウトカムを中心として開発 フルサイクルを支えるため多くの技術的投資と仕組み的な資産を積み重ねています

7 7 Trunk based Development and Feature Flags Trunk based Development and Feature Flags

プロダクト開発の不確実性への対応 ● 迅速に仮説検証を進める ○ 未完成・MVPの早期提供 ○ A/Bテストのような実験 ● 素早く安全に失敗する ○ 失敗の影響範囲を小さくする ○ 心理的安全性の高いトライ 8 トランクベース開発の意義 8 日進月歩で プロダクトを 進化させるため トランクベース開発の不確実性・難易度を 制御するために Feature Flags を活用する 日進月歩で プロダクトを 進化させるため

Full TypeScript である利点を活かし Frontend と Backend で 共通の Feature Flags の定義を参照 9 Full TypeScript x Feature Flags 9 Backend Frontend Core シンプルな Feature Flag の実装例 参照 Feature Flag 🏁

単純な機能のOn/Offだけでなく 特定のユーザー群のみを指定した公開 ● ID単位での指定 ○ テナント ○ ユーザー ● ユーザー属性での指定 ○ 管理者限定での先行公開 ○ 20%などランダムな公開 10 On/Off だけでない柔軟な制御 10 公開範囲の選択肢を作ることで 状況に合った影響範囲にコントロールできる

シーン毎に利用方法を使い分ける ● 短期 x 新機能 ○ 不確実性の高い機能の検証 ● 長期 x 新機能 ○ 画面レベルでルーティング制御 ● 短期 x 既存機能 ○ 不具合がないことの最終確認 ● 長期 x 既存機能 ○ 大規模リプレイスなど最も複雑…。 11 Feature Flags の利用シチュエーションの整理 11 短期 長期 新 機 能 ● 機能検証 ● 顧客案内予定 ● MVP開発 ● 新プロダクト ● 新機能 ● MVP開発 既 存 機 能 ● Blue→Green での公開 ● データモデル 移行 ● 大規模な リプレイス ● データベース 移行 FeatureFlagsの生存期間 対 象 機 能 FeatureFlagsの利用シーンは多様

新機能での Feature Flags の利用 ● 最も一般な新機能開発の場合 ○ ルーティングレベルで 見れない状態にしておく ○ 一方で公開直前には ダイレクトアクセス可にすると 突発的な紹介に活用もできる ● A/Bテストに近い機能検証 ○ 実験的な機能/UIの場合 特定顧客に対して先行公開する ● 顧客周知タイミングをズラす ○ カスタマーサクセスによる 機能説明が必要な場合に スケジュールを分散させる 12 12 短期：ユーザー観点が中心 長期：新規プロダクトの開発期間 注意ポイント 注意ポイント ● 開発終了間際は 短期の観点での扱いに変わる ● 機能開放後に速やかに除却 ○ 生存期間が短いかつ発生も多い ○ 定期的な除却プロセス

既存機能での Feature Flags の利用 ● 最も複雑なリプレイス ○ 複雑である故に細かく制御せず 機能の大元でコードを複製し FeatureFlagsで分岐を作ると楽 ○ 旧版への開発停止も セットで決められると尚よし ● アプリケーションレベルでの Blue→Green 公開 ○ 性能問題が懸念される場合、 懸念の大きい顧客だけ先行公開 ● データモデルの移行 ○ 新モデル・旧モデル版を作り FeatureFlagsを用いて使い分ける 13 13 短期：不具合の最終確認 長期：リプレイス案件 注意ポイント 注意ポイント ● リプレイス以前に細かい 機能改修群にできないか検討 ● できる限り１つのFlagで制御 ● 切り戻しを考慮すること ○ データベースに書き込みが あるケースで後方互換性を担保

アセンドで共に開発をするプロダクトエンジニアを募集しています！ プロダクト開発ナレッジを発信するイベントを 定期的に開催しています！ メッセージ 14 CTO 丹羽 の 𝕏 (@niwa_takeru) お気軽にフォローください。 ASCEND ProductFM Product Engineer Night TS Kaigi 2024春 (仮)

No content