はじめに

こんにちは！SHIFTエンターテインメント業界ウェビナー担当の高木です！

今回で21回目となる、ウェビナー「SHIFT Game Producer Meetup #21 」では、SHIFTの教育専門機関「ヒンシツ大学」講師の杉原、SHIFTアカウントマネージャーの村島が登壇し、1LDK 朝岡 氏をファシリテーターに対談を行いました。

一部分ではございますが、その様子をぎゅっとまとめてお届けします！

👉PDF無料配布中！ゲームテスト効率化にむけたSHIFTの取組みと事例

テーマ：テスト観点について

SHIFT杉原：「テスト観点」って人によって定義が違うと思うんですね。こういう概念があるのって日本だけなんです。だからみんな自分がこうだと思っているやり方で好き放題やっていて、誰しも否定できるようでできなかったり、それが正しいと言い切れるようで言い切れなかったりすることが面白い部分かなと思っています。

1LDK　朝岡氏(以下、1LDK朝岡)： それだと発注するときのコストコントロールが難しくないですか？

SHIFT杉原：そうなんですよ。だから、そのテスト観点というものをどう定義しているかがズレている状態で契約してしまうことが怖い。ただある程度ブレない部分とブレる部分があると思っています。

普段の日常生活に置き換えてみれば良いんですね。例えばラーメン屋だったらどういう風に見るのかとか、どういう風に見ると美味しいラーメンになるかって、自分が判定する時にいろんなことを考えるはずなんです。

具の配置だとか、麺、スープ、見た目、値段、どんぶりの形とか、お店の雰囲気がどうとか、マスターの怖さがどうとか、様々あると思います。

値段は高いけど、お店が綺麗というのは個別に独立している評価なので、お互いに影響しないわけですね。テスト観点と同じで、これを見ればそれぞれ独立した評価のテストとして考えるという風にできるので、同じような概念を実は日常的に使っているんですよ。その考え方をテスト観点に落とし込んでみれば良いんですよね。

うまく出来ているかどうかという風に考えると、そのゴールライン、基準というところが出てくると思います。しっかり動作するかどうかのソフトウェアテストをするときには、どこのポイントが大事なのか、今見ている味だけじゃなくて、ちょっと他の視点から見てみる。テストの観点というのは、「観る点」と書きます。その目線を変えてみる。

例えば握り拳の背中だけを見ていても、指の曲がり具合のテストは思いつかないので、反対側から見たときに親指の位置が見えて、こっちは何が正しい、1番良いのはどれか、逆にここのうずまきのところはどうなのかとか、反対側から見るとそれぞれ観点が違うんですよね。つまり、確認すべきことも変わってくるはずなので自分の中でバリエーションを変えていくんですね。

実際のウェブサイトで出てくるテキストボックスで言えば、こういうテスト観点というところを見ていく現実的なテスト観点として、よくありがちなものというのを例として挙げました。

SHIFT杉原：こうやって、テスト観点を意識することによって、様々な方向からテスト対象というものを見て、それらがどうあるべきか、そこから自分たちが今何を整理して考えるべきかに繋げていく。そうするとテストのケースを作る際の大まかなベクトル、方向性、つまりテスト観点が整理できて、それを突き詰めると、詳細なテストケースにまで落とし込むことが出来るかなと思います。

1LDK朝岡：テスト観点で詳細にすることで何かデメリットはあったりするんですか？

SHIFT杉原：単純に言うと時間がかかる。基準とか細かいところまでやろうとすると、バリエーションや、データ、環境、権限、タイミング、いろんなものを考慮しなきゃいけなくなって、詰まっちゃうんですね。

1LDK朝岡：あとは結構、企業の規模とかもありますよね、このテストを、サービスの性質と企業の規模と導入のタイミング、その3点がそろっていないと、後になればなるほど観点を丁寧にやることができなくなってくるから、そのサービスを立ち上げるタイミングから、これを想定した作りにしておく必要がある感じですよね。

SHIFT杉原：このテスト観点において、重要なところの1つ目は「主語」という概念ですね。誰が確認するかのバリエーションを意識してもらうというのがポイントになります。

2つ目は、何を見て良いな、うまくできたなという風に思うのか。食べるという行為、味をちゃんと判定して、その味に対する感想で結果になる。実際に誰が何をどういう風に作ったのかの過程だったり、どういう状況で出すかだったり、その動作や確認にしっかり中身とポイントを置いていくと、今度は人だけでなくその人が何をするかという形にバリエーションが変わっていきます。

場所と人の主語のバリエーションの後ろに、その動作のバリエーションをそれぞれ付けてあげれば、具体的にこの人がこれをしたとき、また別の人がこれをしたときという風に、テスト観点のバリエーションとなる基軸がたくさん増えていくので、テスト観点として洗い出しやすくなってくると思います。

3つ目、何が動作をして、そしてその先にあるもの。実際のソフトウェア開発となると、仕様の中でも実装されている部品や、その機能、作っている環境、同じ主語がこのことを行うんだけれども、この部品に対してだったらそうだけど、違う部品に対してだったらまた違った結果になる、違うテストになるという風に、それぞれ置き換えていくことができます。

なので、主語、動作、そしてそれをターゲットとして何をするといったバリエーション、ここを考えながら、観点に落とし込んでみてもらうとより良いのかなと思います。

1LDK朝岡：ゲーム業界のテスト観点で、漏れがちな観点とかってあるんでしょうか？

SHIFT村島：ゲーム開発をする上で、1年半～2年とか開発期間も長くなってくると、符号が変わることが結構あると思うんですよね。なので、テストとかが始まって、もうちょっと要素必要だよねとか機能が変わったり、初めに観点は決めていたけど、粒度を決めていく中で漏れが起きやすかったりということはありますね。

1LDK朝岡：そうですよね。互換性とかもありますよね。最初はGoogleとAppleだけ出そうとしたけど、やっぱりSteamも出そうみたいな話になった瞬間に、一気に変わるような。 そこはどうしたら良いんでしょうね？決めきれない部分もあるじゃないですか。

SHIFT村島：そこら辺はもう本当に密にコミュニケーション取りながら、仕様が変わるんだとか、きちんとテスト観点が常にズレてないかということは、定期的にコンフィティングを積み重ねて進めるしかないんじゃないかと思いますね。

テーマ：機能／非機能品質について

SHIFT杉原：機能はイメージとしては「WHAT」。で、非機能は「HOW」という風に表現できるんではないかと思います。どうできますか？という部分に関しては、HOW、非機能になるという形なんですね。

まずは機能として、登録できるかできないか。登録できるようになった、じゃあそこは機能として成立している。ただ登録に5分かかる、遅いですよね。登録処理までが遅い状態で動作している。反応速度などは非機能と呼ばれるものになります。 つまり機能自体だったら、仕様や設計通りに動けば良いと分かりやすく評価できるんですね。品質として担保しやすいですし。

仕様、設計通り動いていれば大丈夫だけどゲームが面白くないとか、テンポが悪い、非機能部分の要素が足りていない、品質が足りていないという風になって、品質問題になってくるというのが最近特に批判になることが多いのかなと思っています。

機能品質が満たされたとしても、その先にある非機能品質が満たされていなければ、やっぱりユーザーの満足度というのは、必ずしも上がるわけでは無いんですよね。じゃあ、非機能品質をきちんと定義して、何をどこまで今回のプロジェクト内で実現するのか、そういった目標に置き換えていく。この考えが非機能品質をコントロールしていくという概念になります。

品質モデルとして、品質を8つに分類して、機能品質は「機能適合性」だけ、残りの7つは「性能効率性」「互換性」「使用性」「信頼性」「セキュリティ」「保守性」「移植性」、これ全部非機能品質です。

これだけやっていれば大丈夫という形ではなくて、自分たちのプロジェクトにとっては、どんな非機能品質がクリティカルなのかという検討がとても重要です。

機能品質を表す「機能適合性」。仕様通りできているかというところ。そして正確性。データ格納や計算、そういった処理関係の動きの部分を特に指します。どちらかと言うと仕様検討の部分になってくるところを品質として指すことにもなります。

非機能品質は「性能効率性」というものになるんですが「数値」で表す品質をイメージされると大抵これになることが多いです。反応速度などです。これが悪いともうゲーム続けたくなくなりますから。

「互換性」。これはどんな環境で動くかという形で、単純にOSのバージョンとか、ブラウザとか、ロジックのインストールされているものが何かということだけでなくて、別のアプリだったり、サーバーだったりが相互に動いている状態を共用できているという相互運用性といった部分まで必要になってくるかなと思います。

「使用性」。ユーザビリティです。使いやすさ、マニュアルを見なくてもすぐ分かるところですね。様々な表現で、認識性が高い、習得性が高いとか、運用操作性が高い、ユーザーエラーが起きないように防止している。インターフェースが非常に美しい快美性とかですね。

「信頼性」。データが壊れないという意味での信頼というのもありますし、問題が起きたときにどれだけで回復するか、そういった部分をどこまで想定して作りこまれているか、そしてそれがちゃんと機能するかを信頼性と表現しております。

「セキュリティ」。これぐらいの職種の方は個人情報にアクセス出来ないようにさせている。逆にある一定以上のランクの権限でなければ、その個人情報はアクセス見えないように管理する。外部的なガードだけでなく、内部的としての情報統制といったところまで含めたセキュリティという非機能品質となります。

「保守性」。ソースコードが非常に読みやすい、作った人以外が読んでもパッと分かる、バグ修正ができる、機能追加できるというようなものは保守性品質が高いという風な言い方をします。

「移植性」。例えばiOS専用で開発していてandroid対応する予定はない。でももし今後android対応するぞって言われたら、フラグを1から2に変えれば、すぐandroidに対応できてパパッと切り替えられるのは移植性品質高いよねということです。

この8つが非機能品質で一般化された定義という形であります。それぞれをちゃんと検討して、自分たちはどれに対して、どれぐらいアプローチするのかを整理してプロジェクトに臨むと、非機能品質に関してもうまく調整ができるんではないかと思います。

―最後に総括としてお2人からアドバイスを頂きました。

1LDK朝岡：村島さんから、ゲーム業界でより改善が回っていくようなアドバイスなどいただけますか？

SHIFT村島：ゲームの面白さを評価する人がその開発の内部だけとか関係者だけだと、どうしても感覚的なものになりがちだと思うんですよね。売れるかどうかは別問題となると思うので、その操作性、シンプルかつ直感的か、視覚の効果、音響の効果、ゲームへの没入感、きちんと取り込むことができるのか、というところはまずベータ版、クローズドでも構わないと思います。 プロダクトをより良くしようという意識があるなら、SHIFTであればユーザーテストなど何か活用していただきたいなと思っています。

SHIFT杉原：全体を通して、仕様通りの機能だけでなく、そこに＋αされる非機能品質といったところまで考えるというのが、プロジェクトの成功に大きく繋がるのではないかな。 非機能品質が全部満たされればそれに越したことは無いんですけど、できるわけないので自分たちで今何をやるべきかの優先度ですよね。そこを検討するのが重要かなと思いますね。

―ここでトークセッションも終了。

いかがでしたでしょうか？今後も「SHIFT Game Producer Meetup」を開催してまいります。ご期待ください！

👉PDF無料配布中！ゲームテスト効率化にむけたSHIFTの取組みと事例

★おすすめマガジン

★お問合せはお気軽に

SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/

SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/

SHIFTの導入事例
https://service.shiftinc.jp/case/

お役立ち資料はこちら
https://service.shiftinc.jp/resources/

SHIFTの採用情報はこちら