ごあいさつ
こんにちは！マイベストでQAエンジニアをしているFukutomiです。
2024年2月に入社して半年が経過しました。
前回のブログから仕事の内容も大きく変わりまして、ここ最近はタイトルの通り「マイベスト みんなでお買い物サポートクラブ（略してみんサポ）」のQAエンジニアとして活動していました。
このたびみんサポがひととおりのリリースを終え、利用開始となりましたのでQA活動を振り返ってみたいと思います。
みんサポとは
みんサポとは、 マイベストとユーザーが一体となって、みんなの日々のお買い物を支援するプログラムです。 現在提供している機能として、クチコミ投稿とアンケート回答によってポイントを獲得できます。詳しくはこちらをご覧ください。
プロジェクト体制とQAの立ち位置
みんサポというプロダクトについてご紹介したところで、ここからはプロジェクトの体制やQAエンジニアの立ち位置について簡単に説明していきます。
体制
大まかな体制は下記の図のとおりです。
今回はチームという形で分かれて開発を進めていましたが、QAエンジニアは自分ひとりしかいないのでチーム横断メンバーとして活動しました。
引用：なおぱーさんのブログ
プロジェクト全体のタイムライン
プロジェクト全体のざっくりとしたタイムラインはこんな感じでした（詳細はなおぱーさんのブログもご覧ください）。
引用：なおぱーさんのブログ
なお、QAはタイムライン上で言う 「怒涛の開発」が終わった時点でプロジェクトから離れています。
元々自分はEnablingの一員として入社したのもあり、リリースを終えた時点で離れる予定でした。
なのでこの投稿でフォーカスを当てるのは基本的に怒涛の開発が終わる7月中旬までとなります。
QAの立ち位置
完全なる新機能、3つのチームに分かれて開発、タイトなスケジュール、QAエンジニアはひとり。。。
ぼんやりしていたら炎上すること必至なので、下記の感じでQAのプロジェクトとの関わり方を決めました。
早い段階で結合テスト実行は各チームにお任せするという判断ができたことで、他のQAタスクや脆弱性診断対応などもなんとかスケジュールに影響を与えることなく進めることができました。
受け入れてくれたPdMのみんなに感謝ですね！
QA活動のタイムライン
プロジェクト期間中のQAの動きです。テスト設計以外にも検証端末の準備など細かいQAタスクも担当しました。
また直接プロジェクトとは関連していないもののマイベストへの脆弱性診断も並行して進めており、診断業者との打ち合わせや見積もり確認などもほぼひとりで対応していたのでだいぶバタバタしていました。
実際のところ、どうだったのか結果を見てみる
とまあこんな感じで活動し、なんとか予定より1週間遅れの7/16に社内リリースまで完了しました。
ここからは開発期間中の出来事およびテスト結果をもとに振り返りをしてみます。
テスト結果
期間中みんなでにらめっこしたテストのダッシュボード。残ケースが0じゃないのが絶妙に生々しい
テスト実施に関する混乱は発生しなかった
先述のとおり結合テスト実行は各チームのPdMにお願いしていたのですが、特に混乱なくスムーズにテスト実行を進めることができました。
もちろん、普段からPdMの方にテストをお願いしているので慣れていたというのはあると思いますが、今回はFukutomiが作ったテストケースを実施してもらう形になったので少し勝手は違ったはずです。
PdMのみんなの柔軟さに感謝ですね！
テスト期間中に致命的な不具合はほぼ出なかった
これはもう奇跡に近いと言って差し支えないと思うのですが、これだけバタバタしたプロジェクトでありながらテスト期間中に致命的な不具合はほぼ起きませんでした。
もちろん不具合自体は何件も出たのですが、テスト実行の妨げになるようなものはなく、非常にスムーズにテスト実行を進めることができました。
スケジュール
大きな遅延なく社内リリースまでこぎつけた
その結果もあり、社内リリースは当初スケジュールから1週間遅れの7/16に社内リリースを完了しました。
「1週間遅れてんじゃん」と思う方もいらっしゃるかもしれませんが、経験上ここまでの緊急プロジェクトを1週間程度の遅れで済ませられたのは快挙と言ってもいいのではないかと思います。いやあ、よくがんばった。。。
ただし、一般ユーザーへの導線開放までは+1ヶ月かかった
社内リリースまでは非常にスムーズだったものの、残念ながらすぐに一般開放とはなりませんでした。
みんサポのリリースが原因でパフォーマンスが落ちてしまう事象があり、それを解決してからの開放となりました。
事前に検知できなかったことは痛恨の極み、、、！
総合的には
それでも、総合的にはうまくやれたと言えそう
それでも当初の計画を思えば、みんサポ開発プロジェクトは総合的にはうまくいったと言えそうです。
リリース後もパフォーマンス以外で大きな不具合はなく、パフォーマンスの問題も一般開放前に気づくことができました。
下手すれば今ブログを書いているこの時間もまだテストをしていたかもしれません。。。
プロジェクトの振り返り
と、まあ事前に「このままでは爆発炎上では。。。？」みたいな感じだった割にはスムーズに社内リリースまでもっていくことができました。
ここからはプロジェクトを終えてみての所感と振り返りを行っていきます。
よかったところ
この項では「なんでうまくいったんだっけ」を考える上で「こうやったの、実は良かったのでは、、、？」みたいなポイントちょっと考えてみます。
すべてのチームの定例MTGにできる限り出てコミュニケーションを取りやすくした
毎日めっちゃ朝会に出ていた
すべてのチームの朝会や振り返り等のMTGにできる限り出席するようにしていました。
チームによってはMTGの時間帯が被っていたりしたので、本当に全MTGに出れていたわけではありませんが、それでもほとんど出席していたと思います。
前のブログでも少しだけ触れましたが、今のマイベストにはQAエンジニアと協業した経験を持つメンバーが多くありません。
「仕様が決まったり、変わったりしたときはFukutomiにもメンション飛ばしてね〜」とは言いつつも、忙しい中で忘れられちゃったりすることもあります。
最初から定例MTGに顔出しておけばそれ、発生しにくくなるじゃん！ということで出席することを決めました。
情報共有的にもとてもよかったのですが、個人的には定期的にみんなと他愛のない話をすることでリラックスできたり、なんとなく同じチームであるという一体感（厳密には同じチームではないんだけど）を持つことができたり、気持ち的に多くのメリットを感じることができました。
テストにまつわるドキュメントを1つにまとめた
すべての情報が集約された渾身のスプレッドシート
テスト項目のスプレッドシートにテスト方針や検証端末、テストアカウント情報まですべてをひとつのスプレッドシートに集約して管理するようにしました。
そうすることで「テストについてはここを見ておけば大丈夫」な状態を作ることができ、資料が見つからずに迷子になる人を発生させずに済みました。
PdMへの引き継ぎをスムーズにできた
先述のとおり結合テスト実行はすべてをPdMにお任せし、スムーズに進めることができました。
これによりFukutomiのリソースに余裕ができ、他の作業も遅延なく完了に持っていくことができました。
もちろんPdMのみんなが慣れていたというのは大きいのですが、こちらの引き継ぎ準備もいい感じにできたのではないかと思っています。引き継ぎとして行ったことはこちらです。
- 引き継ぎとしてやったこと
- テストケース読み合わせ（テスト設計レビューでもある
- お任せしたいことの説明
- 結合テスト実行
- 不具合起票
- 不具合の優先度に沿った修正対応のディレクション
- 仕様変更に伴うテストケースの修正
- QAが用意した基準に沿ってほしい部分の説明
- テスト実行の優先度
- 不具合起票時の優先度
ある程度の基準を準備することで実行者にはスムーズに作業を進めてもらえるのですが、どうしても現場判断が必要な部分も多く、そちらはかなりの部分をPdMメンバーにお任せしました。
落ち着いたタイミングでPdMの方にこの辺の塩梅はどうだったか聞いてみたのですが、概ね好評をいただけました。うれしかったです。
もう少し上手くやれたと感じるところ
もちろんよかった部分ばかりではなく、振り返ってみるともうちょっとうまくやれたな〜と思う部分もありました。
パフォーマンス低下に気づくことができなかった
これは痛恨です。なぜ気づけなかったのか。。。
ただし現状のマイベストには本番同等のスペックを持つテスト環境はないので、リリース前に気づくのはそりゃ難しいよなという感じもします。
パフォーマンス低下はユーザー体験を大きく損なうことになるので、今後こういったことにならないための対策をちゃんとしないとですね。
GoogleスプレッドシートじゃなくてNotionでドキュメントをまとめればよかったかもしれない
結局Slackでの不具合報告にスクショを貼ってもらって、スプレッドシート上ではそのリンクを記載することに
今回はスケジュールがタイトということもあり、フォーマットの類はすべてFukutomiのやりやすさ重視で作ったのですが、それでGoogleスプレッドシートを使ったのはちょっとだけ失敗だったかもしれません。
スプレッドシートはとても柔軟で使いやすいのですが、不具合のエビデンス画像を貼りたいけどやりづらいな、、、と感じるシーンがありました（貼り付け自体は難しくないけど、不具合管理シートで管理しようとすると画像サイズを小さくせねばならず、別シートで管理しようとすると紐付けが難しい）。
こちらは最初からNotionDBで集約していれば起きなかった問題なので、発覚した時はちょっと悔しかったですね。
これからの改善点
Problemをそのままにしておくわけにはいかないので、これから改善施策をやっていきます！
毎日やっている負荷テストと同じタイミングでサイトスピードを計測する
マイベストでは毎日負荷テストを実施しているのですが、その環境を利用してサイトスピードの確認を実装しようとしています。
負荷テスト環境であればスペックも本番と同等のものなので、信頼できる結果を得られそうです。
テストケースはNotionDBに集約していく
PdMの方ともいろいろ話をして、これからテストケースはNotionDBでまとめていこうということになりました。
もちろん画像の扱いやすさというのもあるのですが、テストケースを溜めていくという意味でもNotionDBのほうがやりやすいし、元々PdMの方がつくるドキュメントはNotionで管理されているので情報集約にもなります。
俺たちのみんサポはこれからだ！
プロジェクトが険しいものだったのもあり、気持ち的にはひと段落していますが、みんサポはまだまだ始まったばかり。
これからもスピードを落とさずに機能を追加して、みなさまの「最高の選択体験」を実現すべく走り続けていきます。
自分はEnablingをメインで担当するものとして、開発スピードが落ちることなくより品質のいいプロダクトを届けられるよう頑張っていきます！
それではまたどこかで！
株式会社マイベストのテックブログです！ 採用情報はこちら > notion.so/mybestcom/mybest-information-for-Engineers-8beadd9c91ef4dc2b21171d48a4b0c49
Discussion