こんにちは。QAエンジニアをしているtoyopiです。
フリー以外のサービスと連携するプロダクトの一員としてQAをしています。
freee QA Advent Calendar2024 17日目です。
去年に引き続きアドベントカレンダーを執筆しております!!
はじめに
約1年前、私は今の開発チームに配属されました。
悲しいことに、このチームは社内で1、2位を争うほど障害（※）が多いチームです…。
このチームが開発するプロダクトで起きる障害の中には、外部連携先に依存する原因もありなかなか一筋縄ではいかない現状です。
そうは言っても、ユーザーにとってはバグがあることには変わりないので、対応していかなければならないという難しさがあります。
そんな障害が多いチームで、約1年間QAをやっている私の取り組みを、課題とアクションとともにご紹介していこうと思います。
※「障害」は重篤度が高い事象がリリース後に発生することを指します。
Action1: 重篤度早見表の導入
背景と課題
freeeでは重篤度という概念が存在します。重篤度とはなんぞや。の説明は割愛しますが詳しく知りたい方はymtyさんの記事を参考にしてください。
社内ではよく使われる重篤度ですがfreeeでは4つのレベルが定義してありそのレベルに当てはまる事象を各チームで定義しています。
私たちのチームでは重篤度はスプレッドシートで管理しています。
重篤度の定義表の一部の列について説明すると、重篤度の列には4段階のうちどのレベルかを示し、事象の列には抽象的な障害の事象を、具体的な例の列には過去の障害の例やそのドキュメントのリンクを記載しています。
例えば、重篤度がCriticalの中には、事象としてチームが開発する領域のシステムの全面停止があり、具体的な例にすべての連携先と連携することができない、といったものがあります。
そんな重篤度表ですが、今年の春に全社一斉重篤度見直し活動があり、私たちのチームも見直しを行いました。
重篤度を見直す過程で、PMやエンジニアの方にいろいろ意見を聞いた結果、いくつか課題があることに気づきました。
課題1
同じ事象でもfreee起因、外部起因があり同じレベルで重篤度を判断すると過剰に障害とみなしてしまう傾向があった
課題2
チームに参画して日が浅い人や知識が浅い人には重篤度表に記載の内容から判断するのが難しかった
課題に対するAction
起きている事象からなぞるだけで重篤度が判断できるようにフローチャートを作成しました!!
例えば連携先と連携できないという事象であれば、すべての連携先と連携ができないですか？という分岐がありYESの場合はCritical、NOの場合はMajorというフローチャートにしています。
早見表作成後と今後について
有難いことに一部の方からは便利とのお声をいただいています。
ただ改善点は沢山あります。
不完全なところもありまだまだ完璧にはこのフローチャートだけでは判断ができません。
また障害対応フローに組み込めていないので使い所を定められていません。
障害が多いチームとして障害に対する重篤度判断の質もあげることも大事なので、今後は少しずつ改善していきたいです。
Action2: チーム内QAオフサイトの開催
背景と課題
QAチームでは定期的にQAオフサイトを開催しています。オフサイトでは毎回テーマを決めて開催しており、ここでは説明は割愛しますが、直近で行われたQAオフサイトでは障害がテーマでした。
私はこのオフサイトに参加して、チームの障害にもっと関わっていかなきゃなと強く思いました。そう思える、とても良いオフサイトでした。
ただ、残念なことにこのオフサイトには社員しか参加することができず、業務委託さんは参加していません。
私が所属するQAチームは、社員よりも業務委託さんの方が多い状況です。
そこで、オフサイトで障害に向き合わなきゃと思った感覚を業務委託さんにも感じてもらいたいと思うようになり、私が所属するチームのQAだけのQAオフサイトを開催することにしました。
私が所属するチームは社内でも障害が多いため、障害にフォーカスしていくぞ！とQAチームが目標とした今がナイスタイミングなのではないかと思ったのも、開催に至った理由でした。
課題に対するAction
まず、自分ごとにするためにはどうしたらいいんだろうと考えました。
そこで思いついたのが、見えている課題から自分たちで目標と具体的なアクションを決めることでした。
ただ振られるタスクよりも、自分たちで考えた目標のために行うタスクのほうが、モチベーションが上がるかなと考えました。
そんな思いを込めたQAオフサイトの目的を、「freee QAが目指す姿の理解」と「目指す姿に近づくために必要なスキルや知識の理解」とし、ゴールは私たち自身がfreee QAが目指す姿に近づくための目標を設定することにしました。
そしてオフサイトは、「理解フェーズ」と「目標を立てるワークショップフェーズ」の2部構成で開催しました。
理解フェーズでは、QAの船長（部長）であるdnさんも巻き込み、直近でQAがフォーカスすることの説明をしてもらいました。
私が説明するよりも、QAの方針を決めてくれた部長にお願いすることで、より言葉の重みが出ると思い巻き込みました。
ワークショップフェーズではチームに分かれてFigmaを使って、課題に対するKeep（これからも続けていきたいこと）、Problem（できていないこと、課題）を出し、そこからTRY（課題に対する具体的なAction）を考えるという流れで進めました。
そしてオフサイトで決定した私たちの1年以内の目標がこちらです!!
いくつかの課題の中からメンバー全員で考えて設定した目標なので、自分ごととして考えられる目標になったのではないかと思います。
オフサイトを終えて
オフサイト自体は開催してよかったなと思いました。
参加してくれたQAメンバーからの感想を一部紹介します。
今後は立てた目標が実行できるように、皆で決めたアクションを実施するフェーズに移っていきたいと考えています。
Action3: 外部連携先のリニューアル対応の開発フロー整備
背景と課題
外部連携先のリニューアルが定期的に発生するのですが、その度にチームとしてはシステム改修が入ります。
チームの中ではリニューアル対応と呼ばれるのですが、もともとリニューアル対応起因での障害がちらほら発生していましたが、今年の夏に立て続けに障害が発生しました。
障害の振り返りをした結果、開発フローを整備することで防げたのではないかと思われる原因が多かったので、エンジニアとQAで協力しリニューアル対応の開発フロー整備に取り組み始めました。
課題に対するAction
まずリニューアル対応について、これまでQAは関わりがなかったので、まずはエンジニアにヒアリングすることから始めました。
ヒアリングをしてまず分かったことは、リニューアル対応にはさまざまな規模があることでした。また、その規模が大きくなればなるほど障害になる可能性が高いことも分かりました。
そこでみんなで話し合った結果、ざっくり以下の方針で進めることになりました。
対応するリニューアルの規模、つまり対応工数で段階を分ける
段階に関係なく、リニューアル対応の基本開発フローも作る
段階に応じて開発フローの中で、これはやる・やらないも決める
このうち、現在は2まで着手ができているので、その一部をご紹介します。
まずは「1. 対応するリニューアルの規模、つまり対応工数で段階を分ける」ですが、こちらはまずリニューアル内容を全部洗い出して、それぞれの工数目処をエンジニアにヒアリングしました。
整理した結果、4段階になり、それぞれの段階の名前はチーム全員による厳正なる投票の結果決めました。
（個人的には、「ヘビー（極み）」推しだったのですが、あまり人気はありませんでした…。残念ですが、気持ちを切り替えて臨みました！）
そして表にまとめたリニューアル規模レベル、工数目処、リニューアル内容は以下です。
最もレベルが高い「大」では、工数目処を2週間と設定しました。
レベル「大」にはリニューアル対応の中でも最も大変な、連携先側がフルリニューアルする（ほぼ新規開発に近い）対応が入っています。
また、主なリスクという列も加えることで、このレベルでの対応をミスするとどのような問題が発生するのかも一目で分かるように追記しています。（今後は重篤度と関連付けとかもしたいです）
次に「2. 段階に関係なく、リニューアル対応の基本開発フローも作る」ですが、リニューアルを検知してからリリースするまでの流れを実際に対応しているエンジニアに叩き台を作成してもらい、それをチームみんなでレビューするところから始めました。
開発フローの中ではリニューアル対応の現在の課題が解決するための作業も入れています。
例えば過去のリニューアル対応に何があったのか辿ることができないという問題に関しては、ドキュメントを作成する、リニューアル対応をJIRAでチケット管理すると決めました。
またリニューアル対応時のテスト実施が実装をしたエンジニアに依存しており、絶対押さえておくべき確認や重要なテストだけど知らないと見逃すことが多いという問題に関しては、どんなレベルでも絶対実施!!基本のテストケース・パターンを定義しておくことにしました。(今まさにテストケースを考え中です)
というかたちで、今月中にリニューアル対応フロー60%程度の完成を目指し協力して今も進めているところです。
これから
リニューアル対応ではエンジニアとQAで協力してフローを定義したのですが、私一人では出来なかったのでメンバーには感謝しかないです。 ただまだリニューアル対応の開発フロー完成には至ってないのと、みんなで頑張って決めたので決めるだけではなく運用にのせるところまでやり切りたいと考えています。
おわりに
この1年間でやってきたことは他にもあるのですが障害にフォーカスを当てた３つのActionを紹介しました。 このActionの効果がまだわかっていないところですが、障害を減らすための第一歩として出来ることはやっていきたいなと思い行動してきた1年でした。 これからもロールの垣根を超えて、よりいいものをユーザーの届けられるようにActionを起こしていきたいと考えています。
明日は人事労務QAのshihoさんがfreee QAの生の声をまとめた記事を書いてくれます。 とっても気になりますね。お楽しみに〜！よい品質を〜
