はじめに

askenでは「AI Nativeな開発組織へ進化する」をビジョンに掲げ、その全体像を以下の記事でお伝えしました。本記事は、その取り組みを現場の視点から紹介する関連記事です。

AI Nativeな開発組織へ ― askenエンジニアが挑む2つの変革 - asken テックブログ

こんにちは。Androidエンジニアの佐藤です。

皆さんのチームでは、ABテストは頻繁に行われていますか？
askenでは週に1回はABテストを実施しています。

ABテストのお片付けって、後回しになりがちではないですか？

askenも同じくでした。

今回は、ABテストのロールアウト作業を自動化して、効率的にお片付けできる仕組みを構築した話をさせていただきます。

議題

askenでは、どの形でリリースをするとユーザーの体験が向上するのかを細かく分析しています。

仕組みとしては、FirebaseのRemoteConfigを使用してABテストを行っています。

ABテストはとても重要な検証です。
一方で、ABテストの結果として、新しい提案機能を採用する（proposal）か、既存機能を維持する（current）かが決まったのち、RemoteConfigの設定変更は行うものの、コードに埋め込んだ分岐ロジックの削除（ロールアウト作業）にはなかなか着手できていませんでした。

新たな施策への対応など、優先順位を考えた時に、ABテストのロールアウト作業は後回しになりがちでした。

ロールアウト対応を後回しにすることで、可読性やメンテナンス性の低下を招きます。

実際に別の機能開発に着手した際、コード内に proposal / current 両方のロジックが残っていたため、「いまどちらのコードを改修すべきか」の仕様調査から始めることがありました。RemoteConfigの設定値を掘り返したり、当時の有識者へ確認を行ったりと、本来なら不要な確認作業に余計な工数を奪われてしまいました。

今の時代だからこそAIの力を借りて

解決策として、GitHub Actionsのワークフローをベースとして、ロールアウト作業を自動化できないかと考えました。

検討した結果、以下の構成としました。
名付けてロールアウトくん！ロールアウト作業をAI連携して自動で進めてくれる仕組みになります。

大まかな流れは以下になります。

機能開発のPullRequestがdevelopブランチへマージされたタイミングでロールアウトくんが発動
1. GitHub Actionsのワークフローで動作しています
Devinに渡す前に、ABテストコード判定（Python）で、ロールアウト要否の一次判定を行う
1. 全ての判定をDevinで実施すると、トークン消費が増大するので、そのための回避策
ABテストコードが含まれている場合、PRの説明とコードをインプットにDevinにロールアウト時に必要な情報をまとめたIssueを作成させる
ABテスト完了後、人がIssueに結果（proposal or current）を記載し、ABテスト完了ラベルを付与する
1. ラベル付与のタイミングで、ロールアウトのためのワークフローが発動
Issueの内容をインプットとしてDevinにロールアウトの実装を進めてもらいPR作成までを行う
人がPRのレビューを行い、問題なければマージする
1. 問題がある場合は、Devinに指摘をして、修正を行う

設計のポイントは、スクリプト・AI・人間の役割分担です。
これまではPythonなどで簡単なスクリプトを実装して、ごく一部の作業を自動化するレベルに留まっていましたが、AIと連携させることで自動化できる範囲が大きく広がりました。
一方で、全てをAIに任せてしまうと、トークンの消費量が増えるうえ、毎回同じ品質で動く保証もありません。そこで、次のような役割分担にしています。

単純に判断できる部分（「RemoteConfigの修正が入っているか否か」の検知）は、これまで通りスクリプトで実装し、テストで品質を担保する
AIには、スクリプトで絞り込んだ対象だけを渡し、ロールアウト情報を整理したIssue作成やロールアウト実装といったまとまった作業を任せる
どの結果を採用するかという意思決定だけは、Issueへ記載という形で人間に残す

ロールアウト時のコードをAIに生成させるためにはIssueの内容を充実させる必要があるのもポイントです。
現在では、以下の内容をIssueに記載するようにしています。（随時改良中…）

key名
定義ファイル名
元のPRリンク
- 元のPRにABテストの内容を詳細に記載する
決定内容
- proposal or current

まだ完全に自動とまではいきませんが、ロールアウトプロセスを半自動で進めることができました。
ロールアウトの整理は、AI前提で実装したとしても30分ほどはかかっていたと思いますので、そこが軽減されています。

また、以前はロールアウト作業が「手が空いた時に対応する」扱いになりがちで、意思決定から着手まで数週間〜数ヶ月かかることも珍しくありませんでした。現在はABテスト完了ラベルを付与するだけでロールアウト実装が自動で始まるため、意思決定から着手までが即日に短縮されました。

導入してみて

5月にロールアウトくんを導入しました。

導入から約3ヶ月になりますが、ロールアウトくんの作成PRはiOS / Android合わせて21件になります。
導入前の3ヶ月間、ロールアウト対応は人手によるもので7件（月2〜3件ペース）だったので、ロールアウトくんはその約3倍、月6〜7件のペースで稼働してくれています。

その結果、ロールアウト対応が放置されずに進むようになったことで、コード内に proposal / current 両方のロジックが残り続けることが減り、課題に挙げたような「いまどちらのコードを改修すべきか」を調査する場面はほぼなくなりました。

今後の発展

まだ人が介在しているところがあるので、できる限りAIに自動で動いてもらうように進めたいと考えています。

例えば、

ABテスト結果をSlackからの連携でIssueに反映して、自動でロールアウト実装を発動する
- 弊社はSlackでコミュニケーションをすることが多いです
ロールアウト後の動作確認を自動でテストできるようにする
- MaestroなどのE2Eテスト自動化ツールを利用して実現したいと考えています

などです。

まだまだ改善の余地は多分にあると感じています。

まとめ

今回は、askenで構築したロールアウトの自動化の仕組みに関して紹介しました。

コードに不要なロジックが残り続けると、可読性の低下や不具合の温床につながるリスクがあります。今回の仕組みは、そのリスクを継続的に減らすことを目的として取り組みました。

結果として、ロールアウトのペースは人手で対応していた頃の約3倍になり、意思決定から着手までも即日になりました。

スクリプト・AI・人間で役割を分担したことで、品質とトークンコストを両立しながら自動化の範囲を広げられたと感じています。

是非こちらの記事を参考にしていただき、みなさまのプロセス改善にお役立ていただければ幸いです。

askenでは新しい仲間を募集しています！

askenでは、様々な技術を活用して開発効率を上げていくチャレンジを行っていきたい！という方を募集しています。

カジュアル面談などを通して、ぜひお話しませんか？

https://hrmos.co/pages/asken/jobs/00_00

asken techのXアカウントで、askenのテックブログやイベント情報など、エンジニアリングに関する最新情報を発信していますので、ぜひフォローをお願いします！

Follow @asken_dev