はじめに
こんにちは。MAIと申します。
私のキャリアの大半は営業事務職でしたが、ユーザー側としてシステムの機能改善の打ち合わせに関わるようになったことをきっかけに開発分野に興味を持ち、QAの仕事を始めて3年になります。
タイミングよくQAに挑戦する機会を得たものの、当時担当したプロダクトにQAの先輩は不在。開発者自身が実施していたテストを巻き取る形で、過去のテストケースを参考にした完全な「自己流」でのスタートでした。
基本から学ぶ機会がないまま、「これが正解なのだろうか？」という違和感。新しく仲間が増えても、体系的な知識がないため、うまく教えることができず、技術やノウハウをチームとして繋いでいけないもどかしさ。
そんな思いを抱えていた私がエン・ジャパンに入社し、経験することになったのが、1ヶ月間にわたる手厚いオンボーディングでした。
この記事が、
- 開発やQAの仕事に興味があるけれど、どう立ち上がればいいか分からない方
- 未経験や経験の浅いメンバーを、どう受け入れ育てていけば良いか悩んでいるチームの方々
にとって、少しでもヒントになれば嬉しく思います。
QAとして再出発：1ヶ月の準備期間で見えたこと
1.「即戦力」より「土台作り」。焦らず準備できた1ヶ月間
入社して驚いたのは、最初の1ヶ月間がまるごとオンボーディング期間として用意されていたことです。
営業事務職時代は入社翌日にはOJTが始まり、前職でQAチームへ異動した時も「これが今までのテストケースです。とりあえずやってみて！」と、すぐに手を動かすことを求められました。だからこそ、新しいメンバーを迎える時も「とにかく手を動かしてもらうこと」が当たり前だと思っていたのです。
そのため「え、1ヶ月も！？」と驚きもありましたが、この手厚い期間があったからこそ、私は焦らずに知識を吸収し、土台を築くことができました。
また、事前に1ヶ月の計画が示されていたので、「次に何をしたらいいのだろう。誰に聞いたらいいのだろう」という焦りを感じず、安心して取り組めたのだと思います。
1ヶ月間のオンボーディング計画
2. 「受け身」では終わらない。自ら学ぶ姿勢が成長の鍵
私たちのオンボーディングは、コンテンツを自分で見聞きし、読み進めるのが基本スタイルです。
オンボーディングと並行して担当予定のスクラムイベントに参加していたため、日によってオンボーディングに充てられる時間は異なりました。しかし、それも考慮された上でスケジュールには十分な猶予がもたれており、自分のペースでじっくり考え、理解を深めることができます。
「座学」と聞くと受け身の研修だとイメージされるかもしれません。しかし、「受け身でいては何も得られない」 のです。この環境を最大限に活かすには、自ら学ぶ意欲が不可欠です。
そして、その意欲に全力で応えてくれる環境が、ここにはありました。
3. 一人にしない。「いつでも聞ける」という安心感
自分で進めることが基本とはいえ、決して一人で放置されるわけではありません。
Slack上に私専用のオンボーディングチャンネルを作ってもらい、疑問点を投稿すればすぐに先輩メンバーが返信をくれました。「直接質問したいな」と思えば、朝会や短いミーティング（ハドルなど）で快く時間を作ってくれるのです。
この「いつでも、誰にでも聞ける」という心理的な安全性が、経験の浅い私にとって何よりの支えでした。
主体的な学びと、手厚いサポート。この両輪が揃っているからこそ、人は安心して成長できるのだと実感しています。
専用オンボーディングチャンネル。不明点をどこで誰宛に聞けばよいか明記されていて安心できた。
オンボーディングを終えて気づいた、本当の「貢献」
1. 「銀の弾丸」はない。だからこそ「マインド」を整える
「経験が浅いことは理解してもらっている。でも、一日も早くチームに貢献しなければ」と、入社して間もない頃の私は焦っていました。
しかし、1ヶ月のオンボーディングを終えて、その考えは大きく変わりました。この期間は、すぐに成果を出すための 「銀の弾丸」のようなスキルを身につける場ではなかったのです。QAエンジニアとしての「マインド」を整える大切な期間でした。
これまでの私は、「QAはテストをしてバグを見つけ、完璧な状態でリリースする門番としての役割」が求められていると思っていました。だから、テストスキルばかりを追い求めていたのだと思います。
しかし、このオンボーディングを通じて学んだのは、テストは開発チームや関係者に安心を届けるための一つの「手段」に過ぎないということ。そして、チームが同じ方向を向く「マインドセット」を共有することのほうが効果的だということです。
スキルは後から身につけることができます。専門用語が分からなければ、調べたり聞いたりすればいいのです。一方で、「考え方」や「概念」といったマインドの部分は、そもそも疑問に思うこと自体が難しく、一人で考え、修正していくのは困難です。
最初にこの土台をしっかりと築けたことが、今の私の大きな自信に繋がっています。
2. オンボーディングは「終わり」じゃない。バトンをつなぐ
オンボーディング期間が終わると、いよいよ本格的にスクラム開発に参加します。
しかし、オンボーディングはこれで終わりというわけではありません。
オンボーディング後には大切な役割があります。
それは、先輩から受け取ったバトンを、次の仲間がもっと走りやすいように磨いて渡していくことです。
主に以下の2点を実行しました。
- オンボーディングの良かった点、改善したい点をチームにフィードバックする。
- そのフィードバックをもとに、自分の手で資料を修正・アップデートする。
これらは、得た知識を整理する絶好のアウトプットの機会になります。そして、私自身がしてもらったように、次の人がもっとスムーズに理解できるように資料を最新化していくのです。
具体的には、複数箇所に点在していた画面遷移図を1箇所に集約し、画像の最新化やオンボーディング時点で必要な情報に絞ることで、サービスの流れが分かりやすい内容に変更しました。
この 「バトンをつなぐ文化」 を、これからも大切にしていきたいです。
おわりに：これからの私と、未来の仲間たちへ
ここまで、私の体験したオンボーディングについてお話ししてきました。
「即戦力」という言葉は魅力的ですが、経験が浅いからこそ、先入観なく新しい知識や文化を柔軟に吸収できるという側面もあるかもしれません。大切なのは、技術（スキル）とマインドのバランスなのだと、この1ヶ月で痛感しました。
今取り組んでいる「探索的テスト」のような手法は一朝一夕で身につくものではありません。「この手順で実行すればよい」というマニュアルもありません。日々の積み重ねが不可欠です。
しかし、チームと自分の向かうベクトルが揃っていれば、その成長速度は格段に上がると信じています。
もし、この記事を読んでくださっているマネージャーの方がいらっしゃれば、ぜひオンボーディングを通じて「自分たちの組織が目指すQAの姿」を新メンバーに示してあげてほしいと思います。
とはいえ、私自身はまだまだ修行中の身です。QAとしての明確なキャリアパスを、まだ描けているわけでもありません。今も悩み、模索している最中です。それでも、一つだけ確かなことがあります。
それは、どのような関わり方であれ、「作り手の価値観の押し付けではない、ユーザーにとって本当に優しいプロダクトづくりに貢献したい」 という想いです。
今は、私のおせっかいな性格を活かして、開発チームをあたたかい雰囲気で包み、プロダクトマネージャーの追い風になれるような存在を目指していきたいと思っています。
この記事が、誰かの新しい一歩や、チームづくりのヒントになれば、これほど嬉しいことはありません。
最後までお読みいただき、ありがとうございました。
Discussion