昨日作っていてどんな仕様変更があったかというと「ＢＧＭを今まではmidiファイルで鳴らしてたんだけど、mp3のファイルでも鳴らせるように」という変更。
この事例を使って、次の疑問を考えてきたい。
疑問1：この仕様変更は、どこ（誰）から来たのか？
疑問2：この仕様変更は、なぜ起こったのか？
さて、ゲームより一般的なソフトウェアの場合、仕様の変更は次のような理由で起こる[1]。
（1）ステークホルダが要求文書をレビューする。何か新しいものへの欲求が引き出される。
（2）ステークホルダがシステムの使い方を覚える。何か新しいものへの欲求が引き出される。
（3）ステークホルダがプロトタイプを触ってみる。何か新しいものへの欲求が引き出される。
（4）システムが使われる状況が変わる。たとえば、ユーザ数が増えるなど。
（5）顧客は、現在のシステムのバージョンを使っていると、システムにさせたいことをさらに思いつく。
また、変更がどこからやってくるのかというと、次のようなところからくるらしい[1]。
（1）マーケティング
（2）アナリスト
（3）セールス
(4)顧客やユーザ
(5)開発者
このリストは、単に役割を列挙しただけ（詳細は[1]を参照）だけど、とりあえず色々なところから変更が出てくるということが分かる。
分析：
さて、最初の疑問に戻って、僕が昨日直面した仕様変更は、どこからきて、そしてなぜ起こったのかを考えたい。
まず「どこから」という疑問に答えるには、ゲーム開発はどんな役割の人で行われてるのかを特定する必要がある。この記事では、単純に、ゲーム開発は二つの役割を持った人たちで行われるとする。
役割1：ゲームデザイナ
役割2：ゲームプログラマ
また、ゲームは、3つ目の役割を持った人が関わるとする。
役割3：ゲームユーザ（プレイヤー）
ゲームデザイナは、今まで書いてきた記事に従って、次のようなことを決める人だとする。
（１）ゲームのルール
（２）ユーザインタフェース
（３）ゲームバランス。敵のパラメータ設定など。
（4）品質要求。たとえば、ロード時間に対する要求。
ゲームデザイナは、ゲームをソフトウェアの一種だと考えるなら、要求を決める人に対応する。
ゲームプログラマは、ゲームデザイナが決めたことを実現する人だとする。ゲームをソフトウェアの一種だと考えるなら、ソフトウェアの設計やプログラミングなどをする人に対応する。
ゲームユーザは、ゲームをプレイする役割を持つ人だとする。
さて、この枠組みにしたがって考えてみると、僕が昨日直面した仕様変更である「ＢＧＭを今まではmidiファイルで鳴らしてたんだけど、mp3のファイルでも鳴らせるように」は、どの役割の人からきたんだろうか。なお、僕は、「ユーザ」「ゲームデザイナ」「ゲームプログラマ」の3つの役割を持った人である。
一つずつ考えてみよう。
ユーザの場合：ゲームをプレイするユーザは「BGMがmidiで再生されているのか、それとも、mp3で再生されているのかを気にするだろうか？」たとえば、今までゲームをプレイしてきたけど、そんな要望を思ったことがあるだろうか？ 多くの人は、そんな要望を思ったことはないと思う。したがって、この仕様変更は、ユーザから発生したのではないといえる。
しかし、この種の要望（要求）がユーザから発生する可能性はある。たとえば、ゲームのＢＧＭをユーザが自由に選択できるような機能をゲームが備えているとしよう。とすると、どんなフォーマットのファイルを再生できるのかは、ユーザにとっての関心となる。
今回の仕様変更の場合は、そんな機能はとりあえずないとして話を進める。
ゲームデザイナの場合：ゲームデザイナからこの仕様変更が発生するだろうか。つまり、この変更は、
（１）ゲームのルールに関わるか？ Ｎｏ。midiで再生しようがmp3で再生しようがユーザがゲームをどう遊ぶのかには影響しない。
（２）ユーザインタフェースに関わるか？ あきらかにＮｏ。
（３）ゲームバランスに関わるか？ Ｎｏ。
（4）品質要求に関わるか？ Ｎｏ。
したがって、ゲームデザイナから発生したのではないといえる。
ただし、先ほどと同様に、ゲームのＢＧＭをユーザが自由に選択できるような機能をゲームが備えているとすると、話は変わってくる。ゲームデザイナが、ユーザの役割の立場から、midiでもmp3でも再生できるようにと仕様変更をしてくる可能性がある。
とにかく、今回の仕様変更の場合は、そんな機能はとりあえずないとして話を進める。
ゲームプログラマの場合：残りの発生元は、ここだけになる。話の流れとしてはこんな感じに再現できる。
ゲームデザイナとしての僕「今のＢＧＭの曲じゃなくて、この曲をＢＧＭで鳴らすように変更してくれる？」
ゲームプログラマとしての僕「あれ、この曲って、midiバージョンがないのか。mp3からmidiって変換できるのかな？ え、難しいんだ。じゃあ、ソフトウェア側でmp3を再生できるように機能を変更しなきゃいけないな」
ということから、今回の場合は、この要求変更はゲームプログラマが発生元といえる。
まとめ：
今回取り上げた仕様変更は、「ＢＧＭを今まではmidiファイルで鳴らしてたんだけど、mp3のファイルでも鳴らせるように」というもの。
この仕様変更に対し、次のような疑問を投げかけてみた。
疑問1：この仕様変更は、どこ（誰）から来たのか？
疑問2：この仕様変更は、なぜ起こったのか？
疑問1への回答。ゲームデザインの仕様変更を通して、間接的に発生した。「ＢＧＭ曲の変更」というゲームデザイン上の仕様変更の影響として、「midiだけでなくmp3を再生できる機能への変更」というソフトウェアの機能仕様上の変更として発生した。
疑問2への回答。「ＢＧＭ曲の変更」というゲームデザイン上の仕様変更に対し、ソフトウェアの機能としてうまく対応できていなかったため。
考察：
以上のことを踏まえて考察。
まず、ゲームデザイン次第では、今回のような仕様変更が、ゲームデザイン上の仕様変更でありうる。例で挙げたように、ゲームのＢＧＭをユーザが自由に選択できるような機能がゲームデザイン上の仕様としてあるとすると、その機能に付随する変更として「midiでもmp3でも曲を再生できるように」という変更がゲームデザイン上の仕様変更として発生する。
そもそも、この機能仕様をゲームデザイン上のものとして考ええてよいのかを考え直す必要がある。というのも、この機能は「ゲームのルール」でも「ユーザインタフェース」でも「ゲームのバランス」でも「品質」に関わるものではないと思うから。むしろ、この機能は、「ユーザのゲームの楽しみ方」に関わる機能だと思う。とすると、ゲームデザイナは、「ユーザのゲームの楽しみ方」に関わる決定をする人だとして広く捉えるべきと思う。つまり、
（１）ゲームのルール
（２）ゲームの楽しみ方
（３）ユーザインタフェース
（４）ゲームバランス。敵のパラメータ設定など。
（５）品質要求。たとえば、ロード時間に対する要求。
という感じ。ただし、この5項目の間の関係はまだちゃんと分析できてないので今後も行っていく必要がある。
その他思ったこと：
（1）ゲームへのユーザの要望が、ゲームに直接すぐに反映されるわけではない。
参考：
[1] アラン・M・デービス, 成功する要求仕様 失敗する要求仕様
2008.01.28： 最新のレビュー情報にあわせて、データを更新しました。29件のレビュー件数に28件追加して合計57件のレビューに対して分析を行うように更新しました。最終的な分析結果には影響ありません。
はじめに：
前回の記事で、ルーチンゲームデザインのためのチェックリストの作成という話をしました。
ルーチンゲームデザインとは、過去の経験の積み重ねなどからうまくいくことが分かっている項目に対して、適切な決定を行うことです。たとえば、ゲーム中のムービーに対する項目として「スキップできる」と「スキップできない」のどちらがユーザが望んでいるゲームでしょうか？多くのユーザは「スキップできる」ことを望んでいます。したがって、ゲームデザイナは、ムービーに対する項目に対して「スキップできる」という決定を行う必要があります。
ゲームをプレイするユーザは、ルーチンゲームデザインが適切に行われていないと不満を持ちます。ルーチンゲームデザインは、クリエイティブではありませんが、適切に行う必要があります。適切に行うために、ルーチンデザインが適切にできているかをチェックできるリストなどがあれば便利です。
前回の記事では、簡単な仮のチェックリストして次のようなものを考えました。
（1）イベントはスキップできますか？
（1.1）ムービーはスキップできますか？
（1.2）戦闘シーンはスキップできますか？
（2）ゲームのテンポは適切ですか？
（2.1）戦闘開始までの時間は十分に短いですか？
（2.2）ユーザの入力をテンポよく受け付けていますか？
（2.3）メニュー画面はすぐに表示されますか？
今回の記事では、二番目のゲームのテンポに関わる部分について、このチェック項目が適切かどうかを確認してみたいと思います。
（2）ゲームのテンポは適切ですか？
（2.1）戦闘開始までの時間は十分に短いですか？
（2.2）ユーザの入力をテンポよく受け付けていますか？
（2.3）メニュー画面はすぐに表示されますか？
ゲームのテンポに関する決定は、ルーチンゲームデザインに関する決定だと考えられます。以前の記事でゲームデザインの原則として書いたように、ユーザにとっては、ゲームのテンポが良すぎて困ることはないと考えられるためです。
確認方法としては、このチェックリストを実際のユーザの感想に適用してみようと思います。
ゲームをプレイしたユーザの感想の収集には、ndsmk2 さんのところのレビューを使いました。対象にしたゲームは、去年の12月25日に発売した「ファイナルファンタジー4」です。調査した時点で、全57件のレビューがありました（三郎さん [2007/12/27掲載] からホイミンさん [2008/01/21掲載]のレビューまで）。
ちなみに僕も実際に購入してプレイ中です。
結果：
全57件中36件、約63％の人が、なんらかの観点からゲームのテンポに不満を持っていました。
テンポの不満点をまとめるとだいたい次のような感じになります（各項目に対する件数は未調査）。
・もっさり感がある。
・メニューの開閉のテンポが悪い。
・戦闘のテンポが悪い。
・・全体への魔法が一人ひとりにエフェクトがかかる
・・魔法が長いので、召喚と同様に魔法にもスキップが欲しい
・・敵のＨＰも多めでやや戦闘が長く感じる。
・キーレスポンスが悪い
・・戦闘時のキーレスポンスが悪い
・・メニュー時のキーレスポンスが悪い
・戦闘のロードが長い
・被ダメージ時の数値表示が遅い
チェックリストの改善：
上記の結果をもとに、チェックリストを改善しました。
（2）ゲームのテンポは適切ですか？ もっさりしていませんか？
（2.1）ユーザの入力をテンポよく受け付けていますか？
（2.2）戦闘のテンポは適切ですか？
（2.2.1）戦闘開始までの時間（ロード）は十分に短いですか？
（2.2.2）全体魔法は、一度に全員にエフェクトがかかっていますか？
（2.2.2）キャラクターのアクションから結果の表示までは十分に短いですか？
（2.3）画面はすぐに表示・非表示されますか？
（2.3.1）メニュー画面はすぐに表示・非表示されますか？
さらなる検証：
今回の調査では、ゲームテンポについてレビューで悪い点として書かれているかを確認しました。
一方で、次のような追加調査をする必要があるかも知れません。
（1）テンポが良いことを良いとして書かれているか。テンポが悪いと感じている人と、テンポは良いと感じている人の割合の調査のために。
（2）テンポが悪いことを良いとして書かれているか。テンポが悪くてゲームを楽しめたと感じている人の割合。「ユーザにとってはゲームのテンポが良すぎて困ることはない」という原則の妥当性の確認のために。
（3）テンポが良いことを悪いとして書かれているか。テンポが良くてゲームを楽しめなかったと感じている人の割合。「ユーザにとってはゲームのテンポが良すぎて困ることはない」という原則の妥当性の確認のために。
その他：
分析したデータが欲しい方は、メール（rozenkranz.game at gmail.com）ください。
以前から、ゲームをデザインするとは、以下のようなことについて決定することだとして考えてきました。
（１）ゲームのルール
（２）ユーザインタフェース
（３）ゲームバランス。敵のパラメータ設定など。
（4）品質要求。たとえば、ロード時間に対する要求。
たとえば、ＲＰＧにおけるゲームデザインでは、戦闘に参加できるプレイヤーキャラクターの最大人数の決定があります。他にも、キャラクターの成長をレベルアップ制にするのかそうでないのか、といった決定があります。このような様々な決定を行うことがゲームデザインであると考えてきました。
さて、以前の記事で、決定には、ルーチン的なものと、クリエイティブ的なものがあると議論しました。
（1）ルーチンゲームデザイン：過去の経験の積み重ねなどからうまくいくことが分かっている項目に対して、適切な決定を行います。たとえば、ゲーム中のムービーに対する項目として「スキップできる」と「スキップできない」のどちらがユーザが望んでいるゲームでしょうか？多くのユーザは「スキップできる」ことを望んでいます。したがって、ゲームデザイナは、ムービーに対する項目に対して、「スキップできる」と「スキップできない」のどちらにするかを迷う必要はなくなります。
（2）クリエイティブゲームデザイン：従来のゲームでは存在しなかったような項目を考え出す決定を行います。
ルーチンゲームデザインは、その名が示すように、クリエイティブさは必要ありません。とはいえ、ユーザが満足できるゲームをデザインするためには、ルーチン的な決定は適切に行う必要があります。ルーチン的なデザインがうまくできてないゲームは、クリエイティブな部分を台無しにしてしまいがちです。しかし、商業のゲームでさえ、このようなルーチン的なゲームデザインが適切に行われていないことがあるのが現状です。そこで、ルーチン的なゲームデザインがうまくできているかを確認するためのチェックリストがあれば便利でないかと思いました。
ＲＰＧとシミュレーション系のゲームに特化しているかもしれませんが、いくつかチェック項目を考えてみました。
（1）イベントはスキップできますか？
（1.1）ムービーはスキップできますか？
（1.2）戦闘シーンはスキップできますか？
（2）ゲームのテンポは適切ですか？
（2.1）戦闘開始までの時間は十分に短いですか？
（2.2）ユーザの入力をテンポよく受け付けていますか？
（2.3）メニュー画面はすぐに表示されますか？
今後は、mk2 やアマゾンなどのレビューサイト、2chのスレなどを参考にチェック項目を増やしていきたいと考えています。
信頼できるチェックリストにするためにあると良いと思うのは、次のことです。
（1）ルーチンデザインに反している具体的なゲームタイトルを挙げること。
（2）ルーチンデザインである理由を書くこと。たとえば、なぜムービーはスキップできるべきなのか。
疑問：ゲームプログラマは、ゲームデザインの知識をどれだけ持っているべきか？ ゲームプログラマがより多くのゲームデザイン知識を持っていれば、ゲームデザイナがより品質の高いゲームデザインを生み出せることにつながるのか？
少～し前の話になるけど 同人ど～らく さん経由で PlatineDispositif さんの「スペース大納言(仮」の体験版をやってみた。
今回の記事では、ゲーム内容に直接関わることではないけど、ゲームデザインの観点から感じたことを書いてみようと思う。特にユーザインタフェース（ＵＩ）のメニューにか関わる部分について。メニューとは、たとえば、ゲーム開始、設定（コンフィグ）、ゲーム終了などのこと。
ＵＩは、ゲームの面白さに直接関わらないのかもしれないけど、ここでは、ゲームデザインの一部だと考えます。ゲームデザインとは、次のようなことを決めることだとします。
（１）ゲームのルール
（２）ユーザインタフェース
（３）ゲームバランス
（4）品質要求。たとえば、ロード時間に対する要求。
ゲームデザイナとは、ゲームをデザインする役割を持った人のことだとします。
ゲームデザインだけでは、ソフトウェアとしてのゲームは作れないため、ゲームデザインを実際に実現する役割を持つ人が必要です。ここではその人を、ゲームプログラマ、もしくはソフトウェア設計者と呼びます。ゲームデザインは、言い方を変えれば、いわゆる要求仕様に対応すると考えられます。
役割としたのは、一人の人がゲームデザイナかつゲームプログラマである場合があるためです。
なお、ゲームデザイナは、ゲームプログラミングのことを知らなくてもいい、というわけでもないです。たとえば、ロード時間は、1ミリ秒以下でなければならない、といった要求は実現不可能な場合があります。
一般的に、工学におけるデザイン、つまり人工物を創るという行為は、探索的であり、試行錯誤を伴います[1]。ここでは、ゲームデザインもそのような行為を伴うとします。また、同じことですが、ゲームデザインを要求仕様として捉えるなら、仕様が変化することは避けられません[2]。
さて、ゲームデザイン（要求仕様）を変更するきっかけとなるとは、どのような場合でしょうか？ 一つは、他の人のゲームデザインを見たときです。以下では、具体的な例で説明したいと思います。
さきほど、ゲームデザインとしてユーザインタフェースが含まれるとしました。とすると、自分がゲームデザイナであり、ゲームを作っているとすると、他人が作ったゲームを見たりプレイすることが、自分の作っているゲームのユーザインタフェースに影響を与える場合があります。これが、PlatineDispositif さんの「スペース大納言(仮」の体験版をやっていて気づいたことです。ユーザインタフェース、特にメニュー項目の選択のグラフィックを見て、こんな選択の見せ方もありだな、と思いました。
一般的に、あるゲームデザイナが、他人のゲームデザインのある部分を見たときの反応としては、以下が考えられます。
（1）破棄。
（2）自分のゲームデザイン知識への反映。反映された知識は、現在もしくは後のゲームデザイン時に使われる。
（3）自分のゲームデザイン知識への反映を通じて、作成中の自分のゲームデザインへの反映。そのまま反映させれば、悪く言えば、ぱくり。
ここでは、3のケースについて考えていきます。ゲームデザイナとしては、自分の部分的なゲームデザインＡを、他人の部分的なゲームデザインＢで置き換えるように変更すると決めるのは容易です。また、ゲームデザインは試行錯誤を伴うとするなら、後に、ＢからＣ、もしかすると、ＣからＡというような変更を伴うかも知れまへん。ここでの問題は、一般的に、そのような変更にはソフトウェア設計やプログラミング上のコストを伴うことです。
ユーザインタフェースは、よく変更が伴うとして知られています。そのため、ソフトウェア設計では、ユーザインタフェースに関わる部分とその他の部分を分離し、ユーザインタフェースの変更が他の部分の変更をなるべく伴わないような工夫が行われれます。いわゆる、Model-View-Controller (MVC) アーキテクチャの適用です[3]。
問題は、知識と経験がなければ、ゲームのソフトウェア設計者やゲームプログラマは、ゲームデザイン上のどの部分が変わりやすく（可変の部分）、変わりにくい（不変の部分）かといったことが分からないということです。たとえば、ＲＰＧにおける戦闘への最大参加人数などの決定は変わりにくいと思われますが、敵のパラメータ設定などは変わりやすい部分であると思われます。とすると、変わりにくい部分に関しては、ソフトウェア設計上やゲームプログラミング上の工夫は必要なくなります。
しかし、可変な部分、不変な部分に関する知識、もしくはゲームプログラミングの経験がなくては、ソフトウェア設計やプログラミング上の工夫も難しいのではないかと思われます。
ここで、やっと、最初に書いた疑問が出てきます。
疑問：ゲームプログラマは、ゲームデザインの知識をどれだけ持っているべきか？ ゲームプログラマがより多くのゲームデザイン知識を持っていれば、ゲームデザイナがより品質の高いゲームデザインを生み出せることにつながるのか？
もし、ゲームデザイナーがより素早くゲームデザインを変更でき、多くのゲームデザインを探索できるとするなら、より品質の高いゲームデザインに到達できる可能性も増えると考えられます。しかし、探索のしやすさは、ソフトウェア設計上の柔軟性に依存します。ソフトウェア設計を柔軟にするには、ゲームデザインのどの部分が変わりやすいのか、変わりにくいのか、といった知識と経験が重要な役割を持つと考えられます。
ただし、ソフトウェア設計は、ゲームデザインの変化に耐えられるようにできる限りあらかじめ柔軟でなければならない、というわけではありません。変化を予測して設計を行うことは、設計を複雑にします。必要以上に複雑な設計は、保守や後の変化への対応を難しくします。
プログラミングは、設計行為の一部と考えられますが[4]、設計は思考的にも行えます[5]。思考的に行うとしても、ゲームデザインが変化しやすい部分・変化しにくい部分に関する知識が必要であると考えられます。
ゲームデザインに関する知識がゲームプログラマにとって重要であるとするなら、どうやってその知識を表現し、文章化し、伝えるのが効率的・効果的であるのかを考える必要があります。
最後に、次の本は、今回の記事に関連するかな？ と思う本です。ちゃんと読んだ本ではないので関連しないかもしれませんが列挙しておきます。
・マーチン ファウラー,アナリシスパターン―再利用可能なオブジェクトモデル
・Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software
・マイケル・ジャクソン, プロブレムフレーム ソフトウェア開発問題の分析と構造化,
・Staffan Bjork, Jussi Holopainen, Patterns In Game Design
参考：
[1] Nigel Cross, Engineering Design Methods: Strategies for Product Design
[2] アラン・M・デービス, 成功する要求仕様 失敗する要求仕様
[3] マーチン・ファウラー, エンタープライズ アプリケーションアーキテクチャパターン
[4] P. Kruchten, Casting Software Design in the Function-Behavior-Structure Framework, IEEE Software, Vol. 22, No. 2, Mar./Apr., 2005, pp.52-58. ここ からＤＬできるようです。
[5] Robert L. Glass, Software Conflict 2.0: The Art And Science of Software Engineering