アプリ開発でのプランナー役割紹介
目次
はじめに
はじめまして、アールフォース・エンターテインメント(以下アールフォース)でプランナーをしています袖ヶ浦です。
アールフォースでは「ユーザーストーリー重視」「ユーザードリブン手法」*1という考えを大事にし、常日頃お客様重視で企画をつくっています。
そんな企画をつくる仕事プランナーについて本記事では、意外と知られていない(?)プランナーの仕事内容をアールフォースではどのように行っているか、その一部をプロジェクトの開発フェイズに合わせて簡単に紹介していきたいと思います。
またゲームプランナーの仕事は会社やプロジェクト毎に役割範囲や業務内容が異なることが多分にありますので、1つのモデルケースとしてこんなことやっているんだなぁと思って読んでいただけると幸いです。
開発フェイズ毎に異なる役割
ゲーム開発ではプロジェクトの進捗具合によっていくつかの開発フェイズに分けられます。 よく聞くα版やβ版、最近ではプリプロダクションやバーティカルスライスといった各フェイズが存在し、プランナーも基本的にこの開発フェイズに合わせて様々な役割を順次遂行していくことになります。
①プロジェクト化以前及び初期段階
- プランナーの役割:「企画書」の作成、そのプレゼンテーション
- キーワード:企画書、プレゼンテーション、ターゲット、ペルソナ、コンセプト
- ワンポイント:書類のまとめ方やテンプレは書籍やネットに参考が複数存在するので、まずは企画内容に合った形式を真似してアウトプットに慣れていこう
まずゲーム開発初期段階では、どんなゲームをつくるのか?ターゲットは誰か?どの位の売上が見込めるか?などを調べ思考し企画書としてまとめます。 プランナーと聞いてよくイメージされる仕事がこちらです。
弊社では業種問わず定期的に企画コンペを行っており、意見交換やレビューを行い、そこからプロジェクト化となる機会もあり、アイデア次第で夢の企画が通るかもしれない非常にやりがいのある仕事でもあります!
作成する形式については多種多様ではありますが、主にPowerPointやGoogleスライドなどのプレゼンテーションツールで作成されることが多く、ここでは物事をシンプルに分かりやすく伝えられる様に文字だけでなく図やイラストを用いて読み手に出来るだけ伝わるように心がけています。
②α版開発
- プランナーの役割:「仕様書」の作成、その運用、説明
- キーワード:仕様書、コミュニケーション、常に更新、共有連絡
- ワンポイント:確定仕様に更新があったら関係者に連絡を入れ、認識のズレを解消しよう
ゲームをエンジニアさんに実装してもらう為に、企画書を元に、より詳細を記載したゲームの設計図とも言える仕様書をまとめます。 仕様書は各画面でどんな機能がどう動くかを明記した資料になります。 大規模なゲーム程仕様書自体のボリュームが大きくなる為、機能や画面毎に仕様担当者も割り振りを行い、インゲームやアウトゲーム担当、強化成長画面やガチャ画面担当などに分け作業を行います。
また各機能を仕様化するにあたり、エンジニアさんと実装の可否や手法の相談、デザイナーさんとUIとしてどう見せたら良いかの相談などを密にこなすことで仕様としてのクオリティアップは勿論のこと、 各セクションにスムーズな作業進行をもたらすことができる為、プランナー採用で求めるスキル欄に「コミュニケーション能力」や、あると好ましいスキル欄に「プログラミングやデザインなど別セクションの知識」が書かれていることが多いです。
こちらも主にPowerPointやGoogleスライドなどのプレゼンテーションツールを用いて書面化されています。
この仕様書制作業務はゲームプランナーの仕事でも比較的大きな割合を占めている役割になります。
③β版開発
- プランナーの役割:ゲームデータの設定、及びその調整
- キーワード:レベルデザイン、ゲームサイクル、成長曲線、報酬設計、マップデザイン
- ワンポイント:型をつくることで、修正、量産の手順をできるだけ省こう
仕様が固まったら次にキャラクターの強さやステージの構成、ミッション内容といったゲームの各パラメータを入れていきます。 レベルデザインともいわれる部分で、ここの設定をミスると折角今までつくったものがパーになってしまいかねない大事な部分になります。 マスターデータと呼ばれるデータをまとめた専用参照シートを用いて、プランナーが各自設定したHPの上限値などの値を入力していくことでゲームに設定されていきます。 アールフォースでは最近GoogleSpreadSheetを使用してマスターデータの管理運用を行っています。
ポイントとしては数値の出し方は決して感覚値だけに頼ることなく、参考としている他ゲームの場合はどうであったかや、他機能との関係性を総合的に鑑みつつ計算式や曲線などを用いつつ出来るだけ型にはめた上で調整していくことで、狂いの少ないデータをつくっていきます。
この工程もゲームプランナーの役割では非常に大きな割合を占めています。
④テスト期間
- プランナーの役割:ゲームバランスの調整
- キーワード:テスト、デバッグ、QA
- ワンポイント:テストにしっかりと時間を割き、ゲーム全体を見渡そう
仕様実装が完了し、データ入稿後はゲームが意図通りに仕上がっているか、プレイしていて本当に面白いかをリリースする最後まで確認していくことになります。 各機能とデータが全て揃うことで今まで想定していなかった問題や発見が様々な部分で大小出てくる為、QAさんと連携を取りながら仕様バグの修正、データの再チェックなど行います。
またこちらフェイズ上③のΒ開発と分けましたが、データ調整やテスト作業自体は上記③から常に行い、トライ&エラーを繰り返し、よりよいバランスに仕上げていきます。
⑤リリース後運用
- プランナーの役割:イベント制作
- キーワード:イベント、KPI
- ワンポイント:開発時から運用を意識したデータつくり、機能設計を行い、テンプレ化しておこう
無事リリースを迎えた後は、運用フェイズに入ります。 プランナーとしては、イベントの開催に合わせ上記の③データの設定と④バランスの調整を各イベント毎に行っていくことになります。 イベント制作も近年ではハロウィンやエイプリルフールをはじめ、各社が季節に合わせたこだわりのイベントを提供するのも恒例となってきており、プランナーの腕の見せ所でもあります。
またリリース後は計測したKPI、お問い合わせされる内容、SNSなどの動向を元に、ユーザーが何を求めているのか?どこに不満をもっているのか?どうしたら売上を上げることができるかなどを、 適切に分析し対応していくことで息の長いサービスを提供していくことを目指します。
とあるプランナー1日のサイクル
ここでは実際に出社してから退社するまでのプランナー1日の動きを、少しだけ紹介したいと思います。
仕様書作成期間中の1日の例
- 10:00~11:00:業務開始の1時間は、メールやチャットのチェックや前日タスクの進捗確認、今日の作業予定の洗い出しなどを行います。ここは基本どのフェイズやプロジェクトでも変わりません。
- 11:00~13:00:機能Aを仕様書にまとめます。事前に必要な資料などはまとめておき、大枠から詳細へと仕様を固めていきます。
- 13:00~14:00:お昼休憩です。仲間と外にランチに出かけたり、コンビニ弁当を買い、YouTubeを流しつつイベント周回をして休憩します(笑)
- 14:00~15:00:午前にまとめた機能A資料を元に、プランナーチームで仕様打ち合わせを行いレビューや意見交換を行います
- 15:00~16:00:打ち合わせで上がった要望や矛盾や不整合を修正し、資料に再度落とし込みます
- 16:00~18:00:Aとは別の機能Bを仕様書にまとめます。
- 18:00~19:00:チーム単位で簡単な進捗報告会をデイリーで行い、情報の共有を計ったり、今後のスケジュール調整を行います。
このように扱う資料やデータが違うだけで、普通のサラリーマンと取り分け特別なことをしている分けではありません。 1つ1つの機能や設計、データに対してお客様にどう感じて欲しいのか、どうしたら喜んで貰えるかを丁寧に考え、 最終的に最高のゲーム体験を届けられるように、日々我々も勉強しながら取り組む毎日です!
おわりに
ということで今回は開発フェイズ毎のプランナーの役割と、1日のサイクルについてざっと簡単に説明していきましたがいかがだったでしょうか?
企画書つくりだけではないプランナーの役割を少しでもお伝えできていれば幸いです! 次回のプランナー記事では実際のテクニックやノウハウなどを交えて、もう少し細かく紹介していきたいと思います。
ここまで読んで頂きありがとうございました。
*1:ゲームの画面や機能、システムに対してユーザーに「どう思ってもらいたいか、どう遊んでもらいたいか」ということを意識すること
アールフォース流!Unityチーム開発 ~アーキテクチャ編~
目次
はじめに
はじめまして、アールフォース・エンターテインメント(以下アールフォース)でエンジニアをしております波多野です!
今回はR-FORSCHOOLの第一回目のテック記事を担当させていただきます。
さて今回のテック記事のお題ですが、『アールフォース流!Unityチーム開発とは~アーキテクチャ編~』となっています。
ゲーム開発エンジンといったらUnityと言われるほどメジャーになりましたが、アールフォースでもUnityを使った開発がメインになっています。
そこでアールフォースではどのようにUnityを使ってチーム開発をしているのかご紹介していきたいと思います!
今回の記事では開発アーキテクチャについてご紹介します。
※このテック記事ではUnityの初歩知識を有していることが前提になっておりますのでご注意ください。
チーム開発で気をつけたいこと
Unityでの開発は自由度が高いです。
だからこそ開発時にしっかりとした開発ルールを定めなければ、各開発者が統一性のない開発を行ってしまいます。
その結果、
- 可読性の低いコーディング
- メンテナンス性の悪い実装
- 解決困難なバグが生まれる
といった開発に大きな影響を与えてしまうことがあります。
そこでアールフォースでは、より円滑にチーム開発を進めるためにどのような開発アーキテクチャでチーム開発を行っているのか、説明していきたいと思います。
主な開発アーキテクチャ
2020年2月現在のアールフォースのUnity開発では主にMV(R)Pパターンで実装を行っています。
MV(R)Pパターンとは簡単に説明すると一般的にMVPパターンとUniRxを組み合わせたアーキテクチャになります。 MVPパターンとは
- Model(データ ViewもPresenterも知らない)
- View (表示 ModelもPresenterも知らない)
- Presenter (ModelとViewの仲介役 ModelとViewを監視している)
に分けてプログラムを組むアーキテクチャになります。
概念図はこうなります。
UniRxは上記画像のModelの値の変更の検知に使用しています。
UniRxを追加した概念図はこんな感じです。
MV(R)Pパターンの詳細について記載していくと、それだけで記事が埋まってしまうので割愛させて頂きますが、実際にどのような感じでUnityの実装に落とし込んでいるのか説明していきます!
例) +10ボタンを押したとき、0の値が10ずつ加算されるSampleのMV(R)Pの実装例
/// /// @brief モデルクラス /// using UniRx; namespace RFORSCHOOL { /// <summary> /// モデルクラス /// </summary> public class SampleModel { /// <summary> /// カウント /// </summary> private ReactiveProperty<int> _count; /// <summary> /// カウントのプロパティ /// </summary> public IReadOnlyReactiveProperty<int> Count { get { return _count; } } /// <summary> /// コンストラクタ(初期化処理) /// </summary> public SampleModel() { _count = new ReactiveProperty<int>(0); } /// <summary> /// カウントを追加する /// </summary> public void AddCount(int count) { _count.Value += count; } } }
/// /// @brief ビュークラス /// using System; using UnityEngine; using UnityEngine.UI; namespace RFORSCHOOL { /// <summary> /// ビュークラス /// </summary> public class SampleView : MonoBehaviour { /// <summary> /// 加算するカウントの定数 /// </summary> private static readonly int AddCount = 10; /// <summary> /// 数字を表示しているテキスト /// </summary> [SerializeField] private Text _countText = null; /// <summary> /// +10ボタン /// </summary> [SerializeField] private Button _countUpButton = null; /// <summary> /// +10ボタンが押されたときのリスナー /// </summary> public Action<int> OnCountUpButtonClickedListener = null; /// <summary> /// 初期化 /// </summary> public void Initialize() { OnCountUpButtonClickedListener = null; _countUpButton.onClick.AddListener(OnCountUpButtonClicked); } /// <summary> /// +10ボタンが押されたときのイベント /// </summary> private void OnCountUpButtonClicked() { OnCountUpButtonClickedListener(AddCount); } /// <summary> /// カウントの切り替えが呼ばれる /// </summary> public void OnChangeCount(int count) { //カウント表示を切り替える _countText.text = count.ToString(); } } }
/// /// @brief プレゼンタークラス /// using UnityEngine; using UniRx; namespace RFORSCHOOL { /// <summary> /// プレゼンタークラス /// </summary> public class SamplePresenter : MonoBehaviour { /// <summary> /// ビュー /// </summary> [SerializeField] private SampleView _view = null; /// <summary> /// モデル /// </summary> private SampleModel _model = null; /// <summary> /// Start処理 /// </summary> private void Start() { Initialize(); } /// <summary> /// 初期化 /// </summary> private void Initialize() { _model = new SampleModel(); _view.Initialize(); Bind(); SetEvent(); } /// <summary> /// ViewとModelの紐付け /// </summary> private void Bind() { //Countの値に変更が入ったときにOnCountChangeが呼び出される _model.Count .Subscribe(OnCountChange) .AddTo(gameObject); } /// <summary> /// イベントを設定 /// </summary> private void SetEvent() { //+10ボタンを押したときのイベントをセット _view.OnCountUpButtonClickedListener = OnCountUpButtonClicked; } /// <summary> /// Viewから送られてきたカウントでモデルを更新する /// </summary> private void OnCountUpButtonClicked(int count) { _model.AddCount(count); } /// <summary> /// Modelのカウントが切り替わったときに呼ばれる /// 引数はModelのCountと同じものが返ってくる /// </summary> private void OnCountChange(int count) { _view.OnChangeCount(count); } } }
いかがでしょうか?
こちらの実装を概念図に当てはめるとこんな感じになります。
一見クラス数も多くなり、余計にややこしくなったのでは?と思う方もいると思います。
しかし各クラスに要素を分けることによって、作業者のコーディングに個性が出にくくなり可読性が上がり、拡張性も広がります!
それによって、コードのメンテナンス性が高まり開発速度も向上します!!
自由度の高いUnityチーム開発では、いかに各作業者の個性をなくすことが重要となります。
Model、View、Presenterと、役割を明確にすることで、バグが発生したときの早期発見、早期解決や新規機能の追加のしやすさに繋がります。
また開発アーキテクチャだけでなく、Inspector上からPrefabを操作したり、値を操作するときは[SerializeField]をつけるようにするなど、コーディング規約をしっかりと定めることも重要な要因となります。
終わりに
今回はMV(R)Pパターンの説明でしたが、これはUnity開発における一つの回答であって、正解というわけではありません。
開発の一つの手法として参考にしていただけると嬉しいです。
引き続きアールフォースの文化をガンガン発信していきますので、是非またR-FORSCHOOLに足を運んでいただけると幸いです。
ここまで読んで頂きありがとうございました。
アールフォース・エンターテインメント技術広報ブログ、始めました!
はじめに
はじめまして!
株式会社アールフォース・エンターテインメント広報担当です。
この度、皆さんによりアールフォース・エンターテインメントのことを知って頂きたいと思い、ブログを始めました!
会社での出来事に加え、月に1・2回のペースで弊社の現場社員によるテック記事も更新していきますので是非お楽しみに!
- アールフォース・エンターテインメントとは?
- R-FORSCHOOLって?
- なぜブログを始めたのか
- 今後予定している記事を少しだけご紹介
- 最後に
アールフォース・エンターテインメントとは?
株式会社アールフォース・エンターテインメントは日本国内大手パブリッシャーからの受託制作を中心に、333本以上のタイトルを開発している会社です。
そして2019年の8月には創立20周年を迎えることができました!
近年ではスマートフォンゲームの開発が多くなっておりますが、コンシューマーの開発経験はもちろん、今後はパブリッシングも行っていく予定です。
ちなみに画面に散らばっている緑の生命物体は弊社マスコットキャラクターの「Faun(ファン)くん」です。
R-FORSCHOOLって?
このブログのタイトルです!
株式会社アールフォース・エンターテインメントとスクール(学校)を混ぜてつくった造語になります。
「このブログをご覧いただいた皆様にとって学びの場になるように、また弊社社員にとっても【アウトプット、発信】の文化を創り積極的に学んでいけるように」 という想いから、運営チーム全員で考えました!
今年の5月、6月には弊社の現役社員による講演会も行う予定ですので、学校に遊びに来るつもりでいらして頂ければ嬉しいです!
なぜブログを始めたのか
前述したとおり、弊社は2019年に創立20周年を迎え、「新しいこと始めよう!」「挑戦していこう!」という目標をたてました。
そしてこの機会に、皆さんに弊社のゲーム創りや弊社で働く社員の魅力をお伝えしたいと思い、一念発起!ブログを始めることにしました!
広報からだけではなく、現場のエンジニア、デザイナー、プランナー、ディレクターなどなど様々な社員が発信していく場を作っていきますので是非、ご覧頂ければと思います。
今後予定している記事を少しだけご紹介
- アールフォース・エンターテインメントってどんな会社?(深堀バージョン!)
- プロの現場目線でみたUnity開発
- 社長に直接提案!「にこみ超会議」とは?
などなど様々な記事を月に3~4回のペースで更新していく予定です!
最後に
ここまでお読み頂いてありがとうございます。
まだまだ始まったばかりのブログですが、今後も頑張って発信していきますのでよろしくお願いします!
(良ければ「読者になる」等登録頂けると嬉しいです!)