テストだけではなく、より広い品質活動が役割　LINEの品質組織が考えるビジョンやミッション

LINE QAチームの「新しい品質保証のかたち」

奥田浩行氏：それでは「開発プロセスを改善するLINE QA 〜品質活動のQC領域からQA領域への拡大〜」と題しまして、LINE Fukuoka QA Engineering室 奥田が発表いたします。

簡単な自己紹介です。前職は福岡のSIer企業でWebアプリケーションの開発を行っていました。ここ2、3年は案件のリーダーをしながらレガシーな現場の改善を実施していました。

例えばテストコードを書く文化がなかったのですが、Seleniumを導入してリグレッションテストの自動化であったり、Excelで管理されていた作業をチケット管理に変えたりです。そんなふうに、仕事をしている時に去年（2020年）、QA Engineering室の「LINEの新しい品質保証のかたちを作る」といったビジョンを聞きチャレンジしてみたいなと思い、話を聞いた翌日に応募しました。

そして2020年の12月からLINE Fukuokaに入社し、LINE Front-end Framework、通称LIFFと呼ばれるプロダクトのプロジェクトにQAエンジニアとして参画しています。

さっそくですがQA、Quality Assuranceという言葉を聞いて、みなさんは何を想像されますか？　多くの方がこの「QA」という言葉に対して、テストを想像するのではないでしょうか？　しかしQAが意味するものは本来テストだけではなく、より広い品質活動になります。

本日はテストだけではないQAの活動領域や、その領域で働くLINEのQAエンジニアの役割、そして実際のプロジェクトでの活動内容などについて話をいたします。

本日の発表内容です。まずLINE Fukuokaの品質組織が考えるビジョンやミッションを説明します。いかにして私たちがLINEの品質向上を実現しようとしているかを紹介します。

そしてQAエンジニアとして私が実際のプロジェクトで取り組んだ内容について紹介いたします。最後にその取り組み内容から学んだことを共有します。

QA Engineering室のミッション

LINE Fukuokaの品質組織が考えるビジョンを説明する前に、まずはLINE Fukuokaの品質組織の歴史や、私が所属するQA Engineering室の設立の背景などについて説明します。

こちらはLINE Fukuokaの品質組織が関わるプロジェクト数の推移です。2014年以前では10個程度だったプロジェクトがLINEのサービス拡大とともに関わるプロジェクトも100個以上と急拡大してきました。

テスト工程を中心に活動しながら規模を拡大してきたのですが、サービスのさらなる品質向上のためには、より広い範囲で品質活動を行うべきではないかという考えから、テスト工程に注力するサービステストセンターと別に新たにQA Engineering室が設立されました。

LINE Fukuokaの品質組織のビジョンは「最高の状態でサービスをユーザーに届けるためにLINEの新しい品質保証のかたちを作ること」です。その新しい品質保証のかたちを実現するためのそれぞれの組織のミッションについて説明します。

サービステストセンターは開発工程のテスト工程全体を管理し「プロダクト品質を効率的に担保すること」をミッションにしています。そして私が所属するQA Engineering室はプロダクト品質だけでなくプロジェクト品質も高めることにより、品質の向上やリードタイムの短縮に貢献することをミッションにしています。

プロダクト品質とプロジェクト品質の定義

次に私たちが考えるプロダクト品質とプロジェクト品質の定義について説明いたします。まずプロダクト品質について説明します。プロダクト品質とは実際に作られた動くソフトウェアの品質です。

一般的に「品質」という単語に対してすぐに連想されるのがこちらのプロダクト品質になります。そしてそれはテストにより品質の良し悪しを判断され、必要に応じて品質を向上させます。以上がプロダクト品質の大まかな説明です。

プロジェクト品質の説明をする前に、まずはプロセス品質と内部品質について説明します。まずプロセス品質とは文字どおり開発プロセスの品質であり、具体的な要素を挙げますと開発のやり方であったり手順に関する品質です。そして内部品質とは開発作業で作られる設計書やコードの品質です。

次にこれらの品質の関係性について説明します。プロセス品質の良し悪しが内部品質に影響します。開発のやり方であったり手順の品質が悪ければそれに沿って作られる設計書やコードの品質も低下します。逆にプロセス品質が高ければ内部品質も向上します。

そしてその内部品質の良し悪しは、プロダクト品質に影響します。設計書やコードの品質が悪ければ、それに沿って作られた動くソフトウェアの品質も低下します。逆に内部品質が高ければ、プロダクト品質も向上します。

そして今話したプロセス品質と内部品質が開発工程のどこで登場するかと言いますと、開発のやり方・手順・それにより作られる設計書やコードですのでプロダクトの全工程で登場します。ですので私たちはこのプロセス品質と内部品質を包括したものをプロジェクト自体の品質、プロジェクト品質と呼んでいます。

なぜ品質活動の拡大が必要なのか

次に私たちが考えるQA、Quality Assuranceの活動領域について説明します。冒頭に説明した通りQAを単にテストの意味として使われるのが多いのですが、テスト工程によるプロダクト品質の向上は本来QC、Quality Controlのことを指します。そしてQAは本来テストよりさらに広い品質活動領域を指し、プロダクトを作る過程の品質向上にフォーカスします。

プロダクトを作る過程というのは私たちの言葉でいうと先ほど説明したプロジェクト品質になります。QA Engineering室のミッションであるプロダクト品質だけでなく、プロジェクト品質向上は本発表のタイトルに含まれている通り品質活動の領域をQC活動からQA領域に拡大させることです。

次に、なぜこのように品質活動の拡大が必要なのかについて説明します。ご存知の方もいると思いますが、不具合は後工程で見つかるほど修正コストが高くなります。企画や設計工程で見つかっていれば軽微な修正で済みます。しかし、後ろの工程である実装やテストで見つかるほど手戻りが発生し、修正コストが膨らみます。

こういった前提のもとプロダクト品質だけに注力したとします。プロダクト品質だけに注力するというのは極端な例で言いますと品質は後工程のテストで向上させるといったスタンスです。そういったスタンスのプロジェクトではテスト工程に来た時点での初期不具合件数が多くなる可能性が高くなります。

大量の不具合に対してテスト工程で工数をかければなんとか対応できるものの、プロジェクト全体で考えた場合コスト増加やリードタイム延長につながります。

そういった状況にならないようにテスト工程に来た時点でのプロダクト品質を向上させる必要があります。テスト工程に来た時点でのプロダクト品質とは先ほど説明した通りプロジェクト品質に影響されます。プロジェクト品質を向上させることでテスト工程に来た時の初期不具合件数を少なくします。そうすることでプロジェクト全体で考えた時のコスト削減やリードタイム短縮につながります。

ですのでプロジェクト全体を考えた場合、プロジェクト品質の向上は重要になります。以上が、私たちが品質活動の領域をQC領域からQA領域に拡大させようとしている理由です。

品質向上のために「何でもやる」

次に各領域で実際にどういうタスクを行うか説明したいと思います。QC領域では主にテストを行います。テスト計画やテスト実施です。これはものすごくイメージしやすいと思います。次にQA領域でのタスクです。私たちは「QAエンジニアのタスクってどういうものがありますか？」と聞かれた場合、こう答えます。「品質向上のためには何でも行います」。

質問に対する答えになっていない気もしますが、実際に私たちQAエンジニアに決まったタスクはないです。なぜならプロジェクトが10個あれば、プロジェクト品質の状態も10通りあり、それを向上させるための方法もまったく異なるからです。

あえてタスクとして例を紹介するのであれば、品質を分析し問題を見つけ改善のためのアクションなどになりますが、そのアクションはプロジェクトによりさまざまです。ですので、繰り返しになりますがQAエンジニアは品質向上のためであれば何でも行い、決められたタスクはないです。QAエンジニア自身が考え、あらゆることにチャレンジします。

ここまで話したことをまとめます。LINE Fukuokaの品質組織は従来プロダクト品質にフォーカスしテストに注力してきましたが、さらなる品質向上、リードタイム短縮のためにプロダクト品質だけでなくプロジェクト品質も向上させようとしています。そしてそれは品質の活動領域をQC領域からQA領域まで拡大させようとすることです。

テストをより効率的に行おうとするサービステストセンターとプロジェクト品質向上にチャレンジしようとするQA Engineering室が協力し合い、LINEの新しい品質保証のかたちを作ろうとしています。以上が、私たちがどのようにしてLINEの品質向上を実現しようとしているかの紹介になります。

（後半へつづく）