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

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

akki
September 23, 2022

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

akki

September 23, 2022
Tweet

More Decks by akki

Other Decks in Programming

Transcript

  1. フィーチャートグルを
    使って素早く価値を検証する
    早く安全に失敗し学ぶために
    PHP Conference Japan 2022 / 秋葉 誠一/@akki_megane

    View Slide

  2. 自己紹介
    - 株式会社ROXX back check 事業部
    - スノボ、映画が好きです
    今年ベスト映画「ソー:ラブ&サンダー」
    最近引っ越したのでおすすめの
    家具・家電教えてください
    秋葉 誠一

    View Slide

  3. back check の技術スタック
    バックエンド
    フロントエンド

    View Slide

  4. この発表は
    フィーチャートグルによる仮説検証の取り組みを紹介します。
    なぜフィーチャートグルを採用したのか、どういった思想でアーキテ
    クチャを構築し、運用しているのかを話します。
    フィーチャートグル自体の説明は少ないです
    PHPの話は、ちょっとでてきます・・・

    View Slide

  5. Agenda
    - フィーチャートグルとは
    - なぜフィチャートグルなのか
    - フィーチャートグルの実装・運用
    - まとめ

    View Slide

  6. フィーチャートグル
    とは

    View Slide

  7. フィーチャートグル (a.k.a フィーチャフラグ)
    機能リリースとコードデプロイメントを分離する
    ソフトウェアデリバリの概念である。
    以下4つに分類される
    - Release Toggles (リリーストグル)
    - Experiment Toggles (実験トグル)
    - Ops Toggles (運用トグル)
    - Permission Toggles(権限トグル)

    View Slide

  8. 詳しく知りたい方は kubotak さんの資料を

    View Slide

  9. フィーチャートグル (a.k.a フィーチャフラグ)
    機能リリースとコードデプロイメントを分離する
    ソフトウェアデリバリの概念である。
    以下4つに分類される
    - Release Toggles (リリーストグル)
    - Experiment Toggles (実験トグル)
    - Ops Toggles (運用トグル)
    - Permission Toggles(権限トグル)

    View Slide

  10. フィーチャートグル (a.k.a フィーチャフラグ)
    Experiment Toggles (実験トグル)
    A/B テストやカナリアテストなどに用いられ
    ユーザーごとによる切り替え。
    プロダクトの仮説検証やデータ駆動による
    意思決定を行うために役立ちます。

    View Slide

  11. なぜ
    フィーチャートグルなのか

    View Slide

  12. 早く挑戦して
    早く失敗して
    早く学びを得える
    早く挑戦して
    早く失敗して
    早く学びを得える

    View Slide

  13. アイデアを仮説検証したい
    検証すればもしかしたら価値があるかもしれないアイデアは運用
    当初からいくつもあった。
    不確実性の塊からユーザーにとって
    真に価値があるもの探索するための仮説検証をして
    早い段階で挑戦・失敗をしたかった。

    View Slide

  14. アイデアを仮説検証したい
    「やるべきことは、与えられた時間と資金よりも多い」
                    by アジャイルサムライ
    やるべきことがまだまだある中で、
    不確実性の高い実験的な施策への挑戦はリスク
    が高く敬遠されてしまっていた。

    View Slide

  15. 不確実性を下げていく必要があった
    - 目的不確実性
    - なぜやるのか、誰のためにやるのか
    - Why What
    - 方法不確実性
    - どうやってやるのか
    - How

    View Slide

  16. 不確実性が高いままやるとどうなるのか
    - 目的不確実性
    - なぜかある、誰のためでもないものが生まれる
    - 実装へのしわ寄せで結果、技術的・ビジネス的な負債を
    生み出す
    - 「思ったのとちがう」、「作ったけど使われない」
    - 方法不確実性
    - やり方が決まっていないので先が読めない
    - 「やってみいことには」、「どう作るの?」

    View Slide

  17. 本番で試すことができるのが
    フィーチャートグルの強み
    フィーチャートグルを使うことで、本番環境で、一部のユーザーだ
    けに機能を提供するということができるようになった。
    実際のユーザーのフィードバックと取れたデータを元にすることで
    価値の探索と不確実性を下げることを同時にできた。

    View Slide

  18. フィーチャートグルの
    実装・運用

    View Slide

  19. キーワードは、安全に実験
    キーワードは、安全に実験

    View Slide

  20. アーキテクチャのコンセプト
    - 特定のユーザーのみ絞ってに機能を提供する
    - 特定ユーザーに絞ることによる検証範囲の操作
    - プロダクト本体への依存度を低くする
    - 本体のコードベースへの依存度を下げ、本流の開発への影響を
    押さえ別々で開発できるようにする
    - 検証なので使い捨ての機能として実装
    - 必要最低限の実装
    - 不要ならそのまま消せるように
    - 採用なら実装についてを再度検討し本格的に実装する

    View Slide

  21. 設計方針
    検証のために必要最低限の実装
    施策ごとにフィーチャートグルの設定できる
    フィーチャートグルの実装はフロントエンド・バックエンドそれぞれに存在
    するが、中心はフロントエンド
    フロントエンドは主にコンポーネントの出し分け
    バックエンドは専用のAPIを提供するそれぞれ役割が異なる
    フィチャートグルの制御は Launchdarklyというサビースを使っている

    View Slide

  22. フロントエンドの実装方針
    - 仮説検証用のディレクトリを作る(featuresディレクトリ)
    - 施策単位でのディレクトリ分け
    - 本体のコードとリポジトリは共通
    - フィーチャートグルの分岐(トグルポイント)をHOC(※)に集約す

    - 基本的にディレクトリごと消しされるように、他からの依存度を
    低くする
    ※Higher-Order-Component

    View Slide

  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のディレクトリに検
    証機能を入れて他と明確に
    区別する
    他と依存させない

    View Slide

  24. フロントエンドの実装: HOC
    HOCは React の設計パターン1つで、「コンポーネントを返す関
    数」
    HOCのなかでフィーチャートグルのON/OFFだけを判定して、一部
    のユーザーにだけ検証機能のコンポーネントを返す
    HOCを間に挟んで依存の方向を制御
    親コンポーネント
    子コンポーネント
    (検証機能用)
    HOC
    依存
    依存

    View Slide

  25. 試作用のディレクトリ
    フロントエンドの実装: HOC
    HOC(※)によるコンポーネントの出し分け
    ※Higher-Order-Component
    親コンポーネント
    子コンポーネント
    (検証機能用)
    HOC
    フィーチャートグル
    空コンポーネント
    ON
    OFF

    View Slide

  26. バックエンドの実装方針
    - まず必要なら外部リソースを検討
    - Lambda, Croud Run, GAS
    - モジュラーモノリスを意識して施策ごとにモジュール化
    - リポジトリもDBは共通
    - 施策用の専用HTTPのエンドポイントのみを提供する
    - 本流のコードへの依存度は低く保つ
    - フィーチャートグルの分岐(トグルポイント)をLaravel の
    Middlewareに集約する

    View Slide

  27. バックエンドの実装: ディレクトリ構成
    /modules/features
    └── utils
    │ ├── composer.json
    │ └── src
    └── features1
    ├── composer.json
    └── src
    │ ├── ServiceProvider.php
    │ ├── Http
    │ │ ├── Controllers
    │ │ └── Middleware
    │ └── routes.php
    └── tests
    └── Feature
    └── Http
    施策ごとにモジュールとして
    切り出す
    他とは依存させない
    そのまま消しても影響がな

    View Slide

  28. 試作用のモジュール
    バックエンドの実装: Middleware
    フロントエンド
    検証機能
    検証機能用の処理
    Middleware
    フィーチャートグル
    ON
    OFF
    HTTP request
    HTTP status 40x

    View Slide

  29. 運用例
    要件・仕様・開発
    本番(社内)でテスト
    本番(一部のユーザー)
    でテスト
    プロダクト全体へ展開
    価値検証へ
    最小で実装
    価値がないと判断できたら、再検討や
    廃止の方向にシフト
    検証範囲
    の拡大
    本実装へ向け再度検討
    施策機能はフィーチャート
    グルごと削除

    View Slide

  30. まとめ

    View Slide

  31. メリット
    - 仮説検証が早く安全にできる
    - 「試してみよう」が選択肢としてカジュアルにとれるのはでかい
    - 特定のユーザーに絞ることで施策の変更やクローズの労力が減っ

    - 本流の開発とは別で開発を進めることができるようになった
    - 意思決定がデータドリブンでできる
    - 不確実性が下がることで本格的に実装するときの確実性が上がる

    View Slide

  32. デメリット
    - 依存性の低さと引き換えにできることが限られる
    - 規模が大きくなってくるときつい
    - 今後拡張予定
    - UI的な変更へは弱い
    - 仮説検証のため機能の動作担保も必要
    - 依存度を低くするために、コード量が増えることや、重複するような
    処理が生まれてしまう

    View Slide

  33. まとめ
    - Experiment Toggles(実験トグル) の概念は、 DevOps観点
    的な見方とは異なった、プロダクト開発にフォーカスしたフィー
    チャートグル。
    - フィーチャートグルを導入するときに重要なこと
    - 機能の開発プロセス
    - フィーチャートグルの技術基盤
    - トグルのライフサイクル管理

    View Slide

  34. ご清聴ありがとうございました!
    エンジニア募集してます!
    参考書籍
    「早く挑戦して」、「早く失敗して」、「早く学ぶ」
    そんな願いを込めて作りました。
    ご清聴ありがとうございました!
    エンジニア募集してます!

    View Slide