不確実性を抱えた状況でのリリースの難しさ — tebiki Tech Blog
はじめに
どれだけテストをしても100％の信頼性は保証できません。であればリリースする前に担保すべき品質って何なんでしょうか。そもそも担保することが難しい場合、リリースをして良いのでしょうか。リリース可否の判断にはなかなか難しいものがあります。
今回私も、入社してひと月も経たぬうちにそんな課題に直面し、いろいろと回り道をしながら学びを得たので、今回はその内容についてお話したいと思います。
最初の業務
Tebiki株式会社の高橋です。2024年9月にQAエンジニアとして入社しました。入社オンボーディングも終わりQAとして本格的に活動し始めようとした矢先、動画変換基盤の安全なリリースという課題に直面しました。
本件については、私の入社前からリリースを試みていましたが難航しており、その業務が私に引き継がれました。
動画変換基盤とは大雑把にいうと、ユーザーがアップロードした動画をWeb上でストリーミング再生できるような形式に変換するものです。（ちなみに当時の私は、動画変換基盤？？？ストリーミング再生？？？という感じで何も分かっていなかった）
これまでの経緯
動画変換基盤の切り替えは、動画によって現場教育を促進させようという弊社のサービスにとって根幹に関わる変更だったため、カナリアリリースという手法でのリリースを既に何度か試みていましたが、その都度問題が発覚して旧基盤に切り戻していたようです。
カナリアリリースとは、いきなり全ユーザーに対してリリースせず、段階的にリリース対象を広げていく手法です。炭坑のなかに有害なガスがあるかどうかをカナリアを使って調べていたことに由来しているそうです。
不具合が存在する可能性が高い状況や、不具合が発生してしまった場合の影響が高い状況、つまりリスクの高い状況ではリリース対象を限定し、
→ 限定したリリース対象の中で実績を積む
→ リスクが低下
→ リリース対象を拡大
→ さらに実績を積む
と段階を踏んでリリースすることで、影響範囲を最小化することがすることができます。
問題点
今までのリリース前のテストに問題があったかというとそんなことはなく、私自身が思いつくような一般的なテストケースはすべて網羅されていました。
ではなぜ不具合が起こってしまったのか。理由のひとつにアップロードされうる動画のバリエーションが膨大すぎて事前にすべてのパターンを網羅するのが難しかったことが挙げられます。
動画の長さ、容量、ファイル形式、撮影した媒体とそのバージョン、アップロードする端末とそのバージョン、等のメジャーなパターンに加え、例えば、同じMOVファイルであってもサウンド収録の設定をとある値に設定したiPhone16で撮影した動画のみ動画変換に失敗する、といった非常にニッチで、事前に想定することが難しいケースも存在しました。
つまり我々は、ユーザーがアップロードする動画の網羅が難しく、動画変換に問題がないかどうかは実際に運用してみないと分からない部分がある、という不確実性を抱えた状況でのリリースを行わなければなりませんでした。
そのような状況だったので、当然リリース後に不具合が発生することは予想されますし、事実そうでした。
そして不具合が発生する度に慌てて切り戻しを行い修正する、ということを繰り返しており、これによりいつまでたってもカナリアリリースが完了しないことが問題でした。何度リリースしても、同じことの繰り返しになる可能性は大いにあります。
そこで私達は次こそ全体リリースに進むべく、次の2点を改めて考え直すことにしました。
- カナリアリリースで最終的に達成すべき品質基準は何か
- どのようなステップを踏んでその品質基準までもっていくか
基準とスケジュール
カナリアリリースではどこまでの品質を担保すればいいのでしょうか。
エラーは一切認めない？1件までなら許容？じゃあ2件は？3件は？そもそも母数はどれくらい？…
リスク感覚というものは個人の主観に強く依りますし、定性的なものなので根拠に乏しく、チームで協議してもなかなか一つの案にまとまりません。
そこで私が提案した案は、「現行同等以下のエラー率であること」というものでした。
これは私の前職（日用品の容器開発をしていました）で、リニューアル時などの目標値としてよく使われていた指標で、
現行品の不良率で問題なくユーザー利用されている実績がある→新規品の不良率がそれと同等or以下であれば問題ない
という理屈です。多少のエラーは発生するかもしれないが、品質として劣化はしていません。
Datadogから過去のエラー数を調べることができたので、過去実績から1ヶ月あたりのエラー数からエラー発生率を算出し、それより悪化していなければ品質として合格、という基準で進めることをチーム内で合意しました。
続いてはリリースのスケジュールです。
QAとして、なるべく小刻みにリリースしたいと考えていました。Tebikiの場合、最小のリリース単位は企業ごとです。1つの企業内で動画をアップロードする人は限定されますし、基本的にその人は同じ端末を使って動画を撮るはずです。つまり動画の種類とリリースした企業数にはある程度相関があると考えられます。
不具合が発生した場合の影響を最小化、という観点で考えると、なるべく少ない数の企業にリリースし、検証になるべく長い期間をかけてから次の企業にリリースにするのが理想ですが、これでは時間がかかりすぎます。
そして残念ながら本件にはあまり時間が残されていませんでした。当初の予定より大幅に時間がかかっているため他の機能開発が遅延しており、なるはやで決着をつけたいという状況で、さらに1～2ヶ月かかるようであればリリースを断念する可能性もありました。
結論として、エラー発生率を測れる動画数に達するまで毎日15企業ずつ、リリース対象を増やしていく方式を採用しました。リリース対象を増やすまでの検証期間が1日しかないことに少し不安はありましたが、1日でもそれなりの数の動画がアップロードされていることや、2週間程度で目標に達するスピードの速さを加味し、今の状況に適していると判断しました。
それでも不具合が発生したら
「現行同等以下」という基準は設けたものの、不具合はどんな内容でも同じ1件とカウントするのか、不具合発生後カナリアリリースは続行するのか、など曖昧な部分が多く、リリース作業の完遂に対してまだまだ不安が残っていました。
そこで不具合発生時のフローを整備することにしました。（後で振り返るとこれが一番大事だったかも）
どんな状況で不具合が発生しても、
- カナリアリリース続行
- カナリアリリース中断して修正後に再開
- リリース自体を中止
といういずれかのアクションが取れるようにフローを組み、各分岐点でどちらに分かれるかの判断基準を定めました。
ここまで準備し、遂にカナリアリリースが始まります。
どうなるんだ！と内心かなりドキドキしていたのですが、動画アップロードの数は着々と増えていき、特に大きな波もなくカナリアリリースは無事完了して全体リリースへ。念の為設けいていたひと月程度の様子見の期間もあれよあれよと過ぎていき、すべてのリリース作業がつつがなく終わりました。
振り返り
結果的にうまくいったように見える今回のカナリアリリースですが、このやり方が適切だったのかは正直分からないです。本当はもっと慎重にやるべきだったのかもしれないし、カナリアリリースせずに全体リリースし、バグが発生したら切り戻さずに都度最優先で修正というのをひたすら繰り返す方法でもよかったのかもしれません。
1つ学びだったのは、事前に基準やフローを整備しておくことで次のアクションをすぐに取れるようになる、ということです。
基準というものに正解はありません。その人の感覚や立場によって線引は様々です。だからこそ、共通の基準がない状態で問題が発生すると、その判断で迷い、揉めるのだと思います。そうしている間にどんどん時間が過ぎていく。
今回、リリース遂行のために必要となるであろうすべての判断の基準を先んじて設定し、チーム内で共有できていたことはよかったと思います。
開発チーム及びQAは、「不具合を発生させない」ことを目的にリリース前にテストを行います。これは当たり前です。しかし、今回のような不確実性を抱えてのリリースでは、「発生した後どうするか」についてもっとフォーカスすべきでした。ここの切り替えをもっと早くできていれば、チーム内でひたすら頭を悩ませていた時間を短縮できたのかもしれない、と反省しています。
今後
TebikiのQAは開発チームが主体的に品質向上に向けて行動できるような支援を行う、イネイブリングQAを目指しています。今回は業務の流れで基準づくりをすることになりましたが、テストプロセスや様々な基準の整備といった活動を今後も積極的に進めて行きます。
私たちは仲間を募集しています！
Tebiki社は、エンジニアを募集しています！
興味がある方は、ぜひカジュアルにお話ししましょう！
▼採用HP
https://tebiki.co.jp/recruit.html
▼募集中のエンジニア求人一覧
https://herp.careers/v1/tebiki/requisition-groups/2514f131-4e3b-4f50-9539-27aa01a6639f
