2021年11月10日・11日の2日間にわたり、LINEのオンライン技術カンファレンス「LINE DEVELOPER DAY 2021」が開催されました。特別連載企画「DEVDAY21 +Interview」では、登壇者たちに発表内容をさらに深堀り、発表では触れられなかった関連の内容や裏話などについてインタビューします。今回の対象セッションは「開発プロセスを改善するLINEのQA～品質活動のQC領域からQA領域への拡大～」です。
プロジェクト品質の向上による更なる品質向上とリードタイムの短縮を実現するべく、LINE FukuokaはQA Engineering室を2020年7月に設立しました。この目標を達成するためには品質活動の領域をQC（Quality Control）からQA（Quality Assurance）へ拡大することが重要です。その具体的な取り組みの内容などについて、QA Engineering室のメンバーである奥田浩行に語ってもらいました。
ソフトウェア開発全体の改善に幅広く取り組めることが魅力
――まずQA Engineering室の役割を教えてください。
奥田：もともとLINE Fukuokaには、テスト工程に注力するサービステストセンターがありました。開発フェーズにおけるテスト工程全体を管理し、プロダクト品質を効率的に担保することがミッションです。
ただサービスのさらなる品質向上のためには、より広い範囲で品質活動を行うべきではないかとの考えから、サービステストセンターとは別にQA Engineering室が設立されました。ミッションは、プロダクト品質だけでなく、プロジェクト品質も高めることにより、品質の向上やリードタイムの短縮に貢献することです。
――LINE DEVELOPER DAY 2021のセッションでは、QA Engineering室が設立されるという話を聞いたことが、LINE Fukuokaに転職したキッカケとのお話がありました。なぜチャレンジしたいと思ったのでしょうか。
奥田：もともとシステムインテグレータでWebアプリケーションの開発をしていました。直近2～3年は開発現場の改善に力を入れて取り組んでいました。そのように働いているときに、プロジェクト品質向上に注力するQA Engineering室の存在を知りました。自分の経験を活かせるのではないか、またLINEという大きなサービスで新しいことにチャレンジしたいと考えて転職することを決めました。
特に、品質向上のためにソフトウェア開発全体の改善や課題解決に取り組めることに大きな魅力を感じましたし、やりがいのある仕事だなと思いました。
――プロジェクト品質を高めるための活動のどういった点に魅力があったのでしょうか。
奥田：これは前職の話ですが、今までにないやり方や新たな手法をチームにうまく適用することができれば、みんながすごく楽になるんですよね。実際、何十人月って工数をかけていた作業がゼロになるといったこともありました。
このように目に見える成果を生み出すことができたり、努力に対して大きなリターンが得られたりすることは面白かったですし、チームの状態やメンバーのことを見ながら仕組みを考えるのも私にとっては楽しい取り組みです。
サービスの競争力向上につながるプロジェクト品質
――プロダクト品質だけでなく、プロジェクト品質も重要であると考えたきっかけは何だったのでしょうか。
奥田：きっかけは大きく2つあります。まず1つは、QAエンジニアの役割を学んだときに、テストだけでなくより広い範囲で活動すべきだと知ったことです。
2つ目はLINEが提供するプロダクトのさらなる品質向上や、リードタイムを短縮するためには必要なことだと考えたためです。
LINEにはサーバサイドエンジニアやフロントエンドエンジニアなどの開発エンジニアであったり、QAエンジニアなど、様々な専門職があります。このように専門職を設けることで、より深い技術を持ってプロジェクトに参加できるというメリットがある一方、自然と情報やタスクが分断してしまいやすい難点もあります。
実際、LINEでは開発エンジニアがソフトウェア開発、QAエンジニアはテストのイメージが強く、それによって作業が分かれすぎているプロジェクトも見かけます。作業の分断が強く、かつ設計書の整備が追いついていないプロジェクトの場合は、必要な情報がQAチームに伝わりづらく後工程のテストへの影響が大きい場合もあります。
そういった状況を改善し、サービスの競争力を高めるためには、プロジェクト品質の向上が重要だと感じました。
――プロジェクト品質の重要性について、社内ですぐに認識を合わせることはできたのでしょうか。
奥田：QA Engineering室については、設立の目的がプロジェクト品質を高めることであり、同じ思いを持った人が集まった組織であるため、その重要性は共通認識として持っていました。
ただプロダクトを開発するエンジニアに対して、私からプロジェクト品質について説明したことはありません。相手が知らない単語を使って推進しようとすると、抵抗感が生まれる可能性があると考えたためです。現在でも、プロジェクト品質といった言葉はあえて使わないようにしています。
言葉で説明するのではなく、プロジェクト品質の重要性を徐々に浸透させていくために、行動で示したり、私たちの活動を広く発信することを意識しています。
たとえばプロジェクトで実際に発生している問題について、QA Engineering室の活動によってそれを解決し、プロジェクト品質が改善するといった形です。また今回のLINE DEVELOPER DAY 2021のように、自分たちの考えや取り組み内容を発信することも重視しています。
品質に対するイメージや文化を作り替えていくような取り組みであるため、決して簡単ではないですし、時間がかかることだと思います。ただ私の発表を見ていただいたプロジェクトメンバーの方から、「QA Engineering室は上流工程からプロジェクトの改善などに取り組むんですね」と声をかけてもらったんです。このように私たちの考えが徐々に浸透し、少しずつ変化を感じる部分も出てきています。
QAエンジニアがプロジェクトに入るために工夫したこと
――プロジェクト品質の向上では、上流からプロジェクトに関与することが必要になると思いますが、プロジェクトに入る上で意識していることはありますか。
奥田：開発エンジニアの中には、QAエンジニアが開発工程の上流に入るイメージをあまり持たれていない方もいます。そういった中、いきなり上流にかかわらせてくださいと言っても、「なんで？」っていう感じになりかねません。そのため、「やります」と宣言するのではなく、自然とプロジェクトに入り込むように意識しています。
たとえば、これまで書面で伝えるだけだったテスト計画を早めに作り、打ち合わせで共有しつつ「この仕様はどうなっていますか」などと聞くようにして、徐々に打ち合わせで発言できるような雰囲気を作るなどといった形で工夫しました。
実際、いつもより2～3週間ほど早めにテスト計画を作って共有したプロジェクトでは、振り返り会のなかで「QAチームが早めにテスト計画を作って共有してくれたのがよかった」と言ってもらえました。これはとても嬉しかったですね。
おそらく私がプロジェクトに入るようになった頃までは、QAチームが行うテスト内容を把握しているのは、プロジェクトマネージャー(PM)などごく一部だったと思います。ただ私が入って、プロジェクトにかかわる開発エンジニア全員がいる打ち合わせでテストについて説明するといった機会を作ったことで、テストについて会話をすることも増えつつあります。
――テスト計画を設計と並行して作成するようにしたとセッションで話されていましたが、当初想定した成果は生まれていると考えていますか。
奥田：テスト計画を早めに作ることにより、自然と仕様に関する質問がQAチームから発生します。そうした小さな疑問を掘り下げることで、認識の齟齬や仕様の検討不足に気づけることがありました。テスト開始直前でテスト計画を作成したとしても、これらの問題に気づけると思いますが、そのタイミングが早くなったことで生産性の向上にも寄与できていると考えています。
たとえば入力される値などについて、設計段階でもある程度考えますが、そのパターンを一番細かく、真剣に考えるのはテストを作るときだと私は思っています。実際、テストを作るときは条件や値を表にまとめるのですが、その表を見ながら仕様に不備があることに気づくことはあります。
この気づいたタイミングが開発フェーズの中なのか、それともテストフェーズに進んでしまってから気づくのかではまったく違います。テストフェーズで気づいた場合、そもそもリリースまで時間がない中で対応することが求められるため、負担が大きくなります。その意味で、テスト計画を設計と並行して作成することは、開発エンジニア側にもメリットがあるのではないでしょうか。
――セッションでは、リグレッションテストの最適化についても触れられていました。その成果について教えてください。
奥田：まず1つは、リグレッションテストのドキュメント体系を見直したことにより、機能に対するテストの存在有無がすぐに分かるようになりました。経験が長いメンバーは、各機能に対してどういったテストを行っているかを把握できていますが、新しいメンバーはそうではありません。それに対し、ドキュメント体系を整理したことでキャッチアップしやすくなったと思います。
2つ目はセッションで話した、過剰に行っているテストの削減で、30％程度のテストケースを削除しました。これにより、優先度が高いテストに工数を割くことができました。
PMが管理している機能一覧をQAチームで修正したことも1つの成果だと考えています。QAチームが他のチームのドキュメントを改善してもよいという事例を作ることができたため、今後の活動が進めやすくなりました。
QAエンジニア＝テストだけをする人、というイメージを覆したい
――QAエンジニアとして働く中で感じるやりがいや面白さを教えてください。
奥田：プロジェクトの問題を解決しようとすると、テクニカルな内容だけでなく、チームやメンバーに向き合って考える必要もあります。そこで、プロジェクトの現状やメンバーの考え方などを踏まえつつ改善を進めていくのは、難しさを感じる部分であると同時に、とてもやりがいを感じますし楽しい仕事です。
さらにLINEだからこそのやりがいや面白さもあります。QA Engineering室だけでなく、LINEには会社全体でどんどんチャレンジさせてくれる組織文化があります。何でもやっていいからこそ、自分で考えて行動することが求められますが、そこはやりがいを強く感じる部分です。
また社内では様々な技術が使われているほか、周りの開発エンジニアのスキルも高いです。そういった環境で働くためには、自分も日々スキルを高める必要があり、成長につながっていると思う部分です。
学びという観点では、多様なサービスに触れられることも大きなメリットです。LINE は多種多様なサービスを開発しています。私は最近になり、複数のプロジェクトを兼務するようになったのですが、担当するサービスが変わると、使われている技術やチームの状況が変わり、QAエンジニアとしてやるべきこともガラリと変わります。それによって学ぶべきことの幅が広がり、自己成長にもつながっています。
――品質向上の観点において、開発を担うエンジニアとどのようにコミュニケーションしていきたいと考えていますか。
奥田：ユニットテストやインテグレーションテスト、E2Eテストといったテストのピラミッドを意識しながら、開発工程のいつ、どんなテストを行うかなどを開発エンジニアとQAエンジニアで話し合いながら、共同で品質を高めていけるといいですね。
そのためには、QAエンジニアがより企画、設計、実装などのテスト以外の開発プロセスに入っていく必要があると感じています。QAエンジニアが上流工程から入ることは重要だと考えていますが、一方でスキルがない状態で入ってもベネフィットを生み出すことは困難でしょう。そのため、QAエンジニアとしてテスト以外の開発プロセス全般の知識やスキルを身につける努力していかなければならないと思います。そのような努力や実績を積み上げていくことでQAエンジニアが早い段階からプロジェクトに関わるのが当たり前になっていければうれしいですね。
――最後に、今後QA Engineering室で取り組みたいことを聞かせてください。
奥田：ソフトウェア開発の現場では、QAエンジニア＝テストだけをする人、というイメージがまだまだ強いのが現状だと思っています。
そのイメージを変えるために、QAエンジニアとしてテスト以外の活動でもプロジェクトに貢献し続けることと、LINEのQAエンジニアの活動内容を発信することで、QAエンジニアに対するイメージを変えていきたいと思います。
採用情報
LINE株式会社では一緒に働くエンジニアを募集しています！今回のインタビューと関連する募集ポジションはこちらです。