QAエンジニアは技術的負債にどのように向き合うべきか

急速な成長を目指す企業やWebサービスにとって、新機能のリリースや改修プログラムのリリースには常にスピード感が求められます。このような環境の中で、いま多くのエンジニアが「技術的負債」という問題に直面しています。

システムにおける「技術的負債」という問題に直面したとき、多くの企業やエンジニアがどのように取り組み解消しているのか。負債を解消するためのノウハウやベストプラクティスといった解決策の情報が少ないことも事実です。

そこで今回は第一線で活躍されている現役のQAエンジニアを招いて、「技術的負債とQA」と題したセミナーを2022年10月19日に開催しました。パネルディスカッションで話題となった実際の問題や解消方法など、一部ピックアップしてご紹介します。当日のアーカイブ動画も視聴できますので、より詳しい内容をご覧になりたい方はセミナー概要のフォームよりお申し込みご視聴ください。

セミナー概要

セミナー名

技術的負債とQA 〜現場QAエンジニアは日々どのように向き合っているか〜

開催日時

2022年10月19日（水）16:00～17:00

概要

開発チームにおいて「技術的負債」の解消を図ったとき、QAがどのような役回りを果たすべきなのか。日々の開発現場においてQAがどのように「技術的負債」に向き合っていくべきなのか。今まさに業務に従事している現役QAエンジニアの方々をお招きして、現場の生の意見を語っていただきました。

スピーカー

定金 裕史 氏（Classi株式会社 プロダクト開発部 副部長 QAチーム）

さまざまな組織での開発やQAからQA組織立ち上げ、マネージメント業務を経て2019年Classi社に入社。現在は約15名規模のQA組織のマネジメントに従事している。

久保 治彦（オーティファイ株式会社 Senior QA Manager）

Microsoft OS開発統括部でSDETとしてのキャリアをスタート。その後、VMware, UiPath, Cybereasonで日本向け製品のリリース、QAをSETとして担当。2022年よりAutifyに1人目のシニアQAマネージャーとして参画し、Autifyの2製品のQAやリリースをリードしている。

モデレーター

井上 大輔（オーティファイ株式会社 Senior Technical Success Manager）

約10年間のサーバーサイドエンジニアとしての経験の後、セールスエンジニア・CREを経て現職。Mashup Awards 2018 受賞。共著に「Mackerel サーバ監視実践入門」など。

技術的負債とは

日々のシステム開発においては、品質とスピードのバランスを取ることが重要です。バグが発生しないことを目指したソフトウェア開発と、タイトなスケジュールでリリース日を迎えるソフトウェア開発はまさにトレードオフの関係といえるでしょう。

品質よりスピードを重視したとき、どのようなプログラミングのソースコードが想定されるでしょうか。仕様にそぐわない挙動や不具合の発生だけでなく、処理の非効率や可読性の低下といったことも懸念されます。このことが後に「技術的負債」となり、課題として残る原因となるのです。

蓄積された「技術的負債」を解消するためには、いつの日か対策しなければならない仕事となってしまいます。お金の負債と同じように、技術的負債も目先の利益を得られると後に返済を求められることが予測されるでしょう。

現在のQA体制について

定金: 弊社はベネッセの教育支援とソフトバンクのIT事業を活用して、学校の先生と生徒、保護者をつなぐ教育プラットフォーム「Classi」を提供しています。2014年にリリースして、現在8年目の事業です。QAチームが立ち上がったのは入社した2019年頃で、約4年ほどQAチームを担当しています

2020年からは検証精度向上の取り組みとして、QAが開発の上流工程にも参加するようになりました。2021年からはAutifyを利用したテスト自動化も導入して、品質の可視化を図りました。今年からは内部・外部の品質向上や、QAチームの意識改革にも取り組んでいます。

Classiの開発チームとQAチームの体制ですが、プロダクト開発部という大きな枠の中に各プラットフォームを担当する開発チームが5つ存在します。それぞれの開発チームにはQAチームから2名ずつ、専任のQA担当を配属するようにしました。ただしそれでは網羅的な検証が難しいので、すべてのチームを包括的に見るために共通QAという担当もあわせて配置しています。

久保: ソフトウェアの動作検証におけるプラットフォーム開発を行なうAutifyは、2016年に創業した企業で社員数は約65名規模の組織です。サービスの特徴としてはノーコードでE2Eテストが作成でき、登録したテストはAIがメンテナンスする特徴を持ったサービスです。現在はWebアプリケーションだけでなく、スマホ向けアプリのテストにも対応したサービスをリリースしています。

Autifyの開発体制として「Engineering team」の配下に「For Web」と「For Mobile」がありますが、QAチームは「Engineering team」の直下でWebとモバイルを横断的に検証する役割となっています。

各社における技術的負債の現状

定金: QAチームが立ち上がる以前は、開発者がテスト項目を作成して専門業者に検証を依頼していました。仕様の伝達漏れであったり検証スキルの不足によって十分な検証ができていませんでした。検証プロセスや運用フローも不十分だったので、QAチームにとって必要な検証環境や事前準備、リリース判定といった運用フローを構築するための整備も必要でした。

QAチーム発足後は運用フローも構築され安定的になりましたが、これまで見えてこなかった開発側での要件定義が不完全であったり、検証期間中に実装が不十分であるといった負債が明るみに出てきました。このような出来事が連続して発生したことにより、負債は積み上がる一方だったのです。

象徴的な事例としてはQAが検証したにも関わらず、本番環境で不具合が発生してしまったことですね。チーム内で情報の伝達が漏れていたり、検証パターンの不足であったり、さまざまな要因が浮き彫りになりました。

久保: Autifyの場合は大幅な仕様変更があるときに、現行のソースコードでは対応できないケースが発生しました。整備が必要となる箇所が技術的負債となり、仕様変更を加えるためのリファクタリングに今もなお取り組んでいる最中です。

製品が市場に出ることでユーザーからのフィードバックも大きくなり、当初予定していた開発ロードマップとは少しずつ変化してきました。この点も技術的負債が増えてしまった要因だと考えられますね。

定金: そういう意味ではQAチームの中で事業フェーズを掲げていますね。立ち上げから5年計画でQAチームはどうあるべきか、どのような取り組みをするのかをこれまで考えてきました。これからは開発側の技術的負債についても、QAがどう向き合うのかを考えるフェーズに入ってきたと思います。

技術的負債に対して発生するQA業務

久保: 具体的な業務としてはリファクタリングによるリスクに対するユーザーストーリーの洗い出しや、Autifyを使ってE2Eテストを作成するといったシンプルなアクションでした。

QAはリファクタリングを行うエリアにユニットテストが存在するか、またはユニットテスト自体を変更する必要があるのかを判断することが重要です。エンジニアが安心してコードを変更できるのか、いかにユーザーに向けて品質の保証を担保するのか。そういった点でE2Eテストに着目して業務を行ないました。

リファクタリングを実行しても、基本的にユーザー目線では変化を感じることはありません。ユーザー目線で見ればユニットテストを実行しなくても、事前に準備されたE2Eテストがあれば製品の品質を担保できると考えます。

定金: 各QAチームでは1日に1〜2案件、5チームで合計すると1日に5〜10案件のリリースが発生します。継続的なインテグレーションとより速い開発サイクルを実現するため、いかにテストで負債を解消するかという理由からAutifyを導入しました。

ClassiでのAutifyの活用方法は、定期的なテストの実行、既存機能のリグレッションテスト、あとは深夜メンテナンスですね。導入前は深夜に何十人も集まって手動テストを実施していましたが、今はAutifyを実行するだけに留まりました。

案件ごとの機能改修においては、ステージング環境と本番環境でもテストを実施しています。Autifyならステージング環境向けに作成したテストでも、URLやログインIDの設定を変更するだけで本番環境にも流用できるので、工数削減だけでなく品質の再現性も担保できました。セキュリティ面においてもライブラリの更新頻度が高いので、リグレッションの再検証という点でも活用しています。

技術的負債を解消、防止するために取り組んでいること

定金: 一番ネックになってくるのは内部品質、特にドキュメントといった負債がメインになると思います。QAがそもそも認知していない仕様や、共有されていない情報は検証対象から外れてしまい、結果的に本番環境で不具合が発生しました。このような負債を解消するために、現在は専任のQAチームが設計書の把握、ナレッジの集約などを担当しています。

開発チームは流動的に人員の移動が多く、属人化されてしまうシーンが見られました。本来仕様書は開発側で持つべき資料ですが、仕様を最も把握しているQAチームが開発側のドキュメントを管理できるように考えています。

もうひとつは外部品質だけでなく、内部品質を極めるための情報収集や可視化も進めている最中です。開発フェーズで問題視されている部分をチーム内で深堀りをして、眠っている負債を明らかにできればと思っています。

久保: AutifyではドキュメントやE2Eテストも含めて、デベロッパーが自走式に取り組んでいけるようなプロセス作りに今まさに取り組んでいるところです。QAを担当するリソースがあればいいのですが、状況はデベロッパーに任せているのが実情です。プロセスが構築されれば、ドキュメントやテストなどあらゆる面でパフォーマンスが良くなると考えています。

ユーザーストーリーは基本的にプロダクトマネージャーが定義しますが、デベロッパーには自分達が作りこんだインプリメンテーション（実装）を徹底的にユーザーストーリーとして落とし込む。QAは成果物をレビューするだけであったり、Autifyを活用して汎用的なテストを作成したりすることに注力しています。

最後に

システム開発の現場において、技術的負債は避けては通れない課題です。システムやサービスが進化し続ける以上、必ずつきまとう問題といえます。常に現状を振り返り、負債を返済するために無理のない範囲で継続的に取り組むことが重要です。記事ではほんの一部のみご紹介しましたが、アーカイブ動画ではさらに実践的な取り組みや具体的な課題について語られています。また技術的負債を解消にむけたAutifyの活用事例なども話題になっていますので、気になる方はぜひご視聴ください。

本セミナーは見逃し配信中です！こちらから当日のセミナーの動画をご覧ください。

Autifyではこの他にも品質保証やテスト、アジャイル開発に役立つ資料を無料で公開していますので、ぜひこちらからご覧ください。