LINE QAチームの品質改善事例
奥田浩行氏：ここからは私が実際のプロジェクトで行ったプロジェクト品質改善の事例について話をいたします。今から話をする改善事例は3つになります。
1つはプロダクト品質目標の設定、2つ目にリグレッションテストの最適化、3つ目に設計と並行したテスト計画になります。
事例を説明する前にプロジェクトの簡単な体制です。まずPMが企画を行い、作るプロダクトの仕様を決め概要を設計します。その概要をもとにさらに詳細であったり実装を各デベロッパーチームが行います。そしてQAチームがテストを行います。
QAチームが行うテストはE2Eテストであり、手動テストと自動テストで構成されています。私がこのプロジェクトに参画した時点ではQAチームがテスト工程外で作業を行うことはあまりない状況でした。以上がプロジェクト体制の簡単な紹介です。
それでは事例の1つ目であるプロダクト品質目標の設定について説明します。まず簡単な状況の説明です。テストによりプロダクト品質向上は行っているものの、客観的に自分たちのプロダクトの品質を測定するような指標はない状況でした。
こういった状況に対して品質の改善サイクルなどを回しやすくするために品質の目標として変更失敗率というものを設定し、測定するようにしました。
変更失敗率というのはリリース後に問題が起きた確率で、品質の数値としてDevOpsなどでよく目にする指標です。私が参画するプロジェクトでは不具合のレベルをCritical、Major、Minorと大きく3段階に分けています。この変更失敗率をリリースによってMajor以上の不具合が発生した割合として定義しました。
不具合レベルを定義する方法
次にこの変更失敗率を精度高く測定するために、不具合レベルの詳細化を行いました。プロジェクトにおける、もともとの不具合レベルの定義は早急に修正が必要なものをCritical、必要次第で早く修正するものをMajor、次回以降のバージョンでリリースするものをMinorとなっており、不具合を登録する人の主観によるところが大きかったです。
このような状況に対して変更失敗率の算出に対して、ある程度主観による要素を排除するために不具合レベルの定義を詳細化しました。
1つは不具合が起きた機能ごと。例えばAPIに関する不具合なのか、UIに関する不具合なのかなどで不具合のレベルの考え方を分け、その機能に対しても発生頻度や影響範囲でさらに細分化しています。
このように機能と発生頻度、影響範囲を組み合わせて表にすることで、主観を排除した不具合レベルの設定がある程度できるようになりました。
今説明しました品質目標の設定と不具合レベルの詳細化によるポジティブな効果を説明します。過去1年分の不具合を分析しました。その分析の際に先ほど説明しました不具合レベルの詳細化に沿って不具合レベルを付け直しました。そして品質目標として設定した変更失敗率を下げている原因を分析しました。
不具合分析の結果から特定の機能に対して不具合が偏っており、33％が同じ機能であることを見つけました。主な原因は仕様が複雑で改修により気付かずに壊れている場合が多いのですが、リグレッションテストをこの機能に対しては実施できていないことでした。
ですので対象の機能に対してリグレッションテストを組み込み、毎回のリリースの度に壊れていないかテストを行うようにしました。
このように品質目標を定めることで分析と改善のサイクルを回しやすくなりました。以上が事例の1つ目であるプロダクト品質目標の設定になります。
リグレッションテストの最適化
次にリグレッションテストの最適化について説明します。まず、私がプロジェクトに参画した時のリグレッションテストの状況について説明します。手動テストと自動テストの両方でリグレッションテストを実施していました。そのリグレッションテストに対して、大きく2つの問題がありました。
1つは自分たちのプロダクトの機能に対して、リグレッションテストがどの程度カバーできているか把握できていませんでした。2つ目が手動テストと自動テストを別々のメンバーが担当しており、それぞれでテストを管理していました。それによりお互いに重複して行っているテストもあるだろうと思いつつも明確には把握できていない状況でした。
実際にどのように管理されていたかを簡単に説明したいと思います。機能一覧と手動テストと自動テストの各成果物のイメージを載せています。お互いの成果物をあまり意識させずにそれぞれが独自の体系で成果物を作っていました。
例えば、機能一覧はカテゴリ、サブカテゴリ、機能名といった体系ですが、手動テストはサブカテゴリ、機能名。自動テストはカテゴリがなく機能名のみが並んでいるような状況です。
そして、それぞれの成果物に書かれているカテゴリ名や機能名が異なる文言で書かれている部分もありました。それぞれの成果物を単独で見た場合問題があるわけではないですが、他の成果物と並べた場合に体系が違うため、対比が難しい状況でした。このように体系の異なることがテストの過不足や重複が見えづらい原因でした。
そういった状況に対してどのように改善したか今から説明します。今説明した状況に対して機能一覧を正としてまずは手動テストの体系を修正しました。機能一覧に対してカテゴリ、サブカテゴリ、機能名の体系にしました。
次に今説明しました手動テストの体系を修正したあとに手動テストと自動テストの成果物を1つにまとめました。そのまとめる際に各テストが自動テストなのか手動テストなのかわかるように区分を付けました。そして1つにまとめる際に重複しているテストは基本的に自動テストで行うようにしました。
ここまでの修正によって、機能一覧に対する過不足や手動テストと自動テストの重複が見えるようになりました。最後にここから1つ追加で変更を行いました。機能一覧の成果物に各機能に対するテストにアクセスするためのテスト成果物へのURLを追加しました。補足しますと機能一覧はPMやデベロッパーが主に管理している成果物、手動テストと自動テストはQAチームが主に管理している成果物です。
QAチーム以外のメンバーがテストの成果物がどこにあるか、あまり知らない状況でした。そういった状況でしたのでPM、デベロッパーが管理している機能一覧にテスト成果物へのURLを追加することで、各機能に対してどのようなリグレッションテストを行っているか確認したい際に迷わずたどり着けるようにしました。
成果物のつながりを意識した改善を行った
今説明しました体系見直しに関するまとめです。1つ目に機能一覧とテストの体系を同じ体系に統一しました。次に手動テストと自動テストを1つにまとめました。最後に機能一覧からテストに迷わずにアクセスできるようにしました。
行ったことの一つひとつはものすごく簡単なことばかりですが、それぞれ独立していた成果物に対して、成果物のつながりを意識した改善を行うことで、以前のように過不足が見えない、重複が見えないといった状況に戻らない仕組みを作ることができました。
リグレッションテストの最適化に対して行ったことがあと1つありますので、次にそれについて説明します。最後に行ったのが過剰に行っているテストケースの削除です。過剰というのは判断基準がないと何を持って判断するかは人によりますが、これを判断するのに役に立ったのが先ほどの事例で話した不具合レベルの詳細化の表です。
不具合レベルを詳細化した結果、優先度がそれほど高くない機能、ここでは仮に機能Cに対して細かく分けた多くのパターンのリグレッションテストが実施されていたとします。そういった優先度が低い機能に対して細かすぎるパターンを見直し、削除を行いました。
実際にリグレッションテスト全体で30パーセント程度のテストケースを削除し、その分の工数を優先度が高いテストに使うように見直しをしました。以上が事例の2つ目であるリグレッションテストの最適化の内容になります。
設計と並行したテスト計画
最後に3つ目の事例である、設計と並行したテスト計画について説明します。まず改善前の状況を3つ説明します。
1点目はテスト計画はテスト開始直前に行っていました。2点目は作成したテスト計画は一部のメンバーのみがレビューを行っていました。3点目はデベロッパーが実装するユニットテストの内容とQAチームで行うE2Eテストの内容はお互いがあまり内容を知らない状況でした。
そんな状況からテスト開始後に細かい条件に関する仕様の認識齟齬が発覚してテストがスムーズに進まないといった問題が発生することがありました。そこで改善として設計工程と並行してテスト計画を行うようにしました。
変更したことをまとめると3点です。
1点目はテスト計画を前倒しし、設計工程と並行して行ったこと。今までに比べQAチームが早めに仕様を把握し、必要に応じてPMやデベロッパーに対して質問をすることで認識齟齬や仕様検討不足に早めに気付くことを狙いにしています。
2点目は今説明しました認識齟齬や仕様検討不足に気付くきっかけをさらに作るためにQAチームが作成したテスト計画をPM、デベロッパーを含めた全員でレビューを行うようになりました。
全員でレビューというと多くの時間を使ってしまう印象を受けるかもしれませんが、レビューの観点を絞る。具体的にいうとテスト概要と認識齟齬が発生しそうな部分を中心にレビューを行うことであまり工数をかけないように工夫をしています。
3点目はそのレビューを行うタイミングでデベロッパーが実装するユニットテストの内容とQAチームが行うE2Eテストの内容について関連が強い部分に関して共有するようにしました。
今説明しました変更内容は変更による工数増加などはあまり発生させないようにしています。工数は増加させていないですが、チーム間の情報共有が増えて効率的に品質向上につながるようにしています。以上が事例の3つ目である設計工程と並行したテスト計画の取り組み内容になります。プロジェクト品質向上のための改善事例の説明は以上になります。
「何をしたらいいのかわからない」不安からの脱却
ここからは事例実現にあたってどのように取り組んだかと、そこから学んだことについて話をします。1年前に入社した時の私はQA Engineering室の「LINEの新しい品質保証のかたちを作る」という、ある意味LINEの品質文化を作り変えるといった壮大なテーマを実現させたい、チャレンジしようという思いがありました。とてもモチベーションが高い状態でした。
しかし、実際に業務に入ってみると品質向上に関して何でもやるというのはわかるが、逆に何をしたらいいかまったく思い付かない状態でした。そして時間だけが過ぎていき、ひたすらに不安でした。何をしたらいいかわからないという不安と、もう1つ不安を増幅させていたのがQAエンジニアに対するプロジェクトからの期待値とQA Engineering室として目指すもののギャップです。
プロジェクトの体制説明時に話したとおり、プロジェクトにおけるQAチームのもともとの活動範囲はテスト工程が中心でした。そのためPMやデベロッパーがQAチームに対して期待するものはテスト活動を通じたプロダクト品質向上でした。そういった状況に対してQA Engineering室のミッション実現のために、テスト工程にとどまらず全工程で活動しようとしていました。
こういった期待値のギャップがある中、QA Engineering室の活動がプロジェクトに受け入れられるかわからないことが私の不安をさらに増幅させていました。このような不安だった状況からプロジェクト品質向上の実現のために行った道のりを今から説明します。
まず1つ目にやったことは成功をイメージするということをやりました。プロジェクト品質向上のために何でもやるという状況に対して品質に関する問題や課題を見つけるためにプロジェクトに対する情報収集をしていました。しかし調べることは無数にあり、今調べていることがミッション実現に近付いているかまったくわからず不安でした。
成功をイメージする
そういった状況に対して自分が1年後までに達成させたいと思う成功の定義を2つ設定しました。1つは設計工程に参画し、品質向上に貢献すること。2つ目はデベロッパーとテストについて考え合える状態になることです。
これはあくまで私が勝手にイメージしたものですので、プロジェクトの状況を踏まえた上での内容ではないです。状況を踏まえない内容だったものの、これを作ったことで自分がまず何を知るべきかがイメージできるようになりました。
1つは設計工程の作業内容を知る。2つ目にデベロッパーの行っているテスト内容を知るといったことです。品質向上のために何でもやるといったことしか考えていなかった状況は暗闇の中でどこが前かもわからず進もうとしていたのかなと思います。
当時は思い付きで自分なりの具体的な成功を設定したのですが、これをイメージしたことでおぼろげではありますが目指す方向性が見えるようになり、前に進む感覚ができて不安を軽減させることができました。以上が成功をイメージすることの説明になります。
次に説明するのが、課題を見つけ課題を磨くといったことです。各工程ごとの自分が思う品質向上のための課題・改善できそうな点を一覧化しました。これはプロジェクトの立場で考えた課題というよりかは、QA Engineering室の立場としてまとめた品質に関する課題一覧です。そして、その一覧にまとめた各課題に対して、どうアプローチしたらいいかをひたすら考えました。
そしていったん課題だと思っていたものが実は表面上のことしか見えておらず、課題の捉え方を間違っている場合もありました。ですので、プロジェクトの作業を通じて自分が経験・知ったことを踏まえて、定期的に見直しをしました。時間が経過すると当然プロジェクトの新たな課題が発生しますので、現在でも課題を見つける・課題を磨くということを続けています。
そして次に行ったのが、今説明しました課題一覧に対する改善への取り組みです。具体的にどのように取り組んだか、先ほど説明しましたプロジェクトの改善事例を踏まえて話をします。
テスト工程以外の改善にどう取り組んだか
先ほどの改善事例で説明したテスト工程に関する改善であるリグレッションテストの最適化は順調に前に進めることができていました。しかし、QAチームがもともと参画していない設計工程に関連するテスト計画の前倒しであったり、全工程・全メンバーに関係する品質目標の設定などについては正直スムーズに実現できたわけではありません。
この2つの事例がどのように実現できたか、今から説明します。まずは品質目標について説明します。
事例でも説明したとおり、品質の目標がないところがスタートでした。その状況に対して、全員が品質に対して考えるチームになりたいというものを品質の課題一覧に載せていました。しかしどうやってそれを実現すればいいかは悩んでいるところでした。
そんな時ある日PMが「プロジェクト内のKPIを設定したい」と、プロジェクトメンバーに案を募ることがありました。どういった項目をKPIの項目にするかといったところからの検討でした。
そういった状況に対して私が行ったのは、チーム全体で品質を考えたいという自分の考えとKPIの設定を行おうとするプロジェクトの状況を踏まえてKPIの項目の1つに改善事例で説明したプロダクト品質目標の提案を行いました。プロダクト品質目標はこのような流れで実現されました。
次に設計と並行したテスト計画について説明します。もともとは事例の時に説明したとおり、テスト開始直前にテスト計画を行い一部のメンバーのみがレビューし、E2Eとユニットテストの共有はあまりない状況でした。
そういった状況に対してQAチームが設計工程に参画したい、デベロッパーとテストに対して議論するようになりたいというのを品質の活動一覧に載せていました。
しかし、どうやってそれを実現すればいいかは悩んでいるところでした。そんな時にある日不具合が発生した際に、PMとデベロッパーが再発防止や改善のためにユニットテストの拡充について打ち合わせで検討していました。
その打ち合わせに私が参加した際にユニットテストの拡充だけでなく、QAチームのテスト計画を前倒しし、全員でレビューし、E2Eとユニットテストの内容を共有することで工数をあまりかけずにさらに品質向上できるのではないかと提案しました。
設計と並行したテスト計画はこのような流れで実現されました。設計工程に関連する改善であったり、全工程・全メンバーに関連する改善をどう進めたらいいか悩んでいた状況に対して、品質の課題一覧の内容とプロジェクトの状況を踏まえて提案することで改善事例を実現させることができました。
さまざまな「不確実性」と向き合った
この取り組みから私が学んだことです。品質の課題一覧とは私がQAエンジニアとして考える品質に関する課題や改善内容です。これは言い換えると私がやりたいと思っていることです。
そして、プロジェクトの状況は言い換えればチームが認識している問題と言えると思います。ですので、何かを変えたい、提案をしたいという時は、自分のやりたいことだけを考えるのではなく、自分の考えとチームの問題を組み合わせて問題解決につなげることが重要なことだと実感しました。
そしてそのチームの問題を見つける、気付くためにはQAエンジニアとしての目線だけでなく、相手のロールや相手の作業内容に関心を持ち、相手の立場で物事を考えるのが大事だと思っています。以上が私が不安だった状況から、どのように改善事例の実現にいたったかの話になります。
本日の発表のまとめです。QA Engineering室は、品質の活動領域をQC領域からQA領域に拡大させるためにプロダクト品質だけでなく、プロジェクト品質も向上させようとしています。そしてそれはQCとQAの間、テスト工程とテスト工程以外の間にあった壁を乗り越えようとチャレンジしていることです。
この壁を乗り越えるのは不安なことばかりでした。この不安は何をやればプロジェクト品質の向上に近付くのかわからないことと、QAエンジニアの役割や目指すものがプロジェクトに受け入れられるかわからないことから発生していたと思います。
そして、それに対して成功のイメージを描くこと、相手の問題解決につなげる、相手の視点を持つということで前に進めてきました。
言い換えると、未来に対する不安と自分ではない他人に対する不安に対応してきたことだと思います。やっている時はまったく意識していなかったのですが、これはまさにエンジニアが立ち向かうべき未来と他人から発生する不確実性に対する対応だったのかなと思います。
私が行った不確実性に対する対応である成功をイメージする、相手の問題解決につなげるといった考えが少しでもみなさんのプロジェクト改善などの参考になればと思います。
以上が私の発表内容になります。ありがとうございました。
