有限会社プロソフト
家庭用ゲーム(コンシューマ)、ソーシャルゲーム(ネイティブアプリ／サーバー)の開発会社
ゲーム開発者に勉強が必要な理由
文責：nanao
結論から先に書くと「プロジェクトを無事に完了させるために知識が必要だから」です。
ゲームに限らず、何かしら開発に携わる人たちは誰でも「プロジェクトが無事に完了してほしい」という思いを持っているはずと思いますが、実際にはトラブル発生で苦労したという話をよく聞きます。なぜ、プロジェクトにトラブルが発生するのでしょうか？
回答から言うとプロジェクトに「やって見なければわからない事があるから」です。
やって見なければわからない事を行った結果、時間がかかって予定が崩れ、〆切時間に完成までたどり着かない事態になります。（開発経験者は実感として分かりますよね？）
論理的に解説する為、「プロジェクトではない作業」と比較してみます。
新規開発を目的に一度だけ行う作業「プロジェクト」に対して毎回同じ事を繰り返す作業は「ルーチンワーク」といいます。
目的を達成するために必要な行動が全て解っているので、ルーチンワークでは手順通りに行動すると望む結果が返り、プロジェクトと異なりトラブルも発生しにくいです。
（ルーチンワークでのトラブル原因は作業実施者の行動とマニュアル上の指示のズレ。）
もちろん「プロジェクト」は「ルーチンワーク」にはなりません。しかし、やって見なければわからない事を極力減らし、プロジェクトから不明な要素を減らす事がプロジェクトを無事に完了させる事に繋がるのです。
「プロジェクト」「ルーチンワーク」の区別なく、作業を完了させるには作業工程４つと４つの要素、「目標」「状況」「手段」「結果」を必要とします。
【全ての作業を抽象化するとこうなる】
１．『目標』と現在の『状況』を比較し、差を抽出する。
２．差を埋めるための『手段』を決定して、実行する。
３．実行の『結果』を目標と比較する。
４．目標と結果が一致ならば終了。不一致ならば手順１に戻る。
「目標」「手段」「結果」「状況」それぞれに「不明」をつけた上で、経験上、ゲーム開発でありがちな心境に置き換えてみます。
・目的が不明→完成探しの冒険。「仕様書は書いたけど、こっちの方がいいかも？」
・手段が不明→作業手法の模索。「どうやって作るの？本当に作れるの？」
・結果が不明→確認項目の不備。「とりあえず作りました。問題ないでしょうか？」
・状況が不明→作業工程の不備。「みんな、何の作業をしているんだろう？」
上記が「やって見なければわからない事」とされている事であり、行動開始前に予測して解決する事が望まれている物です。
項目ひとつひとつ考えるだけでも大変ですが、熟練者は経験の辞書を使って最適な対応を一発で選んでいきます。だからこそ熟練者は作業効率が良くなるのです。
では、あなたが熟練者でない場合はどうするか？
ある作業の熟練者ではあるが別の作業を初めて行う場合はどうするか？
何かの初心者の時、「なにが解らないのか、わからない」と思った事はないでしょうか？
何も解らないまま「えいやっ」と行動してみても、それはほとんどハズレますよね。
初心者によくある「なにが解らないのか、わからない」の「判断ができない状態」には、原理があります。まず、判断の仕組みを抽象化すると
【判断の抽象化】
１．事象Ａが事象Ａである判断要素を決める
２．事象Ｂについて判断要素を調べる
３．両方の判断要素を比較して、同じか否かを決定する。
具体例でいうと
【リンゴの絵の判断の場合】
１．理想の絵Ａから「リンゴの絵」である要素「色＝赤い」「形＝丸い」を入手
２．絵Ｂから「Ｂの色＝黄色」「Ｂの形＝丸い」を入手
３．判断結果。「絵Ｂは色が異なるのでリンゴに見えない」
人工知能開発の本に書いてありそうな内容ですが、判断を行うには以下の要素がないとできないという事です。
・「事象Ａ」と「事象Ｂ」、２つの事象がある事
・「事象Ａ」が「理想の事象」である条件が解っている事
ここで、「事象Ａ」と「事象Ｂ」は「理想」と「現実」の２つであるとして「理想が理想とされる条件」という知識を初心者は持っていないために判断要素の比較ができず、「なにが解らないのか、わからない」という事態になる訳です。
必要なのは知識です。
ここで「あなたが熟練者でない場合はどうするか？」の回答として、「『他者の知識の吸収＝勉強』をする」という対策が出てきます。
まず「理想形の条件は何か」を把握しない事には比較ができないので、知識を輸入して、それを判断要素として結果を検討するのです。
理想と現実の比較を行う条件を持つと「やって見なければわからない事」の中に「推測だが、こうしたらできるのではないか」という手法が見えてきます。
結果、「判断できることに変える」事によってプロジェクトの問題は消えてゆきます。
