$30 off During Our Annual Pro Sale. View Details »
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
フィーチャートグルを 使って素早く価値を検証する 早く安全に失敗し学ぶために
Search
akki
September 23, 2022
Programming
0
2.5k
フィーチャートグルを 使って素早く価値を検証する 早く安全に失敗し学ぶために
akki
September 23, 2022
Tweet
Share
More Decks by akki
See All by akki
Open AI APIを使う前に知っておきたいアカウントTier の話
akki_megane
0
2k
データの民主化はじめました 俺たちの民主化はこれからだ
akki_megane
1
1.4k
技術的負債を返し続ける取り組み
akki_megane
0
570
「明日からフロントもよろしく」と言われたときに備える Atomic Design
akki_megane
0
3.6k
Editor 調査
akki_megane
0
170
Laravel Vapor Serverless Laravel
akki_megane
2
320
アノテーションコメントについて調べてみた
akki_megane
2
640
入門 無限LT
akki_megane
0
4.3k
PHP Insights - リファクタリングが100倍楽しくなるツール -
akki_megane
3
1.5k
Other Decks in Programming
See All in Programming
cmp.Or に感動した
otakakot
3
340
.NET 9アプリをCGIとして レンタルサーバーで動かす
mayuki
1
750
イマのCSSでできる インタラクション最前線 + CSS最新情報
clockmaker
5
3.8k
Discord Bot with AI -for English learners-
xin9le
1
110
クリエイティブコーディングとRuby学習 / Creative Coding and Learning Ruby
chobishiba
0
3.5k
useSyncExternalStoreを使いまくる
ssssota
0
170
eBPF Deep Dive: Architecture and Safety Mechanisms
takehaya
12
1.2k
The rollercoaster of releasing an Android, iOS, and macOS app with Kotlin Multiplatform | droidcon Italy
prof18
0
140
Criando Commits Incríveis no Git
marcelgsantos
1
140
かんたんデザイン編集やってみた~「完全に理解した」までの道のり~
morit4ryo
1
120
Refactor your code - refactor yourself
xosofox
1
110
【re:Growth 2024】 Aurora DSQL をちゃんと話します!
maroon1st
0
250
Featured
See All Featured
Building Flexible Design Systems
yeseniaperezcruz
327
38k
Building an army of robots
kneath
302
43k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
Making the Leap to Tech Lead
cromwellryan
133
9k
Speed Design
sergeychernyshev
25
650
4 Signs Your Business is Dying
shpigford
181
21k
Into the Great Unknown - MozCon
thekraken
33
1.5k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
10
780
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
6.9k
Git: the NoSQL Database
bkeepers
PRO
427
64k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
1
93
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
45
2.2k
Transcript
フィーチャートグルを 使って素早く価値を検証する 早く安全に失敗し学ぶために PHP Conference Japan 2022 / 秋葉 誠一/@akki_megane
自己紹介 - 株式会社ROXX back check 事業部 - スノボ、映画が好きです 今年ベスト映画「ソー:ラブ&サンダー」 最近引っ越したのでおすすめの
家具・家電教えてください 秋葉 誠一
back check の技術スタック バックエンド フロントエンド
この発表は フィーチャートグルによる仮説検証の取り組みを紹介します。 なぜフィーチャートグルを採用したのか、どういった思想でアーキテ クチャを構築し、運用しているのかを話します。 フィーチャートグル自体の説明は少ないです PHPの話は、ちょっとでてきます・・・
Agenda - フィーチャートグルとは - なぜフィチャートグルなのか - フィーチャートグルの実装・運用 - まとめ
フィーチャートグル とは
フィーチャートグル (a.k.a フィーチャフラグ) 機能リリースとコードデプロイメントを分離する ソフトウェアデリバリの概念である。 以下4つに分類される - Release Toggles (リリーストグル)
- Experiment Toggles (実験トグル) - Ops Toggles (運用トグル) - Permission Toggles(権限トグル)
詳しく知りたい方は kubotak さんの資料を
フィーチャートグル (a.k.a フィーチャフラグ) 機能リリースとコードデプロイメントを分離する ソフトウェアデリバリの概念である。 以下4つに分類される - Release Toggles (リリーストグル)
- Experiment Toggles (実験トグル) - Ops Toggles (運用トグル) - Permission Toggles(権限トグル)
フィーチャートグル (a.k.a フィーチャフラグ) Experiment Toggles (実験トグル) A/B テストやカナリアテストなどに用いられ ユーザーごとによる切り替え。 プロダクトの仮説検証やデータ駆動による
意思決定を行うために役立ちます。
なぜ フィーチャートグルなのか
早く挑戦して 早く失敗して 早く学びを得える 早く挑戦して 早く失敗して 早く学びを得える
アイデアを仮説検証したい 検証すればもしかしたら価値があるかもしれないアイデアは運用 当初からいくつもあった。 不確実性の塊からユーザーにとって 真に価値があるもの探索するための仮説検証をして 早い段階で挑戦・失敗をしたかった。
アイデアを仮説検証したい 「やるべきことは、与えられた時間と資金よりも多い」 by アジャイルサムライ やるべきことがまだまだある中で、 不確実性の高い実験的な施策への挑戦はリスク が高く敬遠されてしまっていた。
不確実性を下げていく必要があった - 目的不確実性 - なぜやるのか、誰のためにやるのか - Why What - 方法不確実性
- どうやってやるのか - How
不確実性が高いままやるとどうなるのか - 目的不確実性 - なぜかある、誰のためでもないものが生まれる - 実装へのしわ寄せで結果、技術的・ビジネス的な負債を 生み出す - 「思ったのとちがう」、「作ったけど使われない」
- 方法不確実性 - やり方が決まっていないので先が読めない - 「やってみいことには」、「どう作るの?」
本番で試すことができるのが フィーチャートグルの強み フィーチャートグルを使うことで、本番環境で、一部のユーザーだ けに機能を提供するということができるようになった。 実際のユーザーのフィードバックと取れたデータを元にすることで 価値の探索と不確実性を下げることを同時にできた。
フィーチャートグルの 実装・運用
キーワードは、安全に実験 キーワードは、安全に実験
アーキテクチャのコンセプト - 特定のユーザーのみ絞ってに機能を提供する - 特定ユーザーに絞ることによる検証範囲の操作 - プロダクト本体への依存度を低くする - 本体のコードベースへの依存度を下げ、本流の開発への影響を 押さえ別々で開発できるようにする
- 検証なので使い捨ての機能として実装 - 必要最低限の実装 - 不要ならそのまま消せるように - 採用なら実装についてを再度検討し本格的に実装する
設計方針 検証のために必要最低限の実装 施策ごとにフィーチャートグルの設定できる フィーチャートグルの実装はフロントエンド・バックエンドそれぞれに存在 するが、中心はフロントエンド フロントエンドは主にコンポーネントの出し分け バックエンドは専用のAPIを提供するそれぞれ役割が異なる フィチャートグルの制御は Launchdarklyというサビースを使っている
フロントエンドの実装方針 - 仮説検証用のディレクトリを作る(featuresディレクトリ) - 施策単位でのディレクトリ分け - 本体のコードとリポジトリは共通 - フィーチャートグルの分岐(トグルポイント)をHOC(※)に集約す る
- 基本的にディレクトリごと消しされるように、他からの依存度を 低くする ※Higher-Order-Component
フロントエンドの実装: ディレクトリ構成 src/store/featureFlag.t s src/middleware/initializeFeatureFlagClient.ts src/features/ ├── _utils │ ├──
featureFlagClient.ts │ └── featureFlagged.tsx ├── hogehogeFeature │ ├── api │ ├── components │ │ ├── hoge.vue │ │ └── fuga.vue │ └── utils │ └── flagValidation.ts ├── hogehogeFeature2 inspire by bulletproof-react featuresのディレクトリに検 証機能を入れて他と明確に 区別する 他と依存させない
フロントエンドの実装: HOC HOCは React の設計パターン1つで、「コンポーネントを返す関 数」 HOCのなかでフィーチャートグルのON/OFFだけを判定して、一部 のユーザーにだけ検証機能のコンポーネントを返す HOCを間に挟んで依存の方向を制御 親コンポーネント
子コンポーネント (検証機能用) HOC 依存 依存
試作用のディレクトリ フロントエンドの実装: HOC HOC(※)によるコンポーネントの出し分け ※Higher-Order-Component 親コンポーネント 子コンポーネント (検証機能用) HOC フィーチャートグル
空コンポーネント ON OFF
バックエンドの実装方針 - まず必要なら外部リソースを検討 - Lambda, Croud Run, GAS - モジュラーモノリスを意識して施策ごとにモジュール化
- リポジトリもDBは共通 - 施策用の専用HTTPのエンドポイントのみを提供する - 本流のコードへの依存度は低く保つ - フィーチャートグルの分岐(トグルポイント)をLaravel の Middlewareに集約する
バックエンドの実装: ディレクトリ構成 /modules/features └── utils │ ├── composer.json │ └──
src └── features1 ├── composer.json └── src │ ├── ServiceProvider.php │ ├── Http │ │ ├── Controllers │ │ └── Middleware │ └── routes.php └── tests └── Feature └── Http 施策ごとにモジュールとして 切り出す 他とは依存させない そのまま消しても影響がな い
試作用のモジュール バックエンドの実装: Middleware フロントエンド 検証機能 検証機能用の処理 Middleware フィーチャートグル ON OFF
HTTP request HTTP status 40x
運用例 要件・仕様・開発 本番(社内)でテスト 本番(一部のユーザー) でテスト プロダクト全体へ展開 価値検証へ 最小で実装 価値がないと判断できたら、再検討や 廃止の方向にシフト
検証範囲 の拡大 本実装へ向け再度検討 施策機能はフィーチャート グルごと削除
まとめ
メリット - 仮説検証が早く安全にできる - 「試してみよう」が選択肢としてカジュアルにとれるのはでかい - 特定のユーザーに絞ることで施策の変更やクローズの労力が減っ た - 本流の開発とは別で開発を進めることができるようになった
- 意思決定がデータドリブンでできる - 不確実性が下がることで本格的に実装するときの確実性が上がる
デメリット - 依存性の低さと引き換えにできることが限られる - 規模が大きくなってくるときつい - 今後拡張予定 - UI的な変更へは弱い -
仮説検証のため機能の動作担保も必要 - 依存度を低くするために、コード量が増えることや、重複するような 処理が生まれてしまう
まとめ - Experiment Toggles(実験トグル) の概念は、 DevOps観点 的な見方とは異なった、プロダクト開発にフォーカスしたフィー チャートグル。 - フィーチャートグルを導入するときに重要なこと
- 機能の開発プロセス - フィーチャートグルの技術基盤 - トグルのライフサイクル管理
ご清聴ありがとうございました! エンジニア募集してます! 参考書籍 「早く挑戦して」、「早く失敗して」、「早く学ぶ」 そんな願いを込めて作りました。 ご清聴ありがとうございました! エンジニア募集してます!