リリース後のテストだからこそ事前の計画が重要
次の話題は、リリース後のテストであるシフトライトについてだ。ブロッコリー氏はシフトライトについて、3つの事例を示した。
- 計画的にログを仕込み、効果を確認する
- 実際のオペレーションの様子を観察する
- ユーザーと協力して、実際にオペレーションが問題なく進行できるか確認する
まずは「計画的にログを仕込み、効果を確認する」事例だ。話は再びピッキング・パッキング時のオペレーションへ戻る。先ほど確認したとおり、開発時点では「注文締め切り時間の前にパッキング画面を15秒放置するとエラーが出る」修正を盛り込む計画になっていた。しかし、これがあまりにも頻発するようであれば、パッキング業務の妨げになってしまう。
この点を測定・修正するためにブロッコリー氏が取ったのが、アプリ上の振る舞いは変えないままにログを仕込む方法だ。具体的には、「締め切り前の時間帯にhogehogeメソッドを読み込んだ場合」という部分にログを埋め込んでリリースし、どのくらいの頻度でエラー画面が表示される見込みかを測定。その結果、予想していたほどは頻発しないとわかったため、ログを埋め込んだ箇所に修正を行ったという。
まさに「リリースした後のログ状況を見て確認する」というシフトライトの施策であり、ユーザーの動きを確認しながら修正を加えるお手本のような動きだが、ここでブロッコリー氏は注意を促す。「いくらシフトライトのテストだからといって、闇雲にログを押し込み、細かいことはリリース後に考えればいいやという姿勢は危険だ。ログはあくまでも修正案の指標であり、計画的に活用しなければならない」。
修正案が効果的かどうかを確かめるアプローチは他にもある。たとえば、「ある特定の店舗だけ適応する」ような場合、Feature Flag（Toggle）が有効だ。また、パッチなどを適用する際には、初日は全体の10%に適用して問題が起きたらロールバックし、起きなければ翌日は30%に適用するといった段階的リリースが望ましい。
現行版と改善版のどちらが優れているかを統計的に調べるにはA/Bテストが適している。ただしブロッコリー氏によれば、「A/Bテストと他のテストを同時に行うと、正確な結果が得られないため注意が必要だ」といい、場面に応じて適切な手段を選ぶことが求められるだろう。
現場リサーチがもたらす「気づき」がプロダクトの質を高める
2つ目の事例は、「実際のオペレーションの要素を観察する」ことだ。これはオペレーションが効率的かつ確実に行えるかを確認するための施策で、プロダクトが何を実現し、どうあるべきかを認識するために欠かせない位置付けだ。
10Xではフィールド調査とユーザーインタビューをミックスした「現場リサーチ」という形式をとっており、それぞれのパートナーが実際にどうプロダクトを使っているかを現場に赴いてリサーチを行っている。これは店舗スタッフがピッキングやパッキングをする様子をすぐそばから観察し、気になった点をメモして、録画や録音も行うという取り組みだ。
現場リサーチを行うことで、運用でカバーしている点から店舗特有の課題点、自分たちが作った機能がどのように使われているかが手に取るようにわかるという。ブロッコリー氏は具体的な事例として、「2Lペットボトルの6本入りの段ボール」を挙げた。
全く同じお茶の6本入りの段ボールが2つバックヤードに置いてあり、片方には配達コンテナに入らない「大型」のラベル、もう片方にはコンテナに入る「常温」のラベルが貼られている。同じ商品であるにもかかわらず、なぜこのような差が生じたのだろうか。
答えは、「あるユーザーはお茶6本を『1ケース』単位で注文していた。もう1人のユーザーは、同じお茶を『バラバラに6本』注文していた。けれどもバラしてしまうと配達しづらいので、段ボールのまま輸送していた」。注文形式は違うものの、配達の利便性から同じ形に行き着いていたというのだ。
ブロッコリー氏は「こうした運用上の工夫は、データだけでは絶対に分からない。だからこそ、実際に行って現場を知ることが大事だ」と、現場リサーチの意義を強調する。こうして得られた個別の課題から、店舗や企業を問わず共通する課題を見つけ出し、解決策や次の開発プランに活かすことが重要なのだ。
現場リサーチには、「開発チームがアウトカムを意識できるようになる」という副産物があるという。クライアントからは「何に困っているか」という意見や問い合わせが寄せられることはあれど、「何が便利だったか」というフィードバックはなかなか得られない。実際にプロダクトを使う姿を目の当たりにすることで、「この機能はきちんと使われていそうだ」「問い合わせは来ないものの不便そうだ」という肌感覚を得られるのは大きなメリットだ。
開発者としても、作った機能が使われていなければ「ちゃんと価値提供できていない」と気づくことができるうえ、「どうすればリリースまでもっていけるか」という視座でQAとディスカッションできるのだ。
