NPO法人ソフトウェアテスト技術振興協会 イベント報告-JaSST'15 Shikoku

はじめに

高松駅からさほど遠くないところにある香川大学でJaSST'15 Shikokuは開催された。大学の構内は緑が豊富できれいだ。12時になると食堂は多くの学生でにぎわっていた。一角には讃岐うどんコーナー「讃どん」があり、学生に人気のようだ。天候は、朝までは雨が降り悪天候だったが、開始時刻には晴れ間が見えてきた。12月らしく、やや肌寒い。参加者数は、本会場に30名、サテライト会場（後述）に学生が40名だった。

実行委員長挨拶

13時に、実行委員長である香川大学高木先生の開会宣言で始まった。今年で8回目。プログラムは講演とワークショップという二部構成である。講演の部はセガゲームスの粉川氏。ゲームでは、満足、楽しいという魅力品質が重視される。これはゲーム以外でも重要なことで、参考になると思う。ワークショップの部はバルテスの石原氏で、テスト基盤の構築を体験する。今回のJaSSTは香川大学との共催とした。ワークショップの前半90分を、大学の特別講義として工学部のキャンパスをサテライト会場とし、中継する。

講演
「テストの視点で見たゲーム開発の流れと品質を支える仕組み」
粉川 貴至 （セガゲームス）

はじめに

講演者の粉川氏は、ゲーム開発における自動化とQAエンジニアリングを本業としながら、CEDEC運営委員でもある。CEDECとは、日本国内最大のゲーム開発者向け技術交流会で、参加人数はなんと6,000人！業界全体の発展のために重要な活動である。

講演内容は、変化の激しいゲーム開発で実践されている品質を支える主な取り組みの中から、情報管理と自動化を紹介したものであった。粉川氏の会社では、新しい技術への対応、膨大なデータの扱い、そして頻繁な仕様変更などの課題を乗り越えるためにCIなどの仕組みを取り入れ、魅力的で品質の良いゲームを世に送り出している。

講演時間は120分間。途中と最後に質問タイムが設けられた。筆者が印象的だった部分を中心に報告する。

【前半の部】 ゲーム開発の流れ

ゲームシステムの特徴は、画面更新タイミングにシビアであり、処理の高速化やデータ構造の最適化への取り組みが必要なことである。画面更新が間に合わないとユーザから嫌われてしまうので、シビアな画面更新タイミングという制約の中で実現できる表現とは何かを常に考えている。例えば、格闘技ゲームでのパンチの衝突判定は、リアルな拳の形状で行わず、ゲーム性に影響がない範囲で丸や四角に置き換えて判定する。

ゲーム開発に携わる人達は、デザイナが一番多く、次にプランナが多い。プログラマは少ない。プランナは、ゲームデザイナとも呼ばれ、ゲームのキャラがしゃべるセリフや様々なパラメータを作成する。

日々の開発作業では、絵、動画、音声、テキスト、パラメータなど、膨大なデータを取り扱う。仕様変更は頻繁に発生するので、変更分を取り込んだデータを毎日集約してビルドしている。

途中の質問タイム

質問：

プログラマには仕様書を書いて渡すのか

回答：

組織や人によってバラバラである。プランナがプリプロダクション（いわゆる企画段階）で書く仕様書は紙3枚程度である。プログラマ以外はシステムの実現方法について詳しくないため、プランナが仕様書に書いたことをプログラマが解釈して作るのが普通である。

質問：

外部の会社が開発に関わるか

回答：

開発に関するノウハウに関しては秘伝の部分が多く、新しい人が理解するためのコストが高いので、外部の会社には開発を依頼しないことが多い。最近は汎用的なゲームエンジンの使用が広がってきたので、一部を切り出して外部の会社に開発を頼むことができるようになってきた。

【後半の部】 品質を支える仕組み

後半では、ゲーム開発の中で行われる具体的なテスト技術などが紹介された。

日々の開発の流れで起こりそうな問題は、データの修正ミスや管理ミス、ソースコードへのバグ混入などである。これらを仕組みで解決することで製品の品質が上がると考えている。デザイナやプランナなどの様々な作業をツールで支援し、本来のクリエイティブな作業に集中させたい。開発者、デザイナ、プランナはスペシャリストだが、それぞれの間の受け渡しで事故（ミス）が起こるので、データチェック作業やデータ加工／集約作業に関してJenkinsなどを用いた自動化の対策が必要である。

自動テスト。入力だけなら自動化できるが出力検証が難しい。炎や剣のアニメーションにエフェクトがかかる。これ単独であれば正解を決めることができるが、労力の割に効果は限定的である。大きなプロジェクトでは自動テストを作ることがある。その場合は、開発と同時に作る。例えば、開発者の帰宅前にスタートさせ、ランダムで動きまわり、ボタンを押し、ものを拾う、などを実行する仕組み。朝出社して結果を確認する。

上記などの仕組みで日々の開発作業における品質は支えられている。

おまけスライドとして、開発者が意識するデバッグ項目観点（例えばレイヤ表示でよくあるバグ、サウンドの最大数に絡むバグなど）や、チームで参考にしている書籍の紹介があった。また、経営層に向けた品質の見える化に取り組んでおり、試行錯誤中であるとのこと。

質問タイム

質問：

自動テストを用意する時の判断方法は

回答：

以下のパターンがあると考える。
　1. 大きい規模でプログラマの手があいている
　2. 継続タイトルで前回痛い目を見た
　3. プログラマが優秀な人で時間を割いてこっそり作る
実際に効果が出た後だと周りの人が関心を持つので認められることが多い。

質問：

品質保証部門の関わり方について

回答：

動くものが出てきてから品質の善し悪しを判断するのでは遅いので、開発段階から品質保証部門の人が関わるようにしようとする動きがある。そのために、品質保証部門では、エンジニアのスキルセットを持った人を育てようとしている。

質問：

属人性の問題をどうしているか

回答：

スキルが人に紐づいてしまうが、引き継がないこともよくある。なぜなら、ゲームの場合は技術の進歩が早いので、引き継いで役立つことのほうが少ない。ノウハウは社内やCEDECで蓄積し、技術者同士で交換する。

まとめ（筆者感想）

ゲーム業界という、普段なかなか触れることのない分野の開発・テストの話は、興味深いものだった。工夫して良いものを出そうという気合いと貪欲さを十分に感じることができた。

ワークショップ
「テストのプロ直伝！ 長く使い続けられるテスト基盤の構築方法」
石原 一宏 （バルテス）

ワークショップの前半部は、香川大学の学生向け特別講義として開催された。会場では約10名、中継会場では約40名の学生が参加した。ワークショップは、近くの人とペアまたはトリオで進める形式だった。

石原氏が所属するバルテスはテスト専門会社で、年間600プロジェクトのテストを実施しているとのこと。結合テスト、機能テスト以降を担当されており、日々目の前にあるものをどうやってテストするのかを考えているとのことである。

はじめに

仕様書には十分な情報が書かれていない場合が大半である。会場への質問でも同様の結果だった。頻繁な仕様変更で動くものを作ることが優先になり、仕様書は最低限になりがちで、メンテナンスされていない場合が多い。

そのような状況でも、漏れ抜けなく効率的なテストを可能とするテスト基盤が必要で、その構築のためのアプローチとして以下を紹介する。

要求分析

まずは「品質」について説明する。「品質とは顧客の満足度である」と考え、満足度を高めるための3つの要求と3つの品質の考え方に着目する。

3つの要求：基本要求、変動要求、潜在要求
3つの品質：当たり前品質、一元的品質、魅力的品質

この考え方は、テストという観点だけではなく、上流工程でも使用されている。テストエンジニアだけでなく開発エンジニアにも必要なスキルである。「品質」と「要求」をセットで考え、「誰にとってか」を考えることも重要である。

この講義で行なったワークは、スポーツでの素振りや走り込みに近い。繰り返しこのワークを行なうことが効果的である。5分程度の短時間で行なうと個人毎の優先順位や思考のクセが見えてくる。自分のクセにはなかなか気づかないので、他の人と結果を見せ合うことで気づきを得られる。

ワークでは、基本要求の中で、「やってはいけないこと（Never）」に注目する。時間がないときに何をテストしないといけないのか。全数テストが不可能な中、その中でも絶対テストしないといけないものは何か。組み込み系だと、けがをさせる、など。個人情報の流出もそう。正常系の仕様は書かれているが、異常系は書かれていないことが多い。このワークはnever/must/wantの欄を用いておこなう。

FV表

本日のワークには、時間が潤沢にあるわけではないが、最低限の考慮はしたいという背景がある。何をテストするのかを考える際にFV表が有効である。

FV表とは、ユーザが何をしたいのか（要求）を探っていき、テストの十分性を確保するテクニックである。FV表を書き起こすことによって、機能の目的を考えながらテストケースを作っていくことができる。

テストマップ

テスト対象とテスト観点をマトリックスにする。これをテストマップと呼ぶ。仕様書とテストケースを直接結びつけるとわかりにくくなるので、間にテストマップを入れることが有効である。

テストマップに空欄があったら、ここは大丈夫かと考えることが重要。考えた末に空欄だったらよい。問題が出たら改善すればよい。機能も観点もたくさんあってテストマップを作れないという意見をもらうが、100点主義はやめたほうがいい。まずは重要な機能を対象にすることをお勧めする。

テスト観点のデメリットは、それ以上のテストを実施しなくなってしまうことである。まずはnever/must/wantのワークをやってから、テスト観点を参照することをお勧めする。

限られた時間内で最大限のテストをするために、テスト観点に優先度を付ける。テスト対象機能を明らかにすると同時に、テスト非対象機能を明らかにする。そうしないと無限責任を追うことになってしまう。全体を俯瞰したうえで、なにをテストするのか、を明確にする。

以上、テスト基盤の基礎的なところを、ワークを通して体験した。安定したテストの運用のためにテスト基盤を構築し、活用していただきたい。

まとめ（筆者感想）

石原氏が普段から実践されているテスト基盤の一部を、ワークショップという形でわかりやすく体験できたことは、とても有意義だった。様々なワークを通して製品のことを考えるうちに、製品へ愛着が沸き、品質を高めたいと感じた。この感覚が、冒頭の「品質とは顧客の満足度である」につながるのだろう。素振りのように、ワークを繰り返して練習したい。ちなみに、石原氏は時々家電量販店に行って、新製品を対象にnever/must/wantをやっているそうである。

終わりに

2010年以降のJaSST Shikoku は、講演とワークショップが1セッションずつの構成で、それぞれに割り当てられている時間が長い。興味あるテーマをじっくりと聞き、考える良い機会だと思う。