◆ 暗黙知に呑まれるな
以上、ゲームデザインのディレクター的な仕事を紹介しました。
「プロジェクトを指揮する」という言い方をすると、チーム全体ににらみをきかす強面のボスのような姿を連想しがちです。逆に「スケジュールを管理する」では、ただの雑用係のように思えるでしょう。現実のディレクターはその両面を併せ持っているわけですが、ここまでの話で、その奥深さがお分かりいただけたのではないでしょうか。また、一見ただの経験でやっているように見えることが、案外それを支える技法の上に成り立っていることに、驚かれたかもしれません。プロジェクトマネージメント技術は、経営大学院（MBAスクール）でも主要科目のひとつに位置づけられています。とりあげたWBSも、実は精緻な理論に裏付けされた知識体系の一部として教えられているものです。
ただ、ここで展開したのは実のところ「理論」で、実務的にはこうした体系をマスターしていなければならないというものではありません。というのも、会社のプロジェクトは、ゼロから起こすものではなく、たいていの場合、「前のプロジェクト」があるからです。例え新人であっても、以前に行われたプロジェクトを元に組み立てていけば、一応のスケジューリングはできるのです。
新入りばかりを集めて新規プロジェクトを起こすような会社はなく、通常はメンバーの大半がそれ以前のプロジェクト経験をいくつか共有しているものです。そして手順というのも、チーム（場合によっては会社）全体として、ある程度決まっているのが常です。このような成文化されていない知識を「暗黙知」といい、マネージメントでは以前から注目されていました。実際の現場では、MBAスクールで教えられているような知識・技術などはほとんど求められず、むしろ場の空気から暗黙知を学び取れる柔軟さの方が、たいていは優先されることでしょう。
さらに言えば、ガントチャートすらも書かずに済む場合があります。いつも同じメンバーで似た傾向のゲームを作っているようなチームだと、作業の手順というのも、事実上定型化しているものなのです。いつ頃誰が何をしたらいいのか、各自がだいたいわかっているため、特に打ち合わせなどしなくても、どんどん進んでいくということです。
ただ、それが手放しで喜ばしいことなのかは、少し考えてみるとわかると思います。
こういうチームは、人材的に固着してしまいがちです。他の組織で経験を積んだ人間を受け入れられないからです。また、こういうチームに配属された新人は、よそのルールがわからず、将来苦労することになりますね。そして、時代が変わり、求められるゲームや投じられる技術が変化したときには、チームごと取り残されてしまうでしょう。
暗黙知という現象がマネージメントの世界で注目されていたのも、この二面性を持つからです。便利で役に立つ反面、発想の固定化をもたらしてしまうのです。
ゲームデザイナーであれば、プロジェクトマネージメント技術の基本は理解しているべきです。そして、現場の仕事に入っていったとき、無理に導入しようとするのではなく、流れの中で導入が役に立ちそうな場面を見つけ、順次組み込んでいくことが、いちばん現実的だと思います。もしガントチャートすら作らずにプロジェクトが進んでいたとしたら、かなり危険なことだといえるでしょう。
＊ ＊ ＊ ＊ ＊ ＊ ＊ ＊ ＊ ＊ ＊ ＊
『nkc_yamadas』のアカウントで、twitterを始めています。
今のところ、主に授業のフォローや担任としての連絡などに使っていますが、今後、この連載のアフターケアにも活用していきたいと思っていますので、よろしかったら、フォローしてやってください。
質問なども、リツイートでどうぞ。
◆ ガントチャートで可視化せよ
さて、計画を立てた場合、それをどのように使うのかが、重要になります。もし担当者の頭の中にしかないのでは、非常に使い勝手が悪いということになります。基本的に、誰からも見えるようにする＝可視化する必要があるでしょう。
そこで作られるものがあります。ガントチャート（線表）です。
ガントチャートに使う道具は、縦横の表です。縦軸（行）に個々の作業を置き、横軸に日時（通常は週単位）をとった上で、作業を行う期間を横棒で示していきます。
図は、ガントチャートの一例です。手元に公開可能な適切なものがなかったので、オンライン百科事典「ウィキペディア」からパブリックドメインとして公開されている画像を持ってきました。
図を見ればわかるように、ガントチャートはWBSと直結しています。縦軸に書き込む作業は、WBSでリストアップしたものなのです。また、WBSと同時に組み立てておいた手順に沿うように配置することは、言うまでもありません。図の場合、"WBS1.1"の作業と"1.2"の作業は同時にスタートしていますが、"1.3"の作業は"1.2"が終わってから。また、"1.3"と"1.4"、また別項目の"2.3"とは、終わりがそろえられています。
ガントチャートの目的は、プロジェクトの可視化にあります。＊４
これを壁に貼っておけば、どういう段取りでこれからの仕事が進むのか、また誰がどんな作業をすればいいのかわかります。そして、期日通りに進んでいるか......遅れがある場合は、どこがどのように問題になっているのか、即座に把握することができます。つまり、「計画」フェイズだけでなく、「実行」フェイズのリアルタイムな可視化であり、同時に「コントロール」フェイズの強力なツールにもなるわけです。
プロジェクトの可視化には、他にもネットワーク図というものがあります。こちらは、作業手順を可視化したものです。WBSではっきりさせたジョブは、前後関係を正確に把握しておかなければならない場合もあります。上の図における各アクティビティの関係は、このままでも読み解けば理解できますが、ネットワーク図として別途まとめていた方が、より親切でしょう。
私見としては、プロジェクト管理というのは、実際にはこのガントチャートにかかっているように思えます。「適切なガントチャート」というのは、プロジェクトマネージメントの手段のように見えますが、実際にはそれを目的にして取り組んでいくと、ちょうどいいのではないかと思うのです。
◆ 実装と５つのフェイズ
立ち上げ段階で行うことは、目標の明確な設定です。そのプロジェクトが成立するためには、目標において次の条件を満たす明確性が必要です。(1)具体性、(2)現実性、(3)期限の存在、(4)測定可能、(5)合意が取れている、(6)責任が明確、の６つです。
例えば漠然と「斬新な操作性のゲーム」としたとしても、これでは目標は立てられません。また、「プレイヤーの感情を読み取ってステージ展開に反応させる」といった仕様は、表情認識が画期的に向上した現在では技術的には可能かも知れませんが、ゲームソフトに許される工数を考えると、たぶん現実性が乏しいと思います。また、誰が何をしなければいけないのか不明確なままでは、肝心な部分が残ったままで進んでしまったり、いちいち判断でつかえて進まなくなったりといったことも起こります。
特に見落とされがちなのが(4)でしょう。別の言い方をすれば、数値で表現可能なことを目標として設定する、ということです。そもそも日本の文化ではそうした考えをとることが稀で、目標と願望の区別すらあいまいなまま、景気のいいことを掲げる傾向があります。現実的な目標を設定した結果、上司から「そんな心構えではだめだ、無理を承知で挑戦しろ」などと叱責されたりする話も、よく聞きますね。
しかし、数値化できない目標というのは、本来存在そのものがナンセンスなのです。「できる限りがんばる」などといっていたのでは、達成率が全く計算できません。つまり納期管理や品質管理などの基準が立たないと言うことで、これはプロジェクト管理では致命的です。たとえ数値を使っても、景気づけで過大な数字を書いたのでは、子供が「ひゃくおくまんえん」とかいってるのと大差ありません。
もちろん、ゲームの価値の中には、「面白さ」とか「魅力」といった、数値化が難しそうなものがたくさんあります。しかし、そういうものが存在してるということは、一切の努力を放棄する理由にはなりません。私たちがビジネスとしてそれを行っている以上、これらは必要なことなのです。
目標が定まれば、次は計画です。これもまた、理性的な営みでなければなりません。
ここで行うことは、作業の詳細なリストアップと、その段取りの組み立てです。
リストアップは、階層的に行うことが効率的です。まず、大きな作業単位で並べます。次に、その中に含まれる一段階詳細な作業を並べていきます。そして、それをさらに細かな単位に落としていきます。こうして、階層的な構造で、作業のリストを作るのです。最終的には、具体的な各作業について、必要な人数および期間が、達成目標とともにまとめられることになります。プロジェクトマネージメント技術では、これを「WBS」（ワーク・ブレイクダウン・ストラクチャ）と呼びます。
こうしてできあがったWBSですが、各項目は一直線に並んでいなければならないものとは限りません。いくつかの作業は同時進行でできるはずですし、また、工程上後の方にあっても、先行して片付けておくことが可能なものもあるでしょう。こうした点を意識して、手順を組み立てます。この時、可能であれば担当者も併記しておいた方がいいでしょう。なお、不明な部分があった場合も、前後の作業はわかるはずなので、暫定的に項目化します。
以上をわかりやすく言えば、「何をするのか」を「誰が」「いつ」とともにはっきりさせておくということです。
こうして計画ができあがれば、次は実行です。ただ、一度動き出せば後は放っておいても大丈夫という訳にはいきません。進行が遅れたり、担当した仕事にばらつきが出たりで、あれこれ手当しなければならないものです。そもそも、スタート時点で全ての見通しが正確に立てられるというのは、プロジェクトの規模がよほど小さいか、あるいは完全な定型業務など、そもそもプロジェクトと呼ぶのに値しない仕事であるかのどちらかでしょう。計画は、実行段階で補われることが、むしろ当然なのです。
また、途中で予期せぬ事態が発生するということもあります。さらに、仕様や納期の変更など、予定そのものを手直ししていかなければならないこともあります。そして、終了した後もそのままプロジェクトを解散して終わりというのではなく、一連の経験を次に生かすためのまとめかたがひつようです。「コントロール」「終結」の各フェイズも、現実の仕事の上では重要になってくるのです。
◆ 要求仕様と設計
企画が通れば、いよいよ仕様の段階です。そしてこれ以降が、「ディレクター的な仕事」では真価の問われるところです。
企画段階が終わったところで、実際のゲーム開発の作業量ではとても半分などといえるものではなく、せいぜい最初の５～10％に過ぎません。上層部に認めてもらったゲームのプランがきちんと現実の製品になって登場できるかどうかは、ここから先のプロセスにかかっているのです。
仕様というのは、簡単にいえば「ソフトの設計図」です。どのようなものを作るのかを、詳細＆具体的に記述していくものです。なかなか実感がつかめないと思いますが、ここは一歩ずつ考えてみてください。
まず、完成像＝動いているゲームソフトをイメージしてみましょう。自分自身がプレイヤーとしてそのソフトに取り組んでいるところを想像するのです。
このとき、イメージの中心には、外観・制御・振る舞いの３要素があるはずです。
外観は、画面の見え方です。どこにどのような要素があり、ユーザーにどんなインフォメーションを与えるのか、さらにどう遷移していくのかというということです。
制御は、キーボードやマウスなど。どう動かすことで何が起きるのか、メニューがどうなっていてどう働くのかということです。
振る舞いは、プログラムの主な機能となります。ユーザーのアクションに対してどう応答するのかということです。
この３つの視点から、作ろうとしているゲームをしっかりイメージし、人に説明できるようにはっきりさせていきましょう。
さらに継続してプレイしている状態もイメージしてください。おもしろいゲームだと、プレイヤーは食事も睡眠もそっちのけで集中して取り組んだりするわけですが、そこでは何を観て何を感じているのでしょうか。突き詰めて考えれば、マップやステージの配置ということにもなりますし、マイキャラ（あるいはプレイヤー）がどう成長していくか＆どう成長させていくかのプランも含んだものになるでしょう。
こうして出てきた全体を、ソフトウェアとしてどういう形になるのかという視点でまとめます。その結果できあがる文書を、仕様書と呼びます。
仕様書では特定の書式を考える必要はなく、十分な内容がわかりやすく書かれていればOKです。逆に言えば、内容が不十分だったりわかりにくかったりしたら、どんなに立派な体裁でも不合格です。文章だけで書こうとしても、たいていは伝わりません。図や絵、数字・数式なども活用していくことになります。そして、相当な分量になってしまうため、全体の構成も使いやすいように工夫していく必要があります。
こうしてまとまった仕様は、正しくは「要求仕様」といいます。企画屋からプログラマに対して行う、要求（＝こういうソフトを作って欲しい）だからです。プロジェクト全体としては、その次に「どのような技術方法で実装するのか」という問題があり、この部分を「設計」といいます。また、この結果作られた文書を「実装仕様書」と言う場合があります。
ただ、ここは既にエンジニアたちの聖域です。メインプログラマが誇りと責任を持って取り組むべき課題で、ゲームデザイナーがちょっかいをかけていい場所ではありません。
要求仕様と設計の関係は、一応前者から後者へという流れになります。
ただ、実際には、逆転することもあります。要求が、技術的にできなかったり、あるいはもっと合理的な他のやり方で目的を達成できたり、あるいは技術的に可能なことがあってそれを組み込むことで要求にはなかったおもしろさが出せそうな場合など、プログラマの側からあれこれとボールが帰ってくることがあるのです。
そして、ゲームにおける仕様段階は物語性の部分や美術面なども含むため、グラフィッカーやシナリオライターなどとも、同じようなボールのやりとりをすることがあります。
そのため、仕様の決定は、適宜フィードバックループを描きながら、具体化していくことになります。
◆ ゲーム開発の４段階
では、実際にどのような仕事をしていくのでしょうか。これは、仕事の手順に沿って考えてみましょう。
創作は、特定の手順を踏まなければできないというものではありませんが、個人の手作り的な作業でない限り、段階的な手順が必要です。ゲームの場合、大きな流れとして、「構想」→「企画」→「仕様」→「実装」という４段階となります。＊２
構想は、ゲームや商品性のあれこれを考えていく作業です。どんなゲームがおもしろいのか（＋どういう人に、どのように）、いろいろと考えていくのです。日常の観察からおもしろさを見つけ出そうとする場合もありますし、今人気のあるものを分析していくこともあります。一方、技術や予算などの制約要因は、この段階では深く考えません。意識しすぎると発想が萎縮してしまうためです。
企画は、もう一歩実際の商品を意識して具体的なゲームの形を考えていく作業です。単にソフトとしてどういうものにするのかだけではなく、工数、予算、市場なども含めて、どのような商品にするのかを考えます。
仕様は、実際にどういうソフトとして作るのかを、詳細な点まで決めていく作業です。ソフトウェアとしての仕組みを決めていく要素も含まれますし、パラメータの種類や相互の関係といったゲームシステムの部分もあります。世界観やキャラクターの設定など、文芸・美術領域の作業も含むことになります。
そして実装は、実際にコードを書いたりデータを作ったりしてソフトウェアとして現実化していく部分を指す言葉です。
段階的な開発は、「進んだら、振り返らない」という意味でもあります。小説や漫画など個人制作の作品でもこういう意識付けは必要でしょう。それがないと、いつまでもあらすじだの設定だのをいじっているだけで肝心の作品を作らない、"永久志望者"になってしまいます。ただ、会社による開発の場合は、単に意識付けの問題ではありません。段階が進むことで、プロジェクトはより大規模化していきます。人や物が投入され、お金を使うようになっていくのです。後戻りしてしまうと、投じた資金が無駄になってしまいますね。そこでボスとしては、段階を進めてもいいものか判断をしなければなりません。これをゲームデザイナーの側からみれば、各段階でアウトプットを出し、そこで判断をしてもらって次へ進むということになるのです。
構想の終わった段階で作るのが、提案書です。どんなゲームにするのか、どういう面白さを狙っていくのかということを、解りやすくまとめたものです。社内プロジェクトでは、直属の上司に見せることになります。そしてこれが一応の評価をうけた場合、本格的な企画を進めていくことが許されます。
企画段階の目的は、それを通じてプロジェクト自体の許可を得ることにあります。会社にとっても、ここから先へ進めるかどうかは大きな経営上の決断となります。少なくとも、稼げる（最悪、赤字を出さない）という確信が必要なのです。そこで、ゲームデザイナーとしては、単にゲームの形を考えるだけではなく、これがどういう根拠に基づいてどの程度売れるのかといったことも含めて企画を詰めていく必要があります。そして企画段階で最終的に作る文書が、企画書です。ただ、作って提出すれば終わりということはなく、たいていはプレゼンテーションを伴います。つまり、決定権のある人に対して、直接訴えかけるわけです。
そして、ここでOKが出た場合、プロジェクトには予算が付き、スタッフも集められ、実際に動き出すことになります。＊３
◆ 身近な上級職種
さて、前回のプロデューサーに続き、今回はディレクターにスポットを当ててみます。
こちらも多少はあいまいな響きを持つとはいえ、プロデューサーほどではないでしょう。テレビ番組や映画などで、おなじみの職種だからです。また、クリエイター＆志望者にとっての身近さという点でも、大きく違っています。プロデューサーという仕事は、職層的にかなり上の方にあり、立ち位置の面でも、開発現場とは離れた仕事です。しかしディレクターはそうではありません。業務経験が浅い社員でも担当する可能性がありますし、立場は違えども開発チームの一員で、クリエイターから見れば、基本的に同等の存在となるのです。
図は、ゲーム開発の職種を、作業の流れという視点からまとめたものです。
直接作る立場ではないという点から、クリエイターからは除外されています。しかし、開発チームに属して直接プロジェクトにあたっているもので、現場の人間です。図では少し離れたところに描いてありますが、パブリシティやマーチャンダイジングにあたるスタッフ（＝プロデューサーの部下たち）とは、明確に区別されていることがわかると思います。
そもそもゲームデザイナーにとっては、「仕事の一面」でもあります。もともと企画の仕事には、ゲームを構想し提案していくことだけでなく、プロジェクトを動かしてソフトを現実化していくという側面もあります。ディレクターは、（上の図が前提にしているように）独立した職種となっている場合もありますが、企画職が持つ後者の役割に対する呼び方と言いうる場合もあるのです。＊１
第７回 ディレクター的なゲームデザイン
NASAは90年代に短期間「速い、安い、うまい」というスローガンを導いた。この後、プロジェクトが連続して失敗し、このスローガンは放棄された。......（略）......それは「ぼくは飛べる」とか「私は岩を金にできる」と同様のたわ言だ。正しい言い方はこうなる：「速い、安い、うまい。３つから２つ選べ」
ルディ・ラッカー著 中本浩監訳
「ソフトウェア工学とコンピュータゲーム」（2004年、ボーンデジタル）より
【注釈】
＊１ ： 『交響詩ヤマト』
例によって記憶にゆだねての引用なので、このタイトルおよび続くキャッチコピーも含めて、再現率はかなり低いです。「まあこんなことが書いてあったんだ」程度に理解しておいてください。
＊２ ： 外部の投資家から調達する
この投資家が集まって権利主体となるために作られるのが、近年よく見る「製作委員会」です。
映画の世界では、著作権の有無で「製作」と「制作」を分けます。著作権法では、映画に関しては、実際に作った人（監督など）ではなく、費用を負担した人（実際には会社）が著作権者となるように決められています。前者が「制作」、後者が「製作」です。例えば『千と千尋の神隠し』を作ったのは制作会社であるスタジオジブリですが、映画そのものの著作権は「『千と千尋の神隠し』製作委員会」（日本テレビ、徳間書店、三菱商事、電通によって構成）が保有しているのです。
日常語感覚では、工場で"製品"を作るのが「製作」で、デザインスタジオで"作品"を作るのが「制作」なんてイメージがあります。作品性を強調したいゲームソフトのような商品では、あえて「製作」の語を避ける傾向があるのですが、局面によっては異なった意味合いを持ってくるので注意してください。
＊３ ：４つのP
実はこの概念は、「マーケティング」テーマの中で、よく語られるものです。売り手の取り得る手段をこの４側面に分けたもので、それらの具体的な組み合わせを「マーケティングミックス」と呼びます。
企業にはもっぱらマーケティングを担当する人＝マーケッターという人もいます。プロデューサーとマーケッターの違いは、「作る」要素の有無でしょう。マーケッターは、分析をし提案をしますが、商品を開発・製作する訳ではありません。商品化プロセスでは、上流か下流のどちらかに位置していて、最初から最後まで一貫して取り組むようなことはありません。そこへいくとプロデューサーは、個別のプロジェクトに対して責任を持ち、本文中の図に示しているようなプロセスに最初から最後まで関わっていくことになります。
なお、「プレイス」（place）は、辞書的には「場所」となりますが、この文脈では流通ないし販売の意味を持ちます。なんでわざわざこんな単語を持ってきたのかといえば、アメリカ人も、彼らなりに語呂合わせが好きだということでしょう。
＊４ ：内容は業種によってずいぶん違って......
マーチャンダイジングは多義的な言葉で、業種によってはここで説明したのとは全く異なる意味で使われることもあるので、注意が必要です。例えば流通業界では、仕入れから販売にいたる業務のフローを意味しますし、版権ビジネスでは権利の取得行為をそう呼ぶそうです。merchandiseという単語は、辞書的には「商品」を意味しているため、商品に対して行う何かであれば、なんでもその名で呼べてしまうのです。
なお、言葉として少々長いので、「MD」と呼ばれることが多いです。また、日本語化して「商品化」という言葉を使う場合もあります。
＊５ ：役割の違いというものがあり......
図では１つしか書いていませんが、プロデューサーは通常何本ものプロジェクトを掛け持ちします。あるプロジェクトが佳境に入っているとき、別の新規プロジェクトを立ち上げたりしているのです。一方企画職は、通常は開発チームの中で仕事をしていくため、同時期には一つだけです。実はこれが両者の最大の違いと言えるかも知れません。
◆ 事件は会議室で起きる
歩くという運動は、なかなか複雑です。
特記できるのが、それが「倒れる」と「倒れない」の境界線上での運動だとういこと。私たちは、当たり前のように歩くことができますが、これはいちいち考えていないからです。体勢が倒れる前に次のアクションを自律的に繰り出していく、そういう力を私たちは持っています（幼児はまだ練習中なので、しばしば失敗して転びます）。
プロジェクトというもののやっかいさは、この辺に例えられるでしょう。定常業務の場合、各関係者にとっては何度も繰り返している定型作業の集合に過ぎず、どっしりと安定した運動のようなものです。しかしプロジェクトの場合、倒れるようなリスクを冒してこそ成立するものなのです。
そして、参加する人数の多さも、この混乱に拍車をかけます。例えば二足歩行ロボットを操縦しているような状態を想像してみてください。しかも、右と左の手と足に全て別々の操作者がいて、操縦者は彼らに指示を出して歩かせなければならないのです。
これはかなりやっかいです。ただ４人ぐらいなら、何とかなるかも知れません。操縦者が「右！」といえば、右足担当と左足担当が目配せしながら力のバランスを変え、両腕担当の二人もそれにあわせて修正するといった調子で。また、そのロボットが机の上に乗るぐらいのコンパクトなものだったら、多少の問題があっても勢いでなんとかなるでしょう。昔のゲームは、実際に４人ぐらいで作っていましたし、仕事環境も、開発部の島ひとつで納まる程度にコンパクトでした。
しかし今は違います。手足の一本ずつに１０人ぐらいの担当者がいる、巨大なロボットをイメージする必要があるのです。こうなると、各操作者も、周りの様子を見ながら適当に修正というわけにはいきません。ひたすらコマンドを待ち、忠実に実行するということになります。異変が起こってもすくに対応できず、最悪の場合ばったりと倒れてしまいます。
これを解決するのは、手や足にも分散された脳がある状態にすることです。企画職、さらには各職種ごとのリーダー級は、そのような意味である程度の「プロデューサー性」を持って仕事に当たっていくべきです。
＊ ＊ ＊ ＊ ＊ ＊ ＊ ＊ ＊ ＊ ＊ ＊
職業としてのあいまいさは、一般消費者の方だけを向いている訳ではなりません。当人にとってもそうなようで、自分が何をしなければならないのか解っていない"肩書きだけのプロデューサー"が、しばしば見られまです。
例えば、クリエイターの領域をつまみ食いしようとする人。もちろん作品内容への関与は仕事のうちですが、シナリオライターなりゲームデザイナーなりが責任を持って作り上げるべき部分にまで安易に手を出して来る人がいます。逆に、人・金・物の手配だけで済ましてしまう人もいます。つまりは、インプット部分だけを見ていて、アウトプット部分には気付いていないのです。また、単なる情報伝達人になってしまう人もいます。せめて双方向であれば救いようもあるのですが（でも苛立ちますね）、ひどい場合になると、ほんとうにただのメッセンジャーで、上位者や優位に立つ他部署からのリクエストを伝達するだけ。複数のリクエストが矛盾する場合もお構いなしで、実際に何をやるのかは完全に現場任せだったりします。
これは、業界としてなるべく早く克服しなければいけない問題です。そして、これからこの道に進んでいく人は、自ら解決の当事者として活躍して貰わなければならないのだと思います。
◆ クリエイターとの境界線
以上、プロデューサーの仕事を中心に述べてきました。ここまでの理解があれば、小規模な会社において社長がプロデューサーだったというのも、あながち間違ったものではないことが解ると思います。資金繰りを行い、従業員の採否を決め、作品性に対しても決定権を持つわけですから。
しかし、ゲームが産業として成長した結果、両者の役割は否応なしに分けられるようになりました。小さな会社では、未だに社長自らプロデューサーとして走り回っている場合が少なくないのですが、職種としては観念上分離されているわけです。
さて、クリエイター志望者としては、「境界線」が気になるかも知れません。
私は、これは立場ないし役割の問題だと思っています。つまり、<b>企画屋の仕事とプロデューサーの仕事はなめらかに繋がっていて、仕事そのものでは白と黒を分ける境界線はない</b>と思うのです。
ゲームを構想するということは、完成像へのイメージを作るということです。動いているゲーム、それを遊んでいるプレイヤー、両方をイメージできなければいけません。である以上、投入されている技術やコンテンツの規模も推測できなければなりませんし、プレイヤーがどこに面白さを感じているのかということも想定できる必要があり、その前提となる「どういう人なのか」も視野に納めることになります。
結局これは、「４つのP」の中の"プロダクト"を決めていくということなのです。
もちろん役割の違いというものがありますから、優先順位は異なってきます＊５。
どんなゲームにするのかを考える場合、クリエイターはボトムアップ的に考えます。自分や自分の周囲にいる人が面白いと感じるものを考え、それがどんな要素で成り立っているのかを抽出し、誰に対して売れるのかなどへとつなげていきます。プロデューサーの場合、この順番は逆です。誰を顧客層とすべきかを考え、どんなゲームであれば面白いと感じてくれるのかを推測していくという順番になります。
しかし、前にも説いたように、企画屋の仕事は一往復です。ボトムアップし終わったら、今度は逆に自分の構想の妥当性を考えなければなりません。これは実はプロデューサーも同じで、先にトップダウンしてからボトムアップしていくという点で異なっているのです。
そのようなわけで、ゲームデザイナーとしては、自分の仕事の中にプロデューサー的な部分が相当に含まれていることを理解した上で、まずは現場要員として求められる仕事をしっかりとこなしていくことが、必要になるでしょう。
前回とりあげたキャリアプランですが、実際にラダーを構築している会社の場合、プロデューサーをゲームデザイン領域の上級職として捉えていることが多いです。つまり、ゲームデザイナーとして一定の経験を積んだ人間が、いくつかのスキルを獲得することで、プロデューサーとなる資格を得るといういことです。また、特にそういうシステムを持っていない場合でも、立場が高くなれば自動的にプロデューサーに近い存在となってきます。４つのPに代表されるプロデューサーならではの知識も、着実に身につけていくべきでしょう。