二人目のQAエンジニアとしてJoinして半年のふりかえり

価格.com開発本部基盤システム開発部の野澤周平と申します。2024年6月に二人目のQAエンジニアとしてJoinして半年となりましたので、ここまでのふりかえりをしたいとおもいます。気になる方はぜひお付き合いください。

採用面接で話したこと感じたこと

QAチームのメンバーは1人。最初の印象はQAの伝道師という感じでした。開発チームは複数あり、テスト活動は各開発チームが行っているということでした。テストを請け負う形のQAチームとは異なる体制とアプローチについて、どのようなものなのか興味を持って伺いました。

私が転職を考えた理由の1つに、日々の業務がQAチームのメンバー管理や費用管理に占められ、リリーススケジュールや費用削減による効率化が優先される中で、自身が得意とする品質リスク分析やテスト設計に関する追加実践的なアプローチの浸透・波及が難しいといったことがありました。

話を伺う中で、業務内容的にQAコンサルタントのようなイメージも持ちましたが、ひとつの開発チームに入って行う活動もあるということで、実務的なこともできそうだなと感じました。また、品質活動の提案に対する開発チームの受け入れもスムーズに行われているということで、開発スケジュールに余裕をもって品質にもしっかりと取り組める環境にあるものと認識しました。

Joinするまでに考えたこと

イメージしたのはアジャイルライクな開発でした。プロセスよりもプラクティスに寄せたQA活動の考え方です。QA自体がプロセス的なアプローチならば、テスト技術の伝播に焦点を当てるべきか、またその中で自分にできること、技術の引き出しは何があるのかといったことを思考しました。

実際にJoinしてからのこと

突然話は変わりますが、これまでMacを使っていたので、WindowsPCとTeamsの挙動に慣れるのに少し苦労しました。Macに替えてもらうかトラックパットにこだわらず素直にマウスを使えばよかったのですが、開発環境も変わるので敢えてそれに慣れようとおもいそのまま突き進みました。(今ではトラックパットで支障なく扱えています。)また、Join当時はアプリのインストールにワークフロー申請が必要で、セキュリティ対策が意識的に行われているのも印象的でした。

マネージャー、リーダーとの意見交換

まずはどこかのチームに参画して慣れていきたいというところで、ショッピング領域で開発を行っている2チームのマネージャー、リーダーの方々とQA支援として何ができそうかという視点のミーティングを開催してもらいました。そのなかで、品質やテストに関するメンバーの技術面のばらつきといった課題感の共有がありました。そうした視点から、全体のレベルを高めるというよりはベースラインの引き上げをしたいというニーズがあるということが見えてきました。

開発チームのチャットにいれてもらう

どんな開発施策をおこなっているのか。どんなところに課題をもっているのか。チームの雰囲気や開発の進め方はどうか。そうしたところを知りたいということもあり、開発チームのチャットに入れてもらいつつ、週次のレビュー会に参加させてもらうことになりました。

週次のレビュー会では、各々の開発メンバーが担当している施策毎にリリース手順やテスト項目書のレビューが行われており、特にテスト項目書のレビューで実際の成果物を見る機会があったので、初見での印象をフィードバックしたいと考えました。

初回フィードバックの内容

フィードバックもマネージャー、リーダーとのミーティング形式にて実施しました。レビューで確認できたテスト項目書において「テスト項目書からテストの目的(何をテストしようとしているのか)の把握が難しいケースがみられる」という点と「テスト対象の記載に抜け漏れがみられる(テスト項目書外でカバーしている)」という点について実際のテスト項目書を挙げてフィードバックしました。

提示した実際のテストケースを段階的に強化していくとこうなるという具体例をあわせて提示することで元のテスト項目書に不足している要素を認識しやすいよう工夫しました。また、追加情報として、デシジョンテーブルを作成することによってテスト条件と検証パターンを同時視覚的に確認できるようになりテストの目的が把握しやすくなるという提案も行いました。

デシジョンテーブルのつくりかた勉強会をやってみた

フィードバックで行ったいくつかの提案から、デシジョンテーブルについて勉強会の開催をしてはどうかという話が挙がりました。ブラックボックスのテスト技法としては最もメジャーなものではありますが、システム設計の手法としても有効ですし、すでに知っているメンバーにはおさらいを、知らなかったメンバーにはテスト技術の底上げにもつながるということで、開発チームの出社日に合わせてオフライン形式での開催をすることになりました。

勉強会開催後のアンケート結果を共有したいとおもいます。アンケート項目は5段階評価で5が最大値になります。

  • デシジョンテーブルを知っていたか(認知度):平均2.9、分散1.4
  • 勉強会の内容は理解できたか(理解度):平均4.5、分散0.8
  • ワークショップは有益であったか:平均4.1、分散0.9
  • 勉強会としての全体評価:平均3.8、分散0.6

デシジョンテーブルの認知度が意外と低く、一方で分散が大きくでたのは印象的でした。内訳をみると1~5の各スコアそれぞれへの回答がほぼ同数になっていました。マネージャー、リーダーとの意見交換で出ていた「技術面でのばらつき」という部分が裏付けされた結果といえそうです。一つ失敗したことがあり、「デシジョンテーブルを実際の業務に活用できそうか」という項目を入れればよかったとおもっています。勉強会でワークショップを実施したため「ワークショップは有益であったか」がこの内容に類似しているのですが、勉強会で得られた知見が実際に実務に適用されるようになるまでが目指すところなので、より具体的なイメージが持てたかという部分を確認したほうがよかったと後になって気づきました。

レビュー会に出ていて気付いたこと

その後も定期的なレビュー会に参加し、チャンスありと思った場面で、「ここで使えますよ」という感じで実際につくったものを共有するといったことを実践しました。勉強会を行うだけではテスト技法を知っていたとしても実際に活用できるシーンに気づかずにスルーしていることがあるということにも気づきました。実際の適用例を知ることでテスト技法を必要なシーンで活用できるようになっていければと考えています。

QAクライテリアのヒアリングをしたこと

半期に1回、QAクライテリアという質問項目への回答を各開発チームに実施してもらい、QA活動の成熟度を確認しています。直近で9月に実施された回答結果を確認する機会が来たため、前回の実施結果もあわせて自分なりの分析をしてみました。成熟度に応じた以下のスコア換算をして相関分析を行いました。

スコア換算

  • ◎:できている。継続的な改善も行っている ->スコア5
  • 〇:できている ->スコア5
  • △:一部できている ->スコア3
  • ×:できていない ->スコア0

分析結果

  • 標準偏差と平均スコアの相関係数は -0.64という負の相関を示した。5段階評価の平均値が低い項目は、開発チームによってばらつきが大きくなる傾向がみられる。これらの項目はスコアを上げやすい項目であるとも言える
  • 5が付いていない項目は存在しない。つまり、どの項目においても5になれる可能性がある

QAクライテリアはチーム間で比較して優劣をつけるようなものではなく、何を行えていればQA活動がより成熟した状態なのかを各チーム自身が確認するための指針として活用するツールです。一方で、うまくいっているチームのノウハウを横展開することは有益なので、いくつかのチームをピックアップして活動の実態をヒアリングしてみようということになりました。

実際にヒアリングをしてみると、各チームが各々を自己評価しているので評価の基準がばらつきやすいという課題がみえてきました。例えば「テストの観点を蓄積・再利用している。」という項目では何をもってできているとするのかが「チームメンバーが意識して実践していれば」〇なのか、「どこかしらにドキュメント化していれば」〇なのか、「テスト設計とのトレーサビリティまで確保していれば」〇なのか、「再利用のプロセスが運用されていれば」〇なのかと、〇と判断する基準が分かりにくいといった意見がいつくか挙がってきました。

現在、対象のチームが18あり、そのすべてをヒアリングしたうえで評価基準を調整するというのは難しそうです。QAクライテリアをより解像度高く達成基準が明白なものにブラッシュアップするか、別途具体的な内容をヒアリングするアンケート項目を構築するがよさそうだなと考えました。この取り組みはまだ実施には至っておらず、これから行っていきたいと考えているところになります。

価格.comにおけるQAの価値について考えた

半年の活動を通して、これまで行ってきたこと、これから行っていくこと、そして価格.comにおけるQAの価値というものについて考えてみました。

これまで通り

支援によるインプリメントの継続を行っていきたいと考えています。これにあわせた支援メニューの整理も行いました。

これからのこと

QAチームはまだ2名体制なので、今後メンバーが増えて組織的な厚みがでてきたときにできることも考えておきたいとおもいます。開発チームの活動に深く入り込むことによって、例えば「開発チーム内のプロセス改善でタスクフォース的な参画」といった中長期的な支援の形もあり得るかと考えています。

共通して

価格.comの開発チームはリソースに対してコントール可能なスケジュール設定がマネージメントされている組織だとおもいます。実際に発生するソフトウェア起因の障害が少ないことから、機能適合性や性能効率性の面で十分に安定していると言えます。一方で、過去の開発遺産が多く、保守性に関する品質面の課題と、これによる使用性へのアジリティな対応が難しいといった課題があるものと考えられます。この課題に対する取り組みは順次行われており、使用性に注力した改善も多く期待できるようになるものとおもいます。

このような環境において、開発チームが行うQA活動がいわゆるテスト専門チームが行うそれと遜色なく、より開発メンバーが行うことよる優位性をもってその活動に自信をもって取り組めている状態とすることが価格.comにおけるQAの価値であると考えました。一言でいえば、QA活動に対する安心感の担保であり、ちゃんとQAできてますよの保証=QA to QA(QA to AQっぽい)を向上させることにあるのだと考えています。

おわりに

ここまで読んでいただき、ありがとうございました。まだまだ発展途上で、この記事をあとから見返したときに間違っていたこともあるだろうとおもいます。とりあえずの今の考えを書き出してみたという感じですが、思考を継続し、より向上していくことを目指していきたいです。

カカクコムでは、ともにサービスをつくる仲間を募集しています!

カカクコムのエンジニアリングにご興味のある方は、ぜひこちらをご覧ください!

カカクコム採用サイト