見出し画像

医療現場の課題解決を品質面からサポートするQAエンジニアの働き方

やまぐち

1. はじめに

Ubie 株式会社のQAエンジニアの山口です。

最初のQAエンジニアとして入社してから約1年半が過ぎました。現在の主な業務は、医療機関向け(toB)のプロダクトである「AI問診Ubie」を中心とした品質保証活動を行っています。また、プロダクトの蓄積されたナレッジを活かしてユーザーサポートチームの活動支援も行っています。

2. このドキュメントは何？

Ubie ではQAエンジニアの採用活動実施中です。この note では、私が主に品質保証活動に携わっている医療機関向け(toB)「AI問診Ubie」を中心に、どのようなリリースフローやテストが行われているかをご紹介させていただければと思います。

3. Ubie のプロダクトについての紹介

Ubie は「テクノロジーで人々を適切な医療に案内する」というミッションを持ち、世界中の人々に最適な医療の選択肢を提案することで多くの人が健やかで幸せに日々を過ごしていける世界を目指しています。

そのミッションの実現のため開発している主要なプロダクトは現在2つあります。

- 医療機関向け(toB)「AI問診Ubie」
- 生活者向け(toC)「AI受診相談ユビー」

4. QAチームについて

現在、QAエンジニアの正社員は私1人です。そこに、業務委託2人、第三者検証会社1社がサポートに加わってQAチームとなる体制となっています。

サポートメンバーのアサインは、月・火・木曜日の週3回の「AI問診Ubie」のリリース日に合わせてリソースが厚くなるように配置しています。

画像1

5. 主な活動について

「AI問診Ubie」の開発チームではスクラムによる開発を行っています。1スプリント1週間となっており、リリース可能な成果物が出来次第、顧客へ適切なタイミングで価値を届けられるようにしています。

QAチームの私の活動に的を絞ると、スクラムの各イベントに参加しながら、週に3回のリリースタイミングに合わせて、自ら実施するテスト作業とサポートメンバーへ依頼するテスト作業を検討して割り振る作業があります。

週3回のリリースは開発チームの開発力が上がった今、品質と速度を維持出来るギリギリのラインを保っている形になっていると感じています。では、そんな中で今どのように品質と速度を維持しているかをご紹介します。

リリースに関するおおまかなフロー

リリースは基本的に以下のようなステップで行われています。

1. 開発が完了後、開発エンジニアがプルリクエストにテスト観点を記載する
2. チーム内で協議して適切なリリース日を設定する
3. QAチームはチケットとプルリクエストのテスト観点を掘り下げてリリース判定に必要なチェックリストを作成する
4. 多くの場合、リリース当日にテストを行う
5. システム全体のチェックが必要な時はE2Eテストによるリグレッションテストを合わせて実施する
6. 問題がなければリリースし、リリース基準に満たない施策は差し戻す

開発エンジニアとQAチームの担当範囲について

前提として、開発チームには可能な限りユニットテストを書いて貰うように働きかけています。単にテストカバレッジを満たすためのテストを増やすのというわけではなく、QAチームがテストを実施する時にUIからの操作では非効率であったり、条件達成が難しいパターンを優先してカバーして貰えるようにしています。

その前提が崩れてしまうと今のリリースサイクルを維持できなくなる恐れがあります。QAチームが品質の最後の門番とならず、「品質はチーム全体で作っていく」ことを目標としてプロセス改善や、より一層のコミュニケーションを取っていく必要があると思っています。

▼開発エンジニアとQAチームの担当範囲のおおまかなイメージ

開発エンジニアとQAチームの得意な分野を活かすように住み分けし、重要な部分はダブルチェックを行うというイメージになります。

画像2

上記の図の担当範囲のQAチーム側の総合テストを細分化すると以下のようなイメージになります。

画像3

その細分化されたテストの範囲は以下の要素があります。

 - マニュアルテスト(探索的テスト / リグレッションテスト)
 - データテスト
 - 自動テスト(リグレッションテスト)
 - 上記以外の範囲はテスト対象外(優先度低)のイメージ

マニュアルテストについて

新規機能については主にマニュアルテストを行っています。開発チームが挙げたテスト観点や影響範囲を元にテストケースをチェックリスト形式で作成し、正しく機能が動作していることや想定外の動作をしていないことを確認します。また、テストを実行する中で探索的なテストを追加して不具合を洗い出していきます。

ひと通りマニュアルテストが完了すると、既存の機能などに影響が出ていないかどうかを確認するリグレッションテストを行います。

マニュアルテストはサポートメンバーに実施して貰っています。ポイントとしては主にユーザーの立場から機能に不備が無いかどうかをチェックする形を意識して貰っています。

データテストについて

「AI問診Ubie」ではリリースのたびに問診(質問)の内容を充実させたり、病名や病気にかかる確率などの医療に関するデータを大量に投入しています。データは主に医師のメンバーが作成したもので、そのデータをプロダクトに投入した時に想定外の動作をしないようにチェックしています。

このテストは主に私がBigQuery上でSQLを書き、投入されたデータをスプレッドシートへエクスポートしてスナップショットとして残します。そのデータを俯瞰して不備がないかどうか確かめたり、時には関数などを使って件数や重複などのチェックを行っています。

このデータチェックがとても大切です。ここで問題を起こすようなデータがプロダクトへ紛れ込まない限りは致命的な問題が起きにくくなっています。この「問題が起きにくくなっている」に到る過程は、1年以上にも渡る幾たびものリファクタリングやコードによる不正データチェック機能の追加によるもので、開発エンジニアとQAチームとのコラボレーションの結果なのですが、ここに詳細を書くと長い話になってしまいますので、別の機会にご紹介できたらと思います。

E2Eテスト(自動スクリプトによるリグレッションテスト)

また、「AI問診Ubie」では多くのシナリオテストのパターンが存在するため、マニュアルによるリグレッションテストだけでは工数が足りません。そこでリグレッションテストの効率化のためにE2Eテスト自動化にも取り組んでいます。

「AI問診Ubie」では症状ごとにほぼ固定された質問パートと、回答に応じて質問が変化する要素のあるAI問診パートが存在します。そして、質問の内容や長さも症状、性別、年齢によって異なり、パターンを固定化しづらいため開発やメンテナンスコストが多くかかるE2Eテスト自動化に向いていないプロダクトになるかと思います。

その上、スタートアップ企業はプロダクトマーケットフィット(Product Market Fit=PMF)」をいち早く目指すためにプロダクトの内容が日々目まぐるしく変化します。

それでも、限られたリソースの中でE2Eテスト自動化を導入したのは、解決したい課題があり、そこにコストを投入する価値があったからです。

解決したい課題は以下のようなものがあります。

 - 通常のユースケースで進行不可といった重大なエラーを検出する
 - 開発環境では発生しない、または発生しづらい問題を検出する
 - リファクタリングによる想定しない影響が出るケースを検出する
 - ユースケースの最初から最後に到るまでの動作に矛盾があるケースを検出する
 - マニュアルテストのリグレッションテストの工数を削減する

また、多大な開発やメンテナンスコストのかかるE2Eテスト自動化の撤退条件も決めてあります。

 - 課題が解決しないなら止める(効果が出ない場合は止める)
 - 続けられないなら止める
 - よりよい方法があればその方法を検討する(ツール選定や外注など)
 - 作成したものにこだわらずに不要となれば捨てる


結果としては、予想通り開発もメンテナンスもある程度コストはかかっていますが、約1年半の改善の中で一定の水準でプロダクトが安定して稼働するところまで耐え凌いだということが言えると思います。

特に顕著だったのはリファクタリング後のフィーチャーをテスト対象とした時に、開発者が想定しなかったような不具合を再現性をもって検出する状況を作り出すことが出来たのは大きな成果と言えます。

このようなこともあって、開発エンジニアにとってE2Eテスト自動化は不具合をよく見つけてくれる仕組みだという印象が強かったりするのですが、E2Eテスト自動化はテスト効率化の銀の弾丸ではなく、コストと引き換えになっていると啓蒙活動をする必要があり、今後もそのバランスを見極めていく必要があると感じています。

6. Ubie のQAチームで働くことの魅力

ここではQAチームで働くことの魅力3つ厳選してお伝えできればと思います。

医療の未来への貢献

Ubie のプロダクトは医療の現場で実際に使われています。医療の現場で発生する課題を解決し医療関係者の負担の軽減に繋げていくと同時に医療機関を訪れる患者さんの医療の体験をより良いものにしようと全社を挙げて取り組んでいます。QAチームはプロダクトに込めた開発チームのアツイ想いを確実に、場合によってはよりブラッシュアップしてユーザーの元へ届けることで医療の未来に貢献することができます。

また、プロダクトのユーザーは自分自身であったり家族や親戚である可能性があります。医療は誰にとっても身近にあるもので、Ubie のプロダクトは身近な人の医療体験を向上させることにも繋がると信じています。

医師チームとのコラボレーション

Ubie には現役の医師が所属する医師チームが存在します。「AI問診Ubie」の扱う医療に関する専門知識が必要なデータは医師チームが作成し、そのデータに関してQAチームがユーザーの立場になって動作確認を行い、問題がなければ本番環境へ反映されます。その時、データの内容について改善点があれば医師チームのメンバーと直接コミュニケーションをとることがよくあります。

通常、医療関係者でもなければ現役の医師と忌憚なく意見交換をする場は多くはないと思います。また、社内のコミュニケーションツールであるSlackでは医療に関する情報が飛び交っているため貴重な情報を知る機会もあります。

パワフルな開発エンジニアとの協業

Ubie の各メンバーはそれぞれの分野で力を発揮してきた人物が集っていますが、中でもQAチームと関わりの深い開発エンジニアは修羅場をくぐり抜けてきたパワフルな開発エンジニアが多く所属しています。

開発エンジニアの各メンバーは開発力、判断力、実行力、提案力などを高いレベルで備えており、QAチームが機能の不具合や改善点などを提案する時にストレートに進言することが可能です。それを前向きに受け入れた上でより良い方向で改修案などを提示してくれるため、QAチームの想像力や直感力を損なうことなく活動することができます。

また、共同代表の久保がQAチームのあるエンジニアリングチームを経験していることもあり、会社のQAチームの活動に対する理解があるため活動しやすい環境となっています。

7. おわりに

今、Ubie のQAチームでは、テストからリリースまでのサイクルがタイトなスケジュールになっていることが課題のひとつとなっています。現状では一定の品質を満たせてはいますが、開発エンジニアのメンバーが増えて開発力の向上し、合わせてプロダクトの拡大によってこのままでは品質が保てなくなる可能性があります。

この note を通してQAチームの活動に持っていただき、状況を先読みしながら開発プロセス改善やQAチームを開発チーム一丸となって大きく成長させていけるQAエンジニアのご応募をお待ちしております。

是非エントリーフォームからご応募をお願いします。まずは気軽に話を聞いてみたいという場合はカジュアル面談を設定させていただきます。

また、おそらく以下のような事に興味があるとマッチするのではないかと思います。

 - 医療の現場の課題を解決して社会貢献をしたい
 - スタートアップ企業で大きな裁量を持って様々なことにチャレンジしたい
 - スピード感のある開発プロセスの中で適時最適解を選んでいきたい
 - QAチームを組織化して品質に関する多くの課題を解決したい
 - 品質の重要性と品質を改善するQAチームの存在を根付かせたい
 - 技術的なチャレンジでスキルアップしていきたい

会社資料や他のメンバーの発信など

▼Ubie株式会社 求人一覧

▼会社紹介資料

▼ソフトウェアエンジニア募集

▼Ubie メンバー発信まとめ


この記事が気に入ったらサポートをしてみませんか？