#33-プロダクト品質の改善に向けて今取り組んでいること
物流のラストワンマイルをDX化する【207株式会社】がお届けするPodcastの文字起こしnoteです。今回は207のQAエンジニアとして活躍する西田さんに、QAフローの体制、今後のQAチームの展望について伺いました。前回からの続きです。
インタビュアー：207 CTO 福富
インタビュイー：207 QAエンジニア 西田
福富：QAになりたての頃は品質管理をどう回していましたか？
西田：仕様書も作っておらず、当然、仕様が無い状態でテストを書く事も出来なかったことと、スキル的に僕がテスト仕様書をきちんと書けるかというとそうでも無かったので、メンターを採用して頂きました。
いまだに月80時間くらい出向して頂いていますが、その方に色々教わりながら始めていった記憶があります。
福富：たまたま、そのタイミングで副業の募集を出していたところに、某メンターの方から応募を頂いたんです。
西田：とても良いタイミングだった記憶はありますね。その方も実際に配達業務をやった事が無く、仕様書も無いので触ってみながら覚えて頂く形だったので、まず機能を洗い出して、例えば荷物登録機能やマップ連携機能などの機能を全部テストするというフローをとっていった気がします。
福富：メンターの方にも入ってもらいながら、毎週QA定例という定例会議も始まってこれまでPDCAを回してきていると思いますが、QAが発足した2021年2月・3月頃から今に至るまで大きく変わった点はありましたか？
西田：全然ドキュメントに落とし込めていなかったTODOCUサポーター仕様が、どんどん落とし込めて来てからは精度が上がってきていると思います。最初の頃、僕らも知らない仕様があり、そこを見落として本番にバグを出してしまう事があったんですよね。そういう事は減ってきているという印象はあります。
福富：QAのフローややり方がどんどんアップグレードされていく中で、QAをやる前と後で西田さんの中でマインド的に変わった事はありましたか？
西田：そもそもTODOCUサポーターにあまり関わっていなかったので、プロダクトに対する愛は変わりましたね。「TODOCUサポーターを伸ばしたい！」という思いになりました。
TODOCUサポーターは、いち配達員の業務をきちんと効率化してあげて、大きな課題ではなく現時点で配達員さんが悩んでいる事を解決するプロダクトなので、一個バグが出る事でダイレクトに配達員さんの仕事に影響が出ます。そこに対する意識はとても変わったと思います。
以前は「このバグは影響範囲少ないんだから、これくらい良いじゃん」と思っていましたが、今はきちんとQAとして責任をもってバグが出ないように意識して行っています。
福富：いま振り返ると信じられない事ですが、1年前とか少しフリーズしたら「まあタスク切るし再起動したらいいか」が、まかり通ってませんでしたか？（笑）冷静に考えておかしいですからね（笑）
西田：すごくおかしいですよね（笑）そもそもリリースする時にテストを誰もしていなかったですよね。「機能出来上がったんで確認してください」という感じで、すぐリリースしていたので。
「他のところに影響出るかも」と考えるとQAをすることは当たり前なのに、そのままリリースしていたなと（笑）
福富：本当にそうですよね。僕たちは普段から使っているからタスク切りすれば良いと分かるけど、配達員さんが自然とその行動をとれるかというとそんなはずがないので、そう考えるとこの1年半でとても改善したと実感しますね（笑）
日々少しずつ改善しているから気付きづらいですが、たまに1年半前の情景を思い出すと、現在は見えている視野が全然違う気がしています。
西田：確かに全然違いますね。
福富：当時、Androidアプリがバグが多くて壊滅的だったことも大きく改善されましたし、嬉しい事にAndroidユーザーも増えてきていますよね。
西田：そうですね。以前は「動きません」や「写真撮れません」など、そんな事しか問い合わせが来ませんでしたが、いまは僕らが機能を作ってくれていると配達員さんも理解しているので、機能改善要望もどんどん来るようになりましたよね。
福富：本当ですよね（笑）1年半前はそんな感じだったかもしれないですね。
西田：問い合わせが来る度に、皆がぞわっとする感じでした（笑）
福富：最近はポジティブなフィードバックも来るようになっていますしね。とてもありがたいですね。そういえば、QAをやり始めたタイミングでリリースのやり方も変わりましたよね？
西田：そうですね。リリースフローは変わりましたね。
福富：今も更に変えようという話はしていますが、まず今年の2月当初QAが発足したタイミングに、どんな感じでリリースフローを変えたか覚えていますか？
西田：まずQAが出来るまでは、僕と石田という当時ビジネス側を担当したメンバーがいるのですが、2人が配送員さんに聞いた「こういう機能欲しいです」という意見をエンジニアの方にお伝えして、出来上がって動作を確認してOKだったらすぐリリースするフローをとっていました。
なので、回帰テストなどを全くやらない状態で、とりあえず機能が出来たらすぐ本番にリリースする感じでした。それによってどんどんデフレが起きて「あれ、この機能使えなくなってる」ということがすごく増えていたので、リリースフローを整えました。
機能テストが終わった後にリリースするビルド作り、回帰テストまでやりましょう！というフローを入れたのが一番最初の始まりですね。
福富：多分そのタイミングからフィーチャーデバックとリリースデバックという名前が社内に導入されたんですよね？
西田：そうですね！リリースフローを改善する前は出来上がったらすぐリリースしていたのを、フローを変えるタイミングで週次のリリースに変えたんですよね。週次で、A・B・Cという機能が出来上がったらそこできちんと機能テストを終わらせ、それを合わせたA+B+Cというリリースビルドを作り、リリースビルドでQAするというフローを作りましたね。
福富：課題意識としては、当時は機能Aを開発したら、機能Aがきちんと動いているかを確認してOKであればそのままリリースしてしまっていたんですよね？
だから、機能Aを開発した結果元々あった機能がバグを起こしていても気付かずに、本番で初めて問い合わせが来て分かる事が頻発してしまい、これは良くないということで「毎回きちんと回帰テストをしましょう」となり、リリースフローが変わったんですよね。
西田：そうですね。
福富：あれから半年くらい経過して、当時のリリースフローを変えた事による恩恵はありましたか？
西田：とてもあったと思いますね。3月くらいに代表の高柳から福富さんにTODOCUサポーターのPdMが切り替わったタイミングで、機能の見た目をほぼ作り直しましたよね？
あの時、機能の作り替えが大きかったので、リリースフローをきちんと変えていたことで完全に基本機能が出来上がりきったのかなと思っています。
致命的なバグも結局一度も出してはいないと思うので、良い感じでバグを発生させる事無くプロダクトのリニューアルは進んだと思っています。
福富：確かに。この半年で結構大規模な改修をやりましたが、その中で大きな障害無く実現出来たというのは、もしかしたらこのリリースフローを変更していたことが大きかったかもしれないですね。
これだけ大きな恩恵が得られた新しいリリースフローを最近また組み直そうという話が上がっていると思いますが、話が上がってきた背景は何ですか？
西田：僕らとしてはあまり課題意識には感じていませんでしたが、開発チームのエンジニアさんの方から「開発速度を上げたい」という問題意識があり、それを解決する為に週次のリリースではなく、機能が出来上がった毎にリリースする形に変えたいというのが背景です。
それが実現出来たのは、大きな機能をほぼ作り終わっているからです。
今後は細かい機能をどんどん作っていく話になっていくので、やろうとしているリリースフローは機能A+B+Cが出来て一気に週次にリリースするのではなくて、出来上がったものからどんどんリリースして開発速度を上げる方向に変更する予定です。
福富：この話は、開発フローに精通している人でないと少し伝わりづらいかもしれないですね。
西田：そうですね。
福富：僕の方でも認識していた課題感としてあったのは、リリースデバックというフローを用意する事によって全体として整合性が取れているかのテストをきちんと出来る様にはなったのですが、一方で機能A・B・Cのフィーチャーデバックを完了させて、その3つが混ざったものをリリースデバックしたタイミングで、例えば、機能Bの開発が原因で起きたバグが見つかった場合に、一緒に混ざっていたAとCのリリースも遅れてしまうという問題があったんですよね。
なので、エンジニアやプロダクトチーム目線で言うと、それが原因でA・B・C両方とも1週間丸々遅れてしまうことがスピード感からすると「ちょっとペインだよね」という話がありました。A・B・CをそれぞれQAしてOKだったらマージする事が出来ると嬉しいということが、一番の課題意識としてはあった気がしますね。実際、リリースフローを整備する方向で今動いているんですか？
西田：動いてます。エンジニアの柚木がドキュメント化してくれるという話なので、ドキュメント化してくれたものをエンジニアの岸田と若月、僕で確認して、それが問題無ければリリースフローを変えるという話になっています。
福富：これはチャレンジですよね？
西田：そうですね。結局変える事によって回帰テストの手間がとても増えてくるので、QAのリソースを沢山使うことにはなりますが、一応、それと合わせて自動化の動きを進めています。自動化がざっくり9月中には終わるかなと思っているので、問題無くこのリリースフローが遂行出来る様になるかなと思っています。
福富：機能を一つリリースする度に再帰テストも実行する必要があるという事なので、そのままやってしまうとコストが増えますよね。という事はいわゆるE2E（End to End）テストの自動化が必須になってくるという事ですね。
西田：はい、そうですね。
福富：ちなみにこの自動化のツールは何を使うんですか？
西田：Magic Podを今回は使おうと思っています。
福富：これはもうテストは開始していますか？
西田：まだですね。もうそろそろテスト導入すると思います。
福富：これ、個人的にはとても楽しみにしています！
西田：僕も楽しみですね！QAをやりだして半年で自動化出来たら「頑張ったでしょ」と言えるかなと（笑）
福富：確かに。半年前までQA未経験者だったわけですからね。
西田：QAという言葉を知らなかったですからね（笑）
福富：爆速でQAの階段をのぼっていますよね！
西田：そうですね！
福富：あとはこれで本当に再帰テストの自動化が出来て、且つ、先ほどのリリースフローの再設計でスピードも担保出来たら、あざとい事を言わせてもらうといわゆる「Speed with quality」のValuesの実現になりそうですね！
西田：そうですね！
福富：これはPdMの帽子を被った僕としてもとても楽しみにしているので、また進捗があったら是非ご共有よろしくお願いします！
西田：はい！
福富：今日はQA発足からの半年間の歩みについて話させて頂きましたが、例えばこれから半年1年間で、西田さんが207株式会社（以下「207」）でどんな事をやっていきたいかという展望があれば教えてください。
西田：まず、配達員向けアプリTODOCUサポーターの数字をきちんと伸ばしていきたいなと思っていて、配達員さんに使われるアプリNo1には1年以内に出来たら良いなと思っています。
僕は配送の経験もあるので配達員さんの考えが分かりますし、配達員さんと仲良くなることが得意なのでユーザーヒヤリングも出来ると思っています。バグどうこうは関係なく、実際に配達員さんが求めているところもQAから発信出来たら良いなと思っています。
福富：いわゆるプロダクトの肌触りや細かいところに一番気が付くのは、実はQAの目線なのかなと思うところはあるので、守りだけではなく攻めのQAみたいな事も出来るようになっていくと、強いQAチームが出来る気がしますね。
西田：そうですね。QA定例でもお話しさせて頂いていますが、「207のQAチームは配送経験がある」ということを最終的にやりたいなと思っています。QAチームというかプロダクトに関わる方全員ですね。それを文化として作っていきたいと思っています。
福富：それすごく良いですね！配送は楽しいと個人的には思います（笑）
西田：1時間くらいだと楽しいですが、やはり長時間やると大変ですよ（笑）
福富：勿論24時間365日はとても大変でしょうけどね！僕たちと一緒にTODOCUサポーターを改善していける方を絶賛募集中ですので、もしご興味を持たれた方がいらっしゃいましたら、弊社のホームページからご応募頂けるとありがたいと思います。
本日はQAを担当されている西田さんにお越しいただきました。ありがとうございました。
西田：ありがとうございました！
（おわり）
■ お知らせ ■
207株式会社ではPodcastを配信しています。気に入ったらぜひ【フォロー】をお願いいたします！SNSでの感想シェアも大歓迎です。また、採用も絶賛強化中です。気になる方は是非こちら（Wantedly）をご覧ください。