フィーチャートグルを 使って素早く価値を検証する 早く安全に失敗し学ぶために

Transcript

1. フィーチャートグルを 使って素早く価値を検証する 早く安全に失敗し学ぶために PHP Conference Japan 2022 / 秋葉 誠一/@akki_megane
2. 自己紹介 - 株式会社ROXX back check 事業部 - スノボ、映画が好きです 今年ベスト映画「ソー:ラブ&サンダー」 最近引っ越したのでおすすめの 家具・家電教えてください 秋葉 誠一
3. back check の技術スタック バックエンド フロントエンド
4. この発表は フィーチャートグルによる仮説検証の取り組みを紹介します。 なぜフィーチャートグルを採用したのか、どういった思想でアーキテ クチャを構築し、運用しているのかを話します。 フィーチャートグル自体の説明は少ないです PHPの話は、ちょっとでてきます・・・
5. Agenda - フィーチャートグルとは - なぜフィチャートグルなのか - フィーチャートグルの実装・運用 - まとめ
6. フィーチャートグル とは
7. フィーチャートグル (a.k.a フィーチャフラグ) 機能リリースとコードデプロイメントを分離する ソフトウェアデリバリの概念である。 以下4つに分類される - Release Toggles (リリーストグル) - Experiment Toggles (実験トグル) - Ops Toggles (運用トグル) - Permission Toggles(権限トグル)
8. 詳しく知りたい方は kubotak さんの資料を
9. フィーチャートグル (a.k.a フィーチャフラグ) 機能リリースとコードデプロイメントを分離する ソフトウェアデリバリの概念である。 以下4つに分類される - Release Toggles (リリーストグル) - Experiment Toggles (実験トグル) - Ops Toggles (運用トグル) - Permission Toggles(権限トグル)
10. フィーチャートグル (a.k.a フィーチャフラグ) Experiment Toggles (実験トグル) A/B テストやカナリアテストなどに用いられ ユーザーごとによる切り替え。 プロダクトの仮説検証やデータ駆動による 意思決定を行うために役立ちます。
11. なぜ フィーチャートグルなのか
12. 早く挑戦して 早く失敗して 早く学びを得える 早く挑戦して 早く失敗して 早く学びを得える
13. アイデアを仮説検証したい 検証すればもしかしたら価値があるかもしれないアイデアは運用 当初からいくつもあった。 不確実性の塊からユーザーにとって 真に価値があるもの探索するための仮説検証をして 早い段階で挑戦・失敗をしたかった。
14. アイデアを仮説検証したい 「やるべきことは、与えられた時間と資金よりも多い」 　　　　　　　　　　　　　　　　by アジャイルサムライ やるべきことがまだまだある中で、 不確実性の高い実験的な施策への挑戦はリスク が高く敬遠されてしまっていた。
15. 不確実性を下げていく必要があった - 目的不確実性 - なぜやるのか、誰のためにやるのか - Why What - 方法不確実性 - どうやってやるのか - How
16. 不確実性が高いままやるとどうなるのか - 目的不確実性 - なぜかある、誰のためでもないものが生まれる - 実装へのしわ寄せで結果、技術的・ビジネス的な負債を 生み出す - 「思ったのとちがう」、「作ったけど使われない」 - 方法不確実性 - やり方が決まっていないので先が読めない - 「やってみいことには」、「どう作るの？」
17. 本番で試すことができるのが フィーチャートグルの強み フィーチャートグルを使うことで、本番環境で、一部のユーザーだ けに機能を提供するということができるようになった。 実際のユーザーのフィードバックと取れたデータを元にすることで 価値の探索と不確実性を下げることを同時にできた。
18. フィーチャートグルの 実装・運用
19. キーワードは、安全に実験 キーワードは、安全に実験
20. アーキテクチャのコンセプト - 特定のユーザーのみ絞ってに機能を提供する - 特定ユーザーに絞ることによる検証範囲の操作 - プロダクト本体への依存度を低くする - 本体のコードベースへの依存度を下げ、本流の開発への影響を 押さえ別々で開発できるようにする - 検証なので使い捨ての機能として実装 - 必要最低限の実装 - 不要ならそのまま消せるように - 採用なら実装についてを再度検討し本格的に実装する
21. 設計方針 検証のために必要最低限の実装 施策ごとにフィーチャートグルの設定できる フィーチャートグルの実装はフロントエンド・バックエンドそれぞれに存在 するが、中心はフロントエンド フロントエンドは主にコンポーネントの出し分け バックエンドは専用のAPIを提供するそれぞれ役割が異なる フィチャートグルの制御は Launchdarklyというサビースを使っている
22. フロントエンドの実装方針 - 仮説検証用のディレクトリを作る(featuresディレクトリ) - 施策単位でのディレクトリ分け - 本体のコードとリポジトリは共通 - フィーチャートグルの分岐(トグルポイント)をHOC(※)に集約す る - 基本的にディレクトリごと消しされるように、他からの依存度を 低くする ※Higher-Order-Component
23. フロントエンドの実装: ディレクトリ構成 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のディレクトリに検 証機能を入れて他と明確に 区別する 他と依存させない
24. フロントエンドの実装: HOC HOCは React の設計パターン1つで、「コンポーネントを返す関 数」 HOCのなかでフィーチャートグルのON/OFFだけを判定して、一部 のユーザーにだけ検証機能のコンポーネントを返す HOCを間に挟んで依存の方向を制御 親コンポーネント 子コンポーネント (検証機能用) HOC 依存 依存
25. 試作用のディレクトリ フロントエンドの実装: HOC HOC(※)によるコンポーネントの出し分け ※Higher-Order-Component 親コンポーネント 子コンポーネント (検証機能用) HOC フィーチャートグル 空コンポーネント ON OFF
26. バックエンドの実装方針 - まず必要なら外部リソースを検討 - Lambda, Croud Run, GAS - モジュラーモノリスを意識して施策ごとにモジュール化 - リポジトリもDBは共通 - 施策用の専用HTTPのエンドポイントのみを提供する - 本流のコードへの依存度は低く保つ - フィーチャートグルの分岐(トグルポイント)をLaravel の Middlewareに集約する
27. バックエンドの実装: ディレクトリ構成 /modules/features └── utils │ ├── composer.json │ └── src └── features1 ├── composer.json └── src │ ├── ServiceProvider.php │ ├── Http │ │ ├── Controllers │ │ └── Middleware │ └── routes.php └── tests └── Feature └── Http 施策ごとにモジュールとして 切り出す 他とは依存させない そのまま消しても影響がな い
28. 試作用のモジュール バックエンドの実装: Middleware フロントエンド 検証機能 検証機能用の処理 Middleware フィーチャートグル ON OFF HTTP request HTTP status 40x
29. 運用例 要件・仕様・開発 本番(社内)でテスト 本番(一部のユーザー) でテスト プロダクト全体へ展開 価値検証へ 最小で実装 価値がないと判断できたら、再検討や 廃止の方向にシフト 検証範囲 の拡大 本実装へ向け再度検討 施策機能はフィーチャート グルごと削除
30. まとめ
31. メリット - 仮説検証が早く安全にできる - 「試してみよう」が選択肢としてカジュアルにとれるのはでかい - 特定のユーザーに絞ることで施策の変更やクローズの労力が減っ た - 本流の開発とは別で開発を進めることができるようになった - 意思決定がデータドリブンでできる - 不確実性が下がることで本格的に実装するときの確実性が上がる
32. デメリット - 依存性の低さと引き換えにできることが限られる - 規模が大きくなってくるときつい - 今後拡張予定 - UI的な変更へは弱い - 仮説検証のため機能の動作担保も必要 - 依存度を低くするために、コード量が増えることや、重複するような 処理が生まれてしまう
33. まとめ - Experiment Toggles(実験トグル) の概念は、 DevOps観点 的な見方とは異なった、プロダクト開発にフォーカスしたフィー チャートグル。 - フィーチャートグルを導入するときに重要なこと - 機能の開発プロセス - フィーチャートグルの技術基盤 - トグルのライフサイクル管理
34. ご清聴ありがとうございました！ エンジニア募集してます！ 参考書籍 「早く挑戦して」、「早く失敗して」、「早く学ぶ」 そんな願いを込めて作りました。 ご清聴ありがとうございました！ エンジニア募集してます！