ゲームプランナーの仕事ってどんな内容?元ゲーム業界人が解説します!【エンタメチャンネル】

ゲーム業界に就職したい人向け

筆者がこれまで経験した「ゲームプランナーとしての仕事」について、その内容はもちろん。楽しい点や辛い点、どういうことがあったのかを記載していきます。

ソシャゲ会社のゲームプランナーに限った話になります。コンシューマーゲームの会社とは多少違うかもしれませんが、似通った点は多いと思いますので参考までにしてください。

ゲームプランナーはなんでも屋?

職種の名称の通り、プランニングはもちろん行います。しかし、個人的な感覚では実際にプランニングを行うのは全業務内の30%にも満たないくらいの割合です。

主な業務内用はこのくらいあります。(一部です)

  1. 企画立案
  2. 仕様書作成
  3. 仕様書の調整/修正
  4. 多職種への発注/進行管理
  5. 工数管理
  6. クオリティチェック
  7. 動作チェック
  8. リリースチェック
  9. ユーザー動向調査
  10. etc…

これはあくまでも文字に起こしやすい業務内容の一部です。基本的に、エンジニアやデザイナーが行わないことを全て行います。

 

さらに、プランナーの仕事は、筆者としては社内営業だと思っています。企画をしたり、仕様を決めたりしても、実際に作るのはエンジニアやデザイナーです。多職種への発注が必須になってきますので必然的にコミュニケーションを取る機会が非常に多いです。

 

というより、1日中だれかと会話して終わることもあるくらい、社内で走り回ることになります。それでは1つずつ説明していきましょう。

企画立案

これは文字通りです。ゲーム内で新しい仕組みイベント課金要素など、プロデューサーやディレクターの意向を元に企画固めていきます。(立案と書いていますが、自主的に立案できる機会はほぼ皆無です)

基本的には、プロデューサーレベルの人が年間計画を作り、それを元にプランナーは企画をしていきます。

年間計画とは
1年の通して、ゲームをどのようにアップデートしていくのか。課金施策や新機能をどのタイミングで実装し、サービスとしてどのように運用していくか計画した内容になります。

ここでさっそく、プランナーとしては試練が訪れます。年間計画に記載されている内容が非常に曖昧なのです。

筆者が実際に体験した、ビックリした内容にはこんなことが書いていました。

「○○イベントのマンネリを改善」

ん?なにをしたいのかわかるけど、わからん…

こんな感じに具体的になにをしたらいいのかさっぱりわからない内容で記載されているのです。マンネリを改善したいのはわかるけど、課題感は?どういう方針で改善したいの?ざっくりマンネリにもいろんな種類ありますけど?

ここで社内営業が開始されます。プロデューサー(年間計画作成者)に具体的な内容を確認しにいく必要があります。どういう部分を改善したいのか。そのイベントのどの課題にフォーカスしたいのか。またどういう方向で改善したいのか。

方針にもいろいろあります。

  • イベント参加ユーザーを増加させたい
  • イベント完走率を増加させたい
  • 課金率/課金ユーザー数/課金額を増加させたい

などさまざまなアプローチの仕方があるのです。方針がわからなければ、企画のしようがありません。最低限、課題感だけあれば着手はできます。

プロデューサーへの社内営業、第一関門にして最難関の可能性があります。そもそも忙しい役職なので、当人を捕まえられないことが多いので、ストーカー並にスケジュールを把握し、空いている時間に突撃しましょう。

仕様書作成

さて、企画内容が固まればそれで終わりではありません。エンジニアやデザイナーが実際に制作に入るために、仕様書を作成しなくてはなりません。いわゆる設計図ですね。

ここにも様々な難関が存在します。

まず、すでに運用しているゲームであれば、既存の仕組みを理解しなくてはなりません。新規機能であれば、どの画面から遷移できるのか、既存のデータは使用するのか、似たようなUIは存在しないか。

さらに、他のプランナーの仕様と競合しないか、という点にも気をつけないといけません。同じ画面を同時に改修しようとしていた場合、大変なことになりますよね。同じ土地に違う人がそれぞれ家の設計図を作っているようなものです。

その部分にはAという機能を実装する予定なんですが…

えっ!僕の仕様書ではBという機能を実装するつもりなんですが…

現在の既存ロジックはもちろん、すでに動き始めている新規機能や改修にも目を配っていかなくてはなりません。
他のプランナーへのヒアリングも重要です。

さらに大変なのが、ユーザー体験がどうなるか、という設計です。

その機能を使った場合、どういった体験が得られるのか、どんな気持ちになるのかという点を明確に設計する必要があります。これがあるとないとでは、エンジニアやデザイナーの成果物に大きな差が出ます。

例えば、その機能は単純にユーザーが自分のデッキやアイテムを管理するものなのか、それとも「楽しい!」「気持ちいい!」と感じてもらうものなのか。その内容によってはデザイン面は特に大きく影響しますし、エンジニア目線であれば、データ通信速度、データ管理、画面レスポンスの速度などを考慮していく必要があります。

仕様書とは、それを見るだけで作業が完結し、モノが出来上がる状態であるのが望ましいです。ですが実際にはそのようなことは不可能です。プログラマー、デザイナーが作業に入った後に必ず壁が立ちはだかり、修正を余儀なくされます。

仕様書の調整/修正

実際に実装が始まった後に、必ずと言っていいほど発生するのが仕様書の調整や修正です。

運用年数が1年~2年たっていると、既存ロジックとの整合性を保つために、完成した仕様書通りだと実現できないことがあります。この場合、担当エンジニアやデザイナーと一緒に、どういう仕様に修正すれば問題ないかを検討しなくてはなりません。これも社内営業ですね。

さらに、すでに一度完成した仕様書に変更を加えるということは、偉い人の許可を取る必要があります。最初の仕様書が完成した段階で許可を取ったものになりますので「なぜ修正が必要なのか」「どういう修正を行うのか」という内容を伝え、許可をもらう必要があります。

この許可を出すのは基本的にディレクターですね。プロデューサーはそこまで細かい仕様までは管理しないので、ディレクターの元へダッシュしましょう。

この仕様書の調整や修正は、実装終盤まで発生します。なので、実装完了まで気を抜くことなく、担当エンジニアやデザイナーと密にコミュニケーションを取りつつ、進行していきましょう。

多職種への発注/進行管理

さて、ちょっと時間は巻き戻って、仕様書が一旦完成した段階のお話になります。

仕様書が完成し、偉い人の許可が取れた場合、担当になるエンジニアやデザイナーに企画内容/仕様内容を説明し、作ってくださいと依頼する必要があります。

基本的に仕様書を見るだけで完成まで持っていけるのが理想ですが、まぁ不可能なので仕様書を一緒に見ながら解説していきます。ボリュームにもよりますが、これだけで結構な時間を必要とします。

その後、仕様書に関する質疑応答や意見を聞くことになります。

ここで、新たな難関が立ちはだかります。

こういう仕様じゃなくて、○○みたいな内容のほうが良くないですか?

この画面構成だと、既存のUIと整合性が取れないの仕様調整してほしいです

まぁ、よくあることですね。特に「ゲームの面白さ」に直結する機能であれば、人それぞれ思うことはありますので、意見を聞きつつ、仕様書を調整していきます。

仕様書の1回目の完成は完成ではないのです。あくまでもプランナー内での完成であって、実装者込みの完成ではありません。社内営業の如く、意見をくれた方々と意見交換しつつ、仕様書の本当の完成を目指しましょう。

さて、実装者の意見も取り入れ、修正し、偉い人の許可も得た!これで実装に進められるぞ!というフェーズまで行くと、次は進行管理に回ります。

これは、実際に実装を進めていく中で、本当に仕様書通りに作られているかを常にチェックする作業になります。何度もすり合わせた内容でも、細かい部分で認識の相違があったり、そもそも勘違いしている場合も結構多いです。

作業状況どうですかね?大丈夫そうですか?

頻繁に行くと迷惑なので、頻度は調整しましょう。作業者も監視されているみたいでやりにくいですからね。

とはいえきちんとスケジュール通りに進んでいるかもチェックしないといけないので、最低でも1日に1回は進捗確認はしたほうが良いかと思います。

工数管理

工数管理とは、実際に作業する人たちのタスクと工数的に、スケジュール範囲に収まるかを常に確認する作業になります。

前述している通り、実装中にも仕様変更は発生します。変更後の仕様が、変更前と比べて2倍も3倍も時間がかかる内容であった場合、スケジュールが破たんします。さらに、最初に見積もった工数より、実際に進めていくと、思った以上に時間がかかることがあります。というか頻発します。

このタスク、3日で終わる想定でしたが5日かかりそうです。調整できますかね?

そういった場合、プランナーがその情報をキャッチアップして、仕様を削ったり、調整したり、もしくは増員を依頼したりします。基本的に「スケジュールを遅らせてでもやる」という判断はされないので工数管理と仕様調整は常につきまといます。めげずに頑張りましょう。

クオリティチェック

実装が進み、ある程度画面上で確認できるようになったり、デザイン素材が出来上がってくると、そのチェックをしていきます。最初のほうはデザインチェックが多いですね。

画面の構成やボタンデザイン、バナーデザインなど画像データのチェックは、基本的にデザイナーから依頼が来る場合がほとんどです。

バナー素材が完成したのでチェックお願いします!

ここで、こう思われる方も多いのではないでしょうか?

 

デザイン素材のクオリティは本職であるデザイナーのほうで担保してもらったほうがいいのでは?

一理あると思います。ただし、ここで言うクオリティチェックというのは仕様通りに作られているかユーザー目線で見た時に違和感がないか目的に沿った見栄えになっているか、というチェックになります。

仕様書作成者として、責任を持って、希望したものになっているか確認しなくてはなりません。プランナーは発注者ですからね。そこはしっかりやっていきましょう。

そして、ある程度プログラマーの実装が終わり、開発環境で実際のゲーム画面に組み込まれていったら、画面上でのクオリティチェックをする必要があります。

基本的には、画面の構成がデザイナーが作成したものと一致しているか、ボタンの触り心地や画面遷移に問題はないか、などです。画面構成はデザイナーが作成したモックに沿ってエンジニアが組み込んでいきます。

モックとは
どういう画面にするかサンプルとして画像化したものです。実際には、その画像を元にエンジニアが配置していきます。そのため、若干モックとボタンの位置がズレてしまう場合もあります。

また、画面遷移を挟むのであれば、それにかかる時間などの触り心地もチェックします。これに関しては触っていてストレスがないか、違和感がないか、という観点で見ていきます。

動作チェック

いわゆるデバックと考えてもらっていいです。デバッグとは、バグがないかのチェックになります。画面が多岐にわたっていると、細かい文字や色など、仕様書通りできない場合や、特定の操作をしたときに進行不能であったり、エラーが発生する可能性が高まります。

仕様書通りになっていないということは意外とよくあります。細かい文言など、1文字1文字仕様書通りになっているかしっかりチェックしましょう。

超細かい複雑な操作をしないと発生しないバグ等の再現性が低いものは、正式なデバッグ期間に見つかれば良いですが、その前にある程度正常に動くかチェックします。そもそもエラーで進行不可になっているとデバッグもできないですからね。

例えば、デッキを変更するボタンを連打したときに、正しく変更が反映されるか。課金ボタンを押した直後にゲームを落とした場合、課金処理が正常に行われるor中断されているか、などです。(どっちが正解かは仕様によります)

こういった想定しない操作をしたときでも、正しい動作になっているか確認していきます。

ここで問題なければ、一旦実装は完了となり、あとは正式なデバックとなります。これはデバッグ会社に発注していたり、社内のデバッグチームがやってくれたり会社によってまちまちです。

リリースチェック

さて、デバッグも無事終わり、いよいよリリースです。
実際にサービスとして稼働しているゲームに反映されます。この時、担当プランナーはリリース後に正常に動いているかを改めてチェックします。

よし、本番環境でリリースの確認ができたぞ!正常に動くかチェックしよう!

ゲーム以外でも多いと思いますが「開発環境では正常に動いていたのに本番環境では正常に動かない」ということが稀にあります。いろんなゲームで緊急メンテナンスが始まるのはこういったことが原因のことが多いです。

これは、サーバー構成の違いであったり、アクセス数の違いによるデータ通信の遅延などで発生します。本番環境では、数千人/数万人といったユーザーが使うため、予期せぬ事態はどうしても発生してしまいます。また、本番でしか確認できない部分も稀にあったりするので、プランナーはリリース後であってもしっかり確認する必要があります。

ユーザー動向調査

これは、リリース後の数日以内に行うことが多いです。

リリース後、ユーザーが新機能などを正しく使っているか評判はどうか、などを確認します。最近ではSNSでチェックすることが多いですね。人気タイトルであれば、まとめサイトに取り上げられたりもするので、そこのコメントなどをチェックすることも多いです。

また、案外開発側が想定していない使われ方をしたり、正しく使えていない場合もあります。そういった情報を集めて、その機能の課題点や改善点を精査し、今後に生かしていきます。

さて、以上でゲームプランナーの主な業務の流れは終了です。非常に濃いですね。

そして、常に誰かしらとコミュニケーションを取っていることがわかると思います。これが社内営業と呼んでいる理由です。

さらに、こういったものを2~3個同時進行で行っていくことが多いです。1プランナー1機能ということは、まぁなかなかないと思います。その機能のボリュームにもよりますけどね。

結論として、ゲームプランナーはゲーム開発において、エンジニアやデザイナーが行わないすべての作業を行います。そのため業務時間も長くなりがちです。また、コミュニケーションを取る機会が多いので、人と話すことが苦手な人は苦戦するかもしれません。

結構大変なんですよ?ゲームプランナーという仕事は。

そしてですね、今回記載している仕事内容は全体の60%ほどです。実際にもっと細かい雑務なども入ってくるので、もう修羅の道です。

それでも、ゲームが好き、自分の考えたモノを世に届けたい、ユーザーを喜ばせたい、という人はぜひゲームプランナーになると良いかと思います。

では、今回はこの辺にしようと思います。

最後まで読んでいただき、ありがとうございました!
これから書いていく記事も、よろしければ読んで頂けますと幸いです!

それでは、良いエンタメライフを!

コメント

タイトルとURLをコピーしました