ROBOT PAYMENT Engineers Blog

株式会社ROBOT PAYMENTのテックブログです

一人目のQAエンジニア

はじめに

みなさん、はじめましてこんにちは!

昨年ROBOT PAYMENT(以下RP)に入社させていただきました、QAエンジニアの妹川(いもかわ)と申します。

前職では第三者検証会社にてQAエンジニアをしておりました。

本日は入社前のRPの印象と入社後に分かったこと、業務内容等についてブログを書かせていただきます。

一人対談形式でお送りさせていただきますので、最後までお付き合いいただけると幸いです。

目次

入社前後

Q.ROBOT PAYMENTに入社したきっかけは?

転職を考えていた際に下記キーワードでQAエンジニアを募集しており、今後QAを伸ばしていきたいという部分で今までの経験をいかせるのでは無いか、と考えた為です。

(また、CTO*1とのオンライン面接時、開始10分で質疑応答に入ってしまったので、あ、落ちたなと思ったのですが面接通過となり、求められている感が強かったです)

  • QAチームをこれから作っていく
  • 品質向上に力を入れていく
  • QA活動を引っ張っていって欲しい
  • 品質基準が無いので判断出来る人がいない
  • IPOを目指している(サービスの将来性)

Q.入社前の印象は入社後に変化がありましたか?

良い意味と悪い意味で、かなり変化はありました。

面談時に下記のように伝えてもらっていたので、エラーが発生した際に自動的に検知する仕組みやテストの自動化、ユニットテスト等既に一定のQA活動はされているイメージでいました。

  • 様々な自動化を行って効率を上げていき、技術的資産を増やしている

が、上記は開発目線での話であって、品質やサポートに関する部分や効果測定のような側面は後回し、優先度は低かったです。

  • 新しい機能をアウトプットすること=正義

作業内容を把握した現在はそのように感じませんが、入社当初はそのように感じました。 

Q.良い意味で印象が変わったこととは何ですか?

入社直後、業務の進め方に対して色々無茶な改善提案を行ったのですが、秒で業務に取り込んで改善していただけました。私の入社前から既に問題を認識/イメージ/やり方も固まっていて、準備も出来ていて私はきっかけを作っただけに感じました。

リリース判定基準が無かった

実際入社してみると、テスト実施後に欠陥が一つでもあったらリリースNG、修正後にリリースするという運用に既になっていました。一つでも欠陥があったらリリース出来ないという基準が、単純にステークホルダーに伝わっていないだけでした。

ユニットテストのカバレッジが想定していたより高かった?

はい。行カバレッジで70%を目標としており、実際の数値も大体70%になっていました。

こちらの詳細に関しては、いつかエンジニア目線で誰かがテックブログを書いてくれる(はず)と思います。

要件レビュー/コードレビュー/テストケースのチェックリストが存在していた?

想定していたよりもきっちりしたチェックリストが存在していました。項目としてもQAが考える項目と相違はありませんでした。

ですが、結果を記載する際に左の列に追加していくのか右の列に追加していくのかも決まっておらず、チェックについても人によってやる人とやらない人に分かれており、運用について統一がされていませんでした。

改善として、リリース時のチェックを厳格に行うように変更し、漏れをなくしました。

f:id:imoimo77:20210122165024p:plain

チェックリスト

入社後の課題感

Q.エンジニアの品質に対する意識が低いと感じていましたか?

入社前の情報だけですとそのように考えていたのですが、不具合に対する初動、原因の特定から修正までの時間は早く、入社直後は杞憂かなと感じました。

徐々に違和感が

上記のように不具合を解決する為の動きは早いのですが、原因の分析や振り返り、情報共有やノウハウを残すといったことを行っておらずその場限りで属人化してしまい、特定のエンジニアにしか対応出来ない機能が多々存在していました。

個人的な考えとして、出来る人は他の人でも対応が出来るようにノウハウを残して共有し、出来る人はどんどん他にも出来ることを増やしていく。チームとして出来ることを増やしていくような動きをしていかないと、色々広がらず改善も継続出来ないのではないかと考えています。

カスタマーサクセス対応について

また、利用企業様からの問い合わせやカスタマーサクセス(以下CS)からの仕様確認/調査依頼に対するエンジニアからの回答が、誰に対する回答なのかステークホルダーを意識出来ていないなと感じました。

利用企業様へはCS経由で回答するのですが、エンジニアからの回答に対してCSから追加の質問や再確認することが多々ありました。

(利用企業様からの情報が少なすぎて、調査が難しい場合が多いのですが・・・)

  • 事実だけ淡々と報告(不具合であっても謙虚さがない)
  • 利用企業様にどのような影響があったのか無かったのか、対応の必要があるのか無いのかの記載が無い
  • 断言出来ずにフワッとした情報を記載してしまう

どのような情報があれば利用企業様/CSが安心するか。の観点で情報を提供出来るよう都度ツッコミをして改善していっており、最近では利用企業様に対してそのまま伝えられるような情報を伝えられているのでは無いかと考えています。

振り返ったり、先々を見据えた改善を継続的に行う文化がなかった

継続的な改善活動の意識が薄かったです。これは今までの請求管理ロボの文化なのだと感じました。

意識を変えないと属人化していってしまい、その人がいないと解決出来ない問題が発生してしまうことがリスクだと認識しました。

こちらは継続的に指摘し続けて、現在ではノウハウを残すような意識にエンジニアがなってきています。 

今までは文化としてそのような活動がなかったからだと考えますが、今後は色々改善していけそうです。

Q.まとめると?

総じて、品質向上に対して意識と課題感は持っているがやり方が分からないだけ、QAの観点で継続して改善提案していければ理解し、改善していっていただける環境/組織/メンバーだと感じました。

実際の作業内容

Q.入社後の作業内容を教えてください

実際に全てについて私が手を動かしている訳ではありませんが、以下のようなことを行っています。

  • バグ分析
  • バグの見える化
  • 業務フロー/インシデント報告フローの整備
  • CS対応改善
  • 運用系のタスク標準化の推進
  • スプリントレビューでの要件定義レビュー
  • QAの啓蒙活動(勉強会、イベントでのLT)

Q.Autify導入時の記事を拝見したのですが、Autify導入に関してはどのような関わり方をされたんですか?

入社時には既に導入済み、山下という優秀なエンジニアがいてテストシナリオもテストスケジュールも作ってもらっていましたので、Slackへテストシナリオの実行結果を通知するようにしました。

- そ、それだけなんですか?それは身体見切れ*2ますね。。。

今後について

Q.今後のQA活動予定について教えてください

QAエンジニアとして、会社の全アウトプットに対して責任を持つことを目標に日々QA活動を進めて行きます。

加えて、現時点では3つのサービスのうち請求管理ロボにしか関われていないので、徐々に守備範囲を広げて顔を出して行きます。

  • 決済サービス
  • 請求管理ロボ
  • 請求管理ロボ for Salesforce

Q.個人としての目標はありますか?

お金に関わるサービスとして、たった1バイトであっても欠陥が混入した場合、混入した場所によっては大きな問題になると考えている為、継続して厳しい観点で品質改善を推進していきます。

また、社内イベントRP Tech NightのCTOのLTでありました下記名言に関しては心に刻んで周りにも啓蒙していきます。

失敗を恐れずチャレンジし続ける
  • 個人が失敗しても、会社が潰れる訳ではない
  • 失敗という経験は、後になって実になっていると気づく
  • チャレンジすることで新しい価値が生まれる

We are hiring!!

絶賛仲間募集中です。

*1:CTO和賀さん

*2:枠に収まっていない方の