QAを知ったきっかけと、「品質を作る仕組み」について考えた話
最近、QA(Quality Assurance:品質保証)について学び、自分なりに整理した資料を公開しました。
もともと私は、最初からQA職を目指してこの資料やポートフォリオを作っていたわけではありません。むしろ最初の関心は、データを扱う仕組みや、業務の中で使われる情報をどのように整理し、関係者に伝わる形にするかというところにありました。
たとえば、企業の中でAIツールを使う場合を題材にして、利用申請、承認、利用状況、費用、レビュー対象などを扱う小さなポートフォリオを作っていました。
そこで大事にしていたのは、単にアプリやデータ処理を動かすことだけではありません。
どこでデータが生まれるのか。
どのようなルールで受け取るのか。
どのように保存し、整理するのか。
最終的に、誰がどの情報を見て判断できるのか。
そういった流れを、実装とドキュメントの両方で説明できるようにすることを意識していました。
その後、転職サイトなどでQAやテストに関わる職種から反応をいただくことがありました。正直に言うと、最初はQAという言葉に対して、かなりぼんやりしたイメージしかありませんでした。
「テストをする仕事なのだろうか」
「不具合を見つける役割なのだろうか」
そのくらいの理解からの出発でした。
ただ、少しずつ調べていくうちに、QAは単にリリース前に不具合を探すだけの仕事ではないのだと分かってきました。
要求や仕様が曖昧なままだと、作った後に「何をもって正しいと言えるのか」が分かりにくくなります。
データの受け取り方が曖昧だと、後から作るレポートやダッシュボードの信頼性も揺らぎます。
確認の仕組みが整っていないと、変更するたびに不安が残ります。
そう考えると、QAは開発の最後にだけ登場する役割ではなく、もっと前の段階から「品質を扱いやすい状態にする」ための活動なのだと感じるようになりました。
自分がポートフォリオで意識していたことも、後から見るとQAの考え方とつながる部分がありました。
たとえば、申請・承認のアプリでは、誰が申請できるのか、誰が承認できるのか、自分で自分を承認できないようにするにはどうするか、といった業務上のルールを扱っていました。
これは、単に画面が動くかどうかではなく、業務として許される操作を守るという意味で、品質に関わる観点だったのだと思います。
また、利用データを受け取る部分では、必要な項目がそろっているか、想定外のデータが入っていないか、後から確認できる形で保存できるかを意識していました。
これも、後から分析や判断に使うデータを信頼できる状態にするための取り組みだったと捉えることができます。
さらに、分析用のデータを整理する部分では、どの数字が何を意味するのか、どの単位で集計しているのか、関係者が同じ前提で見られるかを意識していました。
こうした経験を振り返る中で、自分が関心を持っていたのは、単にコードを書くことだけではなく、「後から確認できること」「他の人に説明できること」「安心して判断できる状態を作ること」だったのだと気づきました。
その気づきから、QAについて一度きちんと学び直してみようと思いました。
今回作成した資料では、QAを「テストを実行すること」だけに閉じず、要求を整理すること、確認しやすい形にすること、テストを設計すること、自動化すること、品質に関する情報を集めること、運用後の気づきを改善に戻すことなどを、できるだけ一つの流れとして整理しました。
資料を作ってみて、QAは「最後にチェックする人」というよりも、チームが品質について考え、判断し、改善し続けられるように支える役割なのだと感じています。
もちろん、今回の資料作成だけでQAを十分に理解できたとは思っていません。むしろ、自分がこれまで作ってきたものや大事にしてきた考え方を、「品質」という言葉で捉え直すための第一歩だったと思っています。
今後は、データを扱う経験や、仕組みを整理して説明する経験を活かしながら、プロダクトやチームがより安心して開発・運用できる状態を支えることに関わるご縁があればと思っております。
作成した資料, 関連資料はこちらに公開しています。
- QA職能入門：品質を作り、判断し、改善へ戻す仕組み
- AE / DEポートフォリオを品質の観点から読み直す
AE / DEポートフォリオを、QA / DQA / QE / 運用品質の観点から再解釈した補助資料です。
