桜の季節が終わり、季節は初夏。
だんだん気温も湿度も高くなってきて、インドア派の自分には厳しい時期が近づいてきました。
すでに自宅のエアコンは除湿モードでフル稼働中。
通勤用に首掛けタイプの扇風機も購入し、なんとか猛暑を乗り切ろうと準備を進めています。
こんにちは！マイベストでQAエンジニアをしているFukutomiです。
2024年2月に入社してはや3ヶ月、ちょうどいい区切りのタイミングでブログ連載企画が始まったこともあり、ここで入社してからの振り返りを書かせていただくことになりました。
RubyKaigiに合わせてやる企画なのにRubyと関係ない話で恐縮ですが、お付き合いいただければと思います。
簡単な自己紹介
改めまして、Fukutomiです。
趣味は食べることとサッカーの自宅観戦で、冒頭でリンクしたSNSでもごはんの写真かサッカーのことばかり話しています。
キャリアとしては、新卒でシステム制作会社に入社しWebエンジニアとして3年半。
その後第三者検証会社に転職してQAエンジニアに転身。
いくつかの事業会社を経て2024年2月にマイベストに入社しました。
社会人経験ぴったり10年、そのうちの6年半をQAエンジニアとして過ごしてきました。
つい先日新卒して働き始めたばかりと思っていたらあっさり10年経っており。。。
時の流れとは早いものですね。
組織の紹介と自分の立ち位置
ここからはマイベストの開発組織と自分の立ち位置について簡単に説明していきます。
現在は「体験」「事業推進」というふたつのミッショングループと組織横断的に改善活動を行うEnablingに分かれており、QAエンジニアはEnablingに所属しています。
後述するとおり、今実際にやっていることは組織横断的な活動が多いので、この体制がマッチしているなと感じています。
（Enablingがどんなことやってるかはこちらをご覧ください！）
マイベストにおけるテストのこれまで
今まで誰がどうやってテスト活動をしていたのか
タイトルにもあるとおり、現時点でマイベストにQAエンジニアは自分しかいません。
じゃあそれまでエンジニアが作ったものは誰がテストしていたかというと、、、
PdMの方がテストをやってくださっていました。ありがたや〜。
ちゃんとテスト仕様書も作られているし、経験則からくるテスト強化ポイントも記載済み！
さらには月1で若手PdMによるリグレッションテストも実施されており、「みんなしっかりしてるなあ〜」と感動まで覚えました。
このように、マイベストにはすでに品質について考える文化は根付いていました。
この文化をどのように進化させていくかがQAエンジニアの腕の見せどころ。
現時点ではみんなが各々のやり方でやっているテストにQAエンジニアとしての知見を注入し、誰がテストをしても抜け漏れなく、適正なテストを実施できるようにすることが自分の使命になります。
マイベストのQAが実現したい世界
実現したい世界
現時点で、マイベストのQAとして実現したい世界（簡単にいうと夢ですね）はこんな感じで定義しています。
- PdMをはじめとしたプロジェクトチームの全メンバーがQAエンジニアと同じ視点を知識として持ち、それをテスト活動に活かすことができている状態
- QAエンジニアはプロジェクトチームの外におり、テスト活動はすべてプロジェクトチーム内で完結している状態（時にレビューやヘルプでQAエンジニアがプロジェクトチーム内の活動に顔を出すこともある）
- QAエンジニアはプロジェクトチームの外におり、E2Eテストの拡充や分析、フロー構築を通じてプロジェクトチームのテスト活動が効率的に回っていくような改善のアクションができている状態
日々のテスト活動はプロジェクトチーム内で完結してもらい、QAエンジニアはプロジェクトチームに入らずEnablingな活動に従事し、困ったことがあれば飛んでいくスタイルってことですね。
なぜそうしたいのか
なぜそうしたいのか、理由は大きく分けて2つになります。
ひとつは、日々変動する開発組織に対して「QAエンジニアを各チームに配置！」とするのが難しいことです。
QAエンジニアをチームの数だけ採用するのは非常に難しいですし、QAエンジニアの数に合わせてチームを構築するのは本末転倒なので、QAエンジニアがいなくてもサイクルが回るような状況を作りたいと考えています。
もうひとつは、テスト活動をチーム全員でできるようにすることでリリースサイクルを早められると考えているからです。
「テスト活動はQAエンジニアの専売特許！」としてしまうと、複数のプロジェクトが立て込んだ時にボトルネックになりがちです。
しかし、チーム全員がQAの知見を持っていれば同様の状況になっても対処できる確率が高まります。
他にも、チーム全員がQAの知見を持っていれば仕様策定の段階でQA目線でのレビューをすることができるので、手戻りも発生しにくく効率よくサイクルを回すことができそうですよね！
実現するためにやっていくこと
テスト設計ガイドをつくる
前述したとおり、今までマイベストのテスト活動はPdMの方が担っていましたが、これからもそれは変わらない予定です。
PdMの方が無理そうだったら、そのチーム内の他のメンバーでカバーするような形をイメージしています。
そして、全員でテスト活動を回していくためには全員が同じようなテストをできるようにしなければなりません。
そのためのガイドドキュメントを作っていきます。
マイベストにおける品質基準をつくる
今のマイベストには「どんな品質を目指すのか」「どんな状態なら品質が良いと言えるのか」というような基準がありません。
それだと、テスト活動のゴールが究極（不具合ゼロを目指す）になってしまう可能性があります。
基準をつくることでテストのゴールが明確になり、テスト設計や実行がやりやすくなり、スピードも上がっていくのではないかと思います。
また、品質基準を作るなら日々の運用の中でそれを満たせているのか測る仕組みも必要になります。
本番で障害が発生した時の対応フローを明確化し、それをデータとして蓄積しながら改善していく活動もやっていく予定です。
E2Eテストを拡充し、安心してリリースできる環境をつくる
マイベストでは毎日複数回のリリースが行われています。
後述しますが、マイベストのコンテンツはいくつもの共通パーツが組み合わされることで構成されており、共通パーツに改修を入れると途端に影響範囲が大きくなります。
だからといって毎回手動でリグレッションテストを実施していたら日が暮れてしまうので、E2Eテストを拡充することでこれをある程度解決できないかと考えています。
やったこと、今やっていること
上記の「やっていくこと」をもとに、この3ヶ月でFukutomiが実際にやったこと、今やっていることをご紹介していきます。
いろんなことに手を出したのでやったことが結構多いうえ、書くのに疲れてきたので箇条書きで書きます。ごめんなさい。
QAエンジニアという職種を知ってもらう会
一連のスライドでいちばん伝えたかったこと
- 一緒にやる人、やった人
- プロダクト開発に関わるメンバー全員
- PdM
- デザイナー
- エンジニア
- プロダクト開発に関わるメンバー全員
- やったこと詳細
- 「QAエンジニアって何する人なん？」の説明と「マイベストのQAエンジニアはこんなことやるぞ！」を宣言するスライドを作り、プロダクト開発に関わる人々に説明
- なぜやるのか？
- マイベストには毎年多くの新卒が入社しており、当然ですが彼・彼女らはQAエンジニアと働いた経験を持っていない
- 中途で入社したメンバーの中にはQAエンジニアと一緒に仕事をしたことがあるメンバーもいるが、現時点でマイベストのQAエンジニアがやることは他会社のそれと結構違う
- やることでどんな効果が得られたか？もしくは得られそうか？
- プロダクト開発に関わるメンバー全員が、マイベストのQAはこんなことするんだ！という認識が揃う
実際にプロダクトチームに入ってQA活動
- 一緒にやる人、やった人
- プロダクトチームで働くみんな
- やったこと詳細
- チームの開発活動にご一緒させていただく
- 全てのチームMTGに参加
- PdMの方が作成したテスト仕様書を一緒に眺める
- 実際にテスト実行をやってみる
- チームの開発活動にご一緒させていただく
- なぜやるのか？
- マイベストというプロダクトの仕様を理解する
- マイベストの開発活動における現状を理解する
- やることがどんな効果が得られたか？もしくは得られそうか？
- マイベストの仕様が（ある程度）理解できた
- 現状のテスト活動の課題もなんとなく見えてきた
テスト仕様書のフォーマットや格納先の整備
- 一緒にやる人、やった人
- PdM
- やったこと詳細
- テスト仕様書のフォーマットを決めた
- テスト仕様書の格納先を決めた
- なぜやるのか？
- これまではPdMが各々の知識でテスト活動を行っており、誰かのテストドキュメントを参照することがなかった
- 開発チームがいくつかに分かれていても、手を入れるのは同じマイベストというプロダクトなので、テストの知見も横展開できるのでは、と考えた
- やることがどんな効果が得られたか？もしくは得られそうか？
- フォーマットを統一すると項目が整理されて見やすくなる
- 格納先を決めることで有事の際に過去のテスト仕様書を探しやすくなる
- 格納先を決めることで他の人が作ったテスト項目を参考にできる
機能リスト作成
- 一緒にやる人、やった人
- PdM
- やったこと詳細
- 以下を表にして可視化する
- マイベストの各コンテンツがどんなパーツを持っているか
- いろんな種類がある商品情報を表示するパーツのそれぞれがどんな情報を表示しているか
- 以下を表にして可視化する
- なぜやるのか？
- マイベストの各コンテンツはいくつも共通パーツが組み合わされることでできており、ひとつの改修が及ぼす影響範囲が大きい
- PdMやエンジニアも全てを把握するのは非常に難しいので、それをパッと見られるようにできたらよさそう、と考えた
- やることがどんな効果が得られたか？もしくは得られそうか？
- テストだけでなく、開発時、設計時にも影響範囲を簡単に理解することができるようになり、抜け漏れがなくなる
Cypress→Playwrightの移行
- 一緒にやる人、やった人
- フロントエンドエンジニアのみんな
- やったこと詳細
- Cypressで実装されているE2EテストをPlaywrightに移行した
- なぜやるのか？
- 利用していたCypressの有償プランでできることのいくつかが、Playwrightなら無償でできる
- 聞くところによるとテストが高速らしく、これから多くのテストを追加していく予定なのでより速いものを利用したかった
- エミュレートできるデバイスの幅が広い
- やることがどんな効果が得られたか？もしくは得られそうか？
- （これからテストを拡充していくなかでいろいろ享受できる予定）
脆弱性診断の段取り
- 一緒にやる人、やった人
- CTO、EM、SREチームのみんな
- やったこと詳細
- 外部業者へのお見積もり依頼に必要な対応事項すべて
- 最初の問い合わせ
- ヒアリングスケジュールの調整
- ヒアリング対応
- お見積もりに必要な資料調達
- NDAの締結
- 診断環境選定
- 外部業者へのお見積もり依頼に必要な対応事項すべて
- なぜやるのか？
- 外部業者を利用した脆弱性診断を実施した経験がなく、セキュリティ関連のリスクが見えていない
- やることがどんな効果が得られたか？もしくは得られそうか？
- 脆弱性が可視化され、対策を打つことができる
- 対策を打つことでお客さまに安心してご利用いただける環境を提供することができる
インシデント対応フローの見直し
- 一緒にやる人、やった人
- CTO、EM、エンジニアのみんな
- やったこと詳細
- 現状のインシデント対応フローを踏襲しつつ、ふわっとしている部分を詳細まで記載し直し、対応フローとして図に起こす
- Zapier等各種ツールを利用して、作業をある程度自動化する
- なぜやるのか？
- インシデント対応フロー自体は以前から定義されているが、運用が徹底されていない状況で、過去のインシデントの履歴が正しく蓄積されていない状況だった
- マイベストが目指す品質を定義する上で、現状を正しく把握できない状況になってしまっている
- やることがどんな効果が得られたか？もしくは得られそうか？
- マイベストが目指す品質を定義する上で必要な情報を定義することができる
- マイベストの品質の現状を可視化することができるようになる
- インシデント対応フロー自体は厳密なものになるが、フローをある程度自動化するのでメンバーが行う作業自体は大きく変わらない形にすることができる
その他の細かい活動
- 一緒にやる人、やった人
- みんな
- やったこと詳細
- 検証端末の準備、運用ルール制定
- Enabling QAの半期の活動予定や目標の策定
- なぜやるのか？
- Fukutomi入社時点では検証端末を会社で保有しておらず、もちろんルールもなかった
- QAエンジニアとしてやりたいこと、やってほしいことがたっくさんあるので、自分のリソースとも相談しながら優先度をつけて行動計画を立てる必要があった
- やることがどんな効果が得られたか？もしくは得られそうか？
- 検証端末の運用ルールが明確になっているので、それに沿って運用していれば、端末は常にコントロールされた状態になる（利用者が分からなくなったりしない）
- この半期で自分がやることが明確になった
気づき、感想
Fukutomi is 超 Super Ultra Lucky Boy
いきなり何言ってんだという感じですが、本当にそう思っています。
前述したとおり、マイベストにはFukutomiが入社する前から品質について考える文化が根付いていました。
これは本当に素晴らしいことです。本当にありがたいことなんです。
この文化が最初から根付いていたので、自分は「なぜQAエンジニアの知見が必要なのか」「品質についてなぜ考える必要があるのか」等々、現場で布教活動をする必要がなく、すんなりと受け入れてもらうことができました。
「やったこと、今やっていること」の項を見ていただければ分かると思いますが、QAエンジニアがやることって、QAエンジニアひとりでは完結できないものばかりなんですよね。
みんな忙しい中で協力のお願いをしたり、会議の予定を入れさせてもらっていますが、快く引き受けてくださりありがたい限りです。
そういった意味で、自分は超ラッキーボーイだと思っています。
不安は拭えない、それでもやるしかない
ここまでめちゃくちゃポジティブな話ばかり書いていますが、まあやっぱり不安もあります。
施策こそいっぱい打っていますが、基本的にすべて長期スパンなもので、現時点では結果が出ていないものばかりです。
だから、今やっていることが本当に正解なのか、実現したい世界の実現につながるかは分からないんですね。
なので不安です。やべ〜
また自分はQAエンジニアですが、それと同時マイベストの社員でもあります。
なので、今やっていることがマイベストのミッションである「インターネットで、“最高の選択体験”を実現する」に繋がっていないと意味がありません。
もちろん一連の施策がプロダクトの使用体験を向上させ、上記ミッションの達成につながると信じていますが、それでも不安は拭えません。
ただまあ、不安だ不安だと床を転がっていても何も始まらないんですよね。
マイベストにひとりめQAエンジニアとして入社することを決めた瞬間に上記の不安が発生することはわかっていたんだから、どんなに不安でも前に進んでいかないと。
幸い今の自分には頼れる優しき仲間たちがいるので、これからもがんばっていきます。
まだまだこれからだ！
結びの段落なのに打ち切り漫画みたいなタイトルでいいのかという感じがしますが、本当にまだまだこれからです。
そもそもまだ会社として若いので急に方針が変わることもあり得ます。
半年後は全く違うことをやってるかもしれません。でもまあ、それも楽しいんですよね。
また機会があればこうやって振り返りブログを書こうかなと思います。
それでは！
マイベストではエンジニア採用を積極的にやってます！（残念ながらQAエンジニアの採用は今やってませんが、、、）
カジュアル面談でも、とりあえず飲みながら話をしよう！でも大丈夫です！
もし気になることがあればお気軽にお声がけください！
株式会社マイベストのテックブログです！ 採用情報はこちら > notion.so/mybestcom/mybest-information-for-Engineers-8beadd9c91ef4dc2b21171d48a4b0c49
Discussion