遠き開発

（五）新人時代

　新入社員としての日々は無我夢中（むがむちゅう）、五里霧中（ごりむちゅう）としか言い様がない。

　最初の仕事は、開発中のゲームのバグチェック作業から始まった。『バグ』とは、ゲーム上で発生する不具合の事である。ゲームが進行不能になるＳランク、ゲームは進行できるが重篤（じゅうとく）な問題であるＡランク、深刻では無いが不具合であるＢランク、軽微なものであるＣランクと、会社によって定義の差異はあるが、それらのバグが発生すれば、その報告をネット上のバグ管理用データベースシステムに挙げることと、修正されたバグが本当に修正されているか否かを確認するのが、最初の主な仕事となった。

　だが、その時点で早くも雪乃は自分がどれだけゲームを仕事にするということを分かっていないのかを思い知る。バグ報告一つとっても、先輩から厳しく注意を受けた。

「早見さん、君な、バグ報告の書き方がなっていない。まず、タイトルは一行で現象が分かるようにしないといけない。『攻撃をしたらフリーズ（ゲームが完全に止まってしまい、それ以上の進行が不可能になる現象）しました』っていうタイトルだけじゃわからないだろう。どんな状況で攻撃したらフリーズしたのか？　常時なのか、それともキャラクターがパワーアップ状態の時なのか、相手が特別なステータスの時なのか、とかそういう状況を一文で端的に書くこと。詳細はそれを詳しく書く。それから現象が発生したリビジョンと環境も必須。でないと、いつのリビジョンのどんな環境でどんなバグが発生したのか、プログラマーが修正してないバグなのか、修正したけれど再発したバグなのかも分からなくなってしまうだろう」

　ゲームは、数多いスタッフが作成する様々なソース（プログラム）やリソース（端的に言って素材という意味）から成り、膨大な数字のデータから成り立つ。それらをチーム全員で一つのゲームとして組み上げ、管理するために、『バージョン管理ツール』を用いて、誰か、いつ、どのようにプログラムやデータを追加したり、更新したりしたのかを記録していく。それら変更の記録が、『リビジョン』と呼ばれる数字だ。一から始まるその数字は、多くのゲームで数千から数万単位の更新記録を重ねる事になる。

　先輩から指摘を受けるうちにに、バグ報告にも仕事としての『要（かなめ）』があることを雪乃は悟っていった。

　バグ報告のタイトルの書き方は、一文で現象の内容が大まかにでも分かる様に書くこと。バグの詳細は、発生した状況は勿論、手順が分かればその手順、再現性はどの程度か、発生した際のリビジョンやプレイしていた環境、バグのチェックやゲームとしての機能がきちんと仕様書通りに実装されているかの確認を容易にするための『デバッグ機能』を使用していたか否かも書く事等、雪乃はその細かさに目をむいた。

　特に、『再現性』において、滅多に発生しないバグの現象確認と修正確認は骨が折れる作業だった。デバッグのみを専門に請け負う会社から、バグ報告が来る。バグの再現を試みる。進行不能になるＳランクのバグは、その再現性が低くとも、プログラマーに心当たりが無いかどうかを確認した上で、最低百回は再現試行を試みる必要があった。修正された後も同様で、本当に修正されたのかどうか、同様に規定回数、現象の再現を試みる。

　雪乃は、改めてゲームがどれだけ複雑かつ膨大なプログラムとデータから成り立っているのかを思い知ったし、製品バージョンとなるマスターＲＯＭ納品を控えた現場は殺伐としていて、雪乃の想像を超えた開発現場の実態がそこにあった。『ゲームそのものは娯楽だが、それを開発するのは仕事である』という業界の研究本の一節が改めて実感として感じられた。

　ほどなくして、『魔剣でＧＯ！』というアクションゲームの雑魚キャラクターの挙動をスクリプトと呼ばれるそのゲーム用の簡易言語を使って作成する仕事が新人たちに回ってきた。先輩のプランナーやプログラマーに教えられるままに無我夢中で雑魚キャラクターの挙動を作る。自分が作ったスクリプトによって、雑魚キャラクターたちがゲーム上で動き回る様を見た時は、作り手に回った喜びに静かな感激を覚えたものだった。だが、今度は『データ作成』という仕事でまたも雪乃は事あるごとに先輩やプログラマー、デザイナーから怒られた。

「データを新規追加した場合はプログラマに連絡して対応をお願いしろと言っただろう、それを忘れて動きませんとはどういう了見だ」

「早見さん、また動かないデータをコミットして帰宅した？　あれだけ確認しろって言ったのにどういうつもりなの？」

「素材の発注を忘れていたの？　今から作るけど、素材管理くらいちゃんとしてよ。ちょっと可愛いからってちやほやされて気持ちがゆるんでるんじゃないの？」

　直接雪乃の責任でもないのに理不尽に責められることや、いわゆる『逆ギレ』されたりもしたが、それは悪意ゆえ、というよりは、誰が何を担当しているのかが曖昧（あいまい）な箇所で多く発生した。スクリプトやパラメータといったデータ一つとっても、それを作成してゲーム上できちんと動くかを確認し、厳密に管理していかなければならないのだと、失敗を繰り返して身体にたたきこまれたし、『次はどうすればいいか』を自分なりに考えて同じミスをしない様気を配ったが、仕事は次々に押し寄せてくる。

　スクリプト作業をこなしながら、企画書と言われれば企画書、仕様書を作れと言われたら見様見真似で仕様書を作るのだが、特にこの『仕様書を作る』という仕事は、具体的にどう処理したらいいか分からなかった。

『仕様書』とは、ゲームの仕組みの設計図である。プランナーにとって『仕様』とは、ある要素をゲーム上でどの様に実装するか、ルールとその流れ、操作方法、必要な素材、必要なデータ群のことであり、それらを他のスタッフに伝えるために作成するのが『仕様書』だ。

　その作成方法は、株式会社オストマルクには定型的なフォーマットがあるわけでもなく、先輩たちの仕様書を見ても、書き方も細かさもバラバラで、何を参考にしたらいいか皆目見当がつかない。単体では全く意味がくみ取れないものすらあった。

　見様見真似でそれらしいモノを作ってプログラマーに持って行くと、突き返された。プログラマーの多くは男性で、雪乃が美人でかつ、新人である事も関係あってか、彼女に対しての『当たり』はそれほどきつくはなかったが、言われた言葉を要約すると、『穴が多すぎて使えないから作り直して』という事なのである。

　雪乃は何度やり直しても作業してもらえず途方にくれた。学生時代、ゲームサークルで仕様書を作っていたという同期入社の男性は自信満々でいたが、現場でプログラマーから『仕様の穴』を指摘されまくり、抱いていた自信ごと木っ端微塵に粉砕され、青い顔で席に戻っていた。

　だが困ったことに、プログラマーやデザイナーも、『仕様とは何か』という事には答えられても、それを他人に伝えるための『仕様書』の作成方法は答えられない。「やりたいことが伝わればいいんだよ」というばかりで、具体的に言語化できないのである。

『やりたいことが伝わればいいんだ』という事を真に受けて、それをまとめて持って行くと、あれが足りない、ここが分からないと指摘を受けてリテイクをくらう。雪乃は答えのない世界でもがいて、それでも直接口頭のやり取りをメインとしながら、決めたことを仕様書にフィードバックするというやり方で、何とか仕事を進めることができたのだった。

この辺りの粘りは、雪乃が体育会系の部活で学生時代を過ごしてきた事が良い方向に働いた様だった。中学校から軟式テニスを始め、高校では硬式テニス部に切り替え大学でもテニスを続けた。特に高校時代は都内でも強豪に属する強さを誇った部で、練習のキツさや上下関係の厳しさは中学のそれとは比較にならなかった。その反動で、大学では気軽にテニスを楽しみたいと思ったが、覗いたテニスサークルはあまりにも目的意識がなさ過ぎ、男子部員の下心丸見えの勧誘にも嫌悪感を抱いて、結局体育会硬式庭球部へと入部してテニスを続けた。大学の庭球部もまた厳しさはあったが、高校時代を思えばどうということはなかったし、仲間や先輩たちにも恵まれ、雪乃は充実した学生時代を送ることができたのだった。

　こうして、どうにかこうにか『仕様書』らしきものを作って、プログラマーに実装したい内容を伝え、通ればデザイナーに必要な素材を説明して発注する、という体当たりの方式で仕事を進めることを雪乃は覚えた。

　だが、雪乃にとって大きな失敗だったのが、『実装確認』という工程を意識できていなかったことだ。仕様書を作り、素材を発注し、内容をプログラマーに頼んで実装してもらう。大事なのは、それらの作業が終わった後、それらがプランナーの意図通りに実装されているかどうかを確認することだ。この工程を無視していると、いざ関連項目を実装して一つゲームにパッケージングし、クライアントに提出する――通常、『ＲＯＭ出し』と呼ばれる――段階になって、色々問題が起きてしまう。仕様書の意図と違う形で素材や処理が実装がされている、バグでゲームが進行できない、データが反映されていない等、当日に問題がこれでもかという具合に発生して、雪乃は自分がまだ開発の『段取り』と呼べるものを理解できていないことを悟った。

　それからは、現場でやってしまった失敗、仕事で気がついたこと、得た知識を、自分でノートに書き始めた。失敗を積み重ねて、ゲームがどれだけ複雑な構造でできているか、そして、段取りを意識して動かないといけないか、雪乃は身体で覚えていっただけでなく、それを自らのノートに言語化してとりまとめていったのである。