フィーチャートグルを 使って素早く価値を検証する 早く安全に失敗し学ぶために 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観点 的な見方とは異なった、プロダクト開発にフォーカスしたフィー チャートグル。 - フィーチャートグルを導入するときに重要なこと - 機能の開発プロセス - フィーチャートグルの技術基盤 - トグルのライフサイクル管理

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