Upgrade to Pro — share decks privately, control downloads, hide ads and more …

高い開発生産性を支えるFeatureFlagの活用テクニック

Avatar for Niwa Takeru Niwa Takeru
October 27, 2023

 高い開発生産性を支えるFeatureFlagの活用テクニック

Avatar for Niwa Takeru

Niwa Takeru

October 27, 2023
Tweet

More Decks by Niwa Takeru

Other Decks in Technology

Transcript

  1. • 自己紹介・プロダクト開発チームについて • トランクベース開発をする意義 • Feature Flags の実装・機能性 ◦ Full

    TypeScript x モノレポ を活用した実装例 ◦ Feature Flags での制御軸 • Feature Flags の活用事例 ◦ 利用シチュエーションの整理 ◦ 利用パターンの紹介 • 終わりに 2 Agenda 2
  2. 3 自己紹介 3 1990年生まれ 兵庫県出身 2016年 新卒でSIer NSSOLに入社 飲食業向けSaaS開発に従事 2020年

    株式会社グラファーに転職。 行政向けの電子申請SaaSを開発 2021年 アセンド株式会社に取締役CTO就任 物流向け運送管理SaaSを開発 丹羽 健 Niwa Takeru 取締役CTO/TSKaigi運営メンバー
  3. 4 アセンド株式会社の紹介 4 物流業界の価値最大化 Our Mission アセンドが挑む物流の社会課題 中小企業中心で投資余力がなく デジタル化に取り残された運送業界 2030年に物流の供給力は35%不足

    日本の経済損失は10兆円 一方で運送事業の市場規模は20兆円 SaaSを起点として事業が成り立ち 十分にユニコーンが狙える業界 TAM 20兆円 SAM 2兆円 2024年問題対策として、 政策パッケージが発表 解く意義の大きい社会課題を持ち エンジニアとして最大限の挑戦と 社会的インパクトを起こすこと ができる
  4. 5 5 高い開発生産性で 3ヶ月に1度プロダクトをリリース デプロイ頻度 変更リードタイム 5.67 deploys/day 2 hours

    平均修復時間 変更失敗率 24 minutes 2.6 percent 運送業特化 All-in-One SaaS を開発
  5. プロダクト開発の不確実性への対応 • 迅速に仮説検証を進める ◦ 未完成・MVPの早期提供 ◦ A/Bテストのような実験 • 素早く安全に失敗する ◦

    失敗の影響範囲を小さくする ◦ 心理的安全性の高いトライ 8 トランクベース開発の意義 8 日進月歩で プロダクトを 進化させるため トランクベース開発の不確実性・難易度を 制御するために Feature Flags を活用する 日進月歩で プロダクトを 進化させるため
  6. Full TypeScript である利点を活かし Frontend と Backend で 共通の Feature Flags

    の定義を参照 9 Full TypeScript x Feature Flags 9 Backend Frontend Core シンプルな Feature Flag の実装例 参照 Feature Flag 🏁
  7. 単純な機能のOn/Offだけでなく 特定のユーザー群のみを指定した公開 • ID単位での指定 ◦ テナント ◦ ユーザー • ユーザー属性での指定

    ◦ 管理者限定での先行公開 ◦ 20%などランダムな公開 10 On/Off だけでない柔軟な制御 10 公開範囲の選択肢を作ることで 状況に合った影響範囲にコントロールできる
  8. シーン毎に利用方法を使い分ける • 短期 x 新機能 ◦ 不確実性の高い機能の検証 • 長期 x

    新機能 ◦ 画面レベルでルーティング制御 • 短期 x 既存機能 ◦ 不具合がないことの最終確認 • 長期 x 既存機能 ◦ 大規模リプレイスなど最も複雑…。 11 Feature Flags の利用シチュエーションの整理 11 短期 長期 新 機 能 • 機能検証 • 顧客案内予定 • MVP開発 • 新プロダクト • 新機能 • MVP開発 既 存 機 能 • Blue→Green での公開 • データモデル 移行 • 大規模な リプレイス • データベース 移行 FeatureFlagsの生存期間 対 象 機 能 FeatureFlagsの利用シーンは多様
  9. 新機能での Feature Flags の利用 • 最も一般な新機能開発の場合 ◦ ルーティングレベルで 見れない状態にしておく ◦

    一方で公開直前には ダイレクトアクセス可にすると 突発的な紹介に活用もできる • A/Bテストに近い機能検証 ◦ 実験的な機能/UIの場合 特定顧客に対して先行公開する • 顧客周知タイミングをズラす ◦ カスタマーサクセスによる 機能説明が必要な場合に スケジュールを分散させる 12 12 短期:ユーザー観点が中心 長期:新規プロダクトの開発期間 注意ポイント 注意ポイント • 開発終了間際は 短期の観点での扱いに変わる • 機能開放後に速やかに除却 ◦ 生存期間が短いかつ発生も多い ◦ 定期的な除却プロセス
  10. 既存機能での Feature Flags の利用 • 最も複雑なリプレイス ◦ 複雑である故に細かく制御せず 機能の大元でコードを複製し FeatureFlagsで分岐を作ると楽

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