1人目QAとして他業種から飛び込むときのマインドセット

この記事は、Finatextグループ10周年記念アドベントカレンダーの10日目の記事です。昨日は關さんが「法人向けPCのスマートな買い方」という記事を公開しています。

こんにちは！FinatextでQAエンジニアをしている狩野(かりの)です。

7年くらい前からQA(Quality Assurance 品質保証)エンジニアを名乗り、ゲーム → AI医療機器 → ヘルスケアDX → 金融と全然異なる業種を渡り歩いた私が「他業種に1人目QAとして飛び込むときのマインドセット」について語ります。

これから1人目QAとして他の業種へ飛び込もうと考えている方や、異業種から当社へ飛び込もうとしている方に対して、不安に押しつぶされそうなココロに勇気を与えられれば！ということを踏まえつつ以下へスクロールをお願いします。

1. 開拓者精神を持つ

1人目QAという言葉の通り、飛び込んだ先に同じロールモデルで業務しているメンバーはおりません。そもそもQAやQC(Quality Control 品質管理)といった言葉すら浸透していない場合があります。

その環境に対して不安に思うことは一切ありません。あなたが「主役」なのです。主体性を持った行動が肝心です。

今までに身に着けた知識や経験を発揮し、周りを巻き込んでいくというフロンティアスピリッツをココロにいだき、チームメンバーに対してQA/QCの存在の大事さを展開していく。その心構えが何よりも大事です。

2. 朱に交われば赤くなる

いくら開拓者精神を持っていても知らないこと、わからないことは山ほどあります。焦る必要は一切ありません。あなたがQA/QCのメンバーとしてやっていくというココロを持ち続けていれば、自ずと知識と経験は身についていきます。

最初は業務経験がないことで、MECE(漏れなくダブりなく)なテストケースが作れなくても、細かくPDCAサイクルを繰り返したり、チームメンバーとレビューを繰り返すことで、自ずとその企業や環境に適切な設計ができるようになります。

わからない技術やツールがあっても、何度も繰り返して使うことで誰よりも詳しくなることがあり、それをチームメンバーと共有することでさらに自身の技術向上が見込めたりします。

3. アンラーニング / リスキリング

「前まではこうだったから」「このやり方が私に取って最適だから」

業務をいかに早く効率よく進めていくために、このような考え方があるのは大事です。ただし、これは1人目QAにはふさわしくないマインドセットです。今まで経験したことがすべての最適解であるとは限りません。飛び込んだ先の企業や環境が培ってきたことを理解することが大事です。

QA/QCはその名の通りプロダクトの品質を司るポジションのため、開発されたプロダクトが確かに存在します。プロダクトが作られた背景や要件をよく理解することが求められます。文書化されたこと以上をヒアリングして理解するためには学び直しが必要です。仮に今までやってきたやり方が使えたとしてももっと効率の良いやり方があるかもしれません。

特にQAエンジニアに関する技術はココ数年で大きく発展しました。ハードウェア性能の向上から生成系AIの登場。これらをうまく業務に組み込み、「今やっていることの進化系は何か？」を考えながら、今のプロダクトの品質に目を落とすと、過去の経験以上に大きなQA/QC業務が見えるようになります。

4. 大事なのはドメイン知識

精神論のようなことばかりを書きましたが、QA/QCにとって最も大事なのは「ドメイン知識」だと考えます。

自分がQA/QCを担当するプロダクト、自分がマネジメントするチーム、自分が開発するテストツールなど、環境に即した技術やプロセスを理解した上で適用しなければなりません。

ドメイン知識は一朝一夕では身につかないことが多いです。ただし、これを一人で身につける必要はありません。すでにいるメンバーから教わったり、チームで細かく実験して共有してみたり、資格を取得してみたり、方法はたくさんあります。

ドメイン知識を得るために最適な方法は1つとは限りません。あらゆることに興味を持って業務に励むことで、自ずとドメイン知識は獲得できます。気になったことを積極的にチームメンバーにヒアリングしたり、共有することで業務に必要なドメイン知識やその周辺を取り巻く環境を知ることができます。知識を得るための行動が鍵です。

5. 法規制、コンプライアンス意識

ドメイン知識を身につけるうえで、必ず登場するのが法規制、コンプライアンスです。裏を返せば、それらを知る行動を取ることで、業種の共通知を知ることができます。

私の経験してきた業種において、ゲームであれば CESA や GooglePlay / AppStore が用意しているガイドライン、医療であれば薬機法や省令/規約、金融であれば金商法や協会のガイドライン。もちろんこれらだけではなく、より多くの「ルール」が存在します。

QA/QCを担当するにはこれらを幅広く知り、ときには違反がないようにブレーキをかけることもあります。ブレーキを掛ける際の背景を知らないままにチームメンバーや顧客に伝えるのはNGです、理解が得られません。ルールに納得する必要性は無いかもしれませんが、ルールができた背景を知っておくことはとても重要です。

業種によって変わるもの: 技術

開発環境やチームメンバーが変われば、用いる技術や開発プロセスは大きく異なります。

JSTQB や ISO25000シリーズ のようなテストの標準体系があったとしても、それらをどのように運用するかは組織によって変わります。

わかり易い言葉をあげるとしたら「テスト自動化」。

スクラムのような細かく開発を繰り返すような体制や、自社プラットフォームで横展開するようなプロダクトを開発するのであれば、E2E(end to end: 頭から終わりまで通しで行う)テストの運用や、ユニットテストの拡充/徹底は開発スピードの向上に貢献します。

逆に、業務システムの刷新のようなウォーターフォール開発に関しては、E2Eテストではなく、文書生成の自動化や、レビュープロセスにかかるチェックリスト作成の自動化など、プロダクトの周辺を効率化することを求められたりします。代表的なのは RPA(Robotic Process Automation)です。いかに同じことの繰り返しをミスなく効率よく行えるようにするかで、システムの品質向上に貢献します。

他業種に飛び込んでいく1人目QAを生業としているヒトは、このような様々な経験をテスト・デバッグ・検証のポジションで身につけられること発揮できることで喜びを得られるヒトが多いのではないでしょうか。

金融のQAエンジニアの面白さ

Finatextは「金融をサービスとして再発明する」ことをミッションとしている企業です。銀行、証券、保険といった様々な金融業界に対して、自社のエンジニアによって多くのプロダクトやソリューションが開発されております。

私はそのなかの1人目QAとしてジョインしました。1つのプロダクトのテストメンバーとしてのテスト計画や設計/実施、E2Eテストの自動化、レビュープロセスの整備、社内勉強会でのQAというポジションや役割の展開などを進めていますが、まだまだやることは多く存在します。同じQAポジションのメンバーも増えてきて、よりQAとしての活躍の場を広げているところです。

上記のマインドセットをもとに日々業務に邁進し、当社が提供するサービスの品質向上を目指しております。

マインドセットとしては以上になります。

「他業種に飛び込んで身近なことを話題にしたQA/QC活動をしたい」

「金融に興味があって、多少のエンジニアリングスキルはあるのだけど何から手を付けてよいかわからない」

「とりあえず金融で新しいことにチャレンジしたい」

そんな事を考えていらっしゃる方、どうぞFinatextでQAエンジニアとして始めてみませんか？

明日は CTO/CISO 田島さんによる「Enabling Teamを立ち上げました」についての記事です。お楽しみに！