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

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

Niwa Takeru
October 27, 2023

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

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で制御 • 切り戻しを考慮すること ◦ データベースに書き込みが あるケースで後方互換性を担保