デプロイ頻度と本番への不具合数の状況
Uje氏：私、Ujeから「デリバリー速度向上と品質維持のためにここ1年で取り組んだこと」について発表します。まずは自己紹介をします。2021年6月からビビットガーデンにQAエンジニアとして参画しています。主な業務としては、テストに関わる計画から分析ぐらいまでの部分と、あとはテスト関連の技術の導入や実装部分を主に担当しています。（スライドには）書いていませんが、勉強会もやっています。
さっそくですが、現在の状況みたいなものをいくつかお話したいと思っています。ここ1年の速度みたいなところ。
（スライドを示して）まずは「デプロイ頻度」と呼ばれるものです。現在、1営業、1日1回で、営業日に対して1回のリリースを維持しています。青い棒グラフが回数で、赤い折れ線グラフがPR数です。
特にPRの数に対しては、2021年に比べて1.5倍以上、大きいところでは2倍程度になっているところもあります。なので、今は特にリリースする数が増えてきているという点が挙げられます。要因としては人員の拡大がかなり大きいですが、今回取り組んでいる内容について話そうと思います。
もう1つの現在の状況は「本番への不具合数」です。Web版・iOS版・Android版というかたちで表示していますが、傾向としては、正直にお話してまだ（不具合は）ちょこちょこ出ています。ただ、リリース回数の伸びやプルリクエストの数に比べて、傾向としては微減であるというところで、トータルで増えているわけではありません。比率としては上昇していない。そのため、「極端な品質低下を招いているわけではなさそうだ」と判断しています。こちらについても、どういった取り組みをしているのかをお話できればと思います。
こちらについて、まずは「デリバリー速度上昇の取り組み」として3つ挙げます。1つ目は「方針を定める」、2つ目は「リリースフローに関わる部分の整備」、3つ目は「プロダクトのリリース状況を可視化する」。この3本立てでやっていくこととしては、すごく基本的なことになると思います。あらためて一つひとつお話しします。
デリバリー速度上昇の取り組み：方針を決める
まずは「方針を定める」という部分です。私は2021年6月に入りましたが、それまでは明確なテスト方針みたいなものがあまりありませんでした。そこで、CTOの西尾とも話して、少しずつ体制作りを行っています。明確な方針を示し、無理のないテスト体制にしていくところを心がけています。
よくありがちな体制として、エンジニアが開発、QA部門はテストだけといった分断構造がけっこうあると思いますが、そういったかたちではなく二人三脚型ということで、QAはプロダクトチームの一員として、場合によっては各ユニットにジョインして、「将来的には分断構造にしない」という話はあらかじめしています。
あとはちょっとこれはフワッとしていた部分ですが、昔は「リリースしたい変更が溜まった時点で出す」という方針で、2、3日に一度程度のペースでリリースしていました。これを明確に、営業日に対して1日1回リリースしていくとしたのは、大きく変えたところだと思っています。
ユニット化に伴い、テストの実施範囲が変更になったことでやりやすくなったのも大きな理由だと思っています。以前は誰かが実装して別の人がテストするぐらいの感じだったのが、今は同じユニットの中でテストしているので、それですごくスピードが上がったという側面もあるのかなと考えています。
デリバリー速度上昇の取り組み：リリースフローに関わる部分の整備
リリースフローに関わる部分の整備というところで、以前は、スプレッドシートとGASとGitHubの管理でQAに対応していました。これは手動対応と自動対応が混在していて、けっこう運用負荷が高かったことが挙げられます。運用負荷はどういうところかというと、スプレッドシートの更新を忘れたり、その逆でGitHubの更新を忘れたりなどです。
それ以外にも、次のリリース前に声をかけてマージを止めてもらった。弊社も大きいモノリシックなシステムなので、誰かが変更した内容が取り入れられると、他の人に影響を与えかねません。
それらがズルズルと続くとリリースができなくなるという弱点も抱えている部分があって、それを防ぐためにマージを止めるという行為を、わざわざ朝会で声をかけていたことがありました。これは、エンジニアの手によって「Merge Freeze」というツールで強制的にできなくするような仕組みを使って自動化しました。
ほかに、スプレッドシートの更新が漏れがちになる問題です。先ほどのラベルの手動更新やリリースのマネジメントツールはエンジニアに開発してもらって、テストするべきものをリスト化した上で、ステータスの変更が行えるようになりました。他の画面に行ったりする必要がなくなったという積み重ねもあって、すごく楽になったということがあるのかなと考えています。
デリバリー速度上昇の取り組み：プロダクトのリリース状況を可視化する
3つ目は、「プロダクトのリリース状況を可視化する」というお話です。みなさんに大きな影響を与えたと思っているのは、数字化されることによってモチベーションが変わるというか。きつくなればがんばらなきゃいけなくなるし、よくなれば「もっとがんばろう」となったりとか。これも言い方次第だと思いますが、見える化するように努力してみました。
「Four Keysメトリクス」は、確かGoogleの研究チームが提唱していた説です。そのFour Keysに基づく計測を始めています。（スライドを示して）ここは引用していますが、デプロイの頻度、変更のリードタイム、変更障害率、サービス復元時間によってトータル的にプロダクトのリリースが健全であるかを可視化しています。
例えば、最初のリリース頻度は、デプロイの頻度から値を取ってきてグラフ化しています。可視化することで、特に状況の把握や改善効果、効果を実感みたいなことができるいい結果につながっていった。次のいいサイクル、スパイラルにつながったのかなと考えています。
品質維持のための3つの取り組み：ユニットテストの拡張
続いて、同時にリリース速度が上がったことに対してのテスト的な対応みたいなところはどういうことをやっていたのかという話と、意味の文脈で、品質維持の取り組みをあらためてお話しします。
1つ目はユニットテスト拡張の話、2つ目は新しいテスト技術でE2EやVRTの導入の話、3つ目は手動テストをなくさないという話です。こちらもよく言われることだとは思うので、基本的なことですがあらためて紹介します。
1つ目の「ユニットテストの拡張」は、2021年に「大いにみんなでやっていこうぜ」という機運が生まれたのが事実です。こちらは私が技術ブログで書いた「テストチームの改善うんぬんかんぬん」でも紹介したとおり、2020年の年末から、ようやく「ユニットテストを積極的に書いていきましょう」という会社方針になり、そのあとからちょっとずつ積極的に増えてきました。
それまでは、本当に必要なところしか書いていなかったユニットテストが増えて、6月以降の私のジョインに加え、数々のメンバーがジョインしていく中で、仕様を覚えていくとか、「足りないところのテストを拡張していきましょう」というところで、どんどん動いてもらいました。
特にやっていたこととしては、当たり前ですが、そもそもゼロパーファイルテストが1つもないみたいな。自動テストが1つもないところはリスト化するというところで。みなさんユニットを持っているので、隙間時間に少しずつ名前を入れたり担当を奪ったりしてやってもらうかたちを奨励していたところです。
あとはカバレッジ率の記録です。「Nパーセント上がった・下がった」みたいな話をあらためてつなげてグラフとして出す。それがモチベーションになって、さらに加速を生んだり、危機感を煽ったりすることも可視化を意識して動いていました。
品質維持のための3つの取り組み：新しい技術の導入
続いて、新しい技術の導入というところで、E2E（End to End）と呼ばれるものと、VRT（Vocational Readiness Test）と呼ばれるものの自動テストの技術を導入しています。E2EはEnd-to-Endです。みなさんはご存じかもしれませんが、Seleniumというツールで、Web版をテストしています。スライドには表記していませんが、アプリのiOS版とAndroid版は、それぞれに合ったツールを使って実装しています。
あともう1つ、略してVRTテストと呼ばれる、ビジュアルリグレッションテスト。見た目部分を主に行うテストの実施・導入を進めています。やはりどちらも一定効果を上げることができていて、E2Eであれば、きちんと動かなくなったので調べてみたら何か（が）悪かったとか。VRTであれば、些細に壊れるところ。空白が増えたり、小さくなったりしたところ（を見つけることができています）。
変なズレ方をしたか（を確認すべき）という部分は、やはり見える部分というところで。機械らしい正確性が有効であるという点と、同じテストを書いたら書いただけテストを繰り返してくれる点は、自動テストとして非常に有効であるというところで導入しています。
（スライドに）理由は書いてありますが、このあとに話す手動テストの省エネ化と呼ばれる部分です。機械に任せられることは機械に任せる。人間がやらなきゃいけない部分は人間がやるように切り分けていきたいから。また、リリース化について品質を維持しながらスピードを上げていきたいというニーズに応えた結果、自動テスト導入という運びになっています。
品質維持のための3つの取り組み：手動テストはなくさない
3つ目。こちらも重要な概念だと思いますが、「手動テストはなくさない」。より正確に言うと「なくならないもの」だと思っています。実際に機械で判定できることは機械が言ったことしか判定してくれないとか、人間的感情は現在の技術では当然理解が難しいとか。いろいろあると思うので、機械では難しい分野は、やはり人間がやっていく必要がある。実際に利用した使用感であったり、その時のいわゆる感覚的・感情的な変化です。
例えば、失敗した時はエラー表示が出ているので、そのエラーの内容が適切なのか、わかりやすいのかとか、その内容で修正できるのかとか。あとは、出てきた結果の文言に納得できるのかなども含めた一連の流れです。そういった、お客さまの目に見える部分の変更は実施するよう心がけています。
特に自動で見ていない部分の条件や、複雑すぎて作るのも大変な部分は、ちょっと手間でもわざわざ見てもらう。あとは、実際に使い心地と言われるユーザビリティのような部分や、実際に触ってみることで次の課題を自身で見てもらうという意味でも、手動で触る必要があるのかなと思っています。
現状、弊社にはQAエンジニアが私1人しかいなくて、他には各ユニットに配属されているユニットのエンジニアがテストをします。つまり、QAの私はテストのサポートで、アドバイスをしたり自動テストの構築を手伝ったりという部分、実際の手動テストも含めて、エンジニアがやっています。
これについては最初に西尾とも話をして、「分断化して（QA以外のエンジニアがテストを）やらなくなるとどんどん質が落ちる」みたいな話をしていたので、こういった手動テストも含めて、エンジニアにもやってもらっています。
今後の2つの課題
今後の課題みたいなところの現状をお話しすると、「1日10回リリースするにはどうしたらいいか」というお題目です。これは例えばの話ですが、現行体制はもう根本的に厳しくて、手法や問題がある部分を改善していく必要があります。なぜ1日10回かという話ですが、少しでも早く出したい、少しでも早く結果を得たいという気持ちの表れです。
回数はあまり重要ではありませんが、極端なわかりやすい事例として出しています。今は1日1回、さらに1日はだいたい8時間労働だと思うので、当然1時間に1回じゃ足りない。「それ以上の爆速にはどうする必要があるんだろう」「それに耐えうる手法はなんだろう」というところで、今は考えたり調整したりしています。
あとは、手動テストの観点をどうするか。テストの視点みたいな考え方はだいぶ揮発性が高い。消えやすいということです。失いやすいのは、やはり実感としてあります。
これはどうしてもバグが出がちな点だったりするので、1回目は新しい機能が出る時や、大型のアップデートをする時に新しい機能をすごく見ますが、次の改善でちょっと修正して、修正したピンポイントだけ手動テストをして、他の基本的なテストをしきれていない（現状があります）。
これは自動テストでカバーしていないところも問題だし、手動テストで見ることも足りていない点も問題だったのかなという両側面ではありますが、対策は必要かなと（思います）。よくある、ベースとなるテストケースと呼ばれるような、スプレッドシートで作ったり、テスト管理ツールなどを使って行うケースの準備に関して、今は全体的なものがないのが弊社の弱点なのかなと。あとは、それがテスト者の手元に手軽に届く仕組みがないのも弱点かなと思っています。
先ほどテストをする人間はエンジニアだと話しましたが、「GitHubなどの、いわゆる別のツールを使ってスプレッドシートでチェックしてください」と言うと、どんどん更新が減っていったり忘れたりどこにいったかわからなくなりがちなので、なるべくソース管理ツールと一体化したかたちで届く仕組みを、今は検討して調整しています。
簡単ですが、こちらで私の発表とさせていただきます。お疲れ様でした。
