最終更新日: 2021年11月9日

2021年1月28日、第2回目となるmonoAI tecnology〈現・AIQVE ONE)主催のオンラインセミナー、QA Tech Nightを開催いたしました。この記事では、その中で行われた株式会社アカツキ福岡の山﨑氏によるセッションの内容をお届けいたします。

<関連記事>
【QA Tech Nightレポート】外部からの関わりで見えたゲームテストの現状とテスト自動化
【QA Tech Nightレポート】パネルディスカッション―「ゲーム業界におけるソフトウェアテストの理論の浸透と自動化」

今回、お伝えしたいこと

株式会社アカツキ福岡の山﨑と申します。
今回話すのは、QA組織が「最後の砦」とよく言われるのは本当にいいのか悪いのか、というのを私は疑問に思っていまして、そこから脱却するのに何が必要で、どうしたらいいのかということをお話しできればと思っています。

結論から先に申し上げますと、私は「最後の砦」というのは響きが良くかっこいいけれど、大きなリスクを伴うと思っています。またQA組織は、最後に「どん」と構えるだけなのは非常にもったいなくて、「最後」というカッコよさに捉われずに、動いていかなければならないと考えています。

先ほどの花房さんのお話にもありました通り、テスト対象が完成する前の設計等に注力していくべきだと思っています。私はエンジニアという立場でQA組織に所属しているのですが、QA組織・エンジニア両方の立場にいて思うことを率直にお話しできればと思います。

今日お話しすることですが、QA組織のあり方について、概念的・抽象的な話をさせていただきます。その中で、現場で感じたこと思ったこと実際に起こったこと、いわゆる「あるある」とそれに対する原因をここでご紹介していきます。

話の目線についてですが、私はエンジニアとしてQAに所属していますが、ソーシャルゲームアプリケーションの開発をずっとやってきましたので、その立場で話させていただきます。ただ、ここでお話するのは新規でゼロからリリースするまでの開発するプロジェクトではなく、リリース後に運営していく、バージョンアップを繰り返していく開発というチームの話です。また、開発チームの中にQAメンバーが在籍しているチームの話でもあります。

自己紹介

はじめに、自己紹介をさせていただきます。
エンジニアの山﨑友貴と申します。2015年に東京のアカツキのエンジニアとして新卒で入社しました。

そこからオリジナルタイトルのゲーム運営チームにて、次に他社IPタイトルのゲーム運営チームにてクライアントエンジニアをしておりました。

2017年くらいからクライアントエンジニアチームのリーダーをやらせていただいて、そのチームでだいたい4年くらい開発を行った後、2019年にアカツキ福岡に出向し、テストの自動化や効率化のチームの立ち上げを行っていました。

今はチームが立ち上がって、テスト自動化とか効率化とか各プロジェクトを見つつ、QA組織づくりに従事しています。

前提の話

まず前提の話をさせてください。

チームの体制ですが、アカツキのグループには、東京にあるアカツキと、私が今所属しているアカツキ福岡があります。アカツキ福岡はアカツキの子会社で、会社として完全に独立してはいるものの、同じプロジェクトのワンチームとしてアカツキ福岡のQAチームは、アカツキの開発本体チームに所属している形になります。

プロジェクトAというのがあるとすると、実際に開発するエンジニアやデザイナー、ディレクターがいるのは東京のアカツキですが、QAチームが福岡にあるという形で、Zoomなどで密に連携を行っています。

プロジェクト体制ですが、CAPSと呼ばれる品質管理チームがあり、これは横串のチームです。

東京にも福岡にもQAチームがあるのですが、そこのメンバーたちはCAPSというチームに属して、横串で連携しながらQA業務を行っています。

私がどういう目線で仕事をしているかというと、第三者視点で、テスト自動化や効率化というのをチームに対して行っている形です。

CAPSの話もさせてください。CAPSは「顧客とプロダクトの満足度最大化」を追求する集団として業務を行っていて、QAとカスタマーサポート、カスタマーエクスペリエンスをメインで担当しています。

6つの最大化を追っていて、まずQAで製品の満足度最大化を追っています。
2つ目にカスタマーエクスペリエンス=最高の感動体験の最大化を行っています。お客様対応のことですね、カスタマーサポートも行っていますが、カスタマーエクスペリエンスのアプローチも展開しています。

3つ目は面白さの満足度最大化です。ゲームなので、仕様と同じ動作をしても、それが面白いのかどうかというのをしっかり見ていかないと良い製品は出来上がらないので、そこの面白さってなんだろうというのを追求しています。

4つ目に、これは私がいるところですが、エンジニアリングの貢献最大化を行っています。エンジニアリングでテストの自動化・効率化を行っています。

5つ目はリスクマネジメントです。リスクマネジメントの観点でいうと、たとえば課金系やガチャ系など、ゲームで不具合が起きるとまずいところがあるのですが、そのあたりの安全性を第三者的に担保しているチームがあります。

最後に6つ目ですが、働く人は能力を発揮して楽しく働くべきである、というのがCAPSの考え方なので、そこの組織づくりを行う専門のチームがあります。
今日お話しするのはQAのところの、製品の満足度最大化と、エンジニアリング貢献最大化のところです。

最後の砦とは一体なんだろうか?

長くなったのですが、本題に入ります。

QA組織は最後の砦といわれることがよくあり、採用のページでも「最後の砦です」と言っているところもあるのですが、私はそうあるべきではないと思っています。

そこで、最後の砦とは一体何か、なぜ最後の砦ではダメなのか、最後の砦から脱却するために必要なことは何かということをここからお話しさせてください。

最後の砦とは最終防衛ラインとして、「絶対不具合を出さない」と頑張っているQAメンバーがいて、QA組織以外のメンバーは、「お願いします」とか、「不具合見つけてください」というやり取りがある、というイメージです。言語化すると、最後の砦の「最後」とはプロダクトのリリースにおける最後の工程、「砦」というのはリリース前に不具合を発見する役割を持っている、ということかと思っています。

これは弊社の一例でゲームのバージョンアップまでの開発工程の話になるのですが、まずディレクターが機能仕様書をつくり、それをもとにエンジニアやデザイナーが機能を完成させる。そしていくつかの機能が合わさって、マイルストーンであるfeature freeze =機能追加のリミットがあり、続いてcode freeze =コードの変更のリミットがあって、リリースまで向かうというのが一般的な流れです。

QAチームはだいたいfeature freezeからcode freezeまで、そしてあとで説明するフリーデバッグの工程まで、結構がっつりテスト実行をしています。

これが最後の砦ということですね。

なぜ最後の砦となってはいけないのか

それでは、なぜ最後の砦になってはいけないのかということです。

先ほどの機能開発の流れでいうと、機能の仕様書を基にエンジニアは実装を完了させるのですが、QAチームはその間にさぼっているわけではなく、テストの設計やテスト実装を行っています。

ただ、テスト実行は機能が完成しないとできないので、機能が完成したらテスト実行をしていき、リリースまでにクリティカルな不具合があったら、それをエンジニアやデザイナーと連携しながら修正していくという流れです。

ここで、フリーデバッグなのですが、探索的テストに近いテスト形式で、3日間とか5日間とか期間を設定して、何人かで行っています。

この期間に重大な不具合が発見されるということが経験上、稀にあります。
発見するとファインプレーなので功績が称えられて、それで最後の砦と言われるのですが、本当にそれでいいのか、という疑問があります。

私は、最後の砦と言われてもそれを誇りに思ってはいけないと思っています。

QA組織にとって「最後の砦」というのは誉め言葉でなく、自分たちがミスをしたら終わり、というのは、それが重大なものだったらそのままサービス終了というのもなくはないので、私はそういう状況は健全ではないなと。

最後の砦と言われたら悔しいと、本気で思えるような組織でありたいと思っています。

最後の砦という役割が引き起こす3つのこと

最後の砦という役割が引き起こすことは3つあると思っています。
1つがテストの遅延です。

最後に構えているので、機能が完全にできてからでないとテストができず、ディレクター・エンジニア・デザイナーなどがスケジュール遅延を起こすと、そのままQAチームも遅れてしまいます。

ただ、スケジュールは遅延しても、リリースまでは遅延できない。結果、すべでのしわ寄せがQAチームに来て休日出勤というパターンが弊社でもよくみられます。

2つ目がクリティカルな場面でリリースが遅延するということです。

絶対には遅らせることができないリリーススケジュールというのがたまにありまして、その最後の最後で、フリーデバッグで不具合を発見するということがあると、本当にどうしようもなくなります。

これはどうしても出せないとなると、リリースを遅らせるしかなくなり、ディレクターやプランナーたちが組んでいたゲームのイベントスケジュール等を全てずらしたり、自社パブリッシングではなく、協力会社と共に開発を行っているようなところだと、その協力会社とも調整を行う必要があります。そして、かなりの余分な工数が発生してしまうことになります。

3つ目はQAチームへの過度な期待を生むということです。

最後の砦というのを誉め言葉として、QAに任せればなんとかなるみたいな空気がエンジニアに広まると、これは弊社の話ではなく一般論ですが、ユニットテストを書かないなどエンジニアの慢心を生むことにもなると思います。

他にも、たとえば仕様書を見て機能を開発して、コードレビューだけして動作確認をしないまま機能が渡ってきて、実際やってみたら全然動かなかった、というようなことが発生してしまいます。

あとはリリース後に不具合が出たときに、これは当然チーム全体の責任ですが、過度な期待をしている場合、QAチームがなんで見つけられなかったのかと、そういうところをコトに対する批判ならいいのですが、ヒトに対する批判になってしまうという懸念があるのではないかと思います。

最後の砦から脱却するために必要なこととは?

ここからは、最後の砦から脱却するために必要なことをお話しします。
脱却するのに必要なことは以下の3つだと思っています。

1. テストはいつから始まっているのか?
2. 不具合の原因を考えるのは誰か?
3. 品質について考えるのは誰か?

1つずつ順番に見ていきます。

テストはいつから始まっているのか?

テストはいつから始まっているのかというところですが、ソフトウェアテストの7原則のその3に、「早期テストで時間とコストを節約」という、私も好きな原則があるのですが、テスト対象が完成する前からテストは始まっていると思います。ただその意識は、私がエンジニアだった頃は正直ありませんでした。

テストがどのくらいでできるかという見積りをするのですが、その見積りをずらしてしまう要素がテスト工程にあまりに多過ぎると思っています。

エンジニアであれば、手戻りとか自分の責任の範囲でスケジュール調整できますが、テストだと、エンジニアが遅れれば、もちろんテスト工程も遅れますし、エンジニアが出した不具合によってテストが遅れると、その分やりとりが発生して、いくらバッファを積んでも、スケジュールが圧迫してしまう状態になります。

そのため出来る限り早期にテストをやっていく必要があるなと、シフトレフトの概念でやっていく必要があるなと思っています。

ここで先ほどの機能開発のラインなのですが、ディレクターの仕様書とエンジニアの機能完成のあたりをもう少し細かく見ていきます。これも一例ではありますが、仕様書は完成の前にpre-fixというのがあって、8割方完成している状態で、機能の開発に携わるエンジニアやデザイナーやQAチームを呼んで「この仕様でいきますがいいですか?」という話をします。

ここでもテスト可能だと思っていて、仕様の抜け漏れをここでチェックしたりとか、ゲームなので、この仕様で出して本当に面白くなるのかをチェックしたりすることもできます。

あとはエンジニアの工程でいうコード設計レビュー・コードレビューというのがあるのですが、この段階でもテストは可能だと思っています。エンジニアも人なので考慮漏れというのは少なからず発生します。私自身も発生させたことがありますし、そういうものだと思っています。この考慮漏れを指摘したり、あとは、機能が本流にマージされると他の機能も影響を受けるのですが、その前に機能単体でテストを行ってみるとか、動作チェックをしてみるというのもテストの1つかなと思っています。

弊社でやっている一例ですが、マインドマップでテスト設計をするというのを仕様書のpre-fixや完成段階で行っています。

テスト観点の洗い出しは花房さんの話にもありました通り弊社でもやっていますが、これをマインドマップで行い、どこに影響があるのかというのを可視化できるようにしています。

これを、QAチームだけでなく開発に携わっているメンバー全員でレビューをしています。その際にQAチームが予期していなかった影響範囲がエンジニアから出ることもあります。

マインドマップでテスト観点の洗い出しをする前は、テストを行う前にテストケースを全部作り、それを関係者が全てレビューするということをしていました。

スプレッドシートでテストケースがずらっと、多ければ1,000項目とかを、全部レビューしていたのですが、人がどんなに頑張っても絶対に抜け漏れが発生するなと思い、これを導入したという背景があります。

また、コード設計レビュー会といって、エンジニアがコードを書き始める前に、どういうシステムを組むかという設計をし、それが妥当かどうかレビューをする会があるんですが、このコード設計レビュー会にQAチームも参加しています。

ここでよく話し合われるのが、リファクタリングを行うかどうかについてです。リファクタリングは、機能開発の仕様書だけで見ると検知しづらいのですが、これをエンジニアの中で完結してしまうと、影響範囲が全て分からないままテストが進行し、予期せぬところで不具合が発生することがあります。これは「あるある」だと思うので、このリファクタリングの有無をQAチームが認識するだけでもメリットがあると思います。

また、仕様書から予測できない影響範囲の認識や、エンジニアの考慮漏れなどを指摘できるのもメリットの一つです。

不具合の原因を考えるのは誰か?

原因を考えるのは誰かということですが、原因を決定づけるのはエンジニアの役割だと思います。ただエンジニアだけでいいのかという話ですね。

故障とか不正を発見するのはテスター、不具合を修正するのはデバッガ―というのはよく言われます。

ただ、テスターは発見するだけでとどまるべきなのかというのが疑問でして、たとえば「ここに不具合がでています」ということでエンジニアとコミュニケーションをとることがあると思うのですが、クライアントエンジニアに報告して、クライアントエンジニアからすると「これはサーバ側の不具合だ」というのはよくあるなと。

この処理はサーバで行われていたとか、このデータをもっているのはサーバのマスターデータだな、というのが事前に理解できていれば、サーバエンジニアに直接、不具合修正依頼を出すことができます。

この、クライアントなのかサーバなのか、というところを理解しているだけでも、不具合の原因をクリアするスピードアップにつながると思っています。

そこでQAも不具合の原因を考えたいなと思うのですが、そのためにはエンジニア的視点が必要だと思っています。

エンジニア的視点というのは、アプリケーションの内側を理解するということです。
システムの概要、データ構造、通信タイミング、ハードウェア、ビルド方法などの理解や、ソースコードを読み、複雑度を理解するなど、いろいろあります。

エンジニア的視点を持つメリットとしては、

・テスト精度が向上する
・エンジニアとより深い議論ができる
・テスト業務を効率化できる

ということが考えられます。

たとえばテスト精度の向上でいうと、「欠陥の偏在」というのがソフトウェアテストの7原則にもありますが、不具合が出やすいところ出にくいところはシステム上存在すると思います。

特にゲームだと、いわゆる「インゲーム」と呼ばれるバトルとか、スキルを使う場面ではコードが複雑になりがちなので、そういうところをエンジニア的視点があると不具合を見つけやすくなると思います。

デメリットとしては、学習ハードルが高かったりとか、内部構造を知り過ぎていて、エンジニアの確証バイアスをQAでカバーできなかったりということがあります。

エンジニア的視点を持つのが重要だとしても「テスターの域を超えているのでは」と思う方もいると思いますが、私もそう思います。

そこで弊社ではQA組織のスペシャリティの強化を行っています。

QAとして役割を2つ用意していて、スペシャリストとマネージャという2つの定義をしています。その定義のもと、専門性をチームの中で高めていってキャリアパスを歩めるような設計を今行っています。

あとはJSTQBを軸に、チームの課題について議論するというのを行ったりもしています。

一言でいうと、スペシャリストというのはテクニカルな領域で、QAマネージャやエンジニアと連携して最高品質のプロダクトをユーザに提供することを目指しています。テスト技法や、エンジニアリングの観点を持っています。

マネージャはテストチームの価値を最大化させる役割を持っていて、テストプロセスの最適化を目指しつつ、最高品質のプロダクトをユーザに提供することを目指しています。

品質について考えるのは誰か?

品質についてですが、QA組織だけではなくプロジェクトメンバー全員で考えるべきだと考えています。ただし品質に対して誰が最終責任を持つのかは決める必要があると思っています。

開発エンジニアとQAの心理の違いですが、開発エンジニアは、プロダクトの設計や構築を主目的にしていて、不具合が出ているかどうかというのはあまり関心がありません。
QAは妥当性とかプロダクトの検証とかリリース前の欠陥の検出を主目的にしているので、心理が違うのですが、開発エンジニアも品質について考え、QAチームに歩み寄らなければいけないと思っています。

プロダクトの品質を向上させるといった共通の目的を持って議論するなど、お互いの違うマインド、専門性を理解して、不足している部分を補い合うようなチームが良いチームになると思っています。

また先ほどQAはエンジニアの視点を持った方がいいという話をしましたが、開発エンジニアもQAの知識とか視点を持たないとアンフェアだなと思っています。

このあたりの話をアカツキのAdvent Calenderにも書いているのでもし良ければご覧ください。

更にエンジニアのアプローチとして、品質改善のために何ができるのかいうと自動化があり、CEDECでもホットな話題になっています。ただ、自動化は「銀の弾丸」ではないと思っています。

テストを自動化するだけでは品質は上がりませんしコストも下がりません。全てのテストを自動化すべきではないと思っていますし、リリース後の自動化も簡単ではないので、至難の業です。

ただテストの目的は重要で、目的を定めた上で自動化してCIに組み込むと不具合の早期発見につながると思っています。

弊社で私がやっているところになりますが、組み合せ爆発が起きているインゲームのリグレッションテストに対して、手動のプレイ結果を記録して、それを再現することで、再現した結果と手動で記録した結果を見比べて、そこで合っているかどうか、テストが成功しているかどうかを見るようなシステムをつくろうとしています。ただ、ランダム要素が難点だったりとかシードを固定したけれどできていない場所があったりとか、演出とプレイ結果が分離できなくて単純に自動化の時間がすごく長くなったりという課題があります。

なので、理想はリリース前の開発時点から自動化を考慮すべきです。
これでエンジニアもシフトレフトに大いに貢献できると思います。

まとめ

長くなったのですが、まとめに入ります。

最後の砦とは最後の工程で不具合を発見する役割で、最後の砦になってはいけない理由はテストの開始が遅延したり、クリティカルな場面でリリースが遅れたり、QAチームに過度な期待を持たれるためです。

脱却するためには、シフトレフトで考えなければいけないですし、QAチームはエンジニア的視点を持たなければならないと考えています。エンジニアもQAの視点を持つべきですし、自動化という観点などで、品質を考えるべきだと思います。

実際弊社で取り組んでいるのはマインドマップレビューやコード設計レビューを利用してテスト設計をしたり、QAのスペシャリティを定義してエンジニア的視点やマネジメントを高めたり、リグレッションテストの自動化をしたり、などです。

最後の砦だけでなく、たくさんの砦を作って品質の良いプロダクトを作っていきましょう、というのが今回の話でした。

ありがとうございました。

株式会社アカツキ
https://aktsk.jp/
株式会社アカツキ福岡
https://fukuoka.aktsk.jp/