この記事は【株式会社ログラス Productチーム Advent Calendar 2022】の8日目に参加しています。

おはようございます。ログラスQAのコタツです。今日も寒いですね…、わたしこんな名前をしていますが最近湯たんぽを買いまして、湯たんぽ抱えながらリモートワークをしているのでコタツから湯たんぽに名前変えようか検討中です（嘘です）
と言うわけで本日は一人目QAとして半年経過したのでやってよかった・効果があったなと思うことをお伝えしていければと思っています。

この記事はこんな方におすすめです：
・一人目QAをやっている・やろうとしていて、他社事例が知りたい方
・一人目ではないがアジャイルQAをしていて、他社事例が知りたい方
・品質を高めていくためにどうすればいいかお悩みの開発者の方

目次

1. 前提
2. 1. QA/テストの基本的な説明
3. 2. 開発チームに所属し、コードを書き、プルリクを出してみる
4. 3. 品質向上活動をプロジェクト化
5. 4. エンジニア有志にテスト技法セミナーに参加してもらう
6. 5. スクラムマスター的な活動
7. まとめ

前提

そもそもですが、わたしの参画時にログラスの開発チームはこんな状況でした：

• 開発チームは3チーム体制
• アジャイル開発
• わたしが入社するまでQA担当者は不在
• 開発チームの人数はここ一年で3倍の増加

また、やったことは色々あるのですが、他社であんまりやってなさそうなものを独断と偏見で5つ選んでおります！

1. QA/テストの基本的な説明

ログラスの開発チームでは10分勉強会という取り組みを行なっており、その中でまずQAやテストに関する基本的な説明をしました。
ちなみに10分勉強会については以下のツイートにありますが、ゆるいネタも骨のあるネタも色々で、楽しくワイワイやってます。

開発チーム全体に対してこんなことを話しました。

• プロセスQAとプロダクトQAというものがあること
• プロダクトQAをする中で、テスト計画、テスト設計、テスト実装、テスト実行というフェーズが分かれていること
• • その中でテスト設計という工程が重要であることとその理由
  • テスト設計という工程の中でテスト技法を使っていくということ
• QAと一口に言っても、SET（自動化QA）やテストアーキテクト、マネージャー、リーダー、テスターなど多岐にわたること

また、V字モデル、W字モデル、シフトレフト、アジャイルQA、ついでにアジャイル宣言についても上記と同様に開発チーム内に紹介しました。

W字モデル

QA界隈においては一般的な話ばかりですが、この中でわたしの得意な部分・苦手な部分・できる部分・できない部分も交えて話したことで、開発チームとの期待値調整ができたと思います。また、ログラスのQAのありたい姿についても解説し、開発チームの目線を合わせました。

“前提：ログラスにおけるQAのスタンス ログラスにおけるQAの担当領域・興味範囲はテストだけではありません。 中長期的に見て、開発チーム全体で品質担保できる状態になることが理想の状態としています。
そのために動き方として以下を想定しています：
× テスター
○開発チームのQAスキルを上げていく人”

引用：QAとしてログラスを選ぶべき理由と、アジャイルQA大募集の背景

これによって、（もともとそんなことは無かったですが）QAをテスター・テストする人と扱われることは無くなりましたし、シフトレフトが開発チーム全体の共通言語となりました。

シフト◯◯シリーズのslack emojiがいつの間にか生まれていました。これ、全て動きます。masakari_shift_leftは謎

2. 開発チームに所属し、コードを書き、プルリクを出してみる

入社してから最初の2-3ヶ月間で、まずミッションクリティカルなチームに参加し、コードを読み書きしてプルリクを出すということをやりました。これはわたしがJavaの開発経験があり、かつログラスのサーバーサイドはKotlinで書かれているという状況だったからスムーズに行えた部分です（ラッキーでした）。
もちろんスクラムチームなので各スクラムイベントにも参加してますし、local環境構築も行いました。

他にも問い合わせのためのデバッグ・調査なども一緒に行い、開発者のつらみを同じレベルで感じることで、議論や課題間の目線を合わせることができました。

この頃の目標はチームの一員だと受け入れてもらうこと、信頼関係を構築することでした。そしてそれはうまくいったと思っています！

とてもありがたいお声をいただきました

3. 品質向上活動をプロジェクト化

ログラスのエンジニアはわたしの入社前から品質についての課題を一覧化しておいてくれたり、QAの人が入社したらこうしたい！という熱意がある方がとても多かったので、品質について興味がある方を集めて中期レベルの品質向上プロジェクトを立ち上げることにしました。これが、さまざまな人を巻き込んで品質を上げていくという活動に直結し、とても良かったです。

• 参加している開発者のやりたいことや課題感に近い小さめタスクを各々に割り振って週一の定例にて進捗管理を行なった
• • その中でわたしはプロジェクトマネジメントもした
• さまざまな課題のヒアリングだったり、壁打ちに付き合ってくれる開発者が固定で何人もいる状態を作れたので進捗が出しやすかった
• QAとしてやってほしいこと、依頼ごとを参加している開発者に展開しやすかった
• • 例えば各チーム内のテストレビューをやってほしい、など

12月現在は状況が変わり、参加者にタスクを割り振ることはせず「品質向上コミュニティ」のような形に会議体を変更しています。同じく週一で定例MTGを開催しており、各チームから品質・テストに関するお悩みや、チーム内で「こういうことをやってみたら良かった！」という話をする場として機能しています。結果、各チームの相互コミュニケーションが深まり、テストについても案件ベースでの相談をしてもらいやすくなったと感じています。

4. エンジニア有志にテスト技法セミナーに参加してもらう

1チームに所属しスクラムチームのQAとしてやっていく一方、残りの2チームはカバーできていないですし、私自身が体系的にテストのやり方を開発者に教えるという時間的余裕もないので、やはりQAの人数が足りないという話に帰結することがありました。そしてQAあるあるだとは思うのですが、テストベンダーに頼んで人員増強をしてみないかという話が持ち上がりました。
色々考えた結果、テストベンダーに依頼してQA人員増強をするよりか、開発者のテストスキル、特に現状の課題感も踏まえ抜け漏れなくテストを行うスキルをベースアップする方が中長期的に価値が高いと考え、バルテスさんのテスト技法セミナーに開発者有志に参加してもらうことにしました。

有志は参加したいと手を上げた開発者で構成され、開発者全体の半数程度になりました。
やってみたところ、セミナーに行く前と後で格段にテスト自体のクオリティが上がりましたし、シフトレフトに加えチームの共通言語が増えたため、品質についての意識も高まり、テスト考慮漏れ起因の障害は明らかに減ったと思っています！

5. スクラムマスター的な活動

ログラスにはスクラムマスターという明確な役職を持っている方はいません。随所で各々がスクラムマスター的な活動をすることで補っています。なので、わたしもスクラムマスター的な活動の一環として、プロダクトバックログアイテムの分割方法にまつわる問題の勉強会を開催してみました。

プロダクトバックログアイテムの分割方法の問題とはどういうものかと言いますと、細かく分割しすぎても顧客に価値を届けられないし、逆に分割せず大きい粒度で進めても顧客からのフィードバックが得られるタイミングが遠くなるので明後日の方向に開発が邁進してしまうかもしないという問題です。

「プロダクトバックログアイテムの分割」というと長くて言いづらいので、よくスクラム界隈でPBIをケーキの一切れに例えるため、「スクラムケーキ問題」と呼んでいます

そもそも、新機能などのリリース時に「依存関係があるタスクが多く、シビアに順番を考えないと事故に繋がってしまう」「前の工程であった必要なタスクを忘れてしまう」などのリスクが多かったためこの勉強会を行ったのですが、結果的にチームの共通言語となり、「このタスクもっと分割できるんじゃないか？」という観点でプランニングやリファインメントを進行することができるようになりました。
QAとしても、機能やリリース単位などすべての複雑性を下げることがテストをするよりも前の段階で品質を高める効果的な方法だと思っているので、このスクラムケーキ問題の勉強会は大成功でした！チームのベロシティも上がりますし一石三鳥ぐらいの効果を感じました。

アドベントカレンダー4日目、同じチームだった村本さんの記事にも同じ話が載っています。

まとめ

いろいろなプラクティスをご紹介しましたが、ここまで自分で書いてみて共通することがわかりました。
それは共通言語です。共通言語を作り、その共通言語をもとに人を巻き込んで、巻き込んだ人がまた他の人に伝播し、チーム全体で品質が高まるというサイクルを作れているような気がします。

こんなイメージです

これは「こういうことをやりたい！」「こうした方がいい！」と言い出したらちゃんと話を聞いてくれる、お互いへの信頼や尊重があるログラスの優秀な開発者の皆さんがいるからこそできたのだと思います。また勉強会の機会や文化がとても根付いているため、当たり前のようにそのような発信ができる土壌がある、というのも関係しています。
なので今回ご紹介したプラクティスについては万人には当てはまりづらいのかもしれません。まず前提として勉強会文化だったり、チームの雰囲気や文化作りだったり、というところをしていかないと使えないかもしれませんが、よければ参考にしていただけると嬉しいです。

余談ですがログラスではアジャイルQAを大募集しています😌ご興味ある方はこちらの記事もご覧ください。

以上読んでいただきありがとうございました。良いお年を〜！