top of page
  • 執筆者の写真CAPS編集室

#12 「最後の砦」からの脱却　QAの新しい未来へ

〜エンジニアが描く、QAの「新しい在り方」〜


エンジニアリングによる業務改善で、最高品質の体験を世の中に届けるために邁進するエンジニアメンバーにお話を伺いました！

【人物紹介】

[エンジニア / 山﨑 友貴]

九州大学大学院を修了後、2015年にアカツキへ新卒入社。

クライアントエンジニアとしてIPタイトルのゲーム開発に携わる。

2017年よりクライアントエンジニアのリーダーを務め、コアロジックの開発やチームマネジメントに従事。

現在はテストの自動化や効率化を行うための組織をアカツキ福岡で立ち上げ、QA領域の業務改善を推進している。




クライアントエンジニアから、新たな挑戦


──所属している「A4」チームについて、どのようなチームなのか教えてください。


A4（エーフォー）は、"Advanced and Aggressive Aegis of Akatsuki”の略称で、単語の頭文字のAを4つ取って、A4と呼ばれています。


直訳すると、“先進的で積極的にアカツキを守っていくチーム”となるのですが、役割としては、CAPSのミッションである「顧客とプロダクトの満足度最大化」のために、エンジニアリングによる業務改善で貢献し、最高品質の体験を世の中に届ける役割を担っています。


発足当初は、各プロダクトで出た不具合をまとめ、他のプロダクトでも起こり得る不具合について分析し、改善していくという活動を行なっていました。その分析や改善を行っていく過程で、エンジニアリングの力が必要になってくるので、そこから、今のエンジニア集団としてのA4がスタートしていきました。


今では、東京と福岡にそれぞれメンバーがいて、拠点を跨いでワンチームとして活動しています。

──山﨑さんは元々開発側でクライアントエンジニアとして活動されていましたよね。そこからA4のエンジニアとして活動しようと思った理由を教えてください。


開発側のクライアントエンジニアとして活動していたときに、QAの在り方に対してモヤモヤを感じていたことが大きいです。


QAがおこなうテストのフェーズは、開発プロセスにおいて後半に回ってくることが基本ですが、だからこそ、そこに至るまでの色々な進捗の遅れをQA組織が吸収してしまいがちです。

また、QA組織は、よく「最後の砦」と称されることがありますが、僕自身はそうあるべきではないと考えています。

なぜならば、「最後の砦」という言葉の背景には、確かに不具合を発見するとQA組織のファインプレーとして賞賛されますが、逆を言えば、不具合が出てしまうとQA組織のミスと見なされてしまうわけで、重大な不具合の場合、そのままサービス自体が終了してしまうリスクも伴うからです。


このように、QA組織の見逃しによって大きなリスクを伴う状況は決して健全ではないと思っています。


こういった状態をエンジニアの立場から見ていて、今のやり方が良い悪いということではなく、より良い品質を目指すためにそれぞれの領域が協力しあって、新しいQAの在り方を探していきたいと思っていました。


そんな中、アカツキ福岡に行くことが決まり、「自分が福岡で出来ることは何だろう？」と考えたときに、アカツキ福岡が事業としてQAに注力しているからこそ、自分が感じた課題にもっと向き合って改善できるかもしれないと想い、A4所属のエンジニアとして活動する道を選びました。




QAスペシャリティを定義した意義


──実際にA4のエンジニアとして活動を開始してから、具体的にどのようなことを行ってきましたか？

まだまだ走り出したばかりで価値創出のフェーズですが、2020年にA4として活動を開始してからの1年間、たくさんのことに挑戦してきました。


例えば業務改善以外にも、「エンジニアとQAの両面からもっとできることはないか？」を模索し活動してきたので、テストの自動化やQAメンバーの育成、QA業務の改善をより中長期的な視点で見据えた際のR&D（研究開発）、さらには、QA領域だけではなくアカツキやアカツキ福岡の全社的なところでの業務改善など、領域を広げて活動してこれたと思っています。


具体的なところで言うと、リグレッションテストの自動化による工数削減をしようとしていて、とあるプロジェクトでは最大50%程度まで工数削減の目処が立っていたり、QAチームと協働してテスト業務全体の見直しを行っていたり...。


特にこの半年は、「QAでは、どのような専門性があるのか」といった、"QAのスペシャリティ（専門性）”を定義し、QAとして活動しているメンバー一人ひとりがキャリアを思い描き、歩んでいくための道筋を整えていくことに注力しました。

──この半期に注力されたQAスペシャリティの定義について教えてください。具体的にどのように定義したのですか？

まず、スペシャリティの役割を「QAスペシャリスト」「QAマネージャ」の2つで定義しました。

一つずつ説明すると、まず「QAスペシャリスト」は、「テクニカルな領域で組織をリードし、QAマネージャやエンジニアと連携して、最高品質のプロダクトをユーザーに届けることを目指す人」と置きました。


対して「QAマネージャ」は、「QA組織の価値を全方向に伝えるとともに、テストにかかるプロセス全体を最適化し、最高品質のプロダクトをユーザーに提供することを目指す人」と置きました。


細かい定義は今回は割愛しますが、この2つの役割に対して、それぞれに求められる行動やキャリアレベルを細かく定義していきました。



──率直な疑問なのですが...そもそもなぜA4の山﨑さんが、QAのスペシャリティを定義しようと思ったのですか？

元々は僕がQAのことをよく知ろうと思って、「JSTQB (*1)」という資格の勉強を始めたことがきっかけです。

勉強してみると、これまで自分が感じていたQA組織に対するモヤモヤが全て言語化されていくようで、この学びや気づきをQA組織がより良くなるために、何かしら還元していけないかと考えました。


そういった中で、QAスペシャリティを定義しようと考えた理由は、大きく3つあります。


1つ目は、QAメンバーのキャリアの選択肢として、プランナーなどの他職種を目指していくだけでなく、アカツキの中でQAのキャリアを積み上げていくことを目指すメンバーを、もっと応援したいと思ったからです。


背景には、アカツキのQAにおけるスペシャリティの定義が非常に曖昧で、「スペシャリティとはなんだ？」と問いをかけられたときに、「説明できないな。経験に頼りきっている部分があるな。」と課題を感じていたことにあります。

なので、それを組織として明確に説明できるようになりたいと思いました。


…というのも僕は、QA組織はプロフェッショナルな組織だと思っています。


例えば、他のwebサービスと比較したときに、ゲームはとても構造が複雑で、且つ、更新頻度も高いサービスです。これを検証するということ自体、かなり難しいことだと日頃から捉えていますし、その上で、品質を担保するだけではなく、担保しつつ面白くする。というミッションを掲げているアカツキのQA組織はとても難しいことに挑戦している組織だと常々思っているんです。


だからこそ、その凄さを論理的に他者に説明できるようになってほしいですし、組織としてもアカツキ流のQAをしっかりと定義していく必要があるなと考えました。

2つ目は、QA組織の負担を減らしたいと思ったからです。


僕が開発エンジニアからA4所属のエンジニアになろうと考えたきっかけとして、QA組織の在り方に課題を感じていたと話しましたが、QA組織は「最後の砦」と呼ばれることから脱却しなければならないと考えています。


確かに「最後の砦」と聞くと響きは格好良いですが、それを免罪符にしてはいけないと思っていて、自分たちでQA組織の在り方を変えていかなければならないですし、変えていくための武器が、スペシャリティだと考えています。

この辺りの考えについては、社外の勉強会で話をした資料があるので、ぜひ読んでもらえると嬉しいです。


そして3つ目は、QA組織の役割の責任範囲を明確にしたいと思ったからです。


QAの領域は大きく2つの役割があると思っています。

ざっくりしすぎているかもしれませんが、テストのアーキテクチャからより良い品質を追求する役割と、テストプロセス全体を通してそれを最適化しつつより良い品質を追求する役割です。


これまでのQAチームを見ると、その両方を担っていたのがリーダーポジションの方でした。けれど、キャパシティには限界があるので全てを持ちきれず、溢れたボールは他の職能の方が拾っている状態でした。


QAの領域であれば責任を持つべきなのはQAメンバーであってほしいので、テストアーキテクチャは「QAスペシャリスト」、テストプロセスは「QAマネージャ」として責任範囲を明確にしました。それによって、リーダーが持っていた一部責任を別のメンバーが持てるようになるので、負担軽減に繋がると考えました。


今回、役割を定義し、責任範囲を明確にしましたが、これはお互い関与しないということでは決してありません。むしろ「QAスペシャリスト」と「QAマネージャ」は協働しないと成り立ちません。あくまで最終責任範囲はどこか？を明確にしただけです。それぞれの領域がそれぞれの領域で、よりプロフェッショナルに協働していくと良いQA組織になれると信じています。




一人ひとりのより良い成長曲線につながる道づくり



──QAのスペシャリティを定義していく上で壁にぶつかったことはありますか？

そうですね…。QAの専門性を定義するためには、まずQAの原理原則を知る必要があるなと思ったんですが、そこはJSTQBがあって本当に助かったなと思っています。QAとは何かが網羅的に書かれているため、QAという世界の奥深さを知るには充分すぎる内容でした。そこからQAのスペシャリティを定義する流れに行くんですが、そこでいくつか壁がありました。


1つ目の壁は、QAスペシャリストの役割の肥大化でした。

当初、QAの専門性はQAスペシャリストだけを定義するつもりだったんです。JSTQB FLをベースにしつつ、QAとして持つべきスキルや責任範囲を定義していたんですが、これまでリーダーが担っている役割を言語化したような内容になりつつありました。このままだとスペシャリストの役割が重くなりすぎる、と思ったのが最初の壁ですね。


2つ目の壁は、キャリアの初期レベルから専門性を求めすぎていることでした。

弊社内で使用している評価制度にレベル感が定義されているので、それに沿ってJSTQBに書かれているQAの役割を整理していました。定義できるレベルのところまで定義しきって全体を俯瞰して見たんですが、レベルの間に明確な差が生まれていない事に気が付きました。差が生まれていない原因は2つで、初期からQAに関する網羅的なスキルを求めすぎていること、レベルが上がるたびに新しいことができるようになるわけではなく持っているスキルの習熟度がじわじわ上がる設計になっていること、にありました。

──その壁をどのように乗り越えたのですか？

1つ目のQAスペシャリストの役割肥大化の壁ですが、これはJSTQB FLだけではなくALまでを考え方の範囲に入れることで解決しました。ALではテストマネージャ、テストアナリスト、テクニカルテストアナリストの3種に専門性が分かれます。FLで書かれている内容を更に研ぎ澄ませたものです。「QAスペシャリスト」はテストアナリストとテクニカルテストアナリスト、「QAマネージャ」はテストマネージャをベースに作り直すことにしました。そのためにシラバスを読み込んで対話したりしましたね。この時点でALまで視野を広げられたのは良いことだったなと思います。「専門性を持つ者同士が協働しないと良いQA組織になれない」と思うようになったのはALを学んだからですね。


2つ目のキャリアの初期レベルから専門性を求めすぎている壁ですが、こちらは「IVEC (*2) 」のキャリアレベルを参考にしました。JSTQBはQAの役割を網羅的に書いているがゆえに、テストプロセスごとのレベル感が揃えられませんでした。一方、IVECではレベルごとにテストプロセスのどこまでを影響範囲とすべきかが定義されています。例えば、レベル1だとテスト実行ができること、みたいな感じです。このキャリアレベルを基に再構築したかったので、作っていたものを一度ばらしました。弊社内の評価制度のレベル感は汎用的なものなので、それをIVECで定義されているキャリアレベルと照合させ、各レベルの人物像を描き、ピースを埋めるように役割を言語化していきました。最終形に行き着くまでにかれこれ半年くらいは試行錯誤していた気がします。

──実際に半年をかけてQAのスペシャリティを定義してきて、今思っていること、次にやりたいことはありますか？

まず、今回スペシャリティを定義したことで、QAメンバー一人ひとりが自分のキャリアを思い描き、一歩を踏み出していくための参考材料になれば良いなと思っています。


自分がアカツキの中でQAとしてキャリアを積み上げていきたいと思った時、「QAスペシャリスト」と「QAマネージャ」のどちらに軸足を置くかを定めて、自分自身の最終的なゴールを描きながら、そこに向かって進んでいってくれると嬉しいですね。


次にやりたいこととしては、実際に一歩を踏み出したメンバーに対して、僕自身、QAのスペシャリティを定義して終わり。ではなく、メンバー一人ひとりがより良い成長曲線を描けるような道づくりをやっていきたいです。


目指すところへ向かうための旅路を決めるのはメンバー自身であるべきですが、旅の途中でぶつかる様々な困難と戦うための武器を渡すことはできるんじゃないかなと思っています。自らの意志で学び、その学びをひたすらに実践して磨く、その過程で組織も良くなるし、自分自身も成長していける、そのサイクルを後押しできるようなフレームワークを作りたいと思っています。


CAPSは未経験で入社される方も多いんですが、ゲームに対して想いを持ったメンバーばかりです。そのような志が高いメンバーが目指すべき旗を決め、それに向かって切磋琢磨する、その過程での成長や成果がしっかり評価される、そしてまた旗を掴みに進んでいく。スペシャリティの定義はその一気通貫した流れのほんの一部だと思っています。




開発と業務改善。両方のバランスを保つエンジニア集団へ

──今後A4としてアカツキでやっていきたいことはありますか？

まずは、A4の活動に共感してくれる人たちと一緒に、やれることを増やしていきたいですね。

そのためには「A4って何をやっている組織なのか」ということを、短期的にも中長期的にもロードマップを描いて、もっと発信していきたいなと思っています。


あとは、テストの自動化は軸に据えてやっていきたいですね。

ただし、これはあくまで、”自動化”が目的ではなく、はたまた”コスト削減”が目的でもなく、”いいゲームをユーザーに届けること”が最大の目的だと考えています。


CAPSのミッションである「顧客とプロダクトの満足度最大化」のために、自動化をやっていきたいなと。


また、個人的にA4として目指していきたいのは、「開発エンジニアとしても活動できるが、あえて業務改善やテスト自動化が重要だからやっています」というエンジニア組織を目指したいなと思っています。


「開発ができないから、業務改善をやっている」とか「便利屋だけど、実際のところ何をやっているのかわからない」という風には思われたくないですし、A4のエンジニアに求められるのは、開発と業務改善、両方のバランスを保つことだと思っているので、どちらも中途半端になるのではなく、どちらも高いレベルでバランスを保っている組織でありたいと思っています。


難しいことですが、QAやエンジニアのメンバーたちと日々対話をしながら、諦めずに追っていきたいですね。


──最後に、 記事を見ていただいている方にメッセージをお願いします。

ここまで見ていただき本当にありがとうございます。


A4はQAに関する業務効率化やテスト自動化、組織づくりをやっていますが、エンジニア職能の中で細分化された一つの役割だと思っています。

なので、インプット・アウトプットは当然エンジニア基準です。未経験からエンジニアになりたい、興味があります、という声も聞くのですが、決して簡単ではないことは伝えさせてください。「未経験から」というのはエンジニアに限らず、どの職種でも難しいものだとは思います。それでも目指したいという強い意志さえあればきっとどこまででも進んでいけるはずです。


A4は、QAからエンジニアへキャリアチェンジしたい人を応援します。ぜひ一緒に道を切り開いていきましょう。


 

アカツキ 福岡の採用情報はこちら！

アカツキ CAPSの採用情報はこちら！

 

（*1）JSTQBとは、日本におけるソフトウェアテスト技術者資格認定の運営組織で、 各国のテスト技術者認定組織が参加しているISTQB（International Software Testing Qualifications Board）の加盟組織として2005年4月に認定されています。 http://jstqb.jp/committee.html

（*2）IT検証技術者認定試験(IVEC)は、一般社団法人IT検証産業協会(IVIA)が認定するテストエンジニアの資格試験です。特徴はテストの現場における実務を重視していることです。IVECのキャリアレベル(下図参照)ごとに実務力を問う記述式試験を設けており、その合格者(認定者)には実際の現場でも安心して仕事が任せられると、業界でも高い評価を受けています。

https://www.ivia.or.jp/item43

bottom of page