こんにちは。ケムコ社員Nです。
引き続き
今治編です。
既に深夜なのですが、
宿の夕食でお刺身がいっぱい出て上機嫌なので頑張って書こうと思います（お値段のわりにいい宿です）。
なぜかLTEが切れてソシャゲー（他社製）ができなくなったからともいいます。
夜食に買っておいたアジのたたきに醤油がついてなかったので頑張ってそのまま平らげたことで微妙にテンションが下がってきました。
でもワサビとショウガだけで召し上がるのも結構オツだったかも。
なんだかよく分からないまま書き進めることになりそうです。
さて、これまで沢山の業種を紹介してきましたので、もはや読者の皆様はゲーム業界にどんな連中がいて、どうやってゲームを作っていくか、なんとなくつかめていることでしょう。
しかしながら、それでゲーム制作のなんたるかを分かった気になるのはあまりにも早計。
というわけで、今回はケムコにおけるゲーム制作の一連の流れを例にとり、これまでの内容も踏まえつつ、更にゲーム作りのたいへんさや面白さに迫っていこうと思います。
さて、ケムコにおけるゲーム制作の流れとは以下のようになっています。
- 予算割り当て
- 開発会社との打ち合わせ
- 企画書審査
- スケジュールの決定・契約
- αテスティング
- Preβテスティング
- βテスティング（デバッグ）
- マスターアップ
- ローンチ（発売）
- 地獄
発売後の地獄に目を向けるのが既に怖いですが、とにかく順に見ていきましょう。
1.予算割り当て
ここに関わるのはディレクター、マーケターそしてプロデューサーです。
プロデューサーなんてこれまで出てこなかったじゃねえかという声が聞こえそうですが、ゲーム業界においてプロデューサーというのはディレクター以上に扱いが微妙で、下手すると制作現場にまったく立ち入らないため紹介していなかったのです。
プロデューサー（producer）はプロデュース（produce、生産する・製造する）する人の意であり、意味合いとしてはプロジェクトの総責任者でありかつ予算をくれる人です。
プロジェクトの采配を振るうのはディレクターですが、ディレクターはじめスタッフを選定してプロジェクトを始動させるのは予算を動かす権限をもつプロデューサーの役目。
もちろん予算をとってきているわけなので発言権はとても大きく、「こういうゲームにしてね」というプロデューサーの意見は一種神の声として絶対遵守の対象となる。
が、現場に口を出さないプロデューサーもいますし、一方で現場で様々な采配を振るい良いものを作り出し、「○○さんプロデュースのゲーム」という一種のブランド性を持たせているプロデューサーもいます。
会社によってはもっと別のプロデューサー業務の線引きをしているところもあるでしょうが、とりあえずウチにおいては基本的にボスがエグゼクティブプロデューサーで、予算配分をしているディレクターのTさん（なおディレクター島にTさんは３人いる）がプロデューサーの肩書になることが多いです。
基本的にはこの２人の間で年間予算うんうんうん円をどう分割して何本のゲームを作るのか、それらをどう開発会社に割り振るのかが話し合われます。
当然ながら、作品数を増やせば１本あたりの規模は小さくなります。
作品数を減らせば１本あたりの規模が大きくなり、開発期間も長くなることから、大きなゲームは作れるようになりますが、一方でコケたときのリスクも大きくなります。
ハイリスク・ハイリターンというわけです。
これまでケムコが１か月１本RPGリリースという驚異のペースでリリースを重ねて来たのは、１にハイペースでクリアするゲーマーにソフトを提供するため、２に技術力やノウハウを誇示するため、そして３に外した時のリスクを下げるためでした。
これからはおそらく別の方針も模索していくことにもなるでしょうが、要するにこの段階ではそういったリスクヘッジ等も含め、様々な経営判断が行われるのです。
そして、最終的には個々のディレクターの肩が叩かれ、「お前この案件担当しろ」と令達が下ることになります。
実は筆者も１件、担当が決まっている（と思われる）RPGがあって、今から戦々恐々としております。ああ、どうなるんだろう・・・。
ちなみに最初の段階でマーケターから「こういうものが今需要があるから作ったほうがいい」といった意見が出ることもありますが、うちでは参考意見としてディレクターが吸い上げ、最終的な採否は任されることになることが多いです。
大手他社さんだとおそらく、より強烈なマーケティングが開発前に行われ、それによる戦略立案が行われたりしてるんだと思います。
2.開発会社との打ち合わせ
ここで関わるのはディレクター、および開発会社側のプランナーさんですね。
予算が付いたことで、どんなゲームを作ろうか、と相談する段になります。
ただ、このステップは省略されることもあります。
開発会社さんが「今回はこれを作ります！ 断固として！ 異論は認めない！！！」と主張される場合、ウチとしてはOKを出すスタンスです。
パブリッシャーは出版者、あくまで販路を提供してくれればいい。
そういう需要に対しても対応可能ではあります。
しかしながら昨今のマーケットはきわめて難しく、そこでパブリッシャーをやっているからこそできる「こういう風に作ったほうがいいですよ」的なアドバイスもありますし、単純に三人寄れば文殊の知恵よろしくアイデアを出す頭数は大いに越したことがない場合もありますので、求められるかぎりにおいて弊社側もこの段階で色々な意見を出します。
主に「次は○○をテーマにしよう」とか「前はアレが失敗だったから次はこうしよう」とか「今これが流行ってるのでウチでもやってみよう」とか、そういうざっくりした内容を相談して、企画書制作につなげてもらうのを狙う場になります。
3.企画書審査
開発会社のプランナーさんが企画書を書き、うちのディレクターがそれを確認します。
一応、通常、うちとしては企画書をリジェクトする（突き返す）ことができ、また実際にすることも少なからずあります。
企画書段階でディレクターに面白さが伝わらない、それはつまり、その作品の魅力が不十分か、あるいは魅力の伝達が不十分かのどちらかです。
実際に作ってみれば魅力的なのかもしれませんが、企画書にそれを書けていないということは、実物ができた後にお客さんがパッケージやマーケット画像を見てもピンとこない・・・という状態になってしまう可能性も十分にあります。
魅力的な作品は魅力的な企画書から。
その精神で、ディレクターは企画書時点でできるだけ魅力的にまとまるよう、心を鬼にして企画書を突っ返すことになります。
まあやりすぎるとケンカになるので、何事も過ぎたるは及ばざるがごとしということで。
4.スケジュールの決定・契約
無事企画書が通ったら、これをいつまでに作るかという相談を行い、それらが明記されたかたちで契約が締結されます。
うちでは開発案件１本ごとにきっちりと契約書をつくります。
以前のコラムで書いたとおり、筆者も契約書文面を作成したことがあります。
締結実績のある文面であれば、細かい部分を変更して新しい契約文面の土台にすることも楽なのですが、新しい契約先・新しい提携内容であれば契約書作成も結構大変です。
ともあれ、この場合の契約書はいわば発注書のようなものです。
これがあることで開発会社も我々も安心して作業を始めることができるということです。
5.αテスティング
基本的にはうちのディレクター側の作業です。
契約のつぎに突然テストがどうとか言い始めましたが、実のところ契約からここまでに数か月を要します。
その間に、制作チームは企画書にまとまった内容から仕様書を作成し、ゲームを実際に制作します。
製作会社側で、ディレクター、プランナー、ライター、グラフィッカー、コンポーザーといった現場スタッフがフル稼働し、その結果出てくるのがα版です。
パイロット版とかいろんな言い方があると思いますが、要は試作品。
α版をさわることで、ケムコのディレクターは、企画書で感じた魅力がちゃんと形になりそうなことを確認する・・・はずなのですが。
実のところ、なかなかしっかりしたα版を出すのは難しいです。
開発期間はかなりギリギリまで切り詰められていますので、この段階ではろくに動かないということもしばしば。
それでも、進捗を確認しておくことは大事なので、α版は作ってもらいますし、その動作確認は必ず行うのです。
そして、もしこの時点で方向性を変える必要がある場合・・・例えばキモとなっていたシステムが全然面白くないとか、ふたを開けてみたら絵師さんのデザインが思った方向性と異なるとか、そういった状態があれば、ケムコ側のディレクターは方針転換の相談をしたり、細かい調整によってそれらを改善できるよう折衝を開始します。
なお、α版が良くできていて、「フィールド移動は完璧にできます」とか「ストーリーは前半まで全部入ってます」とかいった場合、ケムコ側のディレクターはこの時点からデバッグを初めてしまうこともあります（デバッグ期間が限られているという点ではウチ側も結構余裕がないのです）。
6.Preβテスティング
基本的にはウチのディレクター側の作業です。
Preβ版、β版の１つ前のバージョンという意味ですが、一般的にα版が試作版ならβ版はほぼ完成版です。
ふつうβというのは全仕様が実装され、基本的にはそのまま売りに出せるだけの完成度に達しているということを指します・・・ただしバグは残っているということです。
βになってしまうと仕様が固まっているので手を出せませんが、Preβとはβ版を作る前に仕様の過不足がないかを調べ、不足があればそれを補う・・・という目的を果たすためのバージョンです。ようはテコ入れ段階ですね。
時期的に、この辺で声優さんによるボイスは揃ってるのが望ましいです。
ディレクターにとっては、マズい仕様があった場合はこの期間内に潰しきらなければなりませんので、かなり戦々恐々とします。
コラム内コラム／ユーザーインターフェイス（UI）について
ユーザーインターフェイスとはソフトのユーザー、つまりこの場合はゲームのプレイヤーが、ゲームの操作をどのように行うか、また、その操作をどのようなゲーム側のしくみによってプレイヤーに理解させ実現させるかという、方法論であり、思想であり、またそれらの結晶たる画面パーツのことでもあります。
・・・説明がすごく厄介だな。
例えば、スマホでRPGを遊ぶ場合、当然
キャラクターを左から右へ動かすという操作が生じますよね。
そういうときに、画面の端のほうにこういう物体を置いておくとします。
ゲーマーなら見ただけでこれが何を意味するのか分かるでしょう。
要は方向キーをイメージした画像で、タッチスクリーン上にこれを置いておけば、大体は
右の三角形を触れば右に移動するのだろうと理解されるでしょう。
この画像はUIです。
この画像が４方向を表しているのだということもUIです。
また、
この画像によってキャラを動かすのだということもUIです。
実は昨今、UIの重要度はものすごく上昇しています。
スマートフォン以降、タッチスクリーンですべての操作を完結する必要が出てきましたが、これは実はものすごく難しいことなのです。
スマホの画面は（テレビとかと比べれば）小さい。
さらにスマホは手で持ちながら操作するわけで、実は指の稼働幅というのはかなり狭いのです。
なのに、そこにゲームコンテンツと同時にUIを表示し、そこで操作を完結させなければならない。
ゆえにUIデザインは、全ての画面で不要なUIを徹底的に排除したうえで、一貫性（画面のこの辺は常にこういった機能のUI・・・たとえば「戻る」とか・・・に割り振る、など）と利便性（画面上部には指を伸ばしづらいので重要なUIを置かないなど）を兼ね備えたものになるよう、すごく気を遣う必要があるのです。
一方で、タッチスクリーンならではの操作・・・フリックだスワイプだってのも考慮する必要がありますしね。
あいつらはとても厄介です。
何が厄介って、
誰もが一度はアレがかっこよくて便利そうだから何でもかんでもアレで解決しようとしてしまうからです。
実際のところ、フリックやスワイプといった操作は簡単で単純な操作にしか向きません。
簡単な操作の連続でプレイできるジャンルはスマホ以降かなり充実してきましたが、一方で複雑な操作を要するゲーム（RPGもそうです）だって以前と変わらず面白いわけで、そういったものにはそれなりのUIを置く必要が出てくるのです。
このあたりの塩梅をつけるには長年蓄積したノウハウがモノを言うわけですが、αやPreβの時点でUI設計がグダグダだとディレクターはかなり青ざめることになります。
このあたりは調整が効きづらいですからね。
しかしカスなUIを実装してしまうと大炎上につながりかねませんので、筆者がディレクターをやるときはできるだけ気をつかうようにしています。
なお、スマホのUIデザインに携わっていると、家庭用ゲームやらPCゲームやらを遊んだときに、そのUIのいい加減さや使いにくさに愕然とすることがあります。
マウスやコントローラーは入力方法として優秀すぎるんですね。
だから少々UIが非合理的でもスピーディーに遊べてしまう。
そういった逃げ道のないスマホのUIデザインは本当に難しい。
ところで昨今は、
タッチで遊びやすいUIでありながら、コントローラー差しても遊べるようなゲームを作れというような風潮が徐々に強まってきております。
無茶言うなという現場の声も呼応して徐々に強まっていることを一応述べておきます。
いやー、難しいんですよ、本当。
7.βテスティング（デバッグ）
Preβでのテコ入れが終わり、仕様が固まったところで、山ほどあるバグにようやく目を向けるときがやってきました。
テスティングを行うケムコ側は、ディレクターもデバッガーもフル稼働状態となります。
開発会社側は一応、バグが報告され次第対応する箇所の担当者が動くという形にはなりますが、実際には開発会社側が把握しているバグを必死で直したり、こっそりと実装忘れ箇所を実装していたりするので、こちらも基本的にはフル稼働です。
なお、この時点でアルバイトさんが入るわけですが、当然ながら、ディレクターがPreβで見落としていた要調整点や有用な提案が上がってくることもあります。
しかしながらこの段階での仕様変更は望ましくないので、よほど重要なことでなければ却下されることも多々あります。
それでもすべき調整であれば、ディレクターがなんとか制作会社さんに無理をしてもらうという、難しい交渉に臨むこともありますけどね。
あるいはPreβの段階からアルバイトさん混ぜて意見を出してもらうといった方法を取れる場合もありますが、往々にして、重要な指摘はβになってから出てくるものです。
制作現場のどこかにマーフィーズゴーストがたぶんいます。
倒して経験値を入手しないと・・・
8.マスターアップ
それでもいつかは、ゲームは完成するのです。本当にごく一部、完成しないままにどうしようもなくなって破綻したプロジェクトもありますがそれは見ない方向で。あ、筆者もそういえば担当したアレがあばばばばばｂ
コラム内コラム／機種対応
携帯電話ゲームメーカーならではの悩みです。
皆さんがケータイやスマホを買いたいとおもったらショップでたくさんの種類から選べますよね。
画面サイズや機能、ボタンの有無、色々な違いがあって悩んでしまいますよね。
アレ我々にとっては死活問題なんですよね。
こういう「機種差」があってもウチのアプリは十全に動きますよ、というところまで持っていくのが機種対応作業で、すでに以前のコラムで紹介していますが、もうちょっと詳しく話させて下さい（愚痴ともいう）。
実際のところ、いろんな画面サイズに対応するだけでも、つくりを相当工夫しないと画面がぐちゃぐちゃになったり、ボケボケになったりしますし、画面比（縦と横の長さが●：●というやつ）をうまく対応しないと画面上下または左右に不自然な黒い領域（黒帯、ブラックボーダーなどと呼びます）が発生します。
そりゃあ、そういうのがないように作りますが、初めから全部のサイズがそろってればどれだけ楽か・・・
さらには、マシンパワーやメモリ量などスペックの多寡が端末によって異なるのも問題です。
最新端末だからって油断はできません・・・廉価にするために安いチップセットを使っている可能性もありますからね。
さらにはスペックシートに書かれていない落とし穴もあります。
最近はAndroid4.0以降の内部ストレージというやつに悩まされまくりです。
内部ストレージを参照するから実質MicroSDにデータを置けないとか何なんでしょうか。
さらにはアプリのインストール状態とかも違います。
最初にインストールされたホームアプリと常駐アプリで既に動作重いなんてこともザラですからね。
いや、分かるんですよ。
端末メーカーさんの側も、他と横並びで完全に似たようなスマホを出してたって競争にはならないって。
ただ、せめて画面比をそろえていただいたうえで、メモリやストレージは十分に積んでいただけるとか、そういうアプリ業者側にやさしい配慮があるととても・・・ありがたいな・・・
ちなみにガラケー時代もそんな感じで、「スマホというものが来るらしいぞ」「全部共通のOS使ってるらしいぞ！」「これで機種差に苦しまずに済む！！」などと喜んだものですが、とんだ妄想でしたね。
まあガラケーの場合は基本システムすら結構違っていたので、そのあたりが多少落ち着いたのはその通りですが、たまーに基本システム部分がいじってある（それゆえに問題が起きやすい）端末もあるので注意です。
それ以前にそもそもスマホは基本システムにも色々問題が・・・おっと誰か来たようです。
えー、来たのは怖い人ではなく「ぼくらの好きな端末は一社で一貫した思想に基づくハイエンド機ばかりだから問題ないよね！」と明るく笑う某くだものファンの方だったのですが「独特過ぎる画面サイズ採用したりOSアップデートのたびにバグりまくるのなんとかなりませんか」と聞いたら怒って帰ってしまいました。
みんな色々問題は抱えているのです。
我々はそれに文句を言うのではなく、むしろチャンスととらえるべきなのでしょうね。
困難がある環境だからこそ、乗り越えた先にアドバンテージが得られるのです。
・・・つれえ。
9.ローンチ（発売）
ローンチとはlaunch（発射、打ち上げ）のことです。
「ロケットランチャー」の「ランチャー」はlauncherです。
ラウンチャーはまれに聞きますが、ローンチャーとは言いませんね。
逆にゲーム発売のことはランチとかラウンチとかは言いません。
何故でしょう、ランチでウンチとか嫌だからでしょうか。
とりあえずマスターが終わったらいずれローンチになります。
みんなローンチ期限を守ることに必死です。
入社当初、筆者は「なぜそんなに必死なのだろう。少々遅れても質を上げて良いものを出したほうがいいのではないだろうか。実際ゲーム業界では発売遅延なんてよくあることだし」などと思わないでもなかったのですが、実情はもっとシビアなものでした。
基本的にどこの企業も、フルペースでゲームを作って収益が出るようなスケジュールを組んでいるので、１つの遅延は即座に後続全ての遅延に繋がり、結果として将来的な赤字とイコールになってしまいます。
なんでそんなスケジュールになるのかと言われれば、ゲーム制作は皆さんが思ってるほど儲かりませんよと答えるしかありません。
特にケムコのビジネスモデルでは、とにかくソフトの頭数をそろえ、確実に発売までこぎつけ、それらの収益が見込んだ最低水準だったとしても何とか回るレベルというところを狙っているので、スケジュールの遅延はビジネスモデルの根底を揺るがす超絶ピンチなのです。
というわけで、どんなしんどいプロジェクトでもローンチを迎えればほっと一息つけるわけですが、皆同時に不安を抱くことになります。
地獄が始まらなければいいなあ、という。
10地獄
ゲームの地獄は3重苦でできています。
「発売後バグが出まくる」
「クレームが押し寄せる」
「収益が出ない」
これらは大体セットでやってきて我々ゲーム屋を苦しめるのです。
バグが出ても軽微なものが多く、一方でゲーム本体の評判がとてもよいので、収益はそこまで落ち込まず、バグ修正はむしろ「誠意ある素晴らしい運営だ！」などと好意的にとらえられる・・・といったラッキーな事態もまれにありますが、なかなかそうもいきません。
悲惨なのは、修正しようのない基盤部分にとんでもない見落としがあって「これがないと一切ダメ」という悪評が相次いだ場合ですね。
そういうのが無いようにαとPreβでのテストを頑張ってるはずなのですが、そうは言っても見てるのは人間、見落としもありますし、個人の感覚に依拠する部分はなかなか判断しきらないこともあります。
特にキツイのは「ヒロインがかわいくない」とかでしょうか。
ディレクターの好みがちょっと特殊だったりすると、世間一般感覚とのズレが「干物ヒロインゲー」という悪評にまで発展し、売れないばかりかお気に入りヒロインがボロクソにけなされるという泣ける事態に発展してしまいます。
そんなの予想できねーよ、という理不尽さに、制作陣は枕を濡らして眠っているということをご承知ください。
コラム内コラム／ユーザーサポートの悪夢
ケムコでは各種お客様窓口を設けており、メールおよびお電話にてお客様のトラブル連絡を受け付けています。
筆者は業務の傍ら、ユーサポ担当者を２～３年ほど担当していました。
色々な人がいることを実感しました。
丁寧な方、乱暴な方、冷静に事態を見極めようとしている方、とにかく救済してほしい方、500円を端金だと思っている方、逆にたいへんな出費だと思っている方・・・
彼らに対して共通の応対方法などありません。
ただただ個々の事情や感情を即座に読み取って、適切な対応をすることだけなのです。
と書けばあたかもうまくサポートをこなしているように見えますが中々そうもいきません。
中には最初からケンカする気まんまんの方もおられます。
そういった方は電話対応が数時間に及ぶこともあります。
ケムコのユーザーサポート窓口は選任ではなく社員の持ち回りのため、対応が長引くほどに業務に支障が出ていくことになります。
もちろん、そういうことのないように、ちゃんとした隙の無いものを作っていくべきだ、と日々決意を新たにするわけですが。
そんなこんなで地獄を見ることもありますが、無論、たくさん売れて大成功、ということだってたまにはあります。
その幸福感も、しかし、そう長くは続かないのがこの業界。
次も成功させなくては。
今回の成功をもっと生かさなくては。
そんな強迫観念とともに、次の開発へと飛び込んでいくことになりますから。
・・・というわけで。
今回は、開発の一連の流れをまとめて見てみました。
紹介してきた各業種総出演で、ガチャガチャしながらゲームを作ってるのがお分かりいただけたかと思います。
ホントに大変で、困難なものです。
どこにでもあるありふれたビジネスプロジェクト同様に。
職人などと気取っている我々も結局はサラリーマンです。
別の言い方をすれば、あらゆるサラリーマンは己の業務における職人さんなのだと思います。
お客さんがいる限り、我々は己のプロ意識と技術力にかけて良い仕事をする。
そこに貴賤などありません。
見上げたり見下したりする必要はありませんし、してほしくもない。
ただ社会の一角で我々のような人間もいて、みなさんと同じようにもだえ苦しみながら、この社会をちょっとだけ楽しくすべく頑張っている。
そんなことが伝わるといいなと思っています。
次回、最終回は、予告通り、「世界とRPGとケムコ」をテーマにお話をしていこうと思います。
皆様どうか、最後までご笑覧いただければ幸いです。
※コラムへの感想および「もっと笑える内容にしろ」とかいったご意見はkeitai-info@kemco.jp へ。もう最後のチャンスですよ。１通くらいはレスポンス欲しいな。
【11回 了】
