セッション名は「ガンバリオン仕様書奮戦記～紙からデータへ、そしてこれから～」です。講演者はガンバリオンの芳賀徹氏と土井菜都美氏。セッションは時系列に沿って行われ、（残念ながら撮影禁止でしたが）過去の貴重な仕様書や、現在の仕様書のサンプルが飛び出し、非常に実践的な内容となりました。
仕様書がない時代（創業以前）
はじめに芳賀氏はガンバリオン創業以前の、噂に伝え聞く「仕様書がなかった時代」から切り出しました。開発チームは5人前後で、開発期間は半年間。特定のゲームデザイナーは存在せず、全員で仕様を考えながら、スクラッチ＆ビルドを繰り返す・・・というやり方です。ある意味で牧歌的な時代であり、芳賀氏は「ファミコンの頃はこうした開発スタイルだったのではないか」と説明します。もっとも、現在でもインディゲームデベロッパーや、ゲームジャムでの開発でこうしたスタイルは息づいています。
紙の時代（1999年ごろ）
続いて時代はガンバリオン創業期（1999年8月）に移りました。開発チームは10人程度で、開発期間は半年から1年。ゲームデザイナーという役職が誕生し始めましたが、まだまだアーティストとプログラマーが企画と仕様作成を兼任していた時代です。プラットフォームはPS1で、同社でいえば『FromTVanimation ONE PIECE グランドバトル！』の頃となります。
講演で紹介されたのは実際に使われていた、キャラクターのアクション設定に関する仕様書。キャラクターの技の一つひとつに関する動作が、すべて手描きで説明されています。当時のアーティストはこのイラストを見ながら、技モーションを一つずつ手付けしていきました。仕様書はA3で作成され、手描きのイラストを縮小コピーして張り付け、最後に再度コピーして完成。最終的にファイルしてまとめられます。
芳賀氏は仕様書の作成目的は担当者間の意思疎通がメインで、口頭によるコミュニケーションを補完するために作成されており、それ以外の人が読むことは考えられていなかったと語りました。そのためデバッグや外部資料への活用、次回作での参照などの再利用がしづらかったと言います。また、後に全員が読める形にファイリングされていきましたが、単純にかさばるので取り扱いも一苦労でした。
Excelの時代（2004年ごろ）
仕様書が紙からExcelベースに変化したのが2004年頃で、プラットフォームはPS2、GBA、ゲームキューブといったあたり。開発チームは20～40人程度で、開発期間は1年～1年半。この頃になるとゲームデザイナーの役職が確立し、チームに3～4人が常駐するようになります。またアーティストもモデル、モーション、エフェクトなど、分業が進んでいきます。
イメージとしては紙のフォーマットを、そのままExcelで再現した形です。手描きのイラストなどがスキャンして取り込まれ、張り付けられています。ファイルは仕様書項目毎に用意され、HTMLで目次ページを作ってサーバ上にまとめてアップされます。きっかけとなったのはドット絵の作成を協力企業にお願いするケースが増加したこと。仕様書のデジタル化が必須となり、ほぼすべての項目で作成されるようになったのです。
これにより作業フローも変化しました。格闘ゲームでキャラクターを作成する場合、紙時代はゲームデザイナーとアーティストが打ち合わせを行うと、後はゲームデザイナーの手を離れていました。アーティストが手描きで仕様書を作成し、モデルなどのデータを作成して、プログラマーにデータをわたし、組み込みを行ってもらっていたのです。その結果をゲームデザイナーが確認し、バランス調整を依頼して完成となります。
これがExcel時代になると、ゲームデザイナーがキャラクターの性能や動きを検討し、Excelで仕様書のたたき台を作成。その後ゲームデザイナーとアーティストが細部を調整し、仕様書をブラッシュアップします。その後、仕様書にもとづいてアーティストがデータを作成し、プログラマーが組み込むと、ゲームデザイナーが中心となってバランスを調整します。仕様書と共にゲームデザイナーの役割りが増加したのです。
もっとも芳賀氏は「作りやすいが検索しにくい仕様書になっていた」と振り返ります。書式ルールがあいまいで、人によっては無駄に時間をかけて豪華な仕様書を作っていたことも。芳賀氏もよく「凝り過ぎだ」と注意されたそうです。また仕様書の中に別の関連仕様が紛れ込むなど、全体像がわかりにくい状態に。総ファイル数も1プロジェクトで300近くに増加していたといいます。
wikiの時代（2014年ごろ）
こうした問題を解消するためにトップダウンで改革を実施。社内サーバにMediawikiを立て、wiki上で仕様書を作成・運用されるようになりました。wikiの書式を使用した結果、見出しやフォーマットが統一。仕様書はすべてトップページからリンクされるようになり、ツリー構造の親子関係もルール決めされた結果、「編集や閲覧の手間が目に見えて改善した」（土井氏）といいます。
ちなみに開発チームは外部スタッフも含めて50～70人程度。開発期間は1年～1年半で、ゲームデザイナーはアシスタントも含めて4～6人程度に拡大しました。作業フローは大きく変わらないものの、ゲームデザイナーとアーティストの打ち合わせや仕様書作成の手間が簡便化。アーティストのモデル作成やプログラマーのデータ組み込みも、仕様書の閲覧が簡素化されたことで、作業効率が向上しました。
「このほか、念願の検索機能も実装されました」（土井氏）。もっとも表記ゆらぎが発生すると二度手間になるため、類似ワードや禁止ワードをデータベースに登録し、リアルタイムにポップアップウィンドウで警告を発するなどの工夫も行われています。議事録や関連資料などもwikiに一元化。仕様の進捗具合も色でわかるようになっています。なおパラメータ管理などはExcelで行われ、wikiからリンクがはられています。
もっとも芳賀氏は課題点も残っていると分析しました。図や画像の追加・編集がwikiだとやりにくく、特にシーケンス図などの作成で手間がかかることです。そのためクリップボードから直接画像をwikiに張り付けられないか検討が行われています。仕様が複数の場所で大幅に変更になった場合、更新や告知に労力がかかる点もネック。仕様を外部に出しづらく、現在はpdfに出力して渡しているものの、一苦労だと言います。
そしてなにより「単純に量が増えた」こと。読むだけで大変で、特に途中から合流したスタッフには厳しい文量だとのこと。実際に読み漏らしも多いそうです。Excel時代に比べると低下したものの、仕様書作成のコストがまだまだ高いのも課題点。プロジェクトのたびに同じことを描かなくてもいいように、会社で共通化できる仕様を作って、使い回すなども検討したいといいます。
通常こうした効率化が必用な分野ではツールやミドルウェアが登場するものですが、自分が知る限り海外でも聞かれません（タスク管理システムやアセットマネージャと組み合わせて、包括的なシステムができそうな気もしますが・・・）。いずれにせよ芳賀氏が「みんなで手の内を明かして、仕様書の作成＆管理を高めましょう」とまとめると、大きな拍手が巻き起こりました。さらなる議論の進展に期待したいところです。
