つぶやく
パーティー×開拓×ドラゴンなチルゲー「星のパーティータイム」のインプレッション＆インタビュー。一見不思議なコンセプトの裏には狙いがあった
2025年9月25日から28日にかけて開催された東京ゲームショウ2025のNetEase Gamesブースに「星のパーティータイム」というパーティーゲームが出展されていた。パーティーゲーム要素と，開拓シミュレーション要素を合わせたという本作について会場で試遊し，プロデューサーへのインタビューを実施した。
2023/09/02 13:25イベント
［CEDEC 2023］「テストエンジニアが伝える テストを実施する前に考えるべきテストの話」聴講レポート。開発が参加し，欠陥を未然に防止するテストの大切さ
ゲーム開発者向けカンファレンス「CEDEC 2023」で，「テストエンジニアが伝える テストを実施する前に考えるべきテストの話」と題された講演が行われた。ソフトウェアを作る前に一歩立ち止まり，必要になるテストについて打ち合わせをすれば，コストや手間を削減できるという。ソフトウェアのテストといえば，完成後に行うものというイメージがあるが，その前に行うべきテストとは，どのようなものなのだろうか？
講演を行ったのは，10X / B-Testing Qualityチームの風間裕也氏。ソフトウェアのテストに関する研究やワークショップを行うJaSSTのレビューシンポジウムJaSST Reviewや，若手のテストエンジニア向け勉強会WACATEの実行委員長などを務める人物だ。
今回の講演内容について風間氏は，ゲーム系QAの話ではなく，「システム部分をどうテストすべきか，どうコストを減らせるかの話」だと前置きした。とはいえ，ゲームにまったく無関係な話ではない。ゲーム関連のテストには，「世界観をしっかり表現できているか」「システムがちゃんとできているか」という2つに大別できる。システムのテストに関するコストが削減できれば，全体に良い影響を及ぼすことは想像に難くない。
「ソフトウェアのテストに関する話」と聞けば，テスターやQAチームの職務や，テストコードの書き方といった内容を想像するが，講演で語られたのは，ソフトウェアのテストにおいて，開発者が何をすべきかという点だ。ソフトウェアを作ってからテストを行うよりも，開発者が参加して事前のテストを行うことで，物事がより円滑に進むという。
そもそも，ISTQB（国際ソフトウェアテスト資格認定委員会）は，テストの目的について「欠陥の検出」「対象ソフトウェアの品質レベルが十分なことの確認（完璧であることを保障するものではない）」「意思決定のための情報の提示（ソフトウェアが抱える欠陥について明らかにできれば，リリースを遅らせるかどうかといった意志決定の助けにもなる）」「欠陥の作り込みの防止」であると定義している。「テストの7原則」で言われているように，テストでは欠陥の存在しか指摘できず，原因の特定はできないのだ。
中でも風間氏が重視するのが，「欠陥の作り込みの防止」。もし実装する項目に誤りがあったとして，プログラミングを始める前に確認しておけば，修正に必要なコストもわずかで済む。早い段階であるほどコストは少なく，要求仕様の段階を1とすれば，設計時は5倍，実装後なら10倍，リリースされてからは200倍……と作業が進むごとにテストのコストは上がっていく。誤りを特定し，修正を行うのもタダではないし，リリースされてからの修正ともなれば，対外的な信用も失墜する。いいことは何もないのだ。
一般的に，ソフトウェア作りは集団で行われる仕事だ。例えば「ユーザーにパスワードを入力させる画面を作る」としよう。事前のテストが行われていないと，開発者たちが「エラー対応の部分は，誰か別の人が作ってくれているはず」などと考え，そのままソフトが完成してしまうようなことも起こり得る。
今回の講演は，聴講者同士がグループを作り，風間氏が出した課題に取り組むというグループワークの形式で進められた。それぞれが考えたテスト内容や気になった部分，起こりそうなバグといった部分を挙げていったのだが，内容は見事なほどにバラバラだった。つまり，開発者も参加して事前にテストや意志疎通を行っていれば，欠陥となり得る部分について多くの視点から考察できるということだ。
例題となった「ユーザーにパスワードを入力させる画面を作る」という仕事については，事前に「許容しない文字が入れられたときどうするか」という意見が出てきた場合，あらかじめ開発者たちが，「エラー画面を作る」「テストしとく」などと意志疎通を図っておくことで，作り忘れはまず起こらないという。そもそもコードを書き始める前なのでコストも手間も少なくて済むし，対外的な信用を失うこともない。欠陥のある仕様を作り込むことを防止できたわけで，いいことづくめなのだ。
風間氏によれば，このとき，「機能を作る」と「顧客へ価値を提供する」が同義でないことを意識しておけばより良いという。
例として挙げられたのが，公共施設でエスカレーターや化粧室などの場所を示す看板だ。写真を見てもらえば分かるとおり，この看板は非常に分かりづらい。化粧室へ行きたいとしても，どの方向を目指すべきかが直感的に伝わってこないのだ。この看板も，デザインの採用担当者にとっては面白いものだったのだろうが，顧客に対して価値（この場合は行きたい場所がすぐに分かること）を提供できていない。顧客が本当に求めるものを考えるのがいかに大事であるかが分かるだろう。
どのようにテストケース（ここでは，テストで確認すべき内容，条件，実行手順，期待する結果といったもののセット）を作るかも考えなければならない。つまり，「何をテストするか」「それをどうテストするか」を考えるのが大事だというわけだ。
テストの7原則にあるように，全数テストは不可能。闇雲にテストしていくと，膨大な時間がかかってしまう。そのためテストケースを作る際，作成者に対して大喜利のように「それはどうしてだい？」と尋ねる心持ちが有効だ風間氏は述べる。
なぜテストが必要になるのか，理由も含めて考えていくのが重要なのだ。ここをしっかりやっておけば，テストケース名を付ける際にも役立つ。テストケースを設計する場合，抽象的なハイレベルテストケースから，具体的なローレベルテストケースへ落とし込まれる。なぜテストが必要になるのかの理由をしっかり考えておけば，これをハイレベルテストケースの名前として使うことができ，あとからプログラムを見る人にも意図が伝わりやすくなる。
「これだけテストを充実させれば，QAやテスターは必要ないのでは？」という声も良くあるそうだ。しかし，実際はそうではない。本来，QAやテスターがやるのは，単体テスト→結合テスト→システムテストと開発が進行していく中のシステムテストにおいて，意図したとおり製品が動くかを確認する「Checking」ではなく，想定外の動作でシステムがどうなるかを確認する（風間氏曰く「なんとかして製品を破壊する」）「Testing」だ。
開発者がこの違いを理解していれば，単体テストと結合テストの段階を終えてからQAやテスターに渡せるし，Testingに専念してもらえる。Testingの，「なんとかして製品を破壊する」という感覚は，苦労してプログラムを書いた開発者には，なかなか持てないという。
最後に風間氏は，自分の経験として「開発者に質問する大切さ」を語った。開発者はどうしても「どう作るか」部分に集中しがちだが，テストエンジニアの観点からは，「で，これで何をしたいんだっけ？」というニュアンスの質問を投げようにしているという。こうすることにより開発者は，How（どう作るか）からWhat（何をしたいか）に立ち返ることができ，想定から抜けている部分に気づいてくれるのだそうだ。
テストはソフトウェアが完成してから行われるものだというイメージがあるが，実際には，制作にかかる前にできるテストも存在する。そもそも，テストと一口に言っても，CheckingとTestingがあり，テスターならではの視点で行うのは後者だ。開発者が前者を行う事でよりTestingに集中できるようになる。その一方，テスターは開発者に問いかけることでテストの精度を上げていける。
異なる職種であるからこそ，テスターと開発者が協力することが大事であるわけで，ソフトウェアのテストに関する話であると同時に，組織で働くにあたって普遍的な部分も含まれた講演だと感じられた。
 |
開発が参加し，欠陥を未然に防止するテストの大切さ
 |
今回の講演内容について風間氏は，ゲーム系QAの話ではなく，「システム部分をどうテストすべきか，どうコストを減らせるかの話」だと前置きした。とはいえ，ゲームにまったく無関係な話ではない。ゲーム関連のテストには，「世界観をしっかり表現できているか」「システムがちゃんとできているか」という2つに大別できる。システムのテストに関するコストが削減できれば，全体に良い影響を及ぼすことは想像に難くない。
 |
「ソフトウェアのテストに関する話」と聞けば，テスターやQAチームの職務や，テストコードの書き方といった内容を想像するが，講演で語られたのは，ソフトウェアのテストにおいて，開発者が何をすべきかという点だ。ソフトウェアを作ってからテストを行うよりも，開発者が参加して事前のテストを行うことで，物事がより円滑に進むという。
そもそも，ISTQB（国際ソフトウェアテスト資格認定委員会）は，テストの目的について「欠陥の検出」「対象ソフトウェアの品質レベルが十分なことの確認（完璧であることを保障するものではない）」「意思決定のための情報の提示（ソフトウェアが抱える欠陥について明らかにできれば，リリースを遅らせるかどうかといった意志決定の助けにもなる）」「欠陥の作り込みの防止」であると定義している。「テストの7原則」で言われているように，テストでは欠陥の存在しか指摘できず，原因の特定はできないのだ。
 |
中でも風間氏が重視するのが，「欠陥の作り込みの防止」。もし実装する項目に誤りがあったとして，プログラミングを始める前に確認しておけば，修正に必要なコストもわずかで済む。早い段階であるほどコストは少なく，要求仕様の段階を1とすれば，設計時は5倍，実装後なら10倍，リリースされてからは200倍……と作業が進むごとにテストのコストは上がっていく。誤りを特定し，修正を行うのもタダではないし，リリースされてからの修正ともなれば，対外的な信用も失墜する。いいことは何もないのだ。
 |
一般的に，ソフトウェア作りは集団で行われる仕事だ。例えば「ユーザーにパスワードを入力させる画面を作る」としよう。事前のテストが行われていないと，開発者たちが「エラー対応の部分は，誰か別の人が作ってくれているはず」などと考え，そのままソフトが完成してしまうようなことも起こり得る。
今回の講演は，聴講者同士がグループを作り，風間氏が出した課題に取り組むというグループワークの形式で進められた。それぞれが考えたテスト内容や気になった部分，起こりそうなバグといった部分を挙げていったのだが，内容は見事なほどにバラバラだった。つまり，開発者も参加して事前にテストや意志疎通を行っていれば，欠陥となり得る部分について多くの視点から考察できるということだ。
例題となった「ユーザーにパスワードを入力させる画面を作る」という仕事については，事前に「許容しない文字が入れられたときどうするか」という意見が出てきた場合，あらかじめ開発者たちが，「エラー画面を作る」「テストしとく」などと意志疎通を図っておくことで，作り忘れはまず起こらないという。そもそもコードを書き始める前なのでコストも手間も少なくて済むし，対外的な信用を失うこともない。欠陥のある仕様を作り込むことを防止できたわけで，いいことづくめなのだ。
 |
 |
 |
 |
 |
風間氏によれば，このとき，「機能を作る」と「顧客へ価値を提供する」が同義でないことを意識しておけばより良いという。
例として挙げられたのが，公共施設でエスカレーターや化粧室などの場所を示す看板だ。写真を見てもらえば分かるとおり，この看板は非常に分かりづらい。化粧室へ行きたいとしても，どの方向を目指すべきかが直感的に伝わってこないのだ。この看板も，デザインの採用担当者にとっては面白いものだったのだろうが，顧客に対して価値（この場合は行きたい場所がすぐに分かること）を提供できていない。顧客が本当に求めるものを考えるのがいかに大事であるかが分かるだろう。
 |
 |
 |
 |
 |
どのようにテストケース（ここでは，テストで確認すべき内容，条件，実行手順，期待する結果といったもののセット）を作るかも考えなければならない。つまり，「何をテストするか」「それをどうテストするか」を考えるのが大事だというわけだ。
テストの7原則にあるように，全数テストは不可能。闇雲にテストしていくと，膨大な時間がかかってしまう。そのためテストケースを作る際，作成者に対して大喜利のように「それはどうしてだい？」と尋ねる心持ちが有効だ風間氏は述べる。
なぜテストが必要になるのか，理由も含めて考えていくのが重要なのだ。ここをしっかりやっておけば，テストケース名を付ける際にも役立つ。テストケースを設計する場合，抽象的なハイレベルテストケースから，具体的なローレベルテストケースへ落とし込まれる。なぜテストが必要になるのかの理由をしっかり考えておけば，これをハイレベルテストケースの名前として使うことができ，あとからプログラムを見る人にも意図が伝わりやすくなる。
 |
 |
 |
「これだけテストを充実させれば，QAやテスターは必要ないのでは？」という声も良くあるそうだ。しかし，実際はそうではない。本来，QAやテスターがやるのは，単体テスト→結合テスト→システムテストと開発が進行していく中のシステムテストにおいて，意図したとおり製品が動くかを確認する「Checking」ではなく，想定外の動作でシステムがどうなるかを確認する（風間氏曰く「なんとかして製品を破壊する」）「Testing」だ。
開発者がこの違いを理解していれば，単体テストと結合テストの段階を終えてからQAやテスターに渡せるし，Testingに専念してもらえる。Testingの，「なんとかして製品を破壊する」という感覚は，苦労してプログラムを書いた開発者には，なかなか持てないという。
 |
 |
 |
 |
最後に風間氏は，自分の経験として「開発者に質問する大切さ」を語った。開発者はどうしても「どう作るか」部分に集中しがちだが，テストエンジニアの観点からは，「で，これで何をしたいんだっけ？」というニュアンスの質問を投げようにしているという。こうすることにより開発者は，How（どう作るか）からWhat（何をしたいか）に立ち返ることができ，想定から抜けている部分に気づいてくれるのだそうだ。
 |
テストはソフトウェアが完成してから行われるものだというイメージがあるが，実際には，制作にかかる前にできるテストも存在する。そもそも，テストと一口に言っても，CheckingとTestingがあり，テスターならではの視点で行うのは後者だ。開発者が前者を行う事でよりTestingに集中できるようになる。その一方，テスターは開発者に問いかけることでテストの精度を上げていける。
異なる職種であるからこそ，テスターと開発者が協力することが大事であるわけで，ソフトウェアのテストに関する話であると同時に，組織で働くにあたって普遍的な部分も含まれた講演だと感じられた。
 |
4Gamer「CEDEC 2023」掲載記事一覧
- この記事のURL：
4Gamer.net最新情報
注目記事
プラットフォーム別新着記事
総合新着記事
企画記事
新着連載
新着レビュー
新着インタビュー
