開発チームと一体となった QA
みなさんこんにちは、メドレーの QA エンジニア かみむら です。 入社して間もなく 1 年になります。 CLINICS 開発チームの QA 活動を行っています。
私自身の経歴としては、テスト・品質関連業務に足を突っ込んでから早 20 年になろうとしています。 2020 年はメドレーの QA エンジニアが一気に 0 名 →2 名になりました。 先日 Magic Pod 導入の記事 を公開した米山とはかつての同僚でもあります。 現在は別々の部署に所属していますが、お互い得意分野を発揮しつつ時折情報交換や相談ごとなどをしているような関係性です。 自分とは違うタイプの同職種がいると、何かと捗ります（その辺りはまた別の機会に…）。
CLINICS 開発チームでは、エンジニア・デザイナー・ QA エンジニアがワンチームで開発を進めています。 これまで私が経験してきた現場では、QA は開発チームの外側にいる（ステークホルダーとして）ことが多く、新鮮な気持ちでいます。
この記事では私の入社以降取り組んできた QA 活動の概要についてお話ししたいと思います。
「CLINICS の QA」とは？
さて、何しろこれまで「QA エンジニア」という職種のひとが存在しなかった開発チームのため、まずは「CLINICS に必要な QA ってなんだろう？」というところから考えはじめました。 もちろん、数々のプロダクトを大きな障害なくリリース・運用してきているので、それなりに QA/テストの技術力はあるはずです。
入社前にも、何度も
- なぜ（他の手段ではなく）QA エンジニアの採用が必要なのか？
- QA エンジニアにどんな役割を期待しているのか？
といった点を開発チームの上長と話し合いました。
なぜ（他の手段ではなく）QA エンジニアの採用が必要なのか？
私は第三者検証会社に所属していた期間が長いこともあり、品質についての悩みがある開発チームにテスト支援だったりコンサルティング的役割で関わることが多かったので、「てっとり早く他社に相談するのではなく、採用したいのはなぜだろう？」という疑問が単純にありました。
現場の思いとして、以下の点が挙げられていました。
- プロダクト開発エンジニアがリリース時のリグレッションテスト（シナリオテスト）をメンテ・実施しているが、CLINICS（電子カルテ）の複雑さに追いついていくのが難しくなってきた
- ここに対して専門性をもって取り組むことで、複雑なドメイン知識を扱うプロダクトを安定して開発リリースできる仕組みを作りたい
QA エンジニアにどんな役割を期待しているのか？
描いている組織体制像としては以下のようなお話でした。
- QA エンジニアにテストフェーズだけ縦割り的に関わってもらうのではなく、プロダクト開発チームとしてひとつになって、有るべき開発プロセスを一緒につくり上げていきたい
- 開発エンジニアがテストに関してしっかりと理解をしていくことで、そもそも品質の高いプロダクトをつくることができる、といった世界を目指したい
これら課題に対してチャレンジ的に「やってみたい」と強く思ったのと、私はこれまでにいろいろな現場の開発体制の中でテストエンジニア/QA エンジニアとして活動してきていましたが、「プロダクト開発チームとしてひとつになって」というところがすごく「それ良いな！」と思ったのを覚えています。 専門職に任せるのではなく、「一緒に理想の世界をつくりあげたい」という気持ちがとても見える良い組織だと思いました。
「QA エンジニア」「テストエンジニア」「SET/SWET」
ここで少し職種名に関する補足説明をしますと、「QA エンジニア」という呼称は比較的新しい概念なんじゃないかと思います。
一般的には「テストエンジニア」と言い、文字通り「テスト業務に特化したエンジニア」を指していました。その後『テストから見えてくる グーグルのソフトウェア開発 』（2013 年日本語版発行）から「SET/SWET（Software Engineer in Test）」が日本でも認知され、国内の導入事例が出てきたことで一気に広まった印象です。
私の解釈では、「QA エンジニア」と呼称する場合、「テストエンジニア」や「SET/SWET」の素養も含みつつテスト以外にも「品質向上のための活動全般を積極的に担う役割」という意味合いが濃くなるんじゃないかと捉えています。
CLINICS のありたい「QA」の姿
上長と話し合った結果、以下のような活動をメインに据えていきましょうということになりました。
- （現状行っている）テストの改善
- プロセス改善
- 知識の底上げ
それぞれのトピックについて、現在 CLINICS の QA 活動としてどのように取り組んでいるかを 1 つずつ詳しく説明していきます。
「テストの改善」
現状 CLINICS の開発サイクルは週 1 回のリリースとしています。 毎回リリース用にコードフリーズした環境に対してリグレッションテストを開発チーム全員で手作業（マニュアルテスト）により行っています。 日々の機能追加や改修の際に手をいれてはいますが、リグレッションテストのシナリオもツギハギ感がみえるようになってきました。 そして増えてきたシナリオによってどこがどう品質担保されているのか見通しが悪くなっている点が大きな悩みでした。
そこでまず、「現状のシナリオテストを分析し、全体的に再設計する」という計画をたて、現在は開発チームの中でもカルテに造詣の深い一部メンバーで定期的に MTG（レビュー会）を行いながらテスト設計の方針を組み立てています。 設計図ではマインドマップツールやマトリクスを作成して方向性や粒度をすり合わせしています。
私自身も、今までの業務でこれだけじっくり丁寧にテスト設計をしてきたことがないため、厳しくもたいへんやりがいのあるタスクとなっています。
「プロセス改善」
こちらはテストそのものではなく、開発チームのルーチンワークや体制に関わる改善です。
種まき的にスモールチームで新しいふりかえり手法を試してみたり、開発定例会で共有している障害情報とテスト実施中に見つかったバグの情報を一元化して残す仕組みを導入したりなど行いました。 特に「ふりかえり」については常に改善を意識できるプロセスで、上手なふりかえりをすればするほど開発品質が向上すると考えられているため、勉強会の後にフィードバックコメントをもらう仕組みをつくったりなどちょっとした隙間にも「ふりかえり」を小さく回せるように腐心しています。
それとまだ着手できていませんが、記録した障害・バグ情報も近いうちに分析・分類していって今後の開発に役立てたいと考えています。 バグ分析は時間がかかるのでなかなかサクッとはいきませんが、長期的視点では有用な財産になります。
また「開発プロセス」「業務フロー」自体の現状の悩みごとを現場の声として私が直接探るためと、開発チーム内で「共通の目標」を認識するためのブレストをリード陣と行いました。 進め方は「SaPID 」という改善手法を参考にしています。
SaPID とは、”Systems analysis/Systems approach based Process Improvement methoD”の略語で、当事者自らが（最終的には仲間と共に）解決すべき問題点を特定し、現実的に解決、改善、そして革新を実現しながら段階的・継続的に自律運営へのゴールを目指す手法です。
誰かにやらせる、やらされるのではなく、当事者自らの意思、チーム・組織の意思で自律的に運営を進めることを志向するのが特徴です。
コロナ禍の中、日によってリモートで参加のメンバーがいたりなどふせんをつかったワークにも工夫が必要でしたが、最終的には「共通の目標」として
- 自分と身の周りに役に立つ状況をつくる
- 世間に認知されるプロダクトをつくる
というような定義をつくることができました。
「知識の底上げ」
CLINICS はこれまで中途採用メンバーが多かったため、OJT 中心で体系的な教育はまだまだ整備をしている段階です。 新卒入社も増えてきている昨今ではメンバー全体で知識レベルが合わないことによる弊害が出てきており、目線を合わせていくことが喫緊の課題でした。
普段の業務の中で断片的な情報を得ることはできてもなかなか体系的な知識を効率的に身につけることは難しいので（専門書は分厚くてハードルが高い）、上長からのたっての願いでもあり、QA に従事している者にとっては割と初歩的なテスト技法から教えることにしました。 私のようにずっと QA 活動をしてきた者にとっては当たり前の技法でも、開発エンジニアにとっては意外と知る機会がなかったりするものです。 覚えておくとテストの段階だけではなく設計品質もあげることができるので、定着するように日々取り組んでいます。
まずは教科書的な内容を CLINICS チームのConfluenceに書いて、講義形式で CLINICS 開発チームのメンバーに説明し、実践編として宿題を出して答え合わせと解説を行う、という流れで行っています。 学習者としては話を聞いているだけでは覚えにくく、実際に手を動かしたり、日々の業務で本当に困った経験をすると学びたい欲に火がつくと思っているので、実践を大切にしています。 演習問題は以下のような書籍を参考にして作問しています。ありがとうございます、著者の方々。
『ソフトウェアテスト技法ドリル―テスト設計の考え方と実際 』
『はじめて学ぶソフトウェアのテスト技法 』
『ソフトウェアテスト技法練習帳 ~知識を経験に変える 40 問~ 』
一度教わっただけではなかなか覚えるのも難しいので、大事なテスト技法（境界値分析とか…）は折に触れて何度も何度も口にするようにしています。
（再）「CLINICS の QA」とは？
冒頭で引用した Magic Pod 導入の記事 では、「テストの自動化は（リリース後即座に修正できない）アプリから着手していく」方針としました。 現在は、CLINICS の Web ページ側のテスト自動化も推進しています。
テスト自動化の目的は現場によっていろいろと思いがあるものです。なぜ「テスト自動化をやるのか？」については、機械にリグレッションテストを任せて手が空いた分、より高度な（経験則が必要な）探索的テストができるようになるから、と考えています。
最初の問いに戻ります。
「CLINICS の QA」とは何か？
品質向上する仕組みが自然にできている自律した組織で、私は開発チームメンバーと「おもしろいテスト」「楽しいテスト」をしていきたい、と思っています。 それによって顧客が出会う可能性のある不具合が減り、「そもそも品質の高いプロダクトをつくることができるという世界」に近づけるのではないかな、と考えています。
「おもしろいテスト」「楽しいテスト」とは発見であり、学習であり、フィードバックのサイクルによって生まれます。 そのためにも前述の「プロセス改善」と「知識の底上げ」は両輪で進めていく必要があります。
品質向上のための手段は、テストの他にも実に多岐に渡ります。 長年やってきた私もまだ全貌を掴み切れていない「QA のエンジニアリング」ってこんなに奥深く楽しい！ ということが開発チームメンバーの共通認識になるとうれしいです。
最後までお読みいただきありがとうございました。