はじめに
アソビュー！ - Qiita Advent Calendar 2024 - Qiitaの9日目(B面)の記事です。
アソビューでQAリーダーをしております、渡辺です。
前回は、以下の記事を書かせていただきました。
QA体制の過去〜現在〜未来 - asoview! Tech Blog
その後体制の変化もあったため、体制の変化に伴う課題について今回はテックブログに記載させていただければと思います。
QA課題と体制の変化
QA課題：品質はQAのテストだけでは担保できない
これまでのアソビューでは、QAエンジニアはテストエンジニアの役割に近く、
開発エンジニアが設計/実装したプロダクトに対してブラックボックスのテストをするのがメインの役割でした。
しかし、以下の課題が浮き彫りになっていました。
- 開発エンジニアとQAエンジニアが分断しがちな傾向
- 品質を担保するにはブラックボックスのテスト以外にも重要なことがある
対策：QAはチーム化せず、各プロダクトチーム内にQAエンジニアが所属する体制に変化
前述の課題などから、
開発組織として開発エンジニアとQAエンジニアの分断なく開発チーム内でOneTeamでプロダクト開発をする
という全体の方向性に決まりました。
それに基づいてQAエンジニアはQAチームではなく開発チーム内に所属する形となりました。
また、私は各開発チーム所属のQAエンジニアをサポートできるよう、
チームに所属しない横断的なQAの役割に変更になりました。
新体制での気づき
気づき：QA用語は伝わらなければ多用しない方が良い
Webサービスのスタートアップ企業をメインとして品質保証がQAエンジニアによるテストを主としたものに進化する前は、
開発プロジェクトで開発エンジニアが設計/実装/テストの全てを担っていたと思います。
元々は、開発とテストは分かれているものではなく、開発プロセスの一部としてテストがあるものでした。
Webサービス企業でQAエンジニアが専門的なテストをする役割として独立し、
様々なQA用語が生まれて、独自にどんどん進化しているように思います。
開発についてもアジャイル開発が主流となり、開発用語も技術も日々進化しています。
このような世の流れも、開発とQAの分断を生みやすい状況になっているのではと勝手に推測していますが、
独自に進化してしまったQA用語を、開発者とのコミュニケーションで多用するのはあまり良いことではないという気づきがありました。
元々は開発とQA、またはテストは一体だったはずなので、QA用語の中には開発用語で置き換えられるものも多くあります。
分断を生まず、相互の認識をすり合わせ連携を強化するためには、
共通認識できる用語を多用した方が良いです。
社内で既に浸透している用語があれば、活用するのも良いです。
そうすることで、開発チーム全体を巻き込んだ品質改善では認識齟齬が起きづらくなります。
そのため、QA用語は極力使わず、開発エンジニアにとっても理解しやすい言い回しになるように気をつけています。
これにより、相互理解が段々生まれてきていると感じています。
以下、参考までに共通認識できる用語を利用した例です。
- QA用語を多用しない一例
| QA用語 | 用語の意味 | 共通認識するためには |
|---|---|---|
| ハッピーパスのテスト | ユーザーがたどる一番シンプルな道筋のテスト | 「正常系の疎通テスト」に言い換え |
| 品質を確保する | あらかじめ決めた品質の基準が達成されるようにする | 「品質を担保する」に言い換え |
| テストスイート | 同一テスト目的をまとめたテストの単位 | テストスイートは単体テスト実行単位クラス名のイメージが強いため他の用語に言い換え |
- 社内で浸透した言い回しの一例
| 社内浸透用語 | 用語の意味 | 共通認識のための用語の利用シーン |
|---|---|---|
| 攻め | 事業拡大するためのプロダクト開発 | FourKeys の「変更リードタイム」、「リリース頻度」 |
| 守り | システム障害やインシデント防止のための改修/テストや可用性対応 | プロダクト品質向上目的のプロセス改善認識合わせ FourKeysの「変更失敗率」、「MTTR」 |
気づき：QAが品質を保証するという誤り
近年の開発では、不確実性や変化、および進化が激しく、何をもって品質を保証したと言えるかは難しい側面があると思います。
そのため、QAが品質を保証するのではなく、開発チーム内でQAエンジニアを含めて最適な品質を合意する方が
顧客にとっての品質向上に繋がりやすいことを実感しています。
最適な品質については、「JaSST ソフトウェアテストシンポジウムTOKYO 2024」の講演でも、クーパーモデルが紹介されていました。
一般の方が購入する車を例にした時、
- 受け入れられる限界の品質：ミニクーパー
- 最適な品質：普通車
- 過剰な品質：フェラーリ
が想定されます。「受け入れられる限界の品質〜最適な品質のレベル」の品質をよりよくするためにコストをかけると競合優位に立てますが、
あるレベルを超えるとコストをかけても得られる便益はそれほど変わらず、費用対効果の悪い過剰品質になってきます。
QAだけで品質を保証しようとして過剰品質を求めてしまっては費用対効果が悪い状態になってしまいます。
開発チームがQAエンジニアも含めてOneTeamになったからこそ、
顧客のフィードバックを得ながらチーム内で最適な品質を合意するのが重要で、
そのためにはチーム全員を巻き込んでいくコミュニケーションがQAエンジニアには必要になってきます。
新体制での相乗効果
結果的に、新体制になったことで、以下の相乗効果が生まれてきていると感じています。
- 開発エンジニアとQAエンジニアの連携強化がしやすくなる
- 連携強化により、QAエンジニアの共通課題も浮き彫りになる
- 共通課題の対策のため、QAエンジニアの連携も自発的に強化される
新体制に変わる前は、QAチームが解散になりQAエンジニアがプロダクト開発チーム直下に所属することは、
QAメンバーを含め多少の不安があったのは事実です。
しかし、顧客にとってのプロダクト品質を大事にする上でより効果のある連携が生まれやすい状況になってきており、
相乗効果も生まれ、結果としてとても良かったと感じています。
現体制でより良くするための取り組み
全員参加の品質改善活動
QCサークル活動など、昔から全員参加の品質改善活動は日本企業の製造業などで活発でした。
ソフトウェアにおいても、大企業などでは品質改善活動が確立して名称（例：NECのSWQC活動、富士通のQInfinyなど）もついていました。
「QA=後工程でのテスト」のイメージから脱するには、品質文化醸成としても品質改善活動がスタートしやすく合意形成されやすいと感じています。
アソビューでも、QAエンジニアは転換期として、テストエンジニアから品質改善活動を推進する役割に変化しつつあります。
開発エンジニアとQAエンジニアの連携課題の解決
チームによっては、要件に対して「QAする」というタスク表現をし、開発の後続タスクとしてQAエンジニアを担当にしていたりします。
これには、開発エンジニアから見てQAエンジニアがやっていることが十分に共有されていないため、
なんとなくテストなどをして品質を見ているのだろうという曖昧さがあり、期待値の齟齬が発生しやすくなっていた状態があったと思います。
一方、QAエンジニアは得意分野やアソビューでの在籍歴、開発経験有無もそれぞれ違うため、
開発エンジニアのコードベース/技術ベースの話が理解できない時があったりします。
結果として、開発エンジニアがどの領域の品質を確認し、QAエンジニアがどの領域の品質を確認するかが
十分に擦り合わせられていないことがある状態に課題感がありました。
そのため、チーム横断で開発プロセスの後工程だけでなく初期段階から各フェーズで開発エンジニアとQAエンジニアの連携を強化する目標を掲げ、
多角的視点により品質を担保することに取り組み始めています。
今後の課題と展望
開発エンジニアとQAエンジニアが分断せず、連携は強化する必要がありますが、
各開発チームにより抱えている課題や状況が異なりQAエンジニアの得意分野も違います。
今後の展望としては、開発プロセスの中で最適な連携の仕方は各開発チーム内で地道に振り返りながらテーラリング（カスタマイズ）
していくことが、最終的にはプロダクト品質向上の近道にもなると感じています。
さいごに
アソビューでは、「生きるに、遊びを。」を実現するための良いプロダクトを世の中に届けられるよう共に挑戦していく
各職種のエンジニアを募集しています。
カジュアル面談のご希望も随時お受けしておりますので、お気軽にエントリーください！
お待ちしております。
