この記事はニーリーアドベントカレンダー2024の19日目 その2の記事です。
こんにちは、QAチームの関井（@ysekii_）です。
先日書いたQAチーム2年目を振り返る（体制編）の続きで、今回は2024年にQAチームとして取り組んだことを振り返りたいと思います。
ちなみに、今年取り組んだ内容は「これってQAがやることなの？」と思われるかもしれませんが、そのあたりは大目に見ていただけると幸いです😉
開発チームへの問い合わせの窓口設置
まず、今年の初めから取り組んだことは、開発チームへの問い合わせの窓口設置になります。
ニーリーではPark Directを利用いただいている不動産管理会社様や駐車場ユーザーの方から日々さまざま問い合わせを受けています。 これらの問い合わせを受けているビジネスサイドのメンバーで調査・回答が難しい質問（特定の操作履歴やある設定が変更ができない理由など）について開発チームに確認依頼が来ています。
昨年まではエンジニアのメンバーが持ち回りで調査などを行っていたのですが、問い合わせ件数も少なくないため、開発業務に割ける時間が圧迫されている状況でした。
問い合わせ対応を専門とするチームやワーキンググループを作るといった方法もあるかと思いますが、結果的にはQAチームで問い合わせの窓口を担当することにしました。
QAチームで担当した理由は下記になります。
- 問い合わせ対応によりドメイン知識（特に業務知識）の獲得が期待できる
- QAチームがミッションとしている「品質とアジリティの両立」のアジリティ向上に繋がる
当初は回答に時間がかかったり、QAチーム内で解決できず他チームにヘルプを依頼することもありましたが、現在はほぼQAチーム内で完結できるようになりました。
特にログ調査は最初は時間がかかって大変だったのですが、この記事で紹介されているプロダクトの画面上でログを検索できるツールにより、ログ調査の効率が大幅にアップしました🎉
もはやこのツールなしでは生きていけない体になってしまいました…
あとはSREチームがRedashでPark Directで送受信したメールの検索をできるようにした仕組みもよく利用しています。
そんなこんなで2月から始めた問い合わせ対応ですが、9月あたりから増加傾向にあります😥
今年は問い合わせに回答するので手一杯でしたが、今後は問い合わせ件数そのものを減らすことができるように、問い合わせの傾向を分析し、施策の実行などをやっていきたいと思います！
Jiraワークフローの統一
昨年までニーリーでは、大きく分けて2つのチーム体制で開発を行っていました。 それぞれのチームでJiraのワークフローも決めていたのですが、今年になって4チーム体制になり、ある程度統一した方がメリットが大きいと判断し、統一することにしました。
ワークフローを統一するメリットとしては、下記のようなものがあるかと思います。
- チーム間でメンバーの移動があった際に馴染みやすい
- 各チームが自分達で管理しなくて良くなる
- 承認やレビューフローといったIT統制の仕組みが一本化できる
- 共通のフィールドを設けることにより分析しやすくなる
ただこのフェーズではガチガチに固めるのはあまり良くないと思っていたので、ゆるく統一し、各チームで独自の課題タイプを作るなどは許可することにしました。
Jiraワークフロー統一の方法としては、ベースにできるプロジェクトがあったのでそのワークフローをもとに、各チームのリーダーと会話しながら、汎用的なワークフローを作成しました。 その結果、3つの課題タイプとそれぞれのカスタムフィールド・ワークフローを共通化し、各チームのプロジェクトに適用することにしました。
決めるところまでは順調だったのですが、Jiraには「チーム管理対象プロジェクト」と「企業管理対象プロジェクト」があり、4つすべてのプロジェクトが「チーム管理対象プロジェクト」であったため、それぞれで同じ設定をする必要があり、これがなかなか大変な作業になりました…🫠
このタイミングでは、企業管理対象プロジェクトの移行までは考えていなかったですし、なんとかなるだろうと思って作業していたのですが、カスタムフィールドやワークフローの作成以外にもオートメーションも同じようなものを4チーム分作成する必要があったため、結局全て設定し終わるまでに2週間くらいかかったと思います。
そんなこともあり、今後作成するJiraプロジェクトは「企業管理対象プロジェクト」とするために、今回統一したカスタムフィールドやワークフローを企業管理対象プロジェクトに適用できるよう準備しました。
その後作成したプロジェクトは企業管理対象プロジェクトとすることができましたが、他はまだ移行などはできていないので、これからも何か変更がある度に5プロジェクト分の変更を行わないといけません…
メンテ地獄に追われる前には全プロジェクト移行したいと思います…
ドキュメンテーションルール策定
ニーリーではこれまでドキュメント作成自体は行われていましたが、明示的なルールがなく、確かここに変更を入れたときはこのあたりのドキュメントを変更したらいいのかな〜🤔 という感じでドキュメントのメンテナンスが行われていました。
このような状況だったため、Aチームではこのドキュメントはメンテ対象だと思っていたけど、Bチームではその認識がなかったといったことが発生していました。（また、Aチームの中でも全員が共通認識を持てているわけではなかったり…）
ずっと課題感はあったものの、なかなかそのあたりのルールを整理することができておらず、ようやく重い腰を上げ、ルール策定に動きました。
やったこと自体はシンプルで、下記の2ステップです。
- メンテすべきドキュメントとそうでないものを分類し、
- メンテした方が良いドキュメントについては、「どんな変更時に更新するべきか」を明確化 （例えば、〇〇を変更した場合、□□のページを更新するなど）
決めたことは、どのドキュメントをメンテする必要があるかということだけで、ドキュメントメンテのプロセスは各チームにお任せしています。 これは、チーム毎に都合の良いドキュメント更新のタイミングが異なるためで、あえてメンテプロセスまでは共通化しませんでした。
このルールを決めてから数ヶ月経ちましたが、（おそらく）ドキュメントはメンテされ続けているはずです。 まだ、ちゃんとメンテされているかの効果測定はできていないため、効果のモニタリングは今後やっていきたいと思います。
来年に向けて
今年取り組んだことを書きましたが、やりたかったけどできなかったことも沢山あるので、それは来年の自分に託したいと思います。
おそらく来年もこんな感じで、この施策はQAがやるものなのか🤔 といったものを色々やっていこうと思います。 ニーリーの開発組織の特徴として「ロールを自ら進化させていく集団」というものがありますが、自分もこれに則ってQAというロールを進化させ、より良い開発組織にしていけるよう動いていけたらと思います。
