もりつちの徒然なるままに

ウォーゲームの話や旅の話、山登り、B級グルメなどの記事を書いていきます。 自作のウォーゲームも取り扱っています。

2016年06月

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

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

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

企画書

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

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


ラフモデル

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

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


完成版

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

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


テスト

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

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

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

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

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

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

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


[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]

IMPERIUM(インペリウム)第2版
価格:6,600円(税込、送料別) (2023/7/3時点)


イメージ 11

田原坂の古戦場は以前に訪れた事があったのですが、先日、某所で西南戦争資料館というものが出来た事を知り、「これは是非行ってみなければ」と思って行ってみました。

場所は田原坂公園の真ん中にあり、田原坂の古戦場が一望できる高台にあります。入場料は\300ですが、十分にその価値はありました。ビデオによる田原坂合戦の紹介、当時使われていた小銃、大砲、弾薬、兵士たちの被服や携行食糧、これらが展示されていました。

イメージ 1

イメージ 2

イメージ 3

イメージ 4

イメージ 5

イメージ 8


これだけなら普通の資料館と変わらないのですが、この資料館の一番の目玉は、ドラマ仕立ての3Dシアター。田原坂の戦いをドラマチックに再現しており、山砲による制圧射撃、薩摩士族と政府軍歩兵との射撃戦闘等がリアルに描かれています。戦友を失った薩摩士族が得意の近接戦闘で政府軍歩兵3名を瞬時に切り倒すシーンは痺れます。

イメージ 9

イメージ 6

イメージ 7


交通の便がやや悪いのが難点ですが(JR田原坂駅から徒歩30分)、その点を差し引いても一見の価値ありです。

イメージ 10

非電脳型のシミュレーションゲームは、ソフトウェアである。従って所謂コンピュータソフトウェアと多くの点で類似性がある。アイデア次第、物理法則に拘束されない自由度の高さ等が共通項として挙げられる。

コンピュータソフトウェアにおいて品質が最重要であることを看過したのは、ワッツ・S・ハンフリーだが(他にもいると思うが省略)、シミュレーションゲームの世界で品質が第一であることを文書で書いた人は、私の知る限り日本の鈴木銀一郎氏だけだと思う。Tactics誌第4号に氏の記事が掲載されているのだが、その中で氏は「テストプレーは品質管理である。品質管理を十分に行わない企業は競争に敗れると思わなければならない」と主張している。この主張は30年以上経過した今日においても輝きを失っていない。
この記事が取り上げているゲームは「日本機動部隊」という空母戦ゲームだ。私自身はこのゲーム、恣意的な日本軍贔屓のレーティングが好きになれないので好みのゲームではないのだが、これまでに国際通信社から2度に渡って再販されており、その度に高い評価を得ているという事実を考えると、名作とするしかないのだろう。

さて、鈴木氏の言葉が今でも重みを失っていないのは否定しないが、果たしてそれが現在のゲーム業界の実情に即しているのだろうか。つまりテスト至上主義の品質管理は、既に破綻してるのではないか、というのが今回の問題提起である。

コンピュータソフトウェアの場合、テスト至上主義で品質を担保できるのは、テストにかける工数を回収できるだけの市場規模が確保できる場合、あるいは不具合が致命的な影響を及ぼす場合だけである。それ以外の場合、コンピュータソフトウェアの世界では主に工数制約によってテスト至上主義は既に破綻しており、企業はテスト至上主義に代わる品質確保手段を確立しようと模索している。

実はシミュレーションゲームにおいてもテスト至上主義は既に破綻しているように思う。例えば現在名作として誉れ高いマーク・シモニッチ氏デザインのGMT社製「The U.S. Civil War」を例にとると、私の知る限り発表後数回に渡ってルールの明確化や改定が行われている。シモニッチのような著名なデザイナーであれば、テストプレイヤーの確保に困らないように思うのだが、それでもこの体たらく。いわんや、シモニッチのように著名人ではない場合、テストプレイヤーを確保するだけでも難しい(ボランティア以外でテストプレイヤーを募るのは現時点では困難)。さらに短縮化する開発期間(ヒマな学生なら1日中ゲームデザインに没頭できるが、本業の片手間にゲームデザインを志す我々アマチュアデザイナーにとって時間の確保は何よりも困難な課題である)は、セルフテストの時間すら奪っていく。このような状況下でいくら「テストプレーは品質管理である」と言われても、現実が着いてこない。

実はコンピュータソフトウェアの世界では、テスト至上主義に代わってレビューによる品質確保が主体となってきている。そして先進的な企業では既にテストではなくレビュー主体にシフトすることで高品質なソフトウェアを短期間で生み出している。そのような考え方をシミュレーションゲーム開発にも取り入れることはできないだろうか。

次回は、レビューによるシミュレーションゲームの品質確保について考察してみたい。



[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]

IMPERIUM(インペリウム)第2版
価格:6,600円(税込、送料別) (2023/7/3時点)


イメージ 1

イメージ 2

イメージ 3

イメージ 4

イメージ 5

イメージ 6

イメージ 7

イメージ 8

イメージ 9

先日、九州に行った際、福岡に城なんてあったのかな、と半信半疑で尋ねてみたのがこの城です。
福岡市中央区にあり、近くには福岡市美術館があるとのこと。
福岡ドームが出来る前に平和台球場があった場所です。全体が舞鶴公園として公園化されています。

黒田氏が築いた城とのことで天守閣は現在残っていませんが、石垣はいくつも残っています。結構大規模な築城が成されていたようで、石垣からも往時のスケールが伺えます。

全体を見て歩くのに所要時間は20~30分ぐらいかかりました。

イメージ 1

ソフトウェアプロセス改善手法SaPID入門

安達賢二 日科技連

SaPID(さぴっど)とは、筆者が考案したソフトウェア改善手法である。所謂改善活動のノウハウを体系化したもので、ソフトウェアプロセス改善と銘打ってはいるが、それ以外の改善活動全般にも適用できそうである。
SaPIDでは、現状把握、改善の検討、改善の実行を出来る限り早く回すことに主眼を置いた改善手法である。所謂PDCAと基本的には同じだが、SaPIDでは、各プロセスが必ずしも順番に回す必要はなく、状況に応じて並行作業したり、行きつ戻りつしても良いとしている。一方でSaPIDでは、改善プロセスを早く回すことを特に重視しており、1つの改善活動は3ヶ月以内、さらに改善時にトライアルと呼ばれる縮小版実運用を取り入れ、早い段階で改善のフィードバックを得るように工夫している。間違っているかもしれないが、改善活動の「アジャイル版」といえば当たらずとも遠からずか・・・。
また巻末には改善推進者の心得として「対等な立場でアプローチする」「~させようという下心は持たない」等26ヶ条が記載されており、大いに参考になった。

お奨め度★★★★

↑このページのトップヘ