2024.12.03
セキュリティ製品を入れても検出されず…被害事例から見る最新の攻撃トレンド 不正侵入・悪用を回避するポイント
デリバリー速度向上と品質維持のためにここ1年で取り組んだこと (全1記事)
リンクをコピー
記事をブックマーク
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に基づく計測を始めています。(スライドを示して)ここは引用していますが、デプロイの頻度、変更のリードタイム、変更障害率、サービス復元時間によってトータル的にプロダクトのリリースが健全であるかを可視化しています。
例えば、最初のリリース頻度は、デプロイの頻度から値を取ってきてグラフ化しています。可視化することで、特に状況の把握や改善効果、効果を実感みたいなことができるいい結果につながっていった。次のいいサイクル、スパイラルにつながったのかなと考えています。
続いて、同時にリリース速度が上がったことに対してのテスト的な対応みたいなところはどういうことをやっていたのかという話と、意味の文脈で、品質維持の取り組みをあらためてお話しします。
1つ目はユニットテスト拡張の話、2つ目は新しいテスト技術でE2EやVRTの導入の話、3つ目は手動テストをなくさないという話です。こちらもよく言われることだとは思うので、基本的なことですがあらためて紹介します。
1つ目の「ユニットテストの拡張」は、2021年に「大いにみんなでやっていこうぜ」という機運が生まれたのが事実です。こちらは私が技術ブログで書いた「テストチームの改善うんぬんかんぬん」でも紹介したとおり、2020年の年末から、ようやく「ユニットテストを積極的に書いていきましょう」という会社方針になり、そのあとからちょっとずつ積極的に増えてきました。
それまでは、本当に必要なところしか書いていなかったユニットテストが増えて、6月以降の私のジョインに加え、数々のメンバーがジョインしていく中で、仕様を覚えていくとか、「足りないところのテストを拡張していきましょう」というところで、どんどん動いてもらいました。
特にやっていたこととしては、当たり前ですが、そもそもゼロパーファイルテストが1つもないみたいな。自動テストが1つもないところはリスト化するというところで。みなさんユニットを持っているので、隙間時間に少しずつ名前を入れたり担当を奪ったりしてやってもらうかたちを奨励していたところです。
あとはカバレッジ率の記録です。「Nパーセント上がった・下がった」みたいな話をあらためてつなげてグラフとして出す。それがモチベーションになって、さらに加速を生んだり、危機感を煽ったりすることも可視化を意識して動いていました。
続いて、新しい技術の導入というところで、E2E(End to End)と呼ばれるものと、VRT(Vocational Readiness Test)と呼ばれるものの自動テストの技術を導入しています。E2EはEnd-to-Endです。みなさんはご存じかもしれませんが、Seleniumというツールで、Web版をテストしています。スライドには表記していませんが、アプリのiOS版とAndroid版は、それぞれに合ったツールを使って実装しています。
あともう1つ、略してVRTテストと呼ばれる、ビジュアルリグレッションテスト。見た目部分を主に行うテストの実施・導入を進めています。やはりどちらも一定効果を上げることができていて、E2Eであれば、きちんと動かなくなったので調べてみたら何か(が)悪かったとか。VRTであれば、些細に壊れるところ。空白が増えたり、小さくなったりしたところ(を見つけることができています)。
変なズレ方をしたか(を確認すべき)という部分は、やはり見える部分というところで。機械らしい正確性が有効であるという点と、同じテストを書いたら書いただけテストを繰り返してくれる点は、自動テストとして非常に有効であるというところで導入しています。
(スライドに)理由は書いてありますが、このあとに話す手動テストの省エネ化と呼ばれる部分です。機械に任せられることは機械に任せる。人間がやらなきゃいけない部分は人間がやるように切り分けていきたいから。また、リリース化について品質を維持しながらスピードを上げていきたいというニーズに応えた結果、自動テスト導入という運びになっています。
3つ目。こちらも重要な概念だと思いますが、「手動テストはなくさない」。より正確に言うと「なくならないもの」だと思っています。実際に機械で判定できることは機械が言ったことしか判定してくれないとか、人間的感情は現在の技術では当然理解が難しいとか。いろいろあると思うので、機械では難しい分野は、やはり人間がやっていく必要がある。実際に利用した使用感であったり、その時のいわゆる感覚的・感情的な変化です。
例えば、失敗した時はエラー表示が出ているので、そのエラーの内容が適切なのか、わかりやすいのかとか、その内容で修正できるのかとか。あとは、出てきた結果の文言に納得できるのかなども含めた一連の流れです。そういった、お客さまの目に見える部分の変更は実施するよう心がけています。
特に自動で見ていない部分の条件や、複雑すぎて作るのも大変な部分は、ちょっと手間でもわざわざ見てもらう。あとは、実際に使い心地と言われるユーザビリティのような部分や、実際に触ってみることで次の課題を自身で見てもらうという意味でも、手動で触る必要があるのかなと思っています。
現状、弊社にはQAエンジニアが私1人しかいなくて、他には各ユニットに配属されているユニットのエンジニアがテストをします。つまり、QAの私はテストのサポートで、アドバイスをしたり自動テストの構築を手伝ったりという部分、実際の手動テストも含めて、エンジニアがやっています。
これについては最初に西尾とも話をして、「分断化して(QA以外のエンジニアがテストを)やらなくなるとどんどん質が落ちる」みたいな話をしていたので、こういった手動テストも含めて、エンジニアにもやってもらっています。
今後の課題みたいなところの現状をお話しすると、「1日10回リリースするにはどうしたらいいか」というお題目です。これは例えばの話ですが、現行体制はもう根本的に厳しくて、手法や問題がある部分を改善していく必要があります。なぜ1日10回かという話ですが、少しでも早く出したい、少しでも早く結果を得たいという気持ちの表れです。
回数はあまり重要ではありませんが、極端なわかりやすい事例として出しています。今は1日1回、さらに1日はだいたい8時間労働だと思うので、当然1時間に1回じゃ足りない。「それ以上の爆速にはどうする必要があるんだろう」「それに耐えうる手法はなんだろう」というところで、今は考えたり調整したりしています。
あとは、手動テストの観点をどうするか。テストの視点みたいな考え方はだいぶ揮発性が高い。消えやすいということです。失いやすいのは、やはり実感としてあります。
これはどうしてもバグが出がちな点だったりするので、1回目は新しい機能が出る時や、大型のアップデートをする時に新しい機能をすごく見ますが、次の改善でちょっと修正して、修正したピンポイントだけ手動テストをして、他の基本的なテストをしきれていない(現状があります)。
これは自動テストでカバーしていないところも問題だし、手動テストで見ることも足りていない点も問題だったのかなという両側面ではありますが、対策は必要かなと(思います)。よくある、ベースとなるテストケースと呼ばれるような、スプレッドシートで作ったり、テスト管理ツールなどを使って行うケースの準備に関して、今は全体的なものがないのが弊社の弱点なのかなと。あとは、それがテスト者の手元に手軽に届く仕組みがないのも弱点かなと思っています。
先ほどテストをする人間はエンジニアだと話しましたが、「GitHubなどの、いわゆる別のツールを使ってスプレッドシートでチェックしてください」と言うと、どんどん更新が減っていったり忘れたりどこにいったかわからなくなりがちなので、なるべくソース管理ツールと一体化したかたちで届く仕組みを、今は検討して調整しています。
簡単ですが、こちらで私の発表とさせていただきます。お疲れ様でした。
関連タグ:
2024.11.29
「明日までにお願いできますか?」ちょっとカチンとくる一言 頭がいい人に見える上品な言い方に変えるコツ
2024.11.27
何もせず月収1,000万円超…オンラインゲームにハマって起こした事業 大学中退し4社立ち上げ・2社売却した起業家人生
2024.11.25
仕事はできるのに、なぜか尊敬されない人が使いがちな言葉5選 老害化を防ぐために大切な心構えとは
2024.12.03
職場の同僚にイライラ…ストレスを最小限に抑える秘訣 「いい人でいなきゃ」と自分を追い込むタイプへの処方箋
2024.11.26
タスクの伝え方が部下のモチベーションを左右する マッキンゼー流、メンバーが動き出す仕事の振り方
2024.11.29
やたらと多い自慢話、批判や噂好き…「自己重要感」が低い社員の特徴 管理職が知っておきたい「一生働きたい職場」の作り方
2024.12.04
いつも遅刻や自慢話…自分勝手な人にイラっとした時の切り返し 不平等な関係を打開する「相手の期待」を裏切る技
2024.11.28
管理職の「疲弊感」がメンバーに伝わるリスク 部下の「働きがい」を育む6つのポイント
2024.12.02
給料や人間関係が良いだけでは部下は満足しない メンバーの「働きがい」を育む5つのステップ
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.29
「明日までにお願いできますか?」ちょっとカチンとくる一言 頭がいい人に見える上品な言い方に変えるコツ
2024.11.27
何もせず月収1,000万円超…オンラインゲームにハマって起こした事業 大学中退し4社立ち上げ・2社売却した起業家人生
2024.11.25
仕事はできるのに、なぜか尊敬されない人が使いがちな言葉5選 老害化を防ぐために大切な心構えとは
2024.12.03
職場の同僚にイライラ…ストレスを最小限に抑える秘訣 「いい人でいなきゃ」と自分を追い込むタイプへの処方箋
2024.11.26
タスクの伝え方が部下のモチベーションを左右する マッキンゼー流、メンバーが動き出す仕事の振り方
2024.11.29
やたらと多い自慢話、批判や噂好き…「自己重要感」が低い社員の特徴 管理職が知っておきたい「一生働きたい職場」の作り方
2024.12.04
いつも遅刻や自慢話…自分勝手な人にイラっとした時の切り返し 不平等な関係を打開する「相手の期待」を裏切る技
2024.11.28
管理職の「疲弊感」がメンバーに伝わるリスク 部下の「働きがい」を育む6つのポイント
2024.12.02
給料や人間関係が良いだけでは部下は満足しない メンバーの「働きがい」を育む5つのステップ
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?