前回は、シミュレーションゲームの品質確保に主題について、テストプレーに依存しない方法について考察してみた。今回はその続きで、具体的な方法について考察してみたい。

その前にレビューという用語についてちゃんと定義しておきたい。レビュー(review)とは「評論」「査読」といった意味がある。しかし英語では同じレビューでも、日本語での「評論」と「査読」はかなり意味が違う。「評論」は主に一般に公表された後の製品や作品に対する論評を指し、「査読」は公表前の製品や半製品、中間成果物に対する評論を指す。ここでいうレビューとは後者の「査読」に近い意味とお考え頂きたい。

一言にレビューといっても単にぼんやり眺めているだけではバグを見つけることはできない。これはコンピュータソフトウェアの場合も同じである。そこでコンピュータソフトウェアの場合、チェックリスト方式を用いられることがある。これは読んで字の如くチェックするためのリストで、コンピュータソフトウェアの場合は、要求仕様書、方式設計書といったドキュメント類、ソースコード、そしてテストスペック等を対象としてそれぞれチェックリストが作成される。シミュレーションゲームの場合もチェックリスト方式を採用できないものだろうか。そこで私なりにシミュレーションゲームのレビュー用チェックリストを作成してみた。

企画書

素人デザイナーが企画書を作ってからデザインする事は少ないと思うが、私は企画書のようなものを作った方が「良いゲーム」が出来る可能性が高いと思っている。そこで企画書を作ると仮定して、そのチェックリストを作ってみた。

・テーマは明確か
・表現したい主題は明確か
・購買対象は明確か
・想定するプレイ時間は明確か
・テーマ、主題、プレイ時間は購買対象にとって受け入れ可能か
・想定するコンポーネント規模は明確か
・コンポーネント規模は収益性が確保できる内容か【作り手の事情】
・プレイしていて「面白い」と感じるポイントがプレイヤーに提供されているか
・デザインの動機(熱意)は客観的に表現されているか。
(他にもあるかもしれないので、皆さんのアイデアをお待ちします)

ラフモデル

ここで言うラフモデルとは、コンポーネントは1式揃えた上で、ルールブックはまだ清書せず、デザイナーの口頭説明乃至はメモ書き程度のルールしかない状態である。開発当初にVASSALモデルを使う場合もあるが、最終的にはバーチャルではなく実モデル化されていると仮定している。この段階でのチェックリストは以下の通り。

・テーマや主題は企画書と整合性が取れているか
・プレイ時間は企画書と整合性が取れているか
・コンポーネントは必要十分な数が用意されているか（プレイヤーが2人なのにチャートが1枚等ということはないか？)
・コンポ―ネントに二重定義されている箇所は正しく識別されているか

(注)二重定義とは、例えばユニットとマップの両方にセットアップ情報が記載されているようなケースを指します。この場合、一方を修正した時にもう一方を修正忘れすると、バグになります。

・チャート類はコンパクトにまとめられているか(不必要にバラけていないか)
・ルールブックを暗記しないと致命的なミスを犯すような箇所はないか(コンポーネントで補正されるとか、相手プレイヤーが指摘する等して補正可能か？)
・ユニットの文字は判別可能か
・ユニットはマップ上に問題なく配置できるか(ヘクスが小さすぎる、スタックが大き過ぎる等の問題はないか)
・無駄に煩雑な手順はないか(1回で処理できる内容をワザワザ2回以上の手間をかけさせていないか)
・デザイナーが楽をしてプレイヤーが苦しむような箇所はないか(デザイナーが気を利かせればプレイが楽になる所でデザイナーが手抜きをしていないか)
・コンポーネントは「見ていて楽しい」ようになっているか(別に「萌えキャラ」を使う必要はないが、無愛想なユニット／マップは時代にそぐわない)
・一工夫すればプレイアビリティが向上するような修正ポイントはないか
・セットアップが分かりやすいように工夫されているか
・必勝法乃至は極端に一方の勝率が良くなるような「裏技」的な戦法はないか
・数値の扱いは明確か（以上、以下、未満、範囲、切上げ、切捨て、四捨五入等の扱い）
・企画書に記載したプレイしていて「面白い」と感じるポイントが正しく実現されているか
(他にもあるかもしれないので、皆さんのアイデアをお待ちします)

完成版

完成版はラフモデルに正式版のルールブックを追加した状態を言う。この段階でのチェックリストは以下の通り。

・ルールブックに曖昧な箇所はないか
・ルールブックに矛盾した箇所はないか
・ルールブックは構造化されているか
・ルールブックを暗記しないと致命的なミスを犯すような箇所はないか(コンポーネントで補正されるとか、相手プレイヤーが指摘する等して補正可能か？)
・ルールブックで定義されている数値とチャート類に記載されている数値で二重定義されている箇所はないか。二重定義されている箇所は正しく識別されているか。二重定義されている場合、両者は整合性が取れているか。
・ルールブックは相互参照可能な形になっているか。また参照先は矛盾していないか。
・数値の扱いは明確か（以上、以下、未満、範囲、切上げ、切捨て、四捨五入等の扱い）
・「から」「まで」「～」等の範囲を示す用語について、境界値を含むか含まないは明確か
・用語の使い方は統一されているか。同じ意味で複数の用語、あるいはひとつの用語が複数の意味で使われている事例はないか-->用語集を整備すべきである。
(他にもあるかもしれないので、皆さんのアイデアをお待ちします)

テスト

コンピュータソフトウェアの場合も最終的な品質はレビューではなくテストで担保されるのが普通である。しかしそのテストもただ闇雲にテストしても工数の無駄遣いでしかない。そこで以下にテスト時のチェックリストを作ってみた。

・プレイ時間は企画書の内容を満足しているか
・必勝法乃至は極端に一方の勝率が良くなるような「裏技」的な戦法はないか
・ルールブックを暗記しないと致命的なミスを犯すような箇所はないか(コンポーネントで補正されるとか、相手プレイヤーが指摘する等して補正可能か？)
・企画書に記載したプレイしていて「面白い」と感じるポイントが正しく実現されているか

とまあこんな感じである。他にもチェックリストはアイデア次第で充実可能なので皆さんのアイデアをお待ちしたい。

私の提案したチェックリストについて、プロのデザイナー、デヴェロッパーの方から見れば笑止であろう。それはそれで良い。私は別にチェックリスト自体の内容を自慢したいのではない。そうではなくて、このような知見を形式知化することが重要だと言いたいのである。

またチェックリストの整備は、ファシリテーション的な意味からも有益である。従来ゲームデザインに関する議論は「デザイナーvsレビューア」という図式になるケースが多かった。そこには対立の構図が生まれ、生産的な議論ではなく不毛な議論に陥る。非生産的な議論は対立と恨みしか残さない。
しかしチェックリストを整備することで、議論の図式が「デザイナーvsレビューア」から「我々vs問題点」に変化する。議論している「我々」が「問題点」という共通の敵に立ち向かうという図式になるので、議論が生産的になる。生産的な議論は製品の品質に直接還元される。

このような形でチェックリストを充実させると、テストプレイに過度に依存しなくても、ある程度の品質を持ったシミュレーションゲームがデザインできるようになると確信している。私のアイデアが、私も含めた素人デザイナーにとって新たな可能性を開いてくれることを期待したい。

P.S.　上記のうち、「裏技」的戦法の識別については、現在テスターの技量に依存しているのが実情である。このあたり、もっと形式知化し、半自動的に識別できる方法を研究すると、面白いかもしれない。