ごあいさつ
こんにちは。techtektアドベントカレンダー2022 20日目を担当する吉次（よしつぐ）です。 普段はSalariesの開発・プロジェクトマネジメントをおこなっているWebエンジニアです。
今回は、エンジニア組織の中で「品質」について考え、開発現場をサポートするQAエンジニアとしての活動について これまでやってきたこととこれからについて書きたいと思います。
QAエンジニアチーム立ち上げの経緯
まずは、QAエンジニアチーム（今は私だけの一人チームです）立ち上げの経緯について。 私が所属するサービス開発部は、2018年以降、いくつもの新規サービスを生み出してきました。 それと同時に、組織規模も大きく拡大してきました。
初期に立ち上げたサービスの成熟と、ものづくりに関わる人の増加が同時に進む中で、 品質面において次のような課題が浮き彫りになっていました。
- リリース後のバグ検出頻度があがる
- 仕様書等のドキュメントがなかったり、メンテナンスが追いつかなかったりして実際の仕様や経緯が見えなくなってきている
- リリース前のQA実施時のテストベース（テスト設計などに用いる材料となるドキュメントなど）の準備におけるエンジニアの負荷が高い
これらの問題を解決・改善するべくQAエンジニアのチームを立ち上げていろいろなことに取り組んできましたので紹介していきます。
品質課題のヒアリング
自らが担当しているサービスも含め、5チームのエンジニアのリーダーにヒアリングを行い、 横断的なアプローチを整理することにしました。
ヒアリングを通して挙がった課題や対応案の一部を抜粋してみます。
| 分類 | 課題 | 対応策の案 |
|---|---|---|
| 仕様 | ・仕様書がない（断片的にFigma上に書かれている、誰かの頭の中にある） ・仕様の理解が十分でないまま実装が行われることがある |
・仕様書を作成・メンテナスできる状態を作る |
| 実装 | ・実装時の確認パターンが網羅できていない（異常系の確認漏れなど） ・品質に対する意識が薄れがち |
・エンジニアに対する品質に関する基礎知識のインプット ・一定レベルでの仕様理解が担保されるプロセス、ルールの整備 |
| テスト | ・リリース前のテスト実施時のインプットが不足している ・エンジニアのテスト実施準備負荷が高い |
・仕様書の整備、レビュー体制の強化 |
ヒアリングを通して得られたこのような課題に対して、実際にアプローチしていくことにしました。
テストマネジャーの半常駐体制の整備
サービス開発部では、リリース前のテストをテストベンダーに依頼して実施することが多いです。 このときに、仕様書がメンテナンスされなかったりそもそも存在しなかったりすると、テスト設計の質に影響し、観点の抜け落ちなどにつながってしまうことがあります。 また、テストタイミングで都度Figmaのデザインや仕様を取りまとめてお伝えするというのも地味ながら負荷になっていました。
実は、ヒアリングを行う前のタイミングですでに私がプロジェクトマネジメントを行っているSalariesをパイロットプロジェクトとして、 テストベンダーから半常駐でテストマネジャーをアサインすることでこの問題にアプローチしていました。 仕様を決めるミーティングや定例に参加してもらいつつ、ドキュメントのメンテナンスやリリース前テストの準備を日常的に進めることで 明文化された最新の仕様が関係者間で共有され、リリース前テストの準備においても特別な作業をする必要がなくなっていました。
QAエンジニアチーム（=私）からは、各プロジェクトにおいてそのプロジェクト固有の課題も含めて、 テストマネジャーが加わったときに手伝ってもらう業務や参加するミーティング、想定される稼働時間をまとめてもらい テストベンダーと社内側の担当者を接続するところまでをフォローしました。
結果として、ドキュメンテーションやテスト準備における課題が少しづつ解決に近づいています。
QA輪読会の実施
テストマネジャーの半常駐体制の整備により、仕様やリリース前テストといった、エンジニアが直接的関与が比較的薄い部分の足回りの整備は進みました。 一方で、コードを書くエンジニアにとっても品質に関する知識を持っておくことは重要で、結果的に書くコードの品質があがったり、動作確認時の観点の抜け漏れを減らすことに繋がります。 そこで、エンジニアを対象としてQA輪読会を実施しています。
| 項目 | 内容 |
|---|---|
| 期間 | 約3ヶ月間 |
| 開催頻度目安 | 1時間 / 週 振り返り含め6〜8回で終わる程度 |
| 題材 | JSTQB Foundation Levelシラバス |
| 形式 | 輪読会 + 個人学習 |
| 参加人数 | 5〜6人を想定 |
題材としては、テスター・テストマネジャー・QAエンジニアの方が多く取得されている、JSTQB Foundation Levelのシラバスを利用することにしました。 PDFとして公開されているためアクセスしやすくかつ体系的にまとまっているため、ソフトウェア品質の全体像を把握してみるという意味では適していると考えています。 また、資格取得も奨励し、合格時には受験費用を全額補助する枠組みにしました。
第1クールとしては2022年7月から9月で実施し、終了後にはアンケートを実施し、良好なフィードバックを得ることができたため、現在第2クールも実施中です。 アンケートの結果を一部公開いたします。
全体を通しての満足度
5人の参加者全員が満足したという結果が得られました。
JSTQB Foundation Levelの受験予定
資格試験の受験予定は1人でした。 資格取得が主な目的ではないことを考えると妥当ですが、スキルを身につける機会提供とそのためのサポートは今後も続けていきたいと感じています。
他者におすすめしたいかどうか
運営側として一番気にしていたところです。 幸いにも、他の人にもおすすめしたいという声が多かったです。 継続的に実施していくことで、エンジニアの品質知識のレベルを組織全体で上げていきたいところです。
品質ガイドラインの作成
QA輪読会を行っておしまい、だと少しもったいないのでQA輪読会の最後に振り返りを行い、 実務にも役立てていくためのアクションを話し合いました。 アクションの中の1つとして、ガイドラインを作ることにしました。
実際にQA輪読会に参加頂いたメンバーにドラフトを書いていただき、運営側でレビュー、メンテナンスしていく体制です。
今回は「テストレベル」と「テストタイプ」について抜粋して紹介します。
| テストレベル | サービス開発部内の定義 |
|---|---|
| Unit Test（Component Test） | 一般的な定義と同様にメソッドやクラス、UIコンポーネント単位でのテストを指す |
| Integration Test | サービス開発部では、画面単位でのテストやAPIのE2Eテストを指すことが多い |
| System Test | 予め定められたユーザーストーリーやユースケースに基づいたテストを行う。サービス開発部の場合、テストベンダーに依頼しているリリース前のQAテストがこれに該当する場合が多い |
| UAT | User Acceptance Testのこと。ブラウズや機種を拡張して、想定しているユーザの環境に即して実際の操作を行い、テストを行う |
| テストタイプ | サービス開発部内の定義 |
|---|---|
| 機能テスト | システムが「何を」すべきか、つまり「機能」をテストする |
| 非機能テスト | ソフトウェアの使用性、性能効率性、セキュリティ等をテストする |
| ホワイトボックステスト | コード、アーキテクチャー、ワークフロー、データフローを用いてテストする |
| 変更関連のテスト | 主に変更後の確認テストとリグレッションテストを指す |
ガイドラインにはこのような言葉の定義も含んでいます。 これらのキーワードは割と馴染みがあったりするものも多いのですが、人によってイメージするものが違ったり、コンテキストによって何を指すかが微妙に変わってきたりして、意外と話が噛み合わないなんてことがままあります。 組織内で使われるシーンを想定した基本的な意味を明文化しておくことで、言葉の捉え方をできるだけ揃える狙いを持っています。 その他にも、テスト技法やテストマネジメントについてもまとめました。
このガイドラインはまだ初稿ができたばかりで、展開や実践の場での応用はまだまだこれからなので QA輪読会と合わせて継続的に取り組んでいきたいと思っています。
これからについて
この1年くらいで、紹介したような取り組みを行ってきました。 今後は、これまでの取り組みを継続することでプロダクト品質・開発プロセスの質を向上させていくとともに、 QAエンジニアリングチームの活動を部署の枠を超えて進めていきたいと考えています。
一方で、私自身もプロダクトの開発やマネジメントを行いながらの活動となっているためパワー不足が否めない現状があります。 サービス開発部では、QAエンジニアの活動や組織づくりを引っ張ってくれるリーダーを募集しております。 ご興味のある方はカジュアル面談等も含め、是非チェックしてみてください！
それでは、良いお年を。
吉次 洋毅 Hiroki Yoshitsugu
エンジニアリング統括部 サービス開発部 第3グループ シニアエンジニア
2014年に高専専攻科を修了後、飲食店検索サービスを提供するWeb企業に入社。PHPをメインにバックエンドの領域の開発やプロジェクトマネジメントに従事。2016年にインテリジェンス（現パーソルキャリア）に入社。「doda AIジョブサーチ」の開発などを経て、現在はSalariesの開発を担当している。
※2022年12月現在の情報です。
