2024.05.29
様々な現場でQA業務に携わっている方々の「声」をお届けする『隣のQAに聞く！』。近年、クラウドコンピューティングや人工知能（AI）、IoTなどのテクノロジーの普及が進み、企業がDXを推進するためにデジタル・アダプション・プラットフォーム（DAP）が不可欠なツールとして広く認識されるようになりました。
しかし、DXを推進するツールの導入や運用には高いコストと専門知識やスキルを持った人材が必要です。その中で、注目を集めているのが、DAP市場で3年連続国内市場シェア1位を獲得したテックタッチ株式会社が開発する「テックタッチ」です。
ソフトウェアを提供する企業が自社プロダクトの画面をコーディングなく調整・変更したり、逆にソフトウェアを導入した企業が自社流に画面をカスタマイズすることができます。特にQA目線からは、自社コードをいじらないが故に、自社開発チュートリアルと比較すると継続的なテストから解放されるというメリットもあります。
そんな最先端のDAPを開発する企業では、どのようにQA業務が実施されているか、気になるエンジニアの方も多いのではないでしょうか？本記事では、同社の首藤義景さんに同社のQA活動やQAに取り組む上でのポイントなどについてお話いただきました。
今回インタビューを受けてくださった方
- 首藤 義景 氏
テックタッチ株式会社 QA(品質保証) Project Manager
新卒で第三者検証企業に入社し、テスト工程を経験したのち、複数のソフトウェアの品質保証、QA体制の立ち上げや体制支援業務に携わる。
2021年10月からデジタルアダプションプラットフォームを開発するテックタッチ株式会社に1人目QAとして入社。
社会的意義があるDXの推進
――はじめに、QA業務に携わるようになったきっかけを教えてください。
前職では、いわゆる第三者検証の企業に新卒で入社し、テスターやQAエンジニアを経てマネージャーを務めていました。SaaS系のプロジェクトに携わることが多く、アジャイル開発やスクラムを経験しました。また、品質分析するためのメトリクスの設計収集を通して改善活動や提案を行ってきました。
さまざまなフェーズの企業へのQA体制立ち上げ支援や品質向上支援を行うと同時に、社内の研修やウェビナー登壇等も経験しました。
――テックタッチに入社した経緯を教えていただけますか。
複数の組織でQA体制の立ち上げや支援業務に携わる中で、「自分でもQA組織の立ち上げをやってみたい」という思いが芽生えてきました。その時、偶然にもテックタッチが1人目のQAを募集していることを知ったんです。
当時、DXという言葉が日本でも広まり始めており、「IT化とDXの違いは何か」「DXを推進するために何ができるのか」という疑問が浮かびました。私自身、IT企業で働いているにもかかわらず、この点については明確な解を持っていませんでした。そのため、DAPを開発する企業であるテックタッチで働くことは、社会的意義があると感じ、入社を決めました。
誰でもシステムを使いこなせる世界に
――御社の事業内容を教えてください。
テックタッチは、「すべてのユーザーがシステムを使いこなせる世界に」をミッションに掲げています。私たちは、システム活用の面からテックをより身近に楽しく、世界中の誰もが自然にテクノロジーを使える世界を目指してきました。
当社は、システム導入だけで終わらせず、どんなWebシステム上にも誰でも簡単に操作ガイドを追加できる利活用のためのDXプラットフォーム「テックタッチ」を企画・開発・運営・販売しています。テックタッチを導入していただくことで、操作がわからないことから生じるシステムへの抵抗感をやわらげ、あらゆる人々が思いのままにシステムを使いこなせる、そんなプロダクトを提供しています。
――国内では先駆者としてプロダクトを提供する立場の企業では、QAチームの業務も非常に複雑なのではないでしょうか？
複雑性でいうなら、プロダクト自体も非常に複雑な構造を持っていると考えています。なぜなら、提供しているサービスのユーザー環境をひとつとっても、端末、ブラウザ、OSなどのさまざまな要素に加えて、対象システムとテックタッチが動作するサービスとの相性も問題となるからです。
例えば、あるシステムの環境では正常に動作するものの、他のシステムの環境では問題が発生するといったケースや、特定のプルダウンを選択した際にのみ問題が発生するといった事例です。
そのために、品質を担保することは非常に難しい課題となっており、テストの分析や設計をはじめ、それを実行する際にも全ての環境を網羅するとなると工数が膨大になる傾向があります。したがって、適切なテスト戦略を構築し、重要なポイントを集中的にテストすることが必要になってきますね。
チーム全体で品質を作り込む文化を育む
――事業内でのQA/品証業務の位置づけ・ミッションは何ですか。
QAのミッションは、「不足のない品質を」「安心安全」「品質を科学する」「The Faster, The better」「Professional QA」の5つを掲げて、これらの理念に基づき、主に3つの軸で活動しています。
まず1つ目は、スクラムチームに参画して品質保証やテストの活動を行うことです。スプリントごとにテストを行い、そのテスト分析や開発者との協業を通じて、プロダクト開発に貢献しています。
2つ目は、品質分析です。本番障害やテスト工程で検出されたバグや不具合のデータを分析し、その結果をチームにフィードバックし、この過程で上流の単体テストや実装段階で予防可能な不具合や障害について考察しています。
3つ目は、リリース前の検証です。テックタッチでは※リリーストレインという形式を採用し、3ヶ月に一度のコードフリーズの日にスプリント上で完成したプロダクトをリリースします。複数のスクラムチームがあるため、それらのマージされた状態でリグレッションテストを行い、QAチームがその計画・実行を担当。最近では、E2Eテストの自動化などの活動も行っています。
※リリーストレインとは
リリーストレインとは、リリース日の遅延を少しでも解消するために導入した、締切を作った上で締切に間に合うもののみをリリース対象にする、というものです。
詳細はこちらをご覧ください。
――サービス品質を改善していくために、工夫しているポイントを教えてください。
開発プロセスに新しいテストのアプローチを取り入れ、チーム全体で品質を作り込む文化を育てているところです。これを社内では、DIYをもじって「Test It Yourself（TIY）」と呼んでいます。
具体的には、開発とQAが別れているところを同時に行おうという考え方です。つまり、テストプロセス（テスト計画、テスト分析、テスト設計、テスト実装、テスト実行）を開発者が主体的に実施するということです。このアプローチにより、問題点に対する共通認識を形成したり、見落としを防止したり、テストと開発をリアルタイムでシェアできるなどメリットがあります。これがTIYの第一段階です。
次のフェーズでは、 これまでインプロセス QA としてテストプロセスを担当していた QA は、開発者と並走しながらテストプロセスをレビューします。TIY を導入することで、QA の役割は今よりもイネーブリングの立場でスクラムをサポートする方向にシフトしようと考えています。
――現在、TIYはどのフェーズにあるのでしょうか。
今は実験フェーズです。TIY をスクラムチームに適応できるよう推進中で、まずは有志だけで「やれる人でやってみよう！」と行動していろいろフィードバックを集めて、導入フェーズとして進めていく予定です。
最終的には、QAエンジニアという職種のメンバーがいなくても、開発プロセスにおいてスクラムが回るようにしたいと考えています。そのためには、メンバー1人1人がQAエンジニアの帽子をかぶって活動できるようにスキルアップを目指しています。
――「じゃあQAやらなくなるじゃないか」みたいな言説も出てくるのではないでしょうか。
むしろ、「QAがいないとリリースできないよ！」という状態から脱したいと私は考えています。
というのも、弊社でもTechtouch AI Hubのベータ版をリリースするなど、新しいプロダクトをお客様に提供していく段階で品質保証が必要になってくるので、そちらにリソースをかける必要が出てくると考えています。
なぜなら、新規プロダクトは何が起こるかわからないからです。もちろん、既存のプロダクトもリスクを抱えた状態ではありますが、プロセスを構築し開発者が主体的に品質保証活動をすることでリスクは軽減されると考えています。その分、よりリスクが高いところにQAエンジニアが入っていくべきだと考えています。
価値を早くお客様に提供することが重要
――1人目QAからスタートし、現在は10人体制のチームへと成長していますが、これまでの失敗談があれば教えてください。
私が入社する前からを含めて、テスト自動化に何度もトライしています。当初は手動テストを自動化し、作業を効率化しようと試みましたが、結果的にスクリプトの修正が全体のボトルネックになっていました。
テストを1日1回やプルリクエストがメインにマージされるタイミングなどで実行する形に変更したところ新たな問題が発生しました。
予想外に多くのリクエストが送信され、その結果、バックエンドにインフラ的な面で運用コストがかかる状況が生じました。「じゃあ、それ何とかしなきゃいけないね」というのが最近の課題になっています。
――今後、どのように挽回していくのでしょうか？
得られた教訓としては、最初からバックエンドやフロントエンドのエンジニアを巻き込んで、プロジェクトを進めることが必要だったということです。
そのため、今後はより一層エンジニアとのコミュニケーションを重視し、プロジェクトの構成や方針について話し合っていきます。
――QAのマネージャーとして日々業務に携わる中で、どんなことを大事にしていますか？
お客様へ価値を早く提供することが重要ですね。そのためには、開発者やCSのメンバーと、意思疎通が図れることが不可欠だと考えています。
このような活動は、組織全体で「お客様に良い体験を早く提供しよう」という共通認識があるからこそ成り立つものです。入社する前から、テックタッチにはこのカルチャーが根付いていると感じていました。
そういう意味でもいい会社選びをしたと思っていますし、これを継続できるように、私自身もそのカルチャーを体現していきたいですね。
中長期的に持続可能なQA体制を構築しよう
――今後、業務を通じて達成したいことがあれば教えてください。
ある程度成熟し始めているプロジェクトや芽が出そうなプロダクトがある中で、サービスの成長度に合わせてQAの関わり方は変わっていくものと考えています。
そこで、QAとしての関わり方はどのくらいのタッチが適切なのかをプロセス化したり、みんなでナレッジとして共有したりできるよう構築したいと考えています。
――最後に、今後QA業務にチャレンジしたい方に向けてメッセージをお願いいたします。
前職で1人のQAエンジニアとしての経験を振り返ると「品質保証=テストで大丈夫なのかな？」という不安や焦りが常にありました。
品質保証やQAという役割に就いていても、テストが主な業務になってしまうのはよくあることかと思います。
それは会社の組織風土や職能、あるいはプロジェクトのライフサイクルの状況によるもので、テストが重要となるタイミングも確かに存在します。
しかし、その状態が「全体として最適なのか？」または「3年後など先を見据えたプロダクトの成長に対応できる体制なのか？」という視点で自問自答しながら、中長期的な視点で持続可能なQA体制を考えることが重要だと思います。
――本日はどうもありがとうございました。
