今趣味で作ってるゲームを実例として、ゲーム開発での仕様変更にはどんなものがあるのかを考えてみたい。
昨日作っていてどんな仕様変更があったかというと「ＢＧＭを今までは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・デービス, 成功する要求仕様 失敗する要求仕様
昨日作っていてどんな仕様変更があったかというと「ＢＧＭを今までは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・デービス, 成功する要求仕様 失敗する要求仕様
PR
トラックバック
トラックバックURL: