テスト活動を超えて、QAエンジニアが広げた3つの新たな領域
GO株式会社の堀と申します。
現在、QAエンジニアとして脱炭素サービス『GX（グリーントランスフォーメーション）』のQA業務を担当しています。
今回はQAエンジニアの知見を活かしつつ、直接的なテスト活動以外にも領域を広げる事が出来ている活動を紹介したいと思います。
私から見たGOという会社の空気感を知って頂きたいので、現在関わっている『GX』に関わらず、過去関わったプロジェクトであった出来事も含めて紹介したいと思います。
QAエンジニアとしてテスト活動以外にもチャレンジしたいと考えている方、
また後述しますがGOだからこそチャレンジ出来ている面があるのでそういった会社の空気感を知りたい方、
是非読んでいただけると幸いです。
『GX』のサービスについては以下をご覧頂けると幸いです。
QAエンジニアの知見を活かせている3つの活動
実際に私が行ってきた活動で、直接的なテスト活動とは別の領域で考えてみると、大きく分類すると3つ紹介が出来そうです。
①ビジネスも含めた上流工程からのmtg参加
②仕様の検討、整備、共有
③リリース起点での課題/スケジュール整理
①ビジネスも含めた上流工程からのmtg参加
まず1つ目の活動が「出来る限り上流工程からのmtg参加」です。
何かしらのシステムを開発する時の大まかな流れを考えると、下記が多いと思います。
ビジネス→PjM/PdM→開発＋QAエンジニア
この時、QAエンジニアでありそうなケースとしては、PjM/PdM&開発からのインプットでテストを行う事です。
上記の流れ自体は間違っていないと思いますし、他の領域は各領域のスペシャリストに任せて、自身の領域に集中するという考え方もあると思います。
しかし、私の場合は、これでは「勿体ない」と考えています。
実際、私が出来る限り上流工程からのmtgに参加する事で下記のような事がありました。
ビジネス的な温度感や意図を把握し、テスト含めた全体のスケジュール感の調整や、テストの強弱のバランス調整を行いやすくなった
プロジェクトのビジネス的な面での成長もより意識出来るようになった
QAエンジニアとしての知見を活かして提案を行い、実際にその提案が受け入れられる場合もある
1つ目にあげた内容は、分かりやすくQAエンジニアとしてのテスト活動に活かせています。
「品質が良いとはどういうことか」という話になりますが、1つの考え方として「発案者が思い描いていた事がイメージに近しい形で実現が出来ていて、実際に使用する人が不便が無く満足感を覚える」という考え方があると思います。
ここでPdMや開発は「発案者が思い描いていることを現実に落とし込む」と言う事を専門性をもってやっていると思いますが、PdMや開発からのヒアリングだとフィルターを挟んでしまう事になります。
発案者のイメージを直接把握していると「何が出来ていないといけないのか」が明確になるので品質検証の質も上がります。力の入れどころが分かりやすくなるという事です。
2つ目にあげた内容は、ビジネス的な目線をより理解でき、そういった視点でのプロジェクトの成長をより意識出来るようになるという事です。
QAエンジニアとしてテスト活動を行っていると「システムの品質をどれだけあげられたか」に目が向きがちです。システムの品質を上げるという事は大切ですが目的ではないと私は考えています。
何かしらの課題を解決するためにサービスは開発をされているわけで、そのサービスでより良いものを提供するために私たちはテストを行っています。
この辺り、ビジネス的な目線を得る事で、プロジェクトの成長と言う面もより意識出来るようなり、本質的な課題解決のためのテストを行う思考に至りやすくなると思います。
3つ目にあげた内容については、1つ目と2つ目はビジネス的な目線をテスト活動に落とし込めたという話ですが、逆にQAエンジニア視点を上流工程で活かす事が出来たという話になります。
QAエンジニアとしてテスト活動を行っていると、最新の仕様については人一倍詳しくなるかつ、実際に触っている時間が長い事もあり、よりユーザーに近しい気付きを得る場合も多いので、こういった面を活かしやすいです。
総じて、「QAエンジニアの領域⇔QAエンジニア以外の領域」のように双方向で効果があると感じています。
②仕様の検討、整備、共有
2つ目の活動は「仕様の検討、整備、共有」です。
前述しましたが、QAエンジニアはテスト活動を通じて得たナレッジはかなり有効活用できます。
テスト活動にだけ焦点を当てると、決められた仕様に対してテスト設計を行ってテスト実施と言う範囲にとどまりますが、この領域を広げるような活動も行えています。
仕様の検討
仕様の整備
仕様の共有
1つ目の「仕様の検討」ですが、①の活動の上流工程のmtgへの参加にもあたりますが、「開発での仕様検討のmtg」にも参加しています。
ここでも、ただ参加するだけではなく、「こういう仕様にしたらどうか」という意見をフランクに伝えるようにしています。
特にQAエンジニアとしてのナレッジとして強みを感じる一例としては下記になります。
システムの横の繋がりも理解出来ているので、どこに影響があるかに気づきやすい
パターンで考えた時の細かい部分の考慮漏れ
ユーザビリティ観点でのあった方がいい機能の提案
よくよく考えてみると、QAエンジニアとして培ってきた内容が活かせるのでは？と思って頂けたのではないでしょうか。
また、仕様の検討段階から入る事で、そのまま深い仕様理解にも繋がるので、以降のテスト作業がスムーズに行くようになったりもします。
ここでも「QAエンジニアの領域⇔QAエンジニア以外の領域」で双方向に活かせますね。
2つ目は「仕様の整備」ですが、これも手伝いをしています。
整理の仕方次第ですが、ポイントになってくるのは「現在、リリースされている最新仕様は何なのか」「リリース前の開発中の仕様は何なのか」が明確になっている事だと思います。
この辺り、実はQAエンジニアが整理に向いていると思います。
と言うのも、開発工程においてリリース直前の工程を担っているのがQAエンジニアです。よって、「最新のリリース基準で考えた時に、何がリリースされていて、これからどういう課題が来るのかについて」は一番QAエンジニアが詳しいと思っています。
PdM/デザイナー/開発の目線になってみると、それぞれ最新のリリースよりも少しあるいは遠い未来の事を考えないといけない場合が多いと思います。
立ち位置的に一番見えやすいQAエンジニアがこういったところを担う事で、効率が良く全体の生産性が上がると思うので、行っている活動になります。
3つ目は仕様の共有です。
ここまで何度かお話ししていますが、QAエンジニアはテストを通じて実際にシステムに触れる機会が多いので最新の仕様については詳しいと思います。
私の場合はビジネス関連の方への仕様共有会を行うなどしました。
実際に説明をして好評でしたし、逆に質問等で気づきもあったので、それを開発チームにフィードバックして更に改善なども行えました。
ここまでの話で、QAエンジニアとしてテストのために必要な仕様理解の深さも、実は色んな事に活かせるという事を感じてもらえたのではないかと思います。
③リリース起点での課題/スケジュール整理
3つ目の活動は「リリース起点での課題/スケジュール管理」です。
開発チーム全体での課題/スケジュール管理のmtgがあるのですが、そこでのファシリテートを私が行っています。
QAエンジニアが行っているのは珍しいかもしれないですね。
ここでの1番のポイントはQAエンジニアがこの役割を担うと「テストスケジュール起点でのプロセスマネジメントを行いやすい」という点だと思います。
前述しましたが、QAエンジニアはリリース直前の最後の工程を担うという事もありリリース起点でのスケジュール意識が強めになると思います。
具体例を挙げると、私の場合ですがQAエンジニアとして大まかなスケジュールを考える時に「リリース日→テスト実施期間→テスト準備期間&開発期間→仕様の検討」と言う風に、何がいつまでにと逆算して考えます。
この時にリリース日に絶対に間に合わせるようにリリース日起点で全体感を考えています。
全てのQAエンジニアの考え方と一緒だとは思いませんが、同じように日々のテストスケジュールを考えられている方はいるのではないでしょうか。
これがポイントです。
『GX』の開発チームではアジャイル開発で短いスパンでのリリースを行っています。
短いスパンだからこそ何をいつまでにやらないといけないかという事を明確にしなければならないです。
ここで、課題/スケジュール整理のmtgで「リリース意識強めにリリース日起点で全体感を考えている視点」でファシリテートを行う事で、チームとして決めなければならないことを決め切って話を前に進めやすくなります。
そして、チーム全体で考えた時に、リリース起点での開発工程の後半部分のプロセスマネジメントをQAエンジニアが担うと、PdM/デザイナー/開発の方はより未来の事に向けて頭のリソースを割きやすくなるのではないかと思っています。
ファシリテートは課題解決やスケジュールを決めるという部分を「促す」ことが出来れば可能です。
想像してみて欲しいのですが、自発的に発言をしないといけない場合よりも、ある程度話を振ってもらった方が発言しやすいと思いますし、更にそこで丸投げではなくある程度の道筋を立てた形で聞いてもらえると、より自分の考えを述べやすくなると思います。
QAエンジニア視点で全体感を捉えるようにしていると、このある程度の道筋を立てつつ必要な話を振るというのも出来るのではないかと思います。
こういった活動が出来るのはお互いを尊重出来ているから
領域を広げると言うと聞こえはいいですが「領域を広げる＝他の人が担っている部分にも手を出す」という事になるので、余計なことをしないで欲しいと思う人もいるかもしれないです。
その辺り、配慮が必要で根底では相手へのリスペクトがある必要があります。
また、自分が相手に思うだけではなく、相手から自分に対してもそういった気持ちがないと難しいかもしれません。
関係性を築くという事が何よりも実は大切ではないのかと思っています。
そして、私自身が新しい領域にチャレンジしたいというのもありましたが、「全体の課題解決により良い形で寄与したい」であったり、「ポジション関係なく、誰かの手助けをしたい」という思いもあるので、それが良い活動につながったのではないかと思っています。
また、関わっている人にも恵まれているからだと思っています。
最後に
最後まで読んでくださった方ありがとうございます。
読んでくださった方に少しでも参考になるような内容があったら幸いです。
今回、ブログを記載してみてGOには課題解決に向けて互いを尊重しながら率直な意見を言い合える土壌があると改めて実感しました。
私自身、QAエンジニアの立ち位置を元に少しずつチャレンジしながら領域を広げつつプロジェクトに貢献出来ていてやりがいを感じています。
この記事を読んでGOのQAエンジニアに興味を持たれた方は、以下のページでQA関連の情報について定期的に発信していますので、こちらも併せて見て頂けると別の角度でより知る事が出来ると思います。
また、GOでは、私たちと一緒にチャレンジしてくれる仲間を募集中です。
私個人としても、今回の記事を読んで共感して下さったような方と是非一緒に仕事をしたいと思います。
ご興味のある方は採用ページからご連絡ください。
この記事が気に入ったらサポートをしてみませんか？