はじめに

KINTOテクノロジーズでQAグループFEチームのリーダーをしている遠藤です。

普段、私の作業としてはKINTOテクノロジーズで開発しているKINTO Webサイトのフロントエンド部分について、複数のプロダクトやプロジェクトからQA案件を確認させてもらい、各QA担当者の作業の割り振りや管理をしています。

作業をしているとQA内部だけでなく開発側の方々とお話しする機会も多く、今回は雑談をしている時に、
「なぜQAをやるのか？」
という質問があがり、こういう場をいただいたので私なりの思いを書いてみようと思います。

開発においてQAは、不要か？

「なぜ、QAをやるのか？」をテーマにQAの役割や必要性を書く前に、
そもそもQA自体必要なのか？
という点について考えてみたいと思います。

品質のセミナーや記事とかで、QA不要論があがったりすることがあります。アジャイル開発の中でチームの外にQA部隊を置くのではなく、それぞれのチームメンバーの中にQAの役割が備わっていれば、QAは不要だというのが私が聞いたお話です。

たとえばアジャイル開発チームとは別にQA部隊がある場合、以下のような懸念が考えられます。

• スプリントの中で、仕様変更に柔軟に対応しようとすると、そのあとのQA工程に影響が出る可能性が高い
• QAが仕様を理解するまでのリードタイムが別に掛かることで、QA工程が長くなる
• 不具合が発生した場合、スプリントの中で対応しないためその分の手戻りが大きくなる
  このような点から、アジャイル開発においてはチームの中に開発からQAの役割を含んだテストまで対応できるメンバーさえいればこれらの懸念無く対応できる、というのが話の主旨かなと思っています。

ここで、QA部隊は必要なくともQAの役割自体は否定されてない点が重要だと考えています。

逆に、あくまでQA部隊が必要というお話をされている方の意見として挙げられるのが、

• 開発とは独立した客観的に判断するQA部隊があることで、違った視点からより品質を高められる
• 仕様のナレッジがQA部隊に集中しやすくプロジェクト情報を横串で得られる
• ナレッジを元に、並行して動いている他のプロジェクトに対しても考慮漏れや必要な情報を組織として提供できる
  という部分かと思います。

一方で、QAの役割をアジャイル開発チーム内に置くことの難しい点として、

• 開発からシステムテストまで、テストという面において、高度なスキルを持つメンバーを集めることができるのか
• 集められない場合にはメンバーの育成が必要になるが、適切なスキルを取得するまで時間がかかる
• スキルを持つメンバーにナレッジが集中しやすく、そのメンバーがチームから離脱するとQA対応が難しくなる
  ということが挙げられるかと思います。

他の企業のコラムなどでもQAという部やグループは置いてないが、サービス利用者のためにQA作業は行っているという記事を読んだことがあります。つまり、QA部隊を組織として作るか作らないかは開発手法だったり、組織文化を考慮して選択する。ただし、システム要件にもとづき利用者のために全体的な品質を確認するQAの役割が必要だということは、皆さん共通認識をもっているのかなと感じています。

テストだけではないQAの役割

確認・検証を行うにあたり、QAはテストをするためのテスト専門チームで、QA＝テストと錯覚する方も多いのですが、QAの役割としてはテストだけではありません。その点に関して大きく3つ記述します。

（１）仕様としての正解を確認する

テストを設計する際、システム要件を確認した上で不明点を開発側、業務側にお尋ねします。QAはテストを実施する点から、まずは、要件をもとに仕様の正解を確認します。この作業を通して、仕様の細かい部分に関してQAが指摘することで、要件漏れや仕様の整理につながることがあります。

KINTOのWebサイトで「審査申込の流れ」部分の画面見直しがあった場合を例にご説明します。

この場合、テストの期待結果としては「お申し込みに必要なもの」、「審査お申し込みのステップ」のデザインが、画面仕様と一致していることになります。
お申し込みに必要なものとして、通常のWebからの申し込みの場合は運転免許証画像のアップロードが必要です。ただ、KINTOのサービスは販売店様の店頭でも提供しており、店頭の場合ですとその場で運転免許証を確認できるため、画像をアップロードしなくて良い内容になっています（下記の赤枠の運転免許証の部分）。その点を開発側に確認したところ、だしわけの考慮が必要だということに気づいてもらえたということがあります。

細かい点ではありますが、想定される利用ケースや条件を考慮し、テストの期待結果に相当する正解は何か？という点をしっかり確認します。このように、曖昧な表現や漏れている部分に対して具体的にしていくことで、本来あるべき仕様の確認をします。

先述のように、QAでの仕様確認を通じて、開発側が認識していなかった要件を指摘できることがあります。

また、要件定義段階ではないものの開発工程と並行してテスト観点をまとめることで、テストを実施する前に早めに品質を高めることができます。

（２）テスト設計時における資料整理

短期間に開発する際、開発しながらドキュメントを整理することは時間的に難しい場合があります。

各仕様書があっても、一覧化できていなかったり、操作手順がまとまってなかったりというケースもあります。QAでは上記（１）で仕様の正解を確認しつつ、テスト設計でシナリオ、機能確認、表示確認について、下記のように必要な観点の洗い出しを実施します。

その際、元の情報は開発側にあるので、基本的にはその資料を流用しますが、必要に応じてQA側のテストで確認しやすいように、一覧化したり手順をまとめたりします。
QAが作成した資料を参考にすることで全体の機能を俯瞰して見ることができたり、ある手順を確認するのに役立った等、QA以外の社内関係者から嬉しい言葉を頂くことがあります。
情報としてはプロジェクト内に集約されるため、QAでまとめる資料の内容が最新とは限りませんが、あくまで現状の仕様理解を目的として整理します。また、QAでは並行して動いているプロジェクトを横串に見れている点から、仕様を整理している中で開発側に懸念事項などの情報提供をできることもあり、品質面での支援になっていると言えます。

（３）不具合分析によるフィードバック

プロジェクトが完了した後、QAテストの結果を元に、不具合分析を行います。下記のようにプロジェクト毎に行うのが中心になっていますが、プロジェクトやプロダクト毎の特徴により、要件定義段階での考慮を厚くしてもらうとか、単体テストを強化してもらうなどのフィードバックを行います。

こういった内容を振り返りの場でプロジェクト関係者にフィードバックをすることで、次回のプロジェクト進行の参考にしてもらいます。

不具合分析する際に、プロダクト毎での不具合傾向やプロジェクトとしての課題などを明確にするという点を挙げていき、それについて認識を合わせます。

弱み部分だけの報告ではなく、例えば要件の詰め方を他のプロジェクトとは違った手法を取ってみたとか、単体テスト部分を工夫したという場合に、その効果が出ているという点もしっかり伝えることが大事になります。この報告は、取り組みが良い方向に向かっておりさらにその部分を強化する指針となるので、フィードバックの際には、マイナス面だけにならないよう注意しています。

このようにテストだけではなく、品質を作りこむ面でもQAの役割には意義があります。

結局、QAってなんでやるの？

Webやアプリでサービスを提供する我々にとって、例えば

• デザインは一致しているが、ボタンの位置が画面ごとに異なる
• 画面遷移に時間がかかる
• PCでは問題ないが、スマホだと表示サイズが変わることで文字が読みにくくなる
  という事象があった場合、提供したいサービスの魅力を伝える以前に、使いづらい見づらいという点から利用されなくなる恐れがあります。
  要件としては満たされていることの確認だけではなく、サイトの訪問者が快適に使えるように改善できる点においてQA作業を行う意義はあると思います。

また、QA業務を通して横串でシステム要件を確認できるため、ある程度の仕様情報が得られることで、想定していないプロジェクトのリスクを発見できたりする役割もあります。

KINTOテクノロジーズでは、各プロダクト毎に複数のプロジェクトが並行して動いているため、

• プロジェクトのリリースタイミングによるリスクが発生しないか？
• 共通の仕様が変更される場合、影響があるであろう他のプロダクトがその内容を認識しているか？
• 一連の試験を実施することで、プロダクトをまたがるようなデータの連携を含めた機能に問題ないか？
  という、事前にプロジェクト側で考慮が想定されている部分においても、QAのタイミングであらためて確認を行うことで、残っているリスクを洗い出し品質の作りこみを実施しています。

このように、実際にサービスを利用されるお客様のためにQAが客観的な視点から要件を確認し、品質面の作りこみのサポートを行う必要性はあると思います。

この「お客様のために」という気持ちは私は大事だと思っています。我々のサービスは大多数の方々に利用されています。ただ、お客様は、個人としてそのサービスに向き合います。そのお客様が、ちょっとでも使いづらかったり、見づらかったりすることで、二度とサイトを開かなくなるという事態は、避けなければいけません。
なので、この「お客様のために」という気持ちが、本来伝えたいサービスの魅力を伝え、更なるお客様の獲得につながるという、好循環のスパイラルをにぎる重要な役割と考えています。

さいごに

今回、そもそもQAなんでやるのという漠然とした点から私の考えを記述しました。記事にも書いたように、QAの役割は組織ごとに異なるものでもあります。今回の内容に賛同いただける方や、私が持っていない意見をお持ちでQAに興味のある方など、ご意見ありましたらご連絡いただければと思います。

また、一緒にQAやってみたら楽しそうだなと思った方々、QAを盛り上げてもっと良くしていきたいと思っている方々、いつでも大歓迎ですので以下の採用ページからぜひ応募してください。カジュアル面談からでもOKです。

https://hrmos.co/pages/kinto-technologies/jobs?category=1783696806032474116