みなさん、こんにちは あるいは こんばんは。
エンペイ1人目QAとして4月に入社いたしました
鈴木達也(@The_Tock_T)です。
みんなからは、「T」と呼ばれています。
弊社はコードネーム的なあだ名で呼び合う文化はないですが、親しみ込めてそう呼んでもらっています。
念の為断っておくと、「Tatsuya」の「T」です。「たそがれ」🕵️の「T」ではございません。
期待させるようなことを言ってすみません。
さて、皆さまご承知の通り、エンペイと言えばCTOがエンジニアやデザイナーの採用で苦労していたことで有名ですね。
こんな疑問を抱きませんでしたか?
「QAエンジニアの採用をテーマにしたCTOのブログがないぞ?」
「デザイナーと同じくらい市場にいないぞ?」
そんな中でポンとCTOの前に現れ、QAエンジニア採用問題を解決したのが私です。
(その正体はリファラル採用なのだが)
まずはそんな私の簡単な自己紹介をさせていただき、エンペイ入社後に取り組んできたことについてご紹介させていただきます。よろしくお願いいたします!
なお、このブログは読み終わると自動的に消去されます。🕵️
なんてことはないので、何度も読み返してください。
目次
- この記事のゴール
- 結論
- 自己紹介
- QAエンジニアについて
- エンペイにおけるQAエンジニア
- 入社後の取り組みについて
- 1.「QA」についての「勉強会」を行った
- 2.「リグレッションテスト」の「自動化」を行った
- 3.「シフトライト」施策を行った
- 最後に
この記事のゴール
- エンペイのQAエンジニアの活動について知ってもらうこと
- 1人目QAエンジニアとしてチャレンジしたい、している人にこの事例を知ってもらうこと
- エンペイをちょっと好きになってもらうこと
結論
先に取り組んだことについて、まとめます!(目次でネタバレ済み)
大きくやったことはこの3つです!
- 「QA」についての勉強会を行った
- リグレッションテストの自動化を行った
- 「シフトライト」施策を行った
自己紹介
それでは改めて自己紹介を致します。
- 名前
- T|鈴木達也
- 経歴
- 大手テストベンダー|品質保証エンジニア|6年
- プロジェクトリーダー(PL)|テスト計画立案、テスト設計、テスト実行、マネジメント
- エンペイ入社経緯
- 一緒に仕事をしたことのある Tech Lead 木村からエンペイを紹介される
- エンペイのプロダクトへの共感、CTO田野がいい人、CEO森脇を応援したいと思った
- やりたいことができそうだと思った
- 毎日の楽しみ
- slackに愛犬の画像を貼る
QAエンジニアについて
そもそもQAエンジニアについてあまりご存じない方もいらっしゃると思うので、簡単にご紹介します。
QAとはQuality Assurance(品質保証)を意味します。つまり、品質保証を担うエンジニアです。
そんなQAエンジニアを一言で言い表すと
「影なき英雄」
と言えるかもしれません。🕵️
私たちQAエンジニアの活躍が日の目を見ることはない。🕵️
だがそれでも、私たちQAエンジニアの上に人々の日常が成り立っていることをは忘れるな。🕵️
要は、アプリケーションサービスをより安心・便利に利用いただくため、
QAエンジニアは品質保証のお仕事をしています。
では、より具体的にQAエンジニアと呼ばれる職種について説明していきます。
これはQM(Quality Management)ファンネルを元にした内容です。
- TE(Test Engineer)
- テストを考える人、価値重視のテストする人
- SET(Software Engineer in Test)
- 開発、テストに関わることを自動化する人
- QAE(Quality Assurance Engineer)
- 品質向上について考える人、みんなをよくする人
エンペイにおけるQAエンジニア
TE、SET、QAE 3者それぞれの役割が求められています
とりわけ私が得意とする部分や、働く上で大切にしていることは、TEとしてのマインドです。
具体的に言うと、これからリリースする機能や改修がお客様にとって価値があるものなのかといった考え方を持ってテストをすることです。
私はそれができる環境がエンペイにあると思ってこの会社に入り、実際にそういった業務が行えています。
SETやQAEとしての側面を活動も含め、後述の本題である入社後の取り込むについて詳しく紹介させていただきます。
入社後の取り組みについて
1.「QA」についての「勉強会」を行った
まず、私が入社する以前のエンペイでは、市場バグの発生が重なり、品質に課題を感じ
テストベンダーに業務委託を依頼をしていました。
そういった背景の中で当時の状況はというと、2つのギャップが存在していました。
- 組織カルチャーの違いによるコミュニケーションのギャップ
- 期待したい品質向上施策のギャップ
いわばこの状況は、開発とQAがまさに東西に分断された状況でした。🕵️
具体的に言うと、あくまでテストを実行する立場としてQAエンジニアが存在していました。
当然それは望んでいる状態ではありませんでした。
そこでCTOはさらなる品質向上のための作戦〈オペレーション QA〉として、
QAエンジニアの採用へと舵を切ります。
そして前述の通り私が入社する運びとなります。
今次作戦が東西の・・・引いてはプロダクトの品質を守る鍵となる🕵️
その役目を託されました。
実際に私が入社して感じたことは、
- 「QA」と言う言葉の意味
- 「QAエンジニア」は何をしてくれる人なのか
- 「QAエンジニア」には何を期待できるのか
などがチームの共通認識として存在していない
という課題です。
そこで以下の目的を掲げて「QA説明会」と銘打って勉強会を行いました。
目的
- エンペイにおける今後のQAが行う活動施策について全員に理解してもらう
- QA、QAエンジニアについての意味や活動、期待できることをすり合わせをすることでそれらの認識の齟齬をなくし、円滑なコミュニケーションが行えるようになる
話したい内容は全てnotion1ページにまとめました。
その時のアジェンダとざっくりとした内容について共有いたします。
アジェンダ
- 目的と背景
- QAについて
- QA=テストではないこと。QAとは品質保証活動全てを指す。
- テストはQA活動の一環で非常に重要。常に誰もがテストすべし。みんなでやろう。
- いい品質保証活動を見つけたら「ナイスQA」を送ろう。
- 品質について
- バグがない≠品質がいい。
- 私の思う品質とは製品、サービスに関わる誰かにとっての価値であるとした。
- 価値が届けられてこその品質。みんなで考えよう。
- Tこと鈴木達也について
- 経歴
- 強みと弱み
- エンペイにおけるQAについて
- QMファンネルを用いて求められている姿を示した。
- その上で自分がどのような活動をしていくか伝えた。
- QAポリシー
- 「一丸品質」と言う合言葉を作った!スタンプも作ってみんなで使おう!
- 直近の施策について
- 具体的にいつくらいからこう言う活動をするよと言う内容を伝えた。
- クイズ、質疑応答
このような内容でDevs、CS、デザイナーを全員集めて行いました。発表の最後に、発表内容から作った理解度確認クイズ(通称:人間品質テスト笑)があるよ!
とコンテンツを用意したことで、最後まで楽しんでもらえたと思います。
開催後の反応はというと
ナイスQAスタンプを:ナイス_qa:で登録してしまったがためにUX品質についてのフィードバックをいただけました。
早速「一丸品質」が発揮されてますね!
そして、中島さん「ナイスQA」でした。
私はこの後、:nice_qa:のエイリアスを追加しました。
2.「リグレッションテスト」の「自動化」を行った
私は開発の経験がありません。
それを踏まえた上でCTOから面接時にこのようなお願いをされてました。
CTO
「君の使命は開発組織に入って品質向上することだ」
「そのためにはまず、スルーテストと呼んでいるE2Eテストをツールを使って自動化してくれ」
T
ズバブーッ!(コーヒーを新聞に吹きかける音)🕵️
(いいだろう・・・例え開発経験がなくても自動化をやりきってみせる)🕵️
(全てはより良き世界のために・・・!!)🕵️
といったやりとりがあり、私は入社後にツールの選定から始めました。
まず選定するツールとして候補に上がったのが
この2つのツールに絞った理由としては2点ありました。
- ノーコードのツールであること
- サポートが日本語に対応しているツールであること
スパイではないため、恥ずかしながら英語は苦手なQAエンジニアでした。
2社とも無料でトライアルが行えるため、それぞれ実際に利用しました。
トライアルを通して確認していた内容としては
- 操作性
- サポート
- やりたいテストが組めるか
の3点を重点的に検証しました。
そして、両者と商談を重ね、費用感も確認しました。
「ここに決めます」🕵️
選定の結果、弊社は「MagicPod」の導入を決めました。
上記3点のポイントにおいて非常に甲乙つけ難かったです。
どちらがより優れている、というよりかは私やエンペイのフェーズにあっていると感じたサービスを選びました。
それが「MagicPod」でした。
私が「MagicPod」を選んだ決め手としては、より「ノーコード」と言える点です。
開発言語の知識は本当に必要ありません。
非ソフトウェアエンジニアの私でも確かに自動テストを組むことができました。
とはいえテスト対象の抽出や、やりたいテストの実装に困るときもありますが、その際は気軽に問い合わせも行えて、的確に回答を返していただいております。いつも助かっています。
そのおかげもあって、エンペイでは自動化可能な領域のテスト自動化を行うことができています。
また、自動化が進んだおかげで、私はより機能の価値に向き合ったテストをする時間が確保することができています。
さらには仕様レビューやデザインレビューからどんどん入っていくことができ、シフトレフトも推進することができています。
余談ですがMagicPod社はエンペイとどこか似ているような雰囲気があると思っています。
それは、働く人たちの人の良さが出ているところ、子育てを頑張ってる人が多いところです。
きっとこの記事もMagicPod社広報の田上さん(@TagamiJunko)がたくさん広めてくれると思っております。いつもありがとうございます。
3.「シフトライト」施策を行った
QAエンジニアであったり、QAについてお調べになられている方からすると、
「シフトライト?たいてい1人目QAが行うのってシフトレフトじゃないの?」
「おいおい、お前はQAエンジニアを語るモグリか、否、スパイか?」🕵️
そんな声が聞こえてきます。
いえ、そうではありません。当然シフトレフトも行っています。
ではなぜシフトライトに触れるのか。そういった事例を聞いたことがないからです!(私調べ)
そもそもシフトレフトとは何か
開発プロセスのどのタイミングでもテストを行なうことで、バグの作り込みを防ぐことを目的とした品質保証活動です。
例えば、
- 仕様レビュー
- デザインレビュー
- ユニットテスト
などが挙げられます。
では、シフトライトとは何か
リリース後も継続的に行われる品質保証活動です。
価値を追求していく上でいくら手前側でバグを見つけたり、仕様の抜け漏れを見つけられたとしても、継続的にお客様に使って頂かなければ意味がありません。
シフトライトで行われる主な活動は
- 効果計測
- フィードバック収集
などが挙げられます。
私はそれ以外にもQAエンジニアが関われるサービスの品質向上があると考えました。
それは問い合わせ対応です。
問い合わせ対応もエンペイが提供するサービスの一部であり、
そのユーザー体験を向上させることができればそれは品質向上に直結します。
そこで私はまず、CSとの連携が必要不可欠であると思い、CSの方々全員と1on1を行いました。
弊社CSについて
そして私はCSの皆さんと一緒に、まずは以下のシフトライト活動を行なっています。
- FAQでの問題解決率向上施策
- CSへの新機能勉強会の実施
- Salesの営業へ同行
このレフト・ライトはリリースを起点に語れることが多いです。
でもその実は一方通行ではなくサイクルとなっています。つまり、左にずっと進もうが右にずっと進もうが行き着く場所は一緒なのです。
そしてこの活動を通してDevs以外のCS、Salesといった他部署とのコミュニケーションも増え、
さらにはシフトレフトを行なっていく上でも活かせるさまざまな学びが得られました。
それについては私の次回作成予定記事でその事例を紹介させてください。Tの次回作をお楽しみ。
次回作
スタートアップの1人目QAエンジニアがシフトライトしたら
非エンジニアにめちゃくちゃ感謝された件〜また俺なんかやっちゃいました?〜(仮)
最後に
いかがだったでしょうか。
エンペイのQAエンジニアが何をしているのか知っていただくことができたでしょうか。
これから1人目QAエンジニアとして働く人、あるいは今現在ご活躍されているQAエンジニアの皆様にとって役に立つ情報となったでしょうか。
そして、エンペイを少し好きになってもらえたでしょうか。
私はこの記事を最後まで読んでくれた人、全員好きです。
こんな時になんですが・・・一緒に働きませんか?🕵️
エンペイでは、PdM、エンジニア、デザイナーetc...まだまだたくさん採用中です。
まずはお気軽に、私の好きなCTO田野とのカジュアル面談もどうぞ!
お子さまやご自身が通われている、学校や習い事の集金キャッシュレス化されたい方はぜひこちらからリクエストをください!