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