世は大インディーゲーム時代。
SteamやSwitch、それともPS5、XBOXなどに溢れんばかりにリリースされるインディーゲームに注目しているゲーマーは多いことだろう。そんなインディーゲームについて「職人的な個人、少人数の有志が個性的なゲームを作る、自由なゲーム」というイメージを抱いているのではないだろうか。
それは一面の真実だが、これは別の真実……表に出づらいインディゲームの世界をテーマとした連載である。
本連載で語られるのは、SEモバイル・アンド・オンライン株式会社（SEM&O社）の事例。同社はゲーム開発支援（SES）業務・受託開発、そしていくつかの運営、ダウンロードゲームを手がけているが、2023年に新卒中心のチームで新規にSteam向け自社ゲーム開発を行っていた。
ところが、企業がインディーゲーム開発に乗り出そうとすると個人・少数集団の開発とは異なる問題に直面する。ゲーム開発チームの常識も違うし、経理処理が開発に影響を及ぼすことすらあり（このあたりは第1回をご覧いただきたい）、そうしたノウハウがないために大きな失敗をしてしまうこともある。
これは多くの人が想像する「自由なインディーゲーム」のイメージからかけ離れているだろう。しかし、これはまぎれもない現実であり、日本のゲーム企業からは同じような悩みをしばしば聞くのである。
監査のある企業ともなれば内部事情を話しづらいし、知見が共有されることはまれで、当然皆さんの前にもその話題は出てこない。結果、「あなたの知らない世界」として埋もれ、同じ落とし穴にハマる会社が後を絶たない。
本インタビュー連載「縛りだらけのインディーゲーム開発」では、同じような苦労をしている開発会社に知見を共有すべく、実際のプロジェクトの事例をもとに会社役員としての問題、開発チームの苦労、マーケティングの落とし穴など、全4回程度に渡って開発で直面した苦労を赤裸々に語っていく。
第1回は、経営層にインディーゲーム開発に乗り出した経緯や、その結果突き当たった問題について聞いてきた。ヴァンパイアサバイバー系（サバイバーライク）のゲーム『Rogue Gladius Survivor』（以下、グラサバ）開発が始まるまでの経緯を主に説明させていただいている。
第2回のテーマは「ゲーム開発」だ。
第2回はチームに所属していた唯一のベテラン、シニアデザイナーの渡部が、新人のインディー開発チームがうまく回っていないと感じて、過去に所属していた会社で上司だった筆者・岩崎啓眞に「ヘルプしてもらえないか？」と頼むところから始まる。
あなたの知らない「縛りのなかで自由を目指すインディーゲーム開発」の世界が、ここにある。
なぜ、岩崎が引きずり込まれたのか？
そもそも、シニアデザイナー（ゲームデザイナーではなく海外でいうアーティスト。絵描きがメインの仕事）の渡部は岩崎と知り合いで、岩崎の前々々職の時の部下のひとり。だったのだが、去年の秋ごろからずっと岩崎を仕事に誘えないか考えていた、というのである。
渡部曰く「新人のプランナーにも笑いながら教えてくれて、面白いゲームを作るための経験と知識がある人の心当たりがひとりだけあった。Facebookを開いては、何度も相談しようかと迷った。あの人なら快く質問に答えてくれるかもしれないが、しかし無報酬で甘えるのも何か違う……」と迷った挙句に、ある日、相談を岩崎にしてきたわけだ。
ずいぶん岩崎を高く買ってくれたものだとは思うが、それはともかく最初に相談を受けたとき、こんな会話が交わされた。
シニアデザイナー・渡部：
メインプランナーの子がディレクター的な立場なんですが、持ち帰って考えてもらうと斜め上の答えを持ってきてしまって「なんでそうなった！？」みたいになることがあるんです。だからどう考えたかを説明してもらい、岩崎さんにご指導いただきたいなと！
岩崎：
あー、つまりいろいろな仕様がフワっとしていて、危なっかしいということ？
シニアデザイナー・渡部：
そうなんですよ、だからUIの仕様がコロコロ変わったりして、いろいろ困っているんです。
あと自分が今までいた会社では、「こんなやり方はしなかったぞ」というやり方をチームのメンバーが選択することも多くて、そういうところも不安です。
岩崎：
そういうパターンなら何度も見てきたから、まあ何とかできると思うよ。
若いチームが右往左往している感じが想像できたので、「これなら自分の実力の範囲でなんとかなるだろう」と引き受けた。……のだけど、これがまったくの安請け合いだったことはあっという間にわかるのである。
驚きの「仕様書足りない」騒ぎ
実は最初に質問されたことはゲームの事ではなく（というか、ゲーム以前の話の方が相談としては圧倒的に多かった）、「タスクの抜け漏れが発生するのをなんとかしたい」という問題から話が始まった。要は「やるべき仕事が抜けていることが多いのだけど、どうすればいいですか？」という話だ。
さて、タスクの抜け漏れは必ず発生する。どれだけ完璧な仕様書があろうと発生する……けれど、この時はまったく理由が違った。以下は、その時の会話である。
岩崎：
抜け漏れは、どれだけ正確な画面仕様書が揃っていても必ず発生するんだよ。だから抜け漏れが出ることは前提で、出たときにどれだけ早く修正できるかの方が大事なの。
メインプランナー・櫻井：
全画面分の画面仕様書っていりますか？
岩崎：
ないのかよっ！ すぐ書いて！ このサイズのゲームなら根を詰めれば数日で書けるはずだろ！
※この時、本当に腰を抜かすほど驚いた。なぜなら、画面仕様書が全画面分ちゃんと揃っていなければ、抜け漏れするに決まっているし、さらに完了定義ができなくなるからだ。
……と書いても「完了定義？」となると思うので、この時にメインプランナーの櫻井君にした話を残しておきたい。
岩崎：
ところで、「画面仕様書」が何かはわかってるよね？
メインプランナー・櫻井：
学校で教えてもらいました。何画面分かは書きましたが、全画面分を書くのがそんなに大事なんですか？
岩崎：
全画面分の画面仕様書がないと完了定義がすごく難しくなるんだよ。
メインプランナー・櫻井：
完了定義？
岩崎：
完了定義は「ゲームがとりあえず完成している」と言えること。すごく簡単な例として、タイトル、キャラ選択、ゲーム、ゲームオーバー、ゲームクリア、と5画面から構成されているゲームを考えたとき、この5画面全部について、画面に現れるものすべての仕様を入れた画面仕様書を書いたとします。
メインプランナー・櫻井：
はい。
岩崎：
デザイナーがそれに基づいて絵を用意して、プログラマが仕様に書かれていることをすべて実装したとすると、バランスとかは全部抜きにして、理論的にはゲームとしては完成。最初から最後までプレイできるはずなんだよ。だから全画面分の画面仕様書をなるべく抜け漏れなく書くと、画面仕様書に書かれているものを全部実装すると、ゲームが完成する……すなわち、完了定義ができるわけだ。
メインプランナー・櫻井：
なるほど！ すぐ書きます！
櫻井君本人は優秀なプランナーなので、理解してしまえばあっという間だった。ゲームサイズがあまり大きくないのもあり、会議のあと数日かけて、ふたりがかりで画面仕様書を書き終わっていた。
ところで画面仕様書は、その名の通り画面の仕様なので、UIのパーツやいろいろなものをそれなりに固定してくれるというもうひとつの効能がある。
そしてこれは当たり前の話だが、画面からタスクが作られるようになるので、抜け漏れも大幅に減るはずだという確信があった。つまり、全画面分の画面仕様書を書くということは、シニアデザイナーの渡部が頼んできた「UIの仕様がふらつく」といった問題も解決されるはずだと思っていたのだ。
しかしこの時、やはり実務を経験していないと、「何が重要なのか新人では判断がつかない」ということを同時に感じた。チームのメンバーは学校でしっかり勉強をしてきているし、学校で実際にゲームを作った経験もあるし、画面仕様書といった要素ももちろん座学として学んでいるけれど、実務としてゲームを作るときに、何を重要視すればいいかはわかっていなかった。
例えば、プランナーに先輩がいれば、画面仕様書がどれだけ重要なのかは説明され、理解できたはず。完全に「新人＋絵描き」のチームで、いつでも気軽に相談できる人がいないというのは、やはり危なっかしいよなぁ……と思ったのだけど、実はチームのメンバーはそれについて当初から不安に思っていたことがわかった。
岩崎：
チームができた時の、個人の感想をまず聞きたいんだよね。「新卒でゲーム作らせてもらえる」ってどういう感じだったんでしょう。
メインプランナー・櫻井：
そうですね。チームができた時は、「あ、このメンバーでこれから一年間か二年間かやっていくのかな？」「何本ゲームを作れるかな？」みたいな感じで、ワクワク感はかなりありましたね。
プログラマ・西下：
自分は期待や希望もあったんですけど、先輩のプログラマーがいないのが、プログラマーとして怖かったです。その不安は入る前からあって、「ちょっとした相談ができないとか、なんか怖くない？」みたいな話をしてたりはしました。
岩崎：
先輩がいないってことは、つまり「相談できない、自分で解決しないといけない」だからね。
プログラマ・西下：
そうですね、HAL【※】で学んだことのまま、進んでいいのかどうかもわからなかったので。そこはめっちゃ怖かったです。
※HAL：ゲーム専門学校HALのこと。第1回で触れられているが、このチームに所属する新卒のメンバーは全員がHAL大阪の出身である。
プログラマ・角田：
ですね、その懸念については始まる前から話をしていました。結局、想定していた「会社の人に聞いてもらう→答えが返ってくる」という流れだと、どうしても解決までに時間がかかるので、悩みの種でしたね。
岩崎：
逆に言うと、次のプロジェクトがあるとして、その時にはヘルプというか、何らかの形でプログラマーとして質問できる人間が常駐していると、ありがたい感じがしますかね？
プログラマ・西下：
それは間違いなくそうだと思います。
岩崎：
チーム編成時には、もうシニアデザイナーの渡部さんはいたんですか？
シニアデザイナー・渡部：
いましたね。面接自体が新卒のみんなの採用直前ぐらいで、入社は同時なんですよ。
岩崎：
この新卒だけのチームでゲームを作るというのは、デザイナー的にはどうだったんですか？
シニアデザイナー・渡部：
まず、新卒でゲーム作って売上を上げてほしいっていうミッションだったので……。研修でゲームを作るだけでなく、売り上げを上げることも目指していくとなると、非常に難易度が高いと思いました。
だけど、「とんでもなく優秀な子たちだから大丈夫」という事業部長の後押しがありまして。また、私がプランニング・エンジニアリングは分からないので、フォローしてくださいとお願いしたら、「大丈夫、フォローするから」とも仰ってくれたんです。
実際、フォローはしてもらえたんですが……それでも予想より難易度は高かった、というのが正直なところだったと思います。
このプロジェクトを統括している事業部長の想定は、質問されたことを会社の他のベテランにリレーし、答えをもらうという形でフォローするというものだった。それに加え、インターネットには大量の教材があるので、自己解決できる部分も多いから、これでチームは回るだろうというものだったそうだが、実際にはかなり想定外のことがあり、辛かったというのが答えだったと思う。
上の画面仕様書の重要性なんかが良い例だが、そもそも新人チームでは「どれぐらい重要か」がわかっていないのだから、質問にあがってこない。だから「画面仕様書が足りていない」という問題ではなく、なんだかタスクの抜け漏れが多いという相談になり、本当の問題が見えてこないのだ。確かに、画面仕様書を書くのは手間がかかるので、省いたほうが効率がいいんじゃないかと、経験がない状態では思ってしまうのもよくわかる。
また、例えばUnityを使ってゲームを作るとき、インスペクタにオブジェクトをアタッチしてパラメータを調整する、という作り方が教科書や入門書には書かれている。しかし実務では基本、このやり方はテスト以外では使わない。なぜなら複数の人数で開発するとき、教科書に書かれているやり方は事故の元だからだ。しかし、それが問題だということを新人は知らないから質問できず、「なんだかUnityの事故が多いんですけど、なんとかなりませんか」という質問になってしまう。
つまり、そもそも正確に質問できない問題が存在している場合があるわけだ。
実際に起きた問題のひとつに文字コードがあった。Unityは結構歴史あるソフトなこともあり、Windowsで新規プロジェクトを作ると、現在では使うのが推奨されない文字コード「Shift JIS」でプロジェクトを生成する。実務経験者はそれを知っていて、プロジェクトを生成した後に「UTF-8」【※】に切り替えてしまうのだけど、もちろん新人チームはそんなことは知らない。
Shift JISのまま作業していて、僕が入った時に「えっ!? Shift JIS!?」とビックリして、即時直してもらったということがあった。これなども、このまま進んでいると、どこかで問題が起きたはずなのだが、そこに問題があると気づけないパターンだ。
※UTF-8：現在標準的に使われる文字コード
結局、「新人だけで制作を行い、問題が起きたらベテランに聞ける」という方法は、問題を問題と認識できずに進んでいく状況下ではうまく機能せず、問題が発覚せず、違う事故と捉えられる現象が起こっていたわけだ。
それはともかく、画面仕様書を書いてもらい、ようやくプロジェクトとしては正しく回るようになった。しかし、これでゲームが面白くなるわけではない。岩崎の次の仕事はゲームを面白くする手伝いをすることだった。
