読者の皆さんには、手間暇かけて実装し、たくさんのケースでテストを実行し、やっとの思いでリリースした機能が顧客に受け入れられなかった経験はありませんか？ 開発チーム内で想定していた通りの機能を作ってリリースしたとしても、実際はユーザーに利用してもらえない事態になったとしたら、リリースした価値はないかもしれません。
もちろん、プロダクトがどのように利用されるかを、リリース前から全て想定できるわけではありません。そのため、リリース後にも継続的に確認することが大切です。 本記事では、Dan Ashby（@DanAshby04）が2016年に提唱した継続的テストモデル（Continuous Testing）の考え方を用いつつ、リリース後に行うシフトライトなテスト活動について解説していきます。
- 継続的テストモデルとシフトライトの活動について
- 小売りチェーン向けECシステムの店舗向けアプリで実践
- 事例1. 店舗スタッフによるオペレーションを観察する
- 事例2. フィーチャーフラグによる分割リリースの実現
- シフトライトなテスト活動を実施するために大切なこと
- 合わせて読みたい関連記事
継続的テストモデルとシフトライトの活動について
DevOpsの世界でテストがどのような位置づけにあるかについて、ロンドン在住でQA専門家であるDan Ashbyは「Continuous Testing in DevOps…」という記事で次のような図を使って説明しました。
この図の詳細や継続的テストモデルについては、以前Agile Journeyに執筆した記事で解説しています。
▶️ コードを書き始める前からテストをずっと考える ─ 継続的テストモデルとシフトレフトなテスト活動をアジャイルにどう取り入れるか
この記事で説明したように、継続的テストモデルのポイントはテストを1つのフェーズではなく、常に行うことができる活動（アクティビティ）として捉えていることです。そのため継続的テストモデルのフェーズにはテストが存在しておらず、いたるところに矢印でテストの実行を指し示しています。
継続的テストモデルの図では、MERGEやBUILDを基準に考えて、より左側（前の段階）であるPLAN・BRANCH・CODEの部分でテストすることを「シフトレフトなテスト活動」と呼びます。一方、それより右側となるRELEASE以降の部分でテストすることを「シフトライトなテスト活動」と呼ぶことがあります。
本記事では、日本であまり馴染みがないであろう「シフトライトなテスト活動」について、具体的な事例を交えながら紹介していきます。
小売りチェーン向けECシステムの店舗向けアプリで実践
具体的な事例を説明する前提として、シフトライトなテスト活動を行ったプロダクトを紹介しておきます。私が所属する10Xでは「Stailer（ステイラー）」という小売りチェーン向けECプラットフォームを開発しています。
Stailerは、スーパーマーケット・ドラッグストアなどの小売事業者がオンライン事業を立ち上げて成長させることに特化したプラットフォームとして、一般のお客様・小売事業者・配送業者の三者に必要な機能を提供しています。今回の事例では、そのうち店舗スタッフ向けのアプリを対象として実施しました。
ある機能のリリースで実施した2つのシフトライトなテスト活動
ここで改めてシフトライトなテスト活動について説明すると、開発してリリースまでこぎ着けた機能に対して、リリース後に何らかの方法でテストする活動を指します。 今回は「ピッキングおよびパッキングに関するリリース」に対して実際に行ったシフトライトなテスト活動を2つ紹介します。
- リリース後に店舗スタッフがアプリを利用している様子を観察する
- リリース時におけるフィーチャーフラグの活用
事例1. 店舗スタッフによるオペレーションを観察する
店舗スタッフ向けのアプリが目指すこととして、オペレーションを確実に行うことができる状態を保ちつつ、それをいかに効率化するかを考えています。より最適なオペレーションを実現するには、プロダクトがどうあるべきなのかを認識することが重要になります。
そこで10Xでは、現場リサーチという取り組みを行っています。具体的には、いわゆるフィールド調査やユーザーインタビューをミックスした形式となります。今回は、店舗スタッフがピッキングやパッキングを行っている様子をすぐそばから観察しました。
現場リサーチの際には、あくまで店舗スタッフの普段通りのオペレーションを観察したいので、気になった点をメモしたり録音・録画したりはしますが、使い方を店舗スタッフに教えることはしません。
この取り組みにより、次の2点が見えてきました。
- 自分たちが開発した機能がどのように使われているか
- アプリの機能にないので運用でカバーされていること
店舗向けアプリの「ピッキング」と「パッキング」はどういう作業か
取り組みで見えてきたことの前に、今回の現場リサーチの対象とした「ピッキングおよびパッキング」について説明します。ネットスーパーにおける一連のサービスは、次の図に示す流れになっています。
まず、お客様が商品を注文します。 次に、店舗スタッフが売り場に行き、注文が入った商品を集めます。これをピッキングと呼びます。ピッキング時にはアプリ「Stailer」を用います。カメラを商品に向けて、バーコードを読み取ると、注文を受けた商品であることを確認できます。
例えば、同じ配達時間帯にお客様AがX牛乳を2つ、お客様BがX牛乳を3つ注文した場合、店舗スタッフはX牛乳を合計5つピッキングします。パートナーの多くは実店舗を持っているため、実際には買い物に来ているお客様の隣で商品をピッキングしています。ピッキングした商品はバックヤードに運ばれます。
なお、注文と異なる商品をピッキングした場合にも、すぐに分かる仕組みになっています。
その後、バックヤードに運ばれた商品を注文したお客様ごとに梱包します。これをパッキングと呼びます。 例えば、先ほどピッキングしたX牛乳5つであれば、お客様Aの袋に2つ、お客様Bの袋に3つと分けて梱包します。 ここでもアプリ「Stailer」でバーコードを読み取って確認します。
最後に、パッキングした商品を配送業者がお客様の家まで配達します。
以降では、ここまで説明した店舗スタッフによるピッキングおよびパッキングの業務を観察して、見えてきたことを説明します。
観察1: 自分たちが開発した機能がどのように使われているか
アプリ利用者（「Stailer」の場合は店舗スタッフ）の真横で観察していると、機能がどのように使われているかを実感することができます。
アプリのある機能が「便利」あるいは「不便」だということが、アプリ利用者には「認識できている」あるいは「暗黙的に感じている」という2軸を考えてみます。
| 便利 | 不便 | |
|---|---|---|
| 認識できている | A | B |
| 暗黙的に感じている | C | D |
これは次にようにまとめることができます。
- A＝便利だと認識できている
- B＝不便だと認識できている
- C＝便利だと暗黙的に感じている
- D＝不便だと暗黙的に感じている
アプリ利用者から来る問い合わせの多くはB（不便だと認識できている）と、少しのA（便利だと認識できている）の声です。そのため問い合わせだけ見ると「本当にアプリ利用者に受け入れられているのだろうか……？」と不安になるかもしれません。
しかし、現場リサーチにより実際の業務を観察してみると、C（便利だと暗黙的に感じている）の状況が多いことに気付きました。
また同時に、D（不便だと暗黙的に感じている）ことにも気付けるでしょう。例えば、ある機能を何度も試そうとしている場面に遭遇するかもしれません。それにより「もっと押しやすいUIにした方がいいな」とか「操作を指示する文章をもっと分かりやすくした方いいな」といった気付きが得られます。
観察2: アプリの機能にないので運用でカバーされていること
プロダクトに流れてくる情報は、プロダクトへのin/outのデータのみです。それだけでは断片的な情報に過ぎず、アプリを利用実態への理解が浅いことがあります。特に、利用者が運用でカバーしていることに気付けていない可能性は高いでしょう。
現場リサーチとして実際の店舗に行ったときに遭遇した、具体的な事例を紹介します。
バックヤードに同じ段ボールが2箱ありました。中身は、ともに2ℓのお茶のペットボトルが6本入った1ケースでした。 しかし、段ボール箱に貼られていたラベル（配達先やパッキングに関わる情報が書いてあるもの）は、次のようにそれぞれ違っていました。
鈴木さん宛の段ボール箱には「大型」と印字されていました。これは「コンテナに入らないような大きな商品」の区分であることを意味します。 一方、山田さん宛の段ボール箱も同じ大型ですが、冷やす必要がないことを意味する「常温」とだけ印字されていました。これはコンテナに入る大きさの商品の区分でもあります。
なぜ、同じ2ℓペットボトルのお茶1ケースにもかかわらず、鈴木さん宛の段ボール箱と山田さん宛の段ボール箱に出力されたラベルの商品区分がそれぞれ違っていたのでしょうか？
正解は、鈴木さんがお茶1ケースを注文し、山田さんがお茶6本を注文したからです。山田さんの注文は、お茶6本をバラバラにパッキングすればコンテナに入る「常温」の商品ですが、実際は6本で1ケースになるため配達のしやすさなどを考慮して、現場の判断で段ボールを開けずケースのまま運ぶ運用にしていたのです。
こういった工夫には、プロダクト（Stailerアプリ）のin/outのデータを見ているだけでは気付けないでしょう。
観測で見えてきたことをどう開発に活かしていくか
現場リサーチの見えてきたことは、もちろん全てをアプリに取り込んで開発を進めるわけではありません。今回の事例でも、ケースと中身の対応をアプリ上で頑張って解決することまではしませんでした。
しかし、こういった運用上のさまざまな工夫を知っていくことで、今は工夫して何とか解決しているものの「新しい機能として開発すれば煩わしい作業を行わずにすんで、もっと効率的に業務を行えるのではないか？」という事象に遭遇するかもしれません。
本記事の冒頭に示した継続的テストモデルの図を思い出してください。継続的テストモデルの図は、ループになっています。つまり運用時点のテストを行って終わりではなく、次の開発につなげるということを意味しているのです。
このように現場リサーチを通じて見つけた気付きはアイデアの源泉となり、次の開発に活かすことができます。
事例2. フィーチャーフラグによる分割リリースの実現
事例1では、リリースして実際に運用した際の気付きを開発にフィードバックする方法を紹介しました。しかし、そのためには既に運用していることが前提となります。
そこで事例2として、フィーチャーフラグ（Feature Flag、もしくはFeature Toggleとも）の事例を紹介します。これにより、実際に本格運用に乗る前にアプリの利用状況を制御できます。
フィーチャーフラグとは何か
フィーチャーフラグとは、チームがコードを変更せずにシステムの動作を変更できる強力な手法です。
フィーチャーフラグにはいくつかの種類があります。Martin Fowlerはブログ記事「Feature Toggles (aka Feature Flags)」で、フィーチャーフラグを次の4種類に分類しています。
- アクセス許可フラグ（Permissioning Toggles）
- 実験フラグ（Experiment Toggles）
- リリースフラグ（Release Toggles）
- 運用フラグ（Ops Toggles）
それぞれ、具体的な事例を交えつつ説明します。
- アクセス許可フラグ（Permissioning Toggles）
- アクセス許可フラグとは、ユーザーの状態によってアクセスの許可を切り分ける際に利用するフラグです。「プレミアムユーザーのみ表示されるメニュー」などは代表的な事例と言えるでしょう。
- 実験フラグ（Experiment Toggles）
- 実験フラグとは、新機能の有効性を確かめるために試験的に機能を導入する際に利用するフラグです。代表的な事例として「A/Bテスト」があります。
- リリースフラグ（Release Toggles）
- リリースフラグとは、大規模なソースコードの変更とならないように制御するために利用するフラグです。シフトライトなテスト活動の事例ではありませんが、フィーチャーフラグの理解において重要な方法ですので、章の最後で説明します。
- 運用フラグ（Ops Toggles）
- リリースすると、全利用者に変化を見せることとなります。運用が劇的に変わる場合は、その変化に対する問い合わせが一時的に多くなってしまう可能性が考えられます。そのような負荷を軽減するために利用されるのが運用フラグです。今回の事例で利用したフィーチャーフラグです。
- リリース初日 → 全体の10％に適用
- リリース2日目 → 全体の30％に適用
- リリース3日目 → 全体の50％に適用
- リリース4日目 → 全体の80％に適用
- リリース5日目 → 全体（100％）に適用
- 第1弾 → 利用者数が少ないパートナー
- 第2弾 → 利用者数が第1弾よりは少し多いパートナー
- 第3弾 → 利用者数が多いパートナーのうち、店舗面積が小さめの店舗
- 第4弾 → 利用者数が多いパートナーのうち、店舗面積が大きめの店舗
- 第5弾 → 利用者数が多いパートナーのうち、運用が特殊な店舗
- 風間 裕也（かざま・ゆうや） @nihonbuson
- 電気通信大学大学院修士課程修了。ワークスアプリケーションズに入社後、学生時代から興味のあった品質やテストに関わるためQAチームへ異動。ビズリーチを経て2023年5月から10Xの品質所属部に所属し、現職。B-Testingを開設し、社内外問わず「どのようにテストを考えればよいか」を日々エンジニアに伝えている。
Blog: ブロッコリーのブログ
このうち「A/Bテスト」とは、改善候補と既存の機能を実際のアプリ利用者に比較して試してもらい、有用な改善かどうかを統計的に判断する方法です。アプリ利用者に対して、統計的にランダムに2グループに振り分け、一方のグループには改善候補の機能を、もう一方のグループには既存の機能を利用してもらいます。その際に、クリック率などの指標を計測し、統計的に有意差があるかどうか確認します。その結果を踏まえて、改善候補の機能を全利用者に向けて適用するか、既存機能のまま進めるかを判断します。
今回は4番目の「運用フラグ」の事例として、カナリアリリースと段階的かつ計画的なリリースを紹介します。
カナリアリリース
カナリアリリースとは、まず利用者の一部にリリースして、状況を見て全体に対象を広げるかどうかを判断する方法です。A/Bテストのように統計的なランダム性を取る必要はありません。
例えば、以下のように計画してリリースする方法が考えられます。
このような計画を実行して、想定以上の不具合報告や不満の問い合わせがリリース初日に届いた場合、2日目以降のリリースを取り止めることができます。これにより、まだ適用していない全体の90％のアプリ利用者には、影響を与えずにすみます。
なお、プラットフォームによっては、このような計画を手軽に設定することができます。例えばAndroidアプリの場合、Google Play Developer Consoleにある段階的な公開（Staged rollout）という機能を用いることで簡単に設定できます。
段階的かつ計画的なリリース
カナリアリリースでは、利用者をひとまとめにして全体の何％に適用するかを制御する方法でした。一方、ここで紹介する「段階的かつ計画的なリリース」では、適用する利用者のグループをより具体的に指定します。
「Stailer」の店舗スタッフ向けアプリでは、前述のように毎日のピッキングやパッキングの業務をサポートしています。そのためリリースによってアプリが劇的に変化してしまうと、全利用者が混乱してしまいます。相当数の問い合わせが届くことになるかもしれません。
そのような事態を防ぐため、適用する利用者を細かく指定して、新しい機能を徐々に利用してもらう戦略を取ることが可能です。 例えば次のように、規模が小さな利用パートナーから順に適用する戦略が考えられるでしょう。
利用者数が多く、店舗面積が大きい店舗ほど、アプリの利用頻度も高くなります。そのため運用上の問題が残っていた場合には、その問題と頻繁に遭遇することになります。 そこで小規模な利用パートナーから適用していくことで、規模の大きな適用段階の前に運用上の問題を既に踏み抜いて、対応しておける可能性が高まります。
このように徐々にリリースすることで、新機能に対する問い合わせに忙殺され、機能改修などの時間が確保できなくなるといったリスクの軽減が期待できます。
付記：リリースフラグの詳細
シフトライトなテスト活動の事例ではありませんが、フィーチャーフラグの理解において重要な「リリースフラグ」の使い方を説明しておきます。
一般的には、数スプリントもかかるような大きな機能を作成する際には、1つのfeatureブランチを切って完成するまでmainブランチにマージさせないという戦略を取ります。しかし、完成までに差分が大きくなり過ぎるため、マージ時にコンフリクトが発生したり、統合テストをする際にバグが見つかったりします。
そこで、完成していなくてもmainブランチにマージしつつ、フィーチャーフラグを用いて、アプリ利用者には見えないように制御します。このようなやり方をダークローンチと言います。
これにより、マージごとのfeatureブランチ・mainブランチ間の差分が少ないため、レビューやテストがしやすくなります。ただし、mainブランチにマージは行われているため、きちんとフィーチャーフラグを設定しないとアプリ利用者に開発途中の画面が見えてしまうため注意が必要です。
シフトライトなテスト活動を実施するために大切なこと
ここまで、リリース時から運用におけるテスト活動、つまりシフトライトなテスト活動について説明してきました。最後に、こういった活動を実施する際に大切なことを1つお伝えします。
それは、不具合はシフトライトなテスト活動を行う前に見つけて修正しておくことです。
実験フラグや運用フラグによって、適用する利用者を制限することは可能です。しかし、制限した上で適用された利用者はあくまでもお客様です。テスターではありません。シフトライトなテスト活動は「機能としては動くが、運用上不便である」といった部分を見つけ出すことが目的です。「不具合をお客様に見つけてもらうこと」を目的にしてはいけません。
不具合は従来のテスト活動であったり、シフトレフトなテスト活動を通じて見つけるようにしましょう。
編集：はてな編集部
