QAエンジニアがバックエンドエンジニアにジョブチェンジする話
はじめに
こんにちは！
グロービスでナノ単科のバックエンドの開発を担当しています、nanoチームの矢島です。
以前、この記事にもあるようにテスト自動化を担当するQAエンジニアをしておりましたが、バックエンドエンジニアにジョブチェンジしました。
今回の記事では、「QAエンジニアからバックエンドエンジニアになること」を通して得た知見を皆様に共有したいと思います。
QAからバックエンドになった背景
キャリアの最初は、第三者検証会社のテスターからIT業界に入り、テストエンジニア、テスト自動化エンジニアといろんな役割を経験しました。
その中で共通した経験は、開発エンジニアが作った機能や仕組みを自慢げに紹介する姿を見て、僕も「その機能、そのサービス僕が作ったんやで！」っていつか言いたいと思っていました。
作られたものを評価をするのではなく、自分でコードを書いて、評価される側にいくことがいつしか夢になりました。
また、QAエンジニアとして働く中で、「開発の中で、動いたほうがいい品質保証のあり方があるのでは？」と考えており、以下のような疑問をなかなか晴らせずにいました。
・なぜ、単体テストは書かれないのか？
・なぜ、品質が置き去りになってしまうと感じる事象が起きるのか？
・ウォーターフォールから、アジャイル、DevOpsと時代を経るにつれて、なぜどんどん早く小さくリリースしていく必要があるのか？
実際開発に近づくためのキャリアパスとして今まで、SeleniumやAppium、MagicPodなどを利用したテスト自動化や、開発ワークフローの整備など、開発者に近い動きを行ってみましたが、プロダクトの開発者になってみないと具体的な理由はわからないだろうという仮説が背中を押してくれました。
バックエンドエンジニアとしてジョインする上でどのようなハードルがあったか？
グロービスの開発組織では、Ruby on Railsでほとんどのサービスが運用されていました。
開発者になるにあたり、テスト自動化で扱ってきたRubyに関する知識を活かせるバックエンドエンジニアになることが次のステップとして一番良いと考えていましたが、コードがある程度書けるからといきなりなれるわけではなく、以下のハードルを越えねばなりません。
- 技術的な要因
- テスト自動化や自宅開発は続けてきたものの、業務上でプロダクトコードを触る経験がないと、開発歴はほぼ0と同じ扱いになること。
- Ruby on Railsは触ってきているものの、フロントエンドもある程度の理解が必要なこと。
- 組織的な要因
- 育つためには実績が必要だが、そもそも実務経験を積む場所を探し方がわからないこと。
- 実績もなくアウトプットを保証できない状態では異動願を出すことも難しいと思われたこと。
実務経験が必要だが、実務経験を積むことができないことに悩んでいたところ、ナノ単科を開発しているチームのマネージャーが声をかけてくださいました。
「業務の隙間時間で学習をし、シニアエンジニアに様子を見てもらいながら実績を作る。」
その結果を見て異動を検討するという提案でした。
ちなみにそのシニアエンジニアはこの記事を書かれているyinさんです。
その後、すり合わせた学習方針として、以下のトライを行いました。
- Railsのtutorialの実施
- Flutter tutorialでの学習
- Udemyでのアプリ開発における勉強
- 開発チケットをもらい、PRを出して開発活動に参加する
- （計10件程度、文字修正程度から、機能修正レベルまで対応しました。）
- プロダクトコードの読み込み及び、利用技術の質問を1on1で定期的に確認を行う。
これらのトライを重ねてある程度実績を作れた段階で、移動が決定しました。
2022年3月ごろからトライし始め、受け入れ決まったのが2022年の6~7月ごろでしたので、３ヶ月ほどかかった計算になります。
晴れて実績を作れた状態で2022年10月にnanoチームへ正式にジョインを果たすことができました。
バックエンドエンジニアになったわかったこと。
開発に来て一番感じたことは、「事業インパクトへの意識の違い」です。
「今取り組む作業が一番、事業へインパクトがあるのか？」という問いがエンジニア間でも、PdMとの会話でもよく話題になります。
特によく出る会話は以下のようなものです。
・ROIは良いか？
・他のタスクよりもユーザーにとって価値があるのか？
ビジネス的な事業インパクトを考えつつも、システムの健全性や品質を担保する思考を同時並行で進めなければなりません。
QAであった頃は企画でどの施策が採択されるかは知らず、目の前の機能や仕様に関して集中を行うことがきましたが、開発者になってからは、ビジネス要件とシステム要件をできるだけ擦り合わせた形でアウトプットすることに苦心しています。
そして、苦心してリリースした機能をバリバリ使われているログを見て、事業へインパクトを出せているなという貢献感も同時に得ることができるようになりました。
このような環境の中で、冒頭に出た疑問は解決することになります。
- なぜ単体テストをかかれないのか？
- 開発初期は複雑ではなく、仕様をゼロから知っているメンバーで固まっている場合それほど単体テストが必要でないことがある。
- プロダクトが大きくなる中で、仕様が複雑化し、人が入れ替わった結果、テストが必要な段階になることがある。
- なぜ、品質が置き去りになってしまうと感じる事象が起きるのか？
- 全てはユーザーが価値を得るために開発されており、ユーザーがより大きな価値を得られる場合に、QAが用いる「品質」は稀に引き換えになってしまいます。
- この「品質」というワードが厄介なのですが、なんとなく一つの大きな指標のイメージされることが多いですが、品質は様々な指標の集合体です。
- この集合体の一部が少し下がったところで全体への影響度があまりない場合は優先度が上がりにくくなります。
- 特に引き換えにしてもユーザーが困らず、より大きな価値を得られるという点で引き換えは悪いことではないし、全体的な視野を持てていなかった私の至らなさを知るきっかけにもなりました。
- アジャイルの仕組みにおいて、なぜどんどん早く小さくリリースしていく必要があるのか？
- 体験して感じることですが、明らかに早く小さくリリースした方が、良いと感じます。
- 理由としては以下のような理由でした。
- 小さくリリース、トラブルがあればリバートできることで、壊れている機能を特定しやすくなり、ユーザーがサービスを利用できない状態のインパクトを下げることができる。
- 管理者も含むシステムの利用者の反応を見つつ、小さく修正できること。
- ブランチのコンフリクトがしにくいことでマージミスが減り、手戻りが低下する。
- なぜ、近年アジャイルからDevOpsに進んでいくのか、教科書通りの知識は持っていたものの身をもって体感することができました。
仕事の優先順位などはあることは承知していたものの、多くの案が出ては一つの案になり、さらにそこから優先順位付けして、顧客に届く機能はごくわずかです。
PMやデザイナー、エンジニアなどが選びに選び抜いた機能をリリースしているのだとは知らなかったということが、過去の私の目線ではわからなかったことでした。
今日も事業インパクトを考えつつ、開発活動を行っているたくさんのエンジニアがナノ単科の裏では動いています。
今後の課題
開発として、取り組む中で、自分のバリューを出していくために、私には以下のような課題があります。
ビジネス優先度がどのように決まるのかの知識の浅さ
開発経験の少なさ
顧客のために、仕事をしているとはいえども、どんな価値を提供するのかは方法が無数にあるためその選定やアイデア出しなどの話題についていくので精一杯な瞬間があります。
また、実現方法においても、今後開発を続けていくことで鍛錬を積みつつ、テストやインフラなど、ビジネス価値の創出をサポートする役割だけではなく、価値そのものを生み出す技術力は今後も成長させていき、より貢献して、チームみんなで成果を喜べる機会を作れるエンジニアを目指していきます。
グロービスで一緒に働く仲間を募集しています！
グロービスの開発組織では、一緒に働けるエンジニアを探しています！
まずは、カジュアル面談を通して、あなたに合う組織かどうか確かめてみませんか？
https://recruiting-tech-globis.wraptas.site/
この記事が気に入ったらサポートをしてみませんか？