こんにちは。もうすぐ二年目になる新卒QAのbit0です。 2月12日にオンラインで開催された「現場から学ぶ “QAのリアル” LT」を視聴しました。 本記事では、そこで得た学びと、今後の自分のアクションについて備忘録も兼ねてまとめます。
参加のきっかけ
今回このLTに参加した最大の理由は、「新卒1年目のQAエンジニア」が登壇されていたことです。
大阪でもQA関連のイベントはありますが、自分と同じ立場の人が、現場でどのような壁にぶつかり、どう乗り越えているのかを直接聞ける機会は多くありません。
同じ「1年目」という立場で、
- どのフェーズに関わっているのか
- どのような視点でプロダクトを見ているのか
- どんな学びを得ているのか
自社の状況と比較しながら知りたいと思い、参加しました。
登壇内容と自社との比較
登壇者のTrabbieさんは、サイボウズ OfficeのAndroidアプリチームで活動されています。 新卒1年目ながら、開発の非常に早い段階からQAが関与する体制が整っている点が印象的でした。 中でも気になったポイントをいくつかあげてみます。
デザイン段階でのQAの関与
特に印象に残ったのは、デザイン段階でのリファインメントにQAが参加していることです。 デザイナーが作成したUI案に対して、
- 文字数が長い場合の表示崩れ
- タップ後に戻ったときの挙動
- 想定外操作への耐性
といった観点から、デザイン時点でフィードバックを行っているとのことでした。
実装後に見つかる不具合を、仕様検討段階で未然に防ぐ。 QAが「テスト担当」ではなく、「仕様の検討メンバー」として機能している点に強く刺激を受けました。
マインドマップによる観点整理
テスト観点の洗い出しにマインドマップを活用し、開発チームと認識を合わせている点も印象的でした。
単にテストケースを書くのではなく、 「どんな観点でプロダクトを見るのか」を可視化することで、チーム全体の理解を揃えている。
QAの価値は“実行”だけでなく、“整理”や“構造化”にもあるのだと再認識しました。
自社の現状と目指すべき姿
今回のLTを通じて、自分の中で「シフトレフト」という言葉の解釈が大きく変わりました。
現状：守りのシフトレフト
現在、私のチームでもシフトレフトを意識しています。 しかし実態としては、PMから共有された仕様に対して、
「この挙動はどうなりますか？」 「このケースは想定されていますか？」
と確認する、いわば“受け身”のシフトレフトでした。
情報を早めに取りに行くことはしているものの、 あくまで、決まった内容を確認したり、そもそも仕様として決まっているかを確認する動きにとどまっていました。
目標：攻めのシフトレフト
登壇内容を通じて気づいたのは、真のシフトレフトとは、降りてきた情報を確認することではなく、仕様が固まる前に入り込み、不具合の種を摘み取ることだということです。
デザイン段階からQAが関与することで、
- 実装後の手戻りを減らす
- テストしづらい設計を未然に防ぐ
- チーム全体の品質意識を引き上げる
単に「早く動く」ことではなく、 「上流で影響力を持つこと」こそが本質だと感じました。
少人数QAだからこその生存戦略
私たちのチームはQAの人数が多くありません。 そのため、どうしても目の前のテスト実行に意識が向きがちです。
しかし、人数が少ないからこそ、
- 後工程での手戻りコストを減らす
- 修正と再テストの負担を最小化する
- リリース速度を守る
これらを実現するために、上流工程への関与は避けて通れないと感じました。
要件定義やデザインリファインメントの段階で、
「この仕様だとテスト観点が不足しそう」 「このケースは考慮されていますか？」
と声を上げることは、 自分たちの工数を守る行為であり、 結果としてプロダクト全体のスピードを上げる行為でもある。
それは理想論ではなく、少人数QAにとっての“生存戦略”なのだと強く実感しました。
今後に向けて
今回のLTを通じて、自分の立ち位置を客観的に見直すことができました。
テスト実行の精度を高めることはもちろん重要です。 しかしそれ以上に、
- どのタイミングで関わるか
- どの情報を握るか
- どこに問いを投げるか
この視点を持つことが、QAとしての成長に直結すると感じています。
「1年目だからまだ関与できない」ではなく、 「1年目だからこそ、今から関与する姿勢をつくる」。
今回の学びをきっかけに、 受け身のQAから、上流で価値を出せるQAへと一歩踏み出していきたいと思います。
