note社の全員野球で品質向上活動について #ios_test_tea_time
見出し画像

note社の全員野球で品質向上活動について #ios_test_tea_time

かっくん / iOS Developer

元々は昨年の11月〜12月ぐらいに実施予定だったのですが、延期になり今日開催されることになり、そこで登壇してきました。
登壇内容はnote社内で課題となっていた問題を洗い出し、整理して対応してきたことについての紹介です。
登壇資料はこちら。

組織体制について

現状のざっくりとした組織図を貼ります。

職能軸、目的軸にチームが分かれている
ざっくり組織図

見て気づくこととして、QAやSETなどの品質に関するチームが存在しないことです。
あれ?品質大丈夫?と思われるかもしれません。
正直大丈夫!とは言い切れませんでした。

これまでの品質に関する取り組み

「ユニットテストはなるべく書こうね」ぐらいの意識は浸透していましたが、個人やチームの裁量でばらつきがありました。
ウェブ側のE2Eテストにはmabl、アプリのE2EテストにはMagicPodを採用していました。
ただし、メンテナンスが十分行われていた訳ではなく、テストの失敗に気づいた人がメンテナンスをする程度でした。
機能のリリース前には該当のチームで確認をしていました。

iOSアプリのテスト事情

前述しましたがE2EテストにはMagicPodを利用していました。
新機能系はなるべくテストを追加するようにしていますが、いくらテストを頑張ってもカバレッジが可視化されないデメリットもあるなぁと最近感じています。
ユニットテストはロジックに関するテストはなるべく書くように意識しています。
Viewに関するテストは少し前からSnapshotTestingを導入しています。但し、多すぎると実行時間が長くなってしまうことが懸念なので全ての画面で実行しているわけでは無いです。

マルチモジュールの取り組み

少しずつですがマルチモジュール化も進めています。
今はXcodeGenを利用してターゲットの増減が気軽にできるようにしています。
こちらはテストを高速に回せるのがメリットかなと思います。
本体にコードとテストを追加してしまうと、実行時間が伸びてしまうので、できることならなるべく分けたターゲットでやりたいなと考えています。
しかし、まだまだ本体への依存が強いので切り離せている箇所は限定的です。

品質に対する意識が変化し始めたきっかけ

元々EMである烈さんとの「よもやま行脚 あんぎゃ」と呼ばれる1on1が月に一度ありました。
その中で品質に課題を持っている人や向上させたいという意識がある人が一定数いることがわかってきました。
そこでみんなで話し合ってみましょうということになり品質について課題感を持つ人が集結しました。
QAについて思いを馳せる会が発足されました。後にこの名前はQA委員会と名前を変更します。

miroのスクリーンショット
miroで課題を整理

始まってすぐはmiroを利用して各々が持っていた課題感を言語化し、グループ化しながら今自分達でできることをやりながら進めていました。
そんな中で僕が外部のとある方に相談する機会がありました。

神様の顔が@tarappoさんになっている画像
@tarappo 神

@tarappoさんという品質に関する課題を解決し続けてきた神に相談することにしました。
最初は一緒にランチしましょうという感じだったのですが、後に業務委託として中に入って相談に乗ってもらえるようになりました。

表面化された課題

  • CSからの問い合わせで不具合に気づくことがしばしばある

  • ウェブで複数チームのリリースが同時に被ってしまいリリースの渋滞や不具合が発生した際の切り分けが難しくなっていた

  • テストのスキルや意識が人によってさまざま

  • 何をいつリリースしたのか情報がストックされていない

  • 品質向上の意識を全社に根付かせたい

CSからの問い合わせで不具合に気づくことがしばしばある問題

この件を神に相談したところ「まずは不具合を知るのがどこ経由なのかを計測しましょう」とのアドバイスを頂きました。

@tarappo 神が「まずは計測じゃ」と仰っている
@tarappo 神による助言

計測したいこととして2点が上がってきました。
不具合を見つける箇所がどこ経由が多いのか。ユーザーからの問い合わせなのか、リリース後に自分たちで発見したのか、リリース前のQA中に発覚したのか。そして該当の不具合が本来ならどこで見つからなければいけないのかを振り返りをして、今後の対策を考えていきます。
次に計測したいこととしてコードカバレッジを定期的に観測をしたいという話が出ました。カバレッジが高いからと言って品質が高いとは言えないですが、カバレッジが低いと品質が低いとは言えるためです。
これらの観測したいことについてはそれぞれ過去に登壇したりnoteに書いたので、興味のある方は是非参考にしてみてください。

ウェブで複数チームのリリースが同時に被ってしまいリリースの渋滞や不具合が発生した際の切り分けが難しくなっていた問題

こちらの対応方法として社内向けにリリース予定のカレンダーを作成しました。
これまでもリリース作業自体はChat Opsで自動化されていました。
手軽にリリースができてしまうが故に、複数チームが同じ日に大きなリリースをしようとして渋滞が発生することがありました。
そこでリリース予定カレンダーを入れて予約をしておくことで、リリース日の調整を事前にできるようになりました。
こちらの運用も始まったばかりですが、リリースに関する大きな問題は無くなったように思います。

Google Calendarのスクリーンショット
プロダクトリリースカレンダーの内容例

テストのスキルや意識が人によってさまざまな問題

年末年始の休みを利用して共通の本を読みあう読書会を実施しました。
他社の進んでいる事例を学んだり品質に関する意識をチーム内で醸成できるのでいい取り組みだったと思います。

品質向上の意識を全社に根付かせたい問題

こちらはBug Bashと呼ばれるイベントを実施しました。
先ほどのGoogleのソフトウェアエンジニアリングの中にBug Bashに関する記述があり参考にしました。
時間を決めて参加希望者を募って実施しました。
グループごとに担当機能を振り分けて、10分間打鍵、5分間で不具合の共有、点数の付与を4回実施しました。
良い不具合を見つけたチームには高ポイントが付与され、一番ポイントが高かったチームには賞品が提供されました。
正確な数字はここでは伏せますがたくさんの不具合を発見することができました。
別の方の登壇資料やレポート記事も上がっていますので興味のある方は是非みてください。

何をいつリリースしたのか情報がストックされていない問題

アプリについてはリリースのたびにリリースノートを書いているので割とストックはされていました。
ウェブの方はmasterブランチにマージされることがほぼリリースと同義だったので割と緩い運用になっていました。
そこでリリースブランチを作成し、その中にリリースされるものが一覧化するだけでも最低限は担保できるのでは、という案が採用されて運用が始まりました。
こちらはgit-pr-releaseというツールをGitHub Actionsで利用するようになりました。

まとめ

  • 品質に課題を持っていたり、品質向上をやりたいと思っているメンバーで集まって有志で一緒に品質向上に取り組みを始めました。

  • 現状メンバーは片手間で入っているので課題を一気に倒すことはできないが、仕組みを作って回していくことで少しずつ前進しています。

  • 業務委託で @tarappo さんにも入ってもらって知見を共有していただいており、とても助かっています。

とはいえまだまだ課題は山積みなのでnote社では品質に対して一緒に向上してくれる方を募集中です。
こういう活動に興味のある方、全社的な品質向上に一緒に取り組んでくれる方は是非お声がけください。


この記事が参加している募集

仕事について話そう

この記事が気に入ったら、サポートをしてみませんか?
気軽にクリエイターの支援と、記事のオススメができます!
ぴのこと言います🐱