事業部からQAエンジニアにジョブチェンジした話

こんにちは。株式会社メドレーでQAエンジニアをしている内堀です。
こちらの記事は「MEDLEY Summer Tech Blog Relay」の8日目の記事です。
https://developer.medley.jp/entry/2025/08/15/20250815/

はじめに

私は2021年9月にメドレーに入社し、カスタマーサクセスチームで導入支援やカスタマーサポート等を経験した後、2025年1月にQAチームに異動を決めました。
この記事では、ジョブチェンジの経緯や、約半年QAエンジニアを経験して感じていることについて書きたいと思います。

なぜQAを選んだのか

きっかけ

私がQAに興味を持ったのは、事業部での経験からです。
当時、プロダクトの新機能のリリースに際して受け入れテストを行うことが多くあったのですが、要件定義・開発のフェーズが終わった段階でユーザーの運用を考慮したフィードバックをプロダクトに反映させることの難しさを感じたり、顧客にとって満足のいく品質は何か？について悩んだりすることがありました。

また、レセコン一体型^[1]カルテへのユーザー移行を推し進める中で、様々なユーザーの声を耳にし、「レセコンの品質」についても自分の考えを深めることがありました。
さらに自分自身のキャリア形成にも悩んでいる時期だったので、職種を変えることを含め、キャリアを模索していました。

以上のような悩みから、プロダクトの品質に目を向けることが多くなり、メドレーのQAチームはどのような業務を行なっているのか？という点に興味を持ちました。

QAを選んだ理由

そんな折、当時の上長に提案されたのが開発部への異動でした。
メドレーの開発部には開発職を始めプロダクトマネージャー職やQAエンジニア職が含まれますが、なかでもQAエンジニア職に興味を持ちました。

当時の自分にとっては思ってもいないキャリアでした。まずは、ソフトウェア開発経験がほぼない私が開発部に異動する道がある、という点に驚き、ありがたい話だと思いました。また、受け入れテスト等で行なっていた検証観点（今思えばかなり自己流だったかもしれません）がQAチームの目に留まっていたということも自信になりました。
こういった柔軟な人事や、メンバーのチャレンジの背中を押してくれるのは、メドレーの良いところだなと感じます。

受け入れテストやレセコン移行でドメイン観点を踏まえた品質への意識が強くなっていたこともあり、事業部時代に積み上げた成果や経験をQAエンジニアとして活用してプロダクトの価値提供に貢献したいと考えて、QAエンジニアへのジョブチェンジを決意しました。

QAエンジニアを約半年間経験してみて感じたこと

品質を多角的に捉える

約半年間経験してみて、やっぱり「ドメインの解像度をあげること」がQAにおいて重要だなと感じています。

QAエンジニアとしてのテスト技術はもちろん重要で、そういった点で学ぶことは多くあります。
しかし、例えば「システムの入出力」「状態遷移」といった部分のみの観点になってしまうと、「ユーザーがこの機能をどう思うか？」という観点が抜けてしまう可能性があります。

「ユーザーがプロダクトにどのような価値を求めているのか？」「ユーザーはどのような運用でこのプロダクトを利用しているのか？」といった観点で顧客の解像度をあげ、ドメイン観点における使いやすさを目指すことが、顧客満足度の向上に繋げられると私は考えています。

キャッチアップの難しさ/楽しさと学び

ドメイン知識のキャッチアップ

医療ドメインのキャッチアップはとても難しいものです。私もメドレーで初めて医療ドメインに触れましたが、当時、呪文のような用語が飛び交うMTGに驚いたことを思い出します。
ただ、難しいからこそ学びは多く、日々新しい知識や気づきが得られることが、面白いし楽しいなと感じます。

特に医療という領域は、利用者が医師・看護師・事務スタッフなど多様であり、求める使いやすさや重視する観点も異なります。そのため、単に「システムが正しく動く」だけではなく、誰にとっても安心して使えるプロダクトを目指す必要があります。

QAエンジニアとして

また、QAにおける知識・テスト技法のキャッチアップも難しいものがありました。

ひとくちに「テスト」といっても内包する作業・技術はさまざまあります。テストの要求分析から始まり、設計を経て具体的なテストケースを作成していく活動が中心となります。
これらの概念は理解できても、実際の作業に落とし込んでいくところが難しいと感じていました。

どのように慣れていったかというと、自分が考えやすいように概念や技法を詰め込んだテスト設計のフレームワークを用意し、テスト対象の機能を当てはめて考えるようにしました。
最初に考慮したい観点を構造化してしまえば考慮漏れも減らせるし、自分の思考フローを安定させることもできると感じたためです。

例えば以下のような流れで考えたりします。1についてはテストフェーズよりも前の要件定義段階から確認できるように動くことを意識しています。

1. 要求/要件定義と合致しているか確認
   • 期待値の確認
   • UX観点・顧客運用観点
2. コンポーネントの振る舞い確認
   • テキスト入力/出力なら「空白」「大量の文字」など単体テストレベルのものから顧客のユースケースを考慮した振る舞い確認
   • 特定の条件で状態遷移が変わる場合は条件の境界値分析を利用した確認、など
3. 非機能要件の確認
   • 処理速度
   • OS/ブラウザの差分
4. 結合観点の確認
   • 関連の深い機能と一緒に動かしてみる、など

QAとしてテスト設計を行う際にはQAエンジニアとしての技術も適用しつつ、「この機能は現場でどう利用されるのか？」を想像しながら取り組むことで、単なる不具合検出の活動ではなく顧客にとってより良い価値を生み出す活動ができると感じています。

まとめ

QAエンジニアとして半年を経て思うのは、品質とは単なるバグの少なさで捉えるものではなく、ユーザーや事業にとっての価値のあるものをいかに届けられるかも重要な観点のひとつだということです。

カスタマーサクセスチームで培った経験は「顧客や現場の解像度を上げる視点」として今のQAキャリアに息づいています。
また、プロダクトに反映させるだけでなく、「顧客にどう届けるか」（顧客向けの案内ドキュメントや、プロダクトのヘルプ記事など）も価値を届ける上で重要なポイントだと思っていますが、カスタマーサクセスの経験を活用できていると感じています。

今後も、QAとして必要な技術的なスキルやテスト知識も磨きながら、ドメイン知識とQA技術の両輪で品質向上に貢献できるエンジニアを目指して挑戦を続けたいと思います。

同じような悩みをお持ちの方が読んでくださっていたらお伝えしたいのは、カスタマーサクセスの経験があるからこそQAで発揮できるバリューがある、ということです。
背中を押せる内容になっていたら嬉しいです。

最後まで読んでいただき、ありがとうございました。

明日の「MEDLEY Summer Tech Blog Relay」の記事は、人材プラットフォーム本部 山下さんです！

脚注

1. 「レセコン」とは主に診療報酬における計算や、レセプトと呼ばれる診療報酬の請求書を作成するコンピュータを指します。電子カルテの機能（主訴・所見や処置行為の記録など）と、レセコンの機能（会計・レセプト）を一体化したカルテをレセコン一体型カルテと呼んでいます。