この記事はHubble Advent Calendar 2025の14日目の記事です。

1. はじめに

HubbleにQAエンジニアとして入社してから、気づけば4ヶ月が経ちました。
私は以前、SESとしてクライアント先のプロジェクトに参画しており、自社開発のQAは今回が初めての挑戦でした。

この記事では、「私が感じたSES案件と自社開発の違い」 と 「Hubbleに入って変わった品質の捉え方」 を中心にまとめたいと思います。

この4か月の中で、環境が変わると同じ“QA”でも求められる視座や役割は大きく変わるのだと強く感じました。
その気づきを共有することで、同じようにSESから自社開発へ挑戦しようとしている方の少しでも参考になれば幸いです。

2. 私が感じた「SES」と「自社開発QA」の違い

私はHubbleに入るまでは、SESとしてクライアント先の案件に参画し、主にWebアプリのテスト工程を担当していました。

これらの現場では、
「仕様書や設計書を正しく理解してテストを作ること」　
「作成したテストを期間内に高い精度で実行すること」　
が主な役割で、上流工程に関わることはありませんでした。
（あったとしても、仕様書に記載されていないエッジケースや細かな挙動について質問し、仕様検討漏れを補うことくらい）

そのため当時求められていたスキルとしては、

仕様書・設計書を正しく読み取る理解力
それをテストケースに落とし込む言語化力・設計力
プロダクトの機能を幅広く把握し、操作を具体的に想像する力
正確なテスト実行力

といった決まった仕様を正確に形にする力が中心で、仕様に対しては受け身のスタンスでいることが正しい在り方だったように思います。（私がいた現場での話ですが）

このような“受け身で仕様に向き合う働き方”に慣れていた私ですが、
自社開発の現場に来て最初に感じたのは「QAとして関わる位置の違い」でした。

Hubbleでは、なるべく早い段階でQAにも仕様が共有される流れになっています。

そのため、仕様を読んで気になった点を早めに伝えたり、ユーザー体験的により自然な動きがあれば提案するといった動きがしやすくなり、
結果として、QAも “プロダクト・機能を一緒により良くしていく” という姿勢で上流から携わることができているように感じています。

この関わり方の変化は私の中の
「品質」そのものをどう捉えるかにも影響を与えました。
ここからは、Hubbleに入って特に実感した「品質の捉え方の変化」についてまとめたいと思います。

3. Hubbleに入って変わった「品質の捉え方」

自社開発の現場に入って、私が特に大きく変わったと感じているのが
“品質”という言葉の意味そのものでした。

SESの頃の私は、正直なところ
「テストがすべて通れば品質が担保できている」と考えていました。
不具合がないこと＝品質、というシンプルな認識です。

しかし、Hubbleで働く中でその認識は大きく変わりました。

・改善提案が歓迎される環境で品質の視点が広がった

Hubbleでは、不具合や気になった挙動を報告するときに
QAからどう直すのが良さそうかも合わせて伝えることが良いこととして受け入れられます。

ユーザー体験的にこのような動きにした方がよいのではないか
既存機能との流れを踏まえると別の制御の方が整合が取れそう
今後の拡張を考えると、こうした方がもっといいかも

といった補足が“やりすぎ”ではなく、歓迎される文化です。

報告までで終わっていた頃より求められるレベルが上がり、
品質は「動作の正しさ」だけではないのだなと気づきました。

さらに、この姿勢はHubbleが大切にしているValueの
「圧倒的顧客理解」・「プロダクトへの矜持」・「ブランド・クオリティ」にも深く結びついていることに気づきました。

仕様どおりならOKという認識では、Valueを体現していることにならない＝品質を保証できているとは言い切れない
と感じるようになったことが、自分の中で大きな変化でした。

・ “テスト”と“品質”は同じではないと理解するようになった

こうした経験を重ねる中で、
テストは品質を構成するひとつの要素ではあるけれど、
品質そのものはもっと広い概念だということに気づきました。

UXとしての自然さ
他画面・他機能との整合性
将来の拡張のしやすさ
ブランドとして誇れる細部のこだわり

といったものがすべてつながって判断されるものだと感じています。
“問題がないか確認する” だけでなく、
“このプロダクトとしてどうあるべきか”を考える・提案することこそ
品質を保証することなんだと自然と意識が変わっていきました。

4. 足りないプロダクト知識をAIで補いながら理解を深めた方法

とはいえ、提案や整合性の確認を行うためには大前提として
プロダクト全体の理解が欠かせません。

（今もそうですが）入社したばかりの私は、
画面構成や仕様の背景など把握できていない部分ばかりで、
懸念点を出したり提案するための土台が十分ではありませんでした。

そこで大きな助けになったのが、 Notion AIの活用です。

Hubbleでは仕様書や設計書を Notion で管理しているため、
Notion AIに、

影響がありそうな画面や機能がほかにないか
同じような動きを持つ既存メニューはどれか
過去に似た仕様があったかどうか

といった問いを投げて、関連情報を広く・早く把握するための補助として使っています。

こうすることで、
自分がまだ知らない関連箇所や、見落としがちな観点にも気づけるようになりました。
これはテスト漏れの防止になるだけでなく、
知識が追いついていない段階でも、
仕様に対して気づいたことを伝えやすくなったと感じています。

5. おわりに

HubbleのQAとして働くようになって、
同じ“QA”でも求められる視点や関わり方が大きく変わることを実感しました。
品質の捉え方も少しずつ変わってきたように感じています。

もちろん、まだまだ課題もたくさんありますが、
この4か月で学んだことを日々の業務でもっと体現できるよう、
AIの活用も含め、レベルアップしていきたいです。

この記事が、SESから自社開発に挑戦してみたい方にとって、
「こんな変化があるんだな」とイメージを持つきっかけになれば嬉しいです。

明日は@koyakota1031さんです！