▼前回までの記事はコチラから！
どうも、ぱいたん（@paitanblog）です。
桜のきれいな季節ですね。
どこかへお花見に行きたいなと思っていたら、体調崩したり雨が降ったりでチャンスを逃してしまった感があります。
しかし先日、近所のイオンに行ったとき、駐輪場に咲いている桜を見ただけですが意外と満足感のあるプチ花見ができました。
あいにくの小雨の中でしたが、サーッという軽い雨音で適度に物音が遮断され、その静けさの中で雨粒がついた桜を見るというのもなかなかにオツなものです。
いやー。
いいっすね、桜。
ただ、桜が満開の時期って、意外にすぐ終わっちゃうんですよね。
もう少し長めに期間とってくれたらいいのにと思います。
いかがでしょうか？
ご検討、よろしくお願いいたします。
（桜サイドへの強い要望）
さて本題！
ゲームプランナーのリアルな実務内容
今回はゲームプランナーについてまとめた記事3部作の締めとして、ここ最近で僕が実際に体験したリアルな実務内容から、プランナーという役割の実態についてまとめてみます。
プランナー志望の方は、ぜひ自分が思い描いているお仕事の内容と照らし合わせて、ギャップがないか確認してみてください。
【ちなみに】
開発の進め方は、会社やプロジェクトの規模によって異なる場合があります。
一例としてご覧ください。
開発初期～中期
プロジェクトの立ち上げからプランナーとして参加した場合は、プロジェクトの骨組みを作る仕事がてんこ盛りです。
何から何まで熟考しつつもサクサクと決めていくことが求められるので、かなりエネルギーが必要。
めちゃくちゃ大変ですが、ゲームの全体的な内容作りに自分が関わることができるため、プランナーの醍醐味でもあるところです。
ここを楽しめる人はプランナー向きだと思います。
（ちなみに僕は苦手です。0を1にするより、1を10にする作業のほうが好きなので。）
そんな開発初期～中期のプランナー業務として僕が経験したのは、超ざっくりとですがこんな感じです。
GDDの作成
GDDとは『ゲーム・デザイン・ドキュメント』のことで、ざっくり言えばゲームの全体像を記した資料のことです。
メインプランナー、あるいはディレクターを任されたプロジェクトで書きました。
GDDとは、仕様書のようなもの…という認識でいいと思います。
「ようなもの」という曖昧な表現にした理由は、GDDの定義は会社や書く人によってまちまちのようだからです。
一説には
- 書いてある通りに作ればゲームが出来上がるもの
- ゲームの全容を伝え、上層部から開発の承認を得るための資料
という場合もあれば、
- 企画書よりも内容は詳細で濃く、仕様書よりは若干大まかなもの
という程度でまとめる場合もあるようです。
僕の会社では、後者でした。
開発費用やスケジュールの算出を終え、いざ開発に取り掛かってから
・あ、ちょっと待って！
・まだここ決まってなかった！
・この仕様じゃマズイ！
・あ、こんな仕様も足していい？
・考え直すから待ってて！
・ぎゃああ間に合わない！！
という無駄やロスが発生しないようにするために、
- ゲームの全体の内容が固まっているかどうか、頭の中の再確認
- 仕様が破綻していないかの確認
- 何を作る必要があるかの確認
- 全体の作業ボリュームの確認
など、開発着手段階からしっかりと必要事項の確認を行うための資料、という定義でGDDを作りました。
これは、僕がGDD作成を命じられたときは開発着手までに時間が限られていたので、
『ゲームに含まれる要素が網羅されていて、メンバーが全容を共有できるGDDが早く必要！！ あとの詳細は仕様書として詰めよう！！』
という上司の判断により、仕様書と併用するタイプの簡易版GDDを作ることになったわけです。
（もちろん、この時点でもっと詳細な情報まで詰めたGDDが書けるなら、それが理想だし本来あるべき姿だと思います）
ただ、前者も後者も共通しているのは『これを読めば、ゲームの全体像が分かって、開発スケジュールが立てられる』ということです。
じゃあ、GDDとは一体どんなことを書いておく資料なのか。
僕が初めて書いたアクションゲームのGDDを例として、必要になった項目を抜粋してみます。
- 製品概要
- ストーリー／世界観設定
- ゲーム概要
- ゲームモード概要
- 一人用モード
- ゲームシーン概要
- ゲームサイクル
- プレイヤーキャラ詳細
- 必殺技
- 操作
- レベルアップ
- アイテム
- 画面イメージ
- ダメージ計算式
- マップ
- 敵キャラ
- 難易度による変化
- クリア後の周回要素
- 協力モード
- 対戦モード
- 図鑑
- オプション
- 画面遷移フロー
- サウンド
- 登場キャラクター
などなど。
それぞれの中身としては、キャラのステータス等の最終的に細かく調整するような数値を除いて
- マップの形状
- 必要なUI
- アイテムや魔法の効果、フレーバーテキスト
などなど、極力仕様書に頼らない情報量を心掛けて書きました。
（その結果、新たに仕様書として追加した情報はかなり少なくなりました）
これらをまとめたうえで、チームメンバーと打ち合わせをして、より詳細なイメージの掘り下げを行い、チーム全体の共通認識とします。
開発はGDDをもとにスタートし、各セクションで素材を作ったりプログラムを組んだりしますが、開発中に必要になる細かなパラメータの値やキャラクターのセリフなどは仕様書として別途作成しました。
最終的にはGDDから各仕様書にリンクを貼り、サイトのトップページのような運用をしていた気がします。
他社との打ち合わせ
僕の会社はデベロッパー（開発会社）なので、パブリッシャー（販売会社）や他の開発会社さんとの打ち合わせを行います。
仕様を担当する以外にも、チームを管轄する立場にあることも多いため、プランナーは打ち合わせに参加する可能性が非常に高いです。
まぁ打ち合わせの進行自体はベテランなり、デザインの打ち合わせならデザインリーダーがやったりしますので、新人の頃はそこまで気負わず安心してOKだと思います。
ただ、新人でも議事録担当になる可能性はあるので、会話の内容と要点をササッとまとめる力があると役立ちます。
あと、これはだいたいの仕事でも同様ですが名刺交換します。
これも緊張しますが場数を踏めば慣れてくるので、せめて最初だけは緊張していても教科書通りにキチッとできるよう準備＆意識しておきましょう。
アクションの案出し
ロボットのドラゴン、巨大な魚、全身を鎧で固めた落武者などなど、ゲームに登場するキャラの攻撃パターンやダメージモーション等の案出しです。
デザインが先行している場合はまだ想像しやすいですが、アクション案からデザインを起こす場合はなかなかに難しい。
それがシステム的（あるいはデザイン的）にゲームで表現できるのかはもちろん、そもそもそれがゲームに入ることで面白くなるのかも考慮しておく必要があります。
この作業だけで言うならば、アクションの参考になりそうなゲームを遊んでみるだけでなく、たとえば動物園やロボット博物館などで様々な動きを観察して『人間的ではない動き』に関するアイデアの引き出しを増やしておくと役立つかもしれません。
実装作業
基本的にはデザイナーがキャラクターにモーションを付けたり、実際にゲーム画面に映し出して動きを調整したりするのですが、
Unityを使ってマップにコリジョンを配置したり、攻撃モーションの組み込みをしたりといった実装作業を、プランナーが行うこともザラにあります。
僕の場合は、敵とエンカウントする判定（コリジョン）の配置、モブキャラクターの配置やフラグ設定、アドベンチャーゲームの会話イベントのスクリプトなどを実装してきました。
実装作業の中にはデザイン的な要素が強いものもありますが、デザイナーの手が足りない時などは担当することが多いです。
僕はデザインセンスが無いほうなので不安でしたが、しばらく設定をいじっていると、意外となんとかなります。（経験者・談）
サウンド発注
社内にサウンドクリエイターが不足している場合、サウンドを外部に発注することになります。
ゲーム内で使用するBGM、SE、ボイスのリストを作成するのも、基本はプランナーが頑張るところ。
まだ完成していないシーンを想像しながら、必要な音を洗い出します。
たとえばBGMだと使用箇所のイメージや曲調のニュアンス、尺、ループの有無などを決めておく必要がありますね。
ちなみに、サウンドの組み込みもプランナーが担うことが多々あります。
プログラマーが少ないプロジェクトだと、プログラマは機能の実装（あるいはバグ潰し）で常にヒーヒーいうことになるので、スクリプトの書き方さえわかればできる内容はプランナーが担うことになりがちです。
開発後期
開発後期は、大半の仕様も固まっている（はず）し、デザイン素材も出揃っている（はず）状態です。
なので、プランナーやデザイナーの人数が多いプロジェクトだと、支障のない範囲で他のプロジェクトにヘルプとして駆り出されることがあります。
そんな開発後期、仕上げの時期になるとプランナーが担当する業務はこんな感じです。
調整作業
- キャラのステータス
- アクションのフレーム数
- 敵の出現率
- アイテムのドロップ率
- 移動速度
などなど、ゲーム内のあらゆる値をいじりまくります。
これによってゲーム全体の難易度が大きく変わるので、ここまでに組み上げた『面白いゲーム』を『本当に面白くする』ための超重要な作業といえます。
簡単すぎてもダメ、難しすぎてもダメ。
ここで手を抜くと、今まで頑張って作ってきたゲームが一気にクソゲーと化して世に出るという、最高に萎える結果になります。
プランナーとして、最後の見せ場といっても過言ではないでしょう。
ちなみにこの作業、算数がそこそこできないと結構苦労します。
僕は小学生の頃からずっと算数＆数学が苦手だったのですが、当時はそこまで深刻な問題だと思っていませんでした。
「分数とか確率とか、どうせ実生活で使うことないし！」と。
しかし、キャラの成長曲線やダメージ計算を考える必要に迫られたとき、脳内にある理想を実現するための計算式がまったく思い浮かばず、めちゃくちゃ苦労します。
仕方なく数字に強いプランナーに助けを求めますが、結局は自分の中で消化しきれてないのでモヤモヤ。
どんなに複雑な計算でもExcel先生さえいれば安心ですが、計算式そのものがわからないとお手上げなので……。
デバッグ
社内でデバッグをやる場合、プランナーはデバッガーと化します。
フラグチェック、通信チェック、さらには思いつかないような特殊状況でのみ発生するバグ等を徹底的に探し出します。
何度かやっているうちに怪しそうなところに気づく『探偵の勘』的なものが磨かれてくるとはいえ、『なかなか出ないバグが、絶対出なくなったことを確認する』という、ゴールに到達したかどうかすらわからない苦行です。
今まで経験したすべてのプロジェクトでデバッグをするたび、プロのデバッガーとしてお仕事をしている人たちの並々ならぬ精神力に尊敬の意を表します。
本当に感服です。
今回のまとめ
だいぶ端折った感はありますが、僕が印象に残っているものを中心に、ゲームプランナーのリアルなお仕事について触れてみました。
他にも仕事はたくさんありますので、そのうち気が向いたら別の機会に書いてみます。
ゲームプランナーについて何か知りたい内容のリクエスト等あれば、気軽にコメントで教えてください。
さて。
ここまで読んでいただければわかる通り、『おもしろ企画を考えて、それを作るための指示を出す人』ではないのがプランナーの難しいところです。
プログラムも組めなければ、絵も描けない。（もちろん例外あり）
管理者であり、作業者であり、全知全能の雑用係。
そんな特殊なポジションにおいて、やはり求められるのは『人間力』だと思っています。
チームメンバーどうしを繋ぎ、全員が滞りなく仕事を進められる環境を作り上げる。
社交性、忍耐力、交渉力、説得力、人柄、人生経験、その他もろもろ。
これらを常に磨きながら生きてきた人間がおさまる、夢いっぱいの超現実的なポジション。
技術云々の前に、気持ちでチームを引っ張る苦労人。
それがゲームプランナーという職だと、僕は思います。
（もちろん、ちょっとアレなプランナーも山ほどいるでしょうが）
理不尽なことも、苦しいことも、つらいことも、泣きたくなるようなことも、たくさんあります。
むしろ、そのほうが多いです。
いろんな人と仕事をするって、そういうことです。
毎日、かなりしんどいです。
感動や喜びを感じる瞬間なんて、ぶっちゃけ数か月に1回程度のものです。
でも、必死に食らいついて頑張っています。
プログラマーとデザイナーさえいればゲームを作ることはできることなんて重々承知のうえで、
「プランナーがいてこそ、面白いゲームが、しっかりと完成するのだ！」
というプライドを持ちつつ、日夜戦っています。
これを読んでいる、ゲームプランナー志望の皆さん。
夢と理想はそのままに、生きてきた中で最高の、並々ならぬ覚悟を決めてゲーム業界に飛び込んでください。
間違いなく、100％、必ず、絶対に、つらく厳しい戦いになります。
でも、ひとつゲームを作り終えたとき、努力が報われたとき、きっと想像以上の感動が押し寄せます。
僕がそうでした。
体験談です。
ゲームプランナー、最高にクールです。
あなたも、是非。
