こんにちは！やまもと＠テスト番長です。今はモノグサでQAマネージャーをしています。
モノグサに参画してから10ヶ月ほど経ちましたので、これまでのチーム立ち上げについて振り返ってみたいと思います。
モノグサは「記憶を日常に。」をミッションとして掲げ、AI学習アプリを提供している会社です。
EdtechのQA事情については、先日公開したエントリをご覧いただけますと幸いです。
モノグサのQAチーム
モノグサのQAチームは2022年に発足しました。最初のQAEが入社したのが1年ほど前のことになります。
それ以前はSWEが実装からリリースまで全ての責任を負っておりましたが、プロダクトが巨大化・複雑化し開発チームの人数も増え、品質を保ち続けるためにQAEの採用が開始されました。
モノグサではQuality Management という部署の中にQAとE2E Test Automationがあり、QAは現在社員3名と業務委託スタッフ2名の体制で稼働しております。
モノグサにjoinして取り組んだこと
さて、モノグサに入ってまず取り組んだことは実情調査でした。Web開発の現場は色々経験してきておりますが、それぞれの現場の状況を知る事なくして正しいアプローチ戦略は立てられません。
最初の1ヶ月はオンボーディングメニュー（会社のルール説明を聞いたり開発環境を作ったり）を受けつつ、ステークホルダーを芋づる式に教えてもらい1on1を設定してペインポイントのヒアリングを実施しました。先に入社していたQAEメンバーからも色々と情報を教えてもらい、その結果、寄せられたお悩みを集約すると概ね以下のようになりました。
- 開発者の不具合対応工数を減らしたい
- QAは開発者個々の裁量に任されており、必ずテストされる仕組みがなく不安
- ビジネスサイドからは開発の進行状況が分かりにくい
それらを受けて当面の方針案を作成することとしました。
開発者の作業負担を減らすためにリリース作業の巻き取りプロジェクトを始めました。Android/iOSアプリは2022年7月時点で巻き取り済みで、WEBとAPIのリリースが新たに対象となりました。システム上の制限とサービスポリシーの観点など調整事項が多かったため、こちらは現在も進行中です。
開発プロセスのドキュメントにQAフェイズを段階的に追加していきました。
リリース前リグレッションの明記
影響の大きな変更では着手前に召集してもらうように記載
インテグレーションテストの実施を明記
結果、以前に比べ大きなトラブルは減ってきたようです。（古参スタッフ談）
現在のQAEの人数でカバーできる範囲は自ずと限られているため、体制を整えながら段階的にQAフェイズを拡充していく方針です。
今後は開発者テストとQAテストのレベル感合わせなど細かいところも詰めていくことにしています。
モノグサではリリース内容を事前に確約することはせず、リリースが終わってから周知するスタイルでずっと運営されています。
リリース内容はQAに回ってきた段階でほぼ確定しているので、可能な範囲でなるべく早くビジネスサイドに通知する運用フローを整備しました。
これによって、以前は散発的に発生していたビジネスサイドからのリリースについての問い合わせは減ってきました。
方針案ではエンジニアの負荷軽減を最大のフォーカスポイントと考えました。モノグサには優秀な開発メンバーが多く、工数的な余裕が生まれれば他の様々な問題も連鎖的に解決しそうだったからです。まだまだ十分には軽減出来ていませんが、今後も継続して推進して行きたいところです。
最終的に2023年内までの体制案とロードマップの形に落とし込み、立ち上がりの対応としてはひと段落しました。
新設されたQAチームがやるべきこととは？
既にサービス展開中のプロダクトチームに後からQAが入った場合どう動くべきか？
当たり前のことが多いですが、今回改めて感じたことを整理してみます。
リグレッションテストがあれば本番環境を最低限正常に動作するようキープすることが出来ます。入社して日が浅くプロダクトの仕様に不慣れなQAチームがシステムの全体像を掴んでいくためにも有効でした。
現在モノグサではリグレッションテストをNotion上で管理しています。かなりライトな管理方法ですが、将来的にE2E自動テスト中心への移行を見越してテスト管理システムなどはあえて入れずにやっています。
QAが新設されたということは品質に何らかの懸念があるわけで、その状況下では開発メンバーに相当負荷がかかっているケースが多いように思います。
不具合対応に費やす工数割合が多いと新規開発はなかなか思ったように進みません。市場不具合を減らしていく努力が必要です。
かといって単純にテストの工程を増やすと更に負担を増やしてしまいかねないので、工数を増やさず手戻りを減らせるように意識してプランニングしました。
また、BtoBのビジネスモデルにおいてリリース時期を予告しないスタイルは、顧客対応の難易度が高くなります。可能な限りの事前共有を行うことで、スムーズなサポートが可能になり開発・ビジネスサイド双方の業務負荷が軽減出来るのではと思っています。
- プロダクトや会社の文化を理解しながらQA文化をデザインする
参画直後はどうしても会社の独自ルールが目につくものです。すぐに色々変えたくなりますが、しかしそれはそれなりの過去の経緯が存在するものなので、改善は慌てずに進めるべきです。
過去の時点の組織においてはそれがベストソリューションだったはず。たとえ標準と乖離していても非難されるべきではないのです。
専任のQAが居なかった頃は検証周りの整備にリソースが割けないため、十分にチェックできる状況が整っていませんでした。
2022年7月時点では、対象OSの幅の広さに対して検証端末の数が少なく、主にエミュレーター上でデバッグすることが多かったようです。
とりあえず最初の3ヶ月で検証端末の台数を倍にしてもらいました。
検証環境のダミーデータも少なく、十分にチェックを行えない状況だったのでQAチームでどんどん作成していきました。
日々の備えがあってこそ、守れる品質の水準が上がります。
モノグサQAは最高に楽しい
モノグサのQAチーム立ち上げ話はいかがだったでしょうか？ここ数年、QAチーム立ち上げや一人QAの情報が多く発信されているようですね。QAの重要性に対する認識が広がってきて活躍の場が増えているのだとしたら、とても良いことだと思います。
モノグサは社員たちのオーナーシップが強く互いにリスペクトする文化があり、働き者が多いです。Valueに「いつでもボードゲームを遊ぶ余裕を持つ」とあるように、いつも誰かしらゲームで遊んでいる人がいる稀有で素敵な会社です。
QAチームの環境だけ見ても、どんなアプローチで品質向上に取り組むかは自由に考えられますし、アプリのリリースタイミングがQA主導であったり、開発者が協力的で検証に困ることがなかったり、かなり働きやすい環境だと思います。
モノグサにおけるQAの取り組みはまだまだこれからですが、今後は更に体制を強化して事業に貢献できるチームになっていきたいと思っています。
QAE絶賛募集中ですので、ご興味のある方はぜひご応募ください！
このブログ記事が何かのご参考になりましたら幸いです。
最後に：
記事は状況説明のために一人視点で書いてありますが、これら立ち上げのあれこれはモノグサのQMチーム全員で実現してきたことですので、メンバーのみなさまにも感謝を述べさせていただきたいと思います。
いつも一緒に働いてくれてありがとうございます！
