microCMSでのQAエンジニア募集
microCMS FMは、ヘッドレスCMSサービス であるmicroCMSで働く人たちが、
普段どんな雰囲気やカルチャーで、 そしてどんな思いを持って働いているかを、
雑談を通してお届けするトーク番組です。
こんにちは、メインMCの下津 真鶴です。
普段はカスタマーサクセスグループで、 カスタマーエンジニアとして働いています。
はい、ということで、今回Sharp17というところで 収録していきたいんですけど、
もう早速呼び込んでいきたいと思います。
MCSの方、今回は大西さんと清水さんです。 よろしくお願いします。
よろしくお願いします。
はい、それぞれちょっと今回2人ですね、 開発チームの方からお呼びしたので、
軽く本当に一言、自己紹介だけ いただいてもよろしいでしょうか。
はい、大西です。
僕は開発グループ、エンジニアの組織全体を マネージャーしております。
よろしくお願いします。
お願いします。
マイクロシミュレーションの清水です。
今はプロダクトマネージャー担当してまして、 ちょうど入社4年ぐらいになりまして、
直近まではカスタマーエンジニアというところで お客さんと接する仕事をしていたんですが、
7月ぐらいからプロダクトマネージャーやってます。 よろしくお願いします。
よろしくお願いします。
清水さんも4年で、大西さんもほぼ それに近いぐらいの社歴だと思うんで、
かなり最古参のお二人って感じですよね、 メンバーとしては。
確かには結構そうですね。
経済的には感じになってるかもしれないですね。
昔から在籍してくれてるお二人をお呼びしまして、
結構過去の数回は、いろんな部署、 ビジネス的な部門とか、
エンジニアもそうですけど、いろんな方をお呼びして、 その人のキャリア観というか、
どうやってマイクロCMSに入社されたんですか、 みたいな仕事観とかを話してきたんですけど、
今回は採用のことをテーマに お話をしていきたいなと思っております。
何かと言いますと、現在マイクロCMSで、
いくつかの職種をオープンにして 募集をしてるんですけど、
その中でQAエンジニアという職種が一つございまして、
そちらの今回募集について、
マイクロCMSとしてQAエンジニアを どうやって募集するに至ったかという背景であったりとか、
今の現状のことをお話しできたらなと思っております。
顧客の要望とチームの変化
結構そもそものところなんですけど、
マイクロCMSでは今募集していて、
これオープンにしたのってどれぐらいの時期だったか とか覚えてますか。
ずっとあったわけじゃないと思うんですけど。
確か去年の秋ぐらいだったと思うんですけどね。
QAエンジニアとしてちゃんと枠を作ったのは。
1年ぐらい募集をし続けてるって感じですよね。
結構プロダクトエンジニアとかバックエンドエンジニアとかは、
結構割と早い目の段階から募集開始してたと思うんですけど、
そのあたりのチームというか構成とかも整備してきて、
改めてそういったタイミングでQAエンジニアを募集するに至ったかなと思ってます。
現状の背景のところもお伝えしていきたいと思うんですけど、
まずなんでQAエンジニアを募集するに至ったかみたいな、
大西さん的にはそのあたりどういうふうに捉えてらっしゃいますか。
はい、なぜQAエンジニアを募集し始めたかということですね。
そうですね、直接的には、
ここ2年とか1,2年とか2年とかで、
顧客が結構大手の会社とか観光庁的なところから使われ始めてきて、
結構品質が、ちょっと悪い言い方すると、
最初とかはちょっと落ちてもすぐ直せばOKみたいな雰囲気も
若干あったかもしれないんですけど、
さすがにそうは言ってられなくなってきているので、
顧客の変化みたいなところは結構大きいかなと思ってまして、
エンジニアだけで結構頑張ってた時もあるんですけど、
今も頑張ってるんですけど、
受け入れテストとか、
機能開発も結構加速してますので、
その辺のテスト、QAの段階の仕事が結構増えてきて、
それを全部エンジニアで分担してやるっていうのは、
なかなか厳しくなってきたので、
募集、そろそろちゃんと専任の方を募集したいなというので、
募集し始めましたかね。
ありがとうございます。
ビジネス的な観点で言うと、
どんどん大手のお客様が特に増えてきていて、
そういったお客様に対するご要望の品質保証のところをクリアする、
必要が結構出てきたというところで、
その辺りの対応が求められてきたというのと、
エンジニアチームの観点で言うと、
機能開発するチームとかも専任でというか、
ちゃんとチームとして機能するようになってきていて、
そこが高速で回っていく中で、
QAのところだけがちょっと置き去りじゃないですけど、
ちょっと手薄になってきてしまっていたみたいな、
QAエンジニアの役割と重要性
そんなイメージを抱いてますね。
清水さん的にはそこの大手のお客さんとかが増えてきてくださっていて、
QAのところの必要性を感じていたみたいな部分はありますか。
そうですね。それは間違いなくあるかなと思っていて、
あとはどうなったろうな。
結構初期の段階からQAエンジニア行った方がいいんじゃないか。
話は出てた気もしてはいて、
多分初期フェーズの方が品質的にはより低かったので、
そういう時代もちらほら上がってはいた気がするんですけど、
やっぱりそのフェーズって結構グロースするのが大事みたいな考え方も強かったし、
それはある意味正解でもあると思うので、
そういう中であんまり採用しようというところまで行かなかった中で、
ある程度規模が大きくなってきて、
実際に落ちちゃった時のビジネス影響がでかくなってきたというところが明確に見えてきたので、
そこはちゃんと整備していった方がいいねというか、
守りの仕事をやる人をちゃんとやった方がいいねというところは、
より輪郭がしっかりしてきたのかなという感覚であります。
確かにHeadless CMSっていうサービスの性質上、
結構大事なところにも使われてくる部分だと思うので、
そのお客さんのビジネスにおいて。
だから最初から全くそこは無視していたというわけでは全然なくて、
サービスを伸ばす上ではどんどん攻めのポジションのプレイヤー、
プロダクトエンジニアとか、
そういったところを重視していた時期が長くて、
そこの転換点が去年ぐらいのタイミングできたという、
そういった経緯ですかね、流れとしては。
こんな感じかなと思います。
了解です。
ちょっと1回背景とか整理できたところで、
1回ここで定義じゃないですけど、
QAエンジニアってここまで表現してきましたけど、
ぶっちゃけどういうことをしていく人なのかみたいなところも
お聞きしてみたいなと思ってまして、
各社もちろんQAエンジニアって置いてる職種のポジションの人、
いろんな仕事があって、いろんな定義あると思うんですけど、
一般的に言うとこうですみたいなのと言うと、
大西さん的にどういうふうにここは説明できると思いますか。
すみません、結構むずい質問をやられてるんですけど。
僕も正直QAエンジニアが一般的な言葉なのか、
さすがに最近使われてるとは、
言葉としては使われてるかなと思うんですけど、
中身具体的に何してるか結構会社ごとに全然違うかなと思ってます。
多分あんまり一般的にっていうのもないんかなと思うんですけど、
僕の想像では多分テストケース作って、
テストを実施する人を指してる、
いわゆるテスターとかを指してる会社の方が多いのかなと想像はしますけど、
自動化頑張るとか、アーティストの自動化頑張るとか、
そっち系の仕事もあるでしょうし、
ちょっとわからないですね、すみません。
一般的な話。
ありがとうございます。
ちょっとここで答え合わせじゃないんですけど、
一応チャットGBTの方に聞いてみたら、
QAエンジニアとはサービスの品質を維持・向上させるために重要な役割を担うポジションですという、
めちゃくちゃふとした感じで、
多分それ自体はあっていて、
作業レベルに落としてみると、
アーティストのところを自動的に作っていって回していくみたいな、
そういったポジションなのは間違いないですかね。
なので今出してるジョブディスクリプション、
Micro-CMSのQAエンジニアのジョブディスクリプションも、
自動テストの実装というところを全面に推してるというか、
お任せできる人を探してるという、
多分そういう感じになってるのかなと思いますね。
多分SaaSで他の会社さんもQAエンジニア募集されてると思うんですけど、
そこの自動テストですかね、
いろんなテストの種類ありますけど、
そこをやっていくっていうところは多分共通して、
QAエンジニアの方はミッションとして持っている部分ではあるんですかね。
なんか自分とか結構元々SIR的な文化にいたので、
そういう文化がQAエンジニアみたいな読み方って、
僕は聞いたことなかったなとは思ってて、
さっきのお兄さんの話でテスターみたいな言い方の方が強いというか、
それは多分あれですね、
SIRだとそもそも自動テストみたいな文化がそんなになかったりもする。
それは多分自宅開発なんで、
自社のプロダクトのデリバリーの効率を上げていくみたいなところに
そんなに意識が向かないというか、
結局自宅だったらテストをやることでお金をもらえるみたいなところもあったりするんで、
なんかその辺で僕は全然馴染みはなかったんですけど、
確かにSIRSであれば割と自動テストは入っているのかなとは思うので、
SIRSの中では結構近い認識というか、
ポジションなのかなとは思ったりはしましたね。
確かに僕も前自宅開発、自宅製作をやっている会社にいたときは、
自動テストを専任でやるみたいな人はいなくて、
大きなプロジェクトだったらテスト会社みたいなところに丸っと自宅をするみたいな、
結構そういったこともあったりしたので、
SIRSっていうビジネスモデルにもしかしたら特化したじゃないですけど、
そこにシューニングされた触手なのかもしれないですね。
ここほんと10年とかで確立されてきたポジションみたいな。
もしかしたらそうなのかもなと思いましたね。
マイクロCMS、ヘッドレスCMSサービスだったり、
会社のワークスタイルでいうとフルリモートとか非同期ワークとか、
QAエンジニアの特徴と必要性
そういったトピック要素あると思うんですけど、
そういう性質を考えると、
QAエンジニアを募集するときにどんな特徴を持ったポジションになるんですかね。
ヘッドレスCMS提供してるからこういった特徴があるみたいなのってあったりしますか。
ヘッドレスCMSだからっていうのはどうかな。
そこまでヘッドレスCMSだからっていうのはないかもしれないですけど、
24時間、どのサービスもそうか。
あんまないって言ってしまうとちょっとつまんない。
尖った特徴が別に求めてるわけじゃないっていう感じですかね。
そうですね、別にヘッドレスCMSだからっていうのはあんま思い込まないですね。
マイクロシミスでやってほしいのはこういうことみたいなのは特徴あることというか、
ありますけど。
シミスさんとか何か思いつきますか。
何ですかね。ヘッドレスといえども管理画面のほうでビューはあるので、
別にAPIだけやるとかでもないんじゃないので。
何かそういう意味だと一般的なウェブアプリケーションという感じではあるから、
際立っていうことはないかなとは思って。
ちょっと後ろで出たら申し訳ないんですけど、
技術的なスタックとかで言うと多分リアクトとか使ってるので、
まるっとHTMLをただ吐き出すだけのアプリケーションというか、
そういうふうにマークとかと比べると結構フロントエンドとかのテストは若干難しいとか、
何かそういう点はあるかなと思いました。
ちょっと思いついたのはCMSなんです。
結構お客さんがAPIのスキーマ決めたりとか、
結構入力されるデータの自由度はかなり高いかなと思ってました。
例えばECサイトとかって決まった画面でポチッというだけじゃなくて、
お客さんがこのAPIのフィールドを10個作りたいとか30個作りたいとか、
そのお客さん次第っていうところはあって、
データの自由度は結構高いので、
そこら辺はここら辺に意識が向く方であればよりいいなってちょっと思いましたね今。
いや確かそこめちゃくちゃ重要な観点だと思っていて、
でも特にやっぱりQエンジンが欲しいなって思うときって、
そういうきっかけだと思うんですよね。
多かったと過去思っていて、
何か予期せぬデータ入力されてエラーが起きてちょっとインシデントになってしまったであるとか、
お客さんが、何ですかね、本来はあんまりそういう使い方しないけど、
ちょっと特殊なユースケースで使ったときに、
我々としては意図せぬ危害が起きたみたいな、
多分そういったことは多々あるなと思ってまして、
確かにそこはおっしゃる通り特徴的な部分かなと思ってて、
未だにちょいちょいありますもんね。
このフィールド、確かにこういう入力されたらこうなるのかみたいなのとか、
まだちょっと全部の使い方を開拓というか把握しきれてない部分も多分あったりはして、
そういうところまで目を配らせられるような視野の広いと、
みたいなところが求められる要素なのかもしれないですね。
QAエンジニアの現状と課題
そうですね。
確かに。
APIの呼び出しパターンとかも保持されるデータ以外も結構クエリとか自由に組み立てられるんで。
確かに。
ちょっとそういう難しさがありますね。
管理画面とあと呼び出しの2つの軸でありますね。
大西さんさっきQAエンジニアそんなにめっちゃ解像度高くご自身も分かってるわけではないみたいなお話だったと思うんですけど、
そもそも採用とかってすごい難しいポジションなのかなと思っていて、
それは市場に少ないポジションだからとか、
いろんな要素あると思うんですけど、
QAエンジニアの採用の難しさみたいなところについてどう思ってますか、今のところ。
そうですね。
我々だと自動テストとか、
自動的に品質を担保するような仕組みを整えられる人みたいなのを結構求めていて、
まずやっぱりそういう人って市場に少ない。
1000件以上だと。
やっぱりテストケースを実施する人、テスターですね、さっき出てきた。
一般的にはそっちの方が数はおそらく多いと思うので、
単純に市場に少ないし、
メガベンチャーみたいなところとかがすごい今、
AIの文脈もあって、品質とかQAのところかなり力入れていて、
そっちに採用、すごいそっちに採用取られているっていうのもあるんじゃないかなと。
はい。
確かに。
ただあるテストケースを正常化、不正化みたいなのを見るっていうだけじゃないですもんね、全然求めることって。
そもそもそれを作っていくことから必要としているみたいなところがあって、
それは結構高いスキルだったり経験を必要とするポジションなのかなというのが多分背景になりますよね。
そうですね。もともとエンジニアやってて、何かのきっかけでQAに目覚めた方とかですね。
結構そういう感じの。
じゃないと結構ね、自動テストとかちょっとエンジニア寄りの、プログラマー寄りの話だと思うので。
そういう方じゃないといけないから、やっぱ少ないのは少ないですよね。
いや確かにですね。最初、コンピューターサイエンス的なことを学ぶ大学とかを卒業されて、
初手のキャリアでQAエンジニアってなかなか選びづらいというか、想像つかないですよね。
そうですね。
もうちょっとマイクロCMSの現状のところをフォーカス当てていきたいんですけど、
今って結局専門のQAエンジニアみたいな人はいないということであってますかね。
そうですね。
いないというところで、じゃあ誰が今そこの仕事を賄ってるのかというとどうなってますか。
今は各エンジニアが自動テスト書いたり、自動テストに関しては結構やってまして、
ユニットテストからE2テストまで結構やってるんで、一般的にも結構やってる方だとは思います。
それは今エンジニアが分担して実装してもらっていて、
新機能のリリース前とかにはマニュアルの手動テスト、受入テストと呼んでるものを今いる清水さんPMの方とかマネージャー陣がやったりして回しているという感じですね。
はい。結構直近だと清水さんもかなり受入テストのところを時間とってもらって見てくれてると思うんですけど、そういった認識であってますか。
そうですね。はい。大体同じ認識で。
あとはあれですかね。結構そのカスタマーサクセスのメンバー、それこそ下地さんとかもQAという枠組みに入るかわからないんですけど、
テスト戦略の重要性
お客さん視点でちゃんと期待した動きになっているかというところは見てもらっているので、そこは品質保証の役割は一定になっているかなと思います。
確かにそういった側面での品質保証はしてますかね。
確かに。
例えばじゃあここでQAエンジニアの方がもし上院されたとして、もっと清水さんとかの手も、
そのテストの部分はそういった方に異常していって、
もうちょっと未来の機能開発のことを考える時間であるとか、戦略のところをもうちょっと考えていく時間に当てられそうっていう、そんな感じありますか。
そうですね。ちょっと僕の希望としては、やっぱりそのプロダクトの方針というか、未来をちゃんと描いていくっていうのが多分一番大事だと思うので、
その仕様策定とかを多分やっていくべきではあるとして、そうなんですよね。
なので受け入れテスト、PDMが絶対見るっていうところは今後も続くというか、
ちゃんと仕様の想定というかとなっていくというのは多分見続けはすると思うんですけど、
確かにその割と機械的な確認、それこそCSVインポート、例えば今やってるんですけど、
カスタムフィールドと繰り返しフィールド対応しますみたいなやつって割と何でしょう、
仕様というよりかちゃんと動くかみたいなところだったりするので、
なんかその辺は結構切り出して見てもらえる人とか出てくるかなと思いますね。
しみさんも引き続き見つつ、全部を時間的にも労力的にもカバーできるというわけでは多分難しいと思うので、
そこを自動的にテスト組んで広く見てくれるような方がいるといいなと。
なんかすごい分かりやすくQEngineerを求めるタイミングで言うと、
今本当におっしゃったCSVインポートの特徴的なフィールド、カスタムフィールドとか繰り返しフィールドって、
Micro-SMSが提供しているAPIスキーの中でも特に自由度が高くて、
いろんな使い方されるようなフィールドだと思うので、
そういったところを重点的に見てくれる人がいるとすごいありがたいなとか思うんですけど、
なんかその他で言うと、例えばこういう人がいると今よりもっとこうなるか、
今ちょっとここがウィークポイントで、ここをちょっと穴埋めるような仕事をしてくれる人がいるみたいな観点で言うと、
例えばお西さんその辺はどういう見方がありますかね。
テストのカバレッジみたいなところもかなり高めてきてはいると思っていて、
結構どんどん整備されてきてはいると思うんですよね、今皆さんのお力で。
そこに対してどうやってプラスアルファをしていけるかみたいなところですかね。
そうですね、確かに自動テスト今かなり頑張ってはいて、
自動テストもちろんまだ穴はあると思うので、あるのでその辺埋めていくっていうのはそうなんですけど、
ただE2Eテストとかわかりやすいんですけど、結構エンジニアが新機能を作ったらそこのE2Eテストをバーって実装して、
どんどん増えていくだけみたいな、いわゆるテストピラミッド的にはそのE2Eテストをちっちゃくして、
ユニットテストをでっかくしてみたいな、そういうのがあるんですけど、
E2Eテスト結構肥大化しつつあるので、今って結構、とりあえず実装していきましょうみたいな感じで増え続けているので、
整理するとか、こういう方針でE2Eテストを書いていきましょうよみたいな旗振り役みたいな、
そういうのはやってもらいたいなって思いますね。
マニュアルのテストも、テストケースを蓄積はしているんですけど、蓄積されているだけで、
あんまり再利用するとか、テストケースを整理するみたいなこともあんまりできてないので、
そういったところができるとめっちゃいいなって思いますね。
仕事のレイヤーでいうと、抽象度が低い仕事だけじゃなくて、
レイヤーの高い、抽象の高い、もっと戦略的な、テスト戦略的なところも同時に考えられる人みたいなところがいるとめっちゃ、
今の状況にすごいフィットしそうって感じですかね。
そうですね。テスト戦略という言葉がぴったりだと思います。
多分結構今、テスト追加するという意識はみんなちゃんと持ってもらっているので増えてはいて、
QAエンジニアの重要性
それゆえに多分割と重複している処理とかも、もしかしたらあるかなっていう、
こっちで担保できてるけど、こっちでもやっちゃってるんで、多分増えてくるような気もしていて、
その辺の効率化とかバランス取ってくる人がいるとめっちゃいいんだろうなと思いましたね。
過去の経験としてはちょこちょこフロンテンドのテストを書いたこととかあったりするんですけど、
そこがピラミッド的にどんどん肥大化するみたいなところのデメリットってどういうのがあるんですか。
これちょっと興味があるところを聞いているんですけど。
そうですね。一番わかりやすいので言うと、E2Eテストって実行時間めちゃくちゃ時間かかるので、
我々だとリリースを毎日必要に応じて必要な回数、都度リリースしていく、
1日に3回とか4回とかリリースしてるんですけど、その都度E2Eテストを全回ししてるんですね。
今だと多分30分とか、10分、20分、30分みたいなオーダーで時間かかっていて、
結構きついというか、これが1時間とかなりだしたらもうさすがに無理だよねみたいな感じなので。
わかりやすいので言うと、実行時間がとにかく肥大化していくっていうところがありますね。
多分特に何もなく順調にリリースフローがどんどん流れてる状況だったら別に多分問題ないとは思うんですけど、
結構早めにリリース出したいとき、例えばインシデント対応とか重大な不具合とかあったりすると、
そこは見ると長くなってしまうとちょっとお客様に対しても屈合出てるというところはあるのかなと思いましたね。
テストしてる的なところで言うと。
そうですね。
なるほど。だからそこはただただどんどん増やしていけばいいって話じゃなくて、
適宜、ちゃんとストリーム化して必要なところを抑えてちゃんとテストを作っていくというところが必要なんだなと思いましたね。
ちょっとそうですね、いろいろお話してきた中で、改めてみたいなところになると思うんですけど、
ちょっとマイクロCMSのクールエンジニアとしてはこういう人が来て欲しいという求める人物像で言うと、
改めてそこをお伺いしてもいいですかね。ちょっとさっきも話した部分かもしれないんですけど。
そうですね。ちょっと今日話してないテーマとしては、生成AIみたいなところがあるかなと思っていて、
すごい一般論というかではありますけど、とりあえず動くコードみたいなのを作ることのハードルとかスピードとかって結構下がった、早くなったっていうのはあると思っていて、
なのでその機能を作る方っていうのはどんどん増えてはいくんだけどね。
結局誰がそれに対して責任を持ってるのかっていう。
ちゃんとパッと見動いてるけど大丈夫なんだっけみたいなところってあるので、
そこってまだしばらく絶対に人の目が入るっていうところはなくならないかなと思っていて、
その意味で今後のニーズとしてはプロダクトエンジニアよりもQAとかの方に傾いていく可能性って結構あるかなと思ってるので、
キャリアとしてもあるように面白いというか、結構現実でもあるというかっていうときかなと思っていて、
もちろん業務としてもテストケースの作成とか、既存のコードから自動テストをしたりとか、
AI使えるところって普通にたくさんあると思うので、
そういうAI時代でいろいろ変わっていく状況っていうところをある意味自由度高くできるポジションだと思うので、
そういうのを楽しみつつできる方が来るといいのかなと思いました。
だからある意味おいしいポジションじゃないですけど、長期的にキャリアを構築していく上ではかなり面白いポジションなのかなと思いましたね。
自動化と生成AIの未来
おにさん、そこの生成AIを使って、今も社内でもクロードコードとかコーデックスとか使ってる方とかもしかしたらいると思うんですけど、
そこを絡めたご意見と言いますか、旧エンジニアの立場みたいなところって現状どうお考えですか。
現状だと多分AIの文脈で旧エンジニアめちゃくちゃ需要増えてますよね。
確かに一般的にそうだと僕は理解してるんですけど。
なので旧エンジニアの経験自体はないけど、エンジニアプログラマーとして自動テストとか頑張ってたり品質のところ結構気をつけてやってたよっていう方が旧エンジニアとしてジョブチェンするのも結構いいんじゃないかなと僕は思いますけどね。
繰り返しになっちゃいますけど、やっぱり自動化がちゃんとできる方っていうのはすごい来てほしいなと思ってまして、テストして終わりみたいな感じだとちょっと効率的にも悪いので、
しかも会社的にも、もともとエンジニアだけの会社だったっていうのもあって、会社全体的に自動化にめっちゃ熱がある量が高いと言いますか、
いろんなものを自動化して効率化しようよっていう雰囲気がまだあるので、テストとかも手動でテストするんじゃなくて、一回テストしたら自動化されててその後は気にしなくていいみたいな、
どんどん自動化していくっていうのをやっていってほしいなと思うので、その辺興味ある方に来ていただけると嬉しいなと思います。
ありがとうございます。
もしちょっとでもご興味があるという方がいらっしゃいましたらですね、カジュアルメンナーからでも全然ウェルカムですので、
弊社の方にご一歩くださいというところで、今日はお二人を招きして旧エンジニアの採用してますというところのお話ができたかなと思いますので、この辺で締めたいなと思います。
マイクロCMS FMでは今後も社内のメンバーをゲストにお呼びしお話をしていきます。
番組のご感想は、X等でハッシュタグマイクロCMSunderbarFMをつけて投稿いただけると嬉しいです。
それではまた次回お会いしましょう。ありがとうございました。
ありがとうございました。
ありがとうございます。
