「またSHIFTにお願いしたいと言われる為に」株式会社SHIFT 渡邊綾乃さんインタビュー

今回はテストの現場について「株式会社SHIFT」のアカウントマネージャーを務める渡邊さんにインタビュー！
ゲーム内のバグを見つけるだけではなく、クライアントが抱えている課題を解決するにはどうすればいいのか。
テストの最適な項目を提案するのはもちろん、さらに実施したテストをベースにさらなる改善の提案まで行うSHIFTの強みについてお話していただきました。

※本インタビューは2020年1月にコロナ流行以前に行われたものです。記事内の写真もコロナ流行以前に撮影されており、現在は感染防止対策を施しております。

後編「一石を投じて新しいルールを作っていきたい」株式会社SHIFT 左近充勇人さんインタビューはこちら

株式会社SHIFT
エンターテインメントビジネスユニット　品質支援グループ
アカウントマネージャー　渡邊　綾乃（わたなべあやの）さん

アカウントマネージャーとしてお客様の課題を一緒に考え、解決のためにどうするべきかを提案し改善の手助けを行っている。
ローカライズのテストはやりがいがあるので好き。

株式会社SHIFTはソフトウェアテストからプロジェクト運営、コンサルティングなど、ソフトウェアの「品質」を軸としたお客様のソフトウェア開発プロジェクトにおいて、自社のノウハウやナレッジを最大限に活用したサービスを展開している。

HP:株式会社SHIFT

1 お客様の課題に対して一緒に考える
2 経験値が集約されたテスト仕様書
3 環境テスト・多端末テスト・フリーテスト
4 このバグはエディさんじゃないと出せない！
5 必要なのはゲームが好きであるということ
6 ドキュメントは独り歩きしてくれる
7 テストをものづくりのスタートとして捉える
8 またSHIFTにお願いしたいと言われる為に

お客様の課題に対して一緒に考える

本日はお忙しいところ取材を受けて頂きありがとうございます。
今回ぼんやりとイメージしているデバッグという作業について、実際にどういうことを行い、ゲームの品質に対してどのような役割を担っているのかを教えていただければと思います。

アカウントマネージャーの渡邊です。
こちらこそよろしくお願いします。

まずはアカウントマネージャーがどういう仕事を行っているのか具体的に教えて下さい。

私はお客様のかかえている品質課題に対する解決方法を一緒に考えて提案するという仕事をしています。
またトラブルなどで案件のスケジュールが乱れた時に、いかにうまく調整するかということも大事な仕事です。
現在までに10社ほどの品質マネージメントを担当しています。

経験値が集約されたテスト仕様書

デバッグってひたすらプレイしておかしい所があれば報告するというイメージなのですが、実際デバッグではどういうことをしているのか教えて下さい。

まずテスト前に担当者が要件をヒアリングして、テスト内容のすり合わせをします。
「こういうテストをしてください」「はい。わかりました。」ではなく、プロジェクト側とやり方を詰めた上で進めるようにしています。
例えば「フリーテストから始めてはいかがでしょうか」とか、「アプリがある程度出来上がってますので詳細テストから始めましょう」という具合です。
その後、いただいた仕様に基づいてテスト仕様書を作成してから、テスト実行フェイズとなります。

テスト仕様書というのは、テストで何をチェックするかなどの仕様が書かれているんですか？

そうです。
SHIFTはテスト設計が強みで、必要なテスト観点をナレッジ化して蓄積しています。
なので今のスマホゲームで共通の機能に関しては、ほぼほぼ最適なテストケースがあって、あとはゲーム独自の部分だけカスタマイズしたテスト項目を作ることができます。
もし仕様書に十分な記載がなかったとしても、蓄積した経験から適した項目を非常に高い精度で提供できます。

全体で経験を貯めるというのを意識してやってるというのがすごいですね。

はい。
経験豊富なメンバーの職人芸だけに頼ってしまうと、安定した品質でのサービス提供ができません。
ゲームのテストは難しいので、デバッグのスーパースターが必要な場面も沢山ありますが、毎回安心して頼めるように確実に高い品質を保証できる仕組みを作ることも大事にしています。

環境テスト・多端末テスト・フリーテスト

先程フリーテストや詳細テストという事をおっしゃってましたが、テストにはどういうものがあるんですか？

SHIFTではテスト仕様書に基づいてアプリが仕様通りになっているかをチェックする詳細テストのほかにも、環境テスト、多端末テスト、フリーテストなど、目的にあわせたテストをトータル的に行っています。

環境テスト

環境テストというのはどのようなことを行うんですか？

主には電波環境や使用環境に応じた異常系の動作チェックを行います。
例えば電車の中やトンネル、地下などの電波の弱い状況でのテストですね。
でもそういうテストって実際に行うのはすごく大変なので、電波の弱い状況を再現できる弱電波装置という機材を使ってテストしています。
それに端末を入れると電波を弱くしたり届かないようにできるので、その環境を再現して不具合のチェックをしています。

それはすごく便利ですね。
地下鉄でゲームすることが多いので電波が弱い環境はぜひ検証してほしいです。

アプリケーションってOSの影響をすごく受けるんです。
でもアプリケーション開発者って、アプリケーション外の操作によってどういう挙動が起こるのかまで想定していない事が多いです。
イレギュラーが起こったときの動作の定義ができているかどうかはとても重要で、例えば通信途中で途切れてしまったときに、ずっと電波がないままだとタイムアウトさせて動作を止めないといけないんですが、その処理がアプリ側に入ってない、などもあります。
ある端末はOSでタイムアウトさせるという指令が出るので問題なく動作が止まるはずなのですが、OSが何らかの理由でそのタイムアウトの指示を出さないということもあります。
このように、急にアプリキルされたり、ホームボタンを押されたり、スリープに入ったり、LINEなどの通知が来たりとか、アプリケーションが意図しない状態のチェックが環境テストに含まれます。

多端末テスト

テストの為に端末が2300台以上あるとHPで見かけたんですけど。

多端末テストの為に様々な端末を揃えていて、日々増えています。

スマホとかコンシューマーも含めての数でしょうか？

含めてです。
あとVRやSTEAM用の端末もあります。

STEAM用というのはPCですか？

そうです。
PCのスペックを色んなパターンに合わせて用意しています。
OSがこれでCPUがこれ、8Kで出力したいからグラフィックボードはこれ・・・など、様々なバリエーションに対応してますのでどんどん増えてます。

もう8Kも対応してるんですね！
組み合わせのパターンとかとんでもない数になりそうです。

全部網羅してみようとなるととんでもないコストと時間がかかります。
なのでどれを見るのかというところがポイントになります。
今世の中で流通している端末のランキング上位に入ってるものや、これまで不具合が出やすかった端末を選んでご提案させていただいてます。
流通量、CPUのチップセット、OSバージョン、画面解像度で区分けしてテストしたり、もっとバリエーション増やしましょうということなら同じ性能の別メーカーも含んだりという感じですね。
これらを効率よく網羅できるような組み合わせでテスト用の端末を組んでいます。

フリーテスト

※コロナ以前に撮影したものです。現在は感染防止対策を施しております

フリーテストについてどういうテストか教えて下さい。

テスト仕様書で拾いきれない不具合は、フリーテストで拾います。
この部分は特にテスターの経験と勘に頼ったテストになりがちですが、弊社ではここでも見るべきチェック観点をまとめています。
同時押しや、連打とかしても大丈夫か、とか。

同時押しなどで時々画面ずれるゲームってありますね！
あれってメイン画面戻らないと直らなかったりするんですけど、同時押しって意外と厄介なんですね。

・・・あとは、テスト用のアプリをいただいても、そもそもテスト開始時にそのアプリが動かないとかあるんです。
動きがおかしいとかじゃなく、動かないんです。
起動しないこともあります。

起動しないのは凄いですねｗ
動かないというのも相当でかいバグですよね。

そういったいわゆる粗いバグというのを洗い出す目的で、フリーテストを実施する場合もありますね。

その他のテスト

ちなみに私はローカライズテストが好きなんです。

ローカライズテストでチェックするのはどのような部分になるんでしょうか？

誤字や脱字、一人称や呼称のチェックのほか、ゲームの世界観にあっているかどうかなどのチェックも行います。
世界観にあったローカライズはなかなか難しくて、例えば「オッス！オラ悟空」とかってローカライズするのは難しいんですよ。

わかりますｗ
海外で「Hello, I’m GOKU」とかになってるのは、日本人からすると気持ち悪いですよね。

ですよねｗ
そういう本来のニュアンスが欠落していることもあるので、それがわかるテストエンジニアに見てもらって違和感のないようにしています。
元々ライターをやっていた子がアサインされたりもしますよ。

台詞回しはセンスが必要そうなので、元ライターさんだと期待できそうですね。

このバグはエディさんじゃないと出せない！

テストエンジニアの皆さんについてどういう方がいるのか教えて下さい。

実はSHIFTには「FF6」のバグを使った攻略を追求している「エディさん」というすごい方がいます。
飛空艇を使ったバグで結構有名だと思います。

エディさんってFF6界隈だとめちゃくちゃ有名な人ですよね！
飛空艇バグの人ってニコニコ大百科でまとめられてましたし。
動画も見たことありますけど変態だなと思いましたｗ

（もちろん褒め言葉で）変態だと思いますｗ
バグ報告を読むと、エディさんが見つけたかどうかがわかるほどです。
「このバグはエディさんじゃないと出せない！」って。
彼のすごいところは、プログラムの知識を持っているわけじゃなく、思いつきで進めていくうちに処理が見えているようにバグを出していくところなんです。
「この操作をを繰り返してたらカウントアップされて、あそこのメモリをぶっ壊すんじゃないか」とか、彼にはそういうのがだんだん見えてくるらしいですｗ

完全に能力者じゃないですかｗ
知識量がすごいんですね。

異常ともいえる探究心ですよね。

異常ですねｗ

必要なのはゲームが好きであるということ

エディさんは特殊として、テストエンジニアで多いのはどんな方ですか？
またどういう方が向いていますか？

年齢でいうと20代の方が多いです。
学生も多いですが、ライターだったりパン屋さんだったり、いろんな職業を経験している方もいます。
ゲーム好きで将来ゲーム業界にいきたくて、入り口としてテストエンジニアの仕事を選ぶ方も多いようです。
ここで品質やテストに興味を持って、そういったキャリアを目指す方もいますし、経験を積んでプランナーやディレクターの道に進む方もいます。

なるほど。
どういう方がテストエンジニアに向いていますか？

データをひとつひとつ確認する作業が多いので、コツコツやれる方ですね。
某ロボット漫画やアニメにひたすら強いとか、そういう知識があると原作との不一致を見つけられるので向いていると思います。
あと、必須ではありませんが、バフ・デバフや攻撃力の計算とかって複雑なので、計算力はあると重宝されますね。
ゲームをやってると、ステータスとかシステムを見て最強のパーティとか攻略法を考えるじゃないですか。あれを仕事としてテストするんです。
ときどき飛び抜けて強いキャラがいますが、もしかしたらバグの可能性があるんですよね。

確かにバグみたいな性能とかありますねｗ
求められる能力としては、コツコツやれるのと計算力。
あと探究心とかあるといいんですね。

何より「ゲーム好き」であることが大事です。
この仕事をしていると段々ゲームが仕上がっていく過程が見れますし、自分が携わったゲームを世の中の色んな人がプレイしてくれるところを見れるのは本当に面白いと思います。
時々、自分の意見を反映していただけたりもしますし、クレジットに名前が載ることもあるんですよ！

それはゲーム好きにとっては一生の思い出ですね！
夢のようだと思います。

これを読んでくれているゲーム好きの皆さん、ぜひ一緒に働きましょう！(笑)

ドキュメントは独り歩きしてくれる

いろんなテストを行った後クライアントへの報告というのはどのようにしているんですか？

テストの結果はレポートにまとめています。
テストが終わった後にどういった内容の不具合が多くて、どういう課題があるかを報告させていただいています。
また、目安として「不具合発生率３％」が基準ということと、その数値を下げる、つまり「初期品質を上げる」ためのお話をさせていただいています。
報告が終わった後には今後の課題改善のご提案をすることもあります。

次回テストをする場合はこういうふうにしましょうというのを提案してもらえれば、相手のやり方が改善されて効率良くなってテスト側としてもやりやすくなりますもんね。

そうなんです。
これはお客様のために提案しているのはもちろんなんですけど、SHIFTにとっても次回につなげるチャンスになります。

ここまでしてもらったらまた次回お願いしようってなりますね。

開発の最終フェイズで、品質にかかわるさまざまな問題が顕在化してくる事が多いんです。
テストフェイズでどうにかするのではなく、開発フェイズで取り組んだほうが良いケースもたくさんあります。
ドキュメント化して社内で見れるようにしておくと、ドキュメントが独り歩きしてくれるんです。
私たちの報告資料は、次回以降、お客様が他のプロジェクトを立ち上げる時のナレッジになると思っています。
そういう点も重視しているので、課題のドキュメント化だったり客観的データをしっかりレポートにしてお渡ししています。

こういう形でレポートにしてもらうとありがたいですよね。
リリースフェイズのレポートと、運用フェイズのレポートに違いはあるんですか？

ゲームがリリースされてサービスが開始してからも、対処すべき課題にあわせたレポートをご提出しています。
例えば、お客様の抱えている課題がコストであれば、検証の費用を下げるためのレポートを作成したりします。
また、よくある課題としては、企画の仕様がなかなか決まらずスケジュールに余裕がなくなってしまい、テストにあてる期間が非常に短くなってしまうことがあります。
そうなると検出漏れのリスクは高まりますので、スケジューリングの段階からお話しさせていただくこともあります。

なるほどｗ
完璧だと思って持っていっても、だいたいなにか指摘されますもんね。
自分も身に覚えがあります。

ただ、作り手の立場ではスケジュールも大事だけれど、ゲームそのものの面白さを追求したいという思いもわかります。
弾を1回撃つってなると、やっぱりその弾にできるだけ詰め込みたくなるものですよね。
結果その詰めこみによってすごく人気が高まるということもあります。
特に上り調子のタイトルはユーザーがとにかく新しいものを待っている状態なので、ユーザーが欲しい物をどんどん出すことも重要になります。
安定してくると目新しさよりもちゃんと遊べることをユーザーも求めますし、運用フェイズによってもやり方の正解は変わっていくと思います。

確かに歴代のヒットタイトルを見てもそういう流れを経てる気はしますね。

運用フェイズでのテストは1週間未満

リリースされてからの運用フェイズのテストでいうと、実施期間はだいたいどれくらいになるんでしょうか？

運用フェイズのテストは大体1週間未満ですね。
新しいキャラクターとかクエストがきちんと動くのか、データが正しいのかということを見るので、短期間で一気に人数を掛けてやります。

テストをものづくりのスタートとして捉える

テストで大事なことは何か教えてもらえますか。

「テストは最下流工程」と思われるかもしれませんが、そこで出てくるデータは今後の開発に最初から活用できるので、「ものづくりのスタート」として捉えるのもテストを面白くする見方なのかなと思います。
SHIFTは、そういう仕事をしたい方にとっても魅力を提供できますし、テストをただの作業と思ってる方はそこで見方を変えてもらえるとテスト、つまり品質の重要さを感じてもらえるかと思います。

自分も軽く見てたなと、このインタビューで思いました。
もっと単純なバグ取りや最終チェック係みたいなイメージだったので、開発の取り組み方にまでアドバイスというか提案してるのには驚きました。
パートナーと呼ぶ方がいいような関係なんですね。