エントリー
採用情報
社員の声
プロジェクトの流れ
運用フェーズ
- プランナーM
- 2016年入社。多くのタイトル運営と若手教育をこなす。プランナー職最初のメンバー。2児の父。
- デザイナーK
- 2020年入社。デザイナー長。デザイナー全体の管理も担当しており業界歴は当社メンバーで最も長い。
- プログラマーT
- 2019年新卒入社。主に運営担当。入社3年目。黙々と作業をしつつ意見も発信できる。本当に野菜が苦手。
- 管理部T
- 2022年度新卒入社。大学では経済学を中心に、マーケティングや統計、データ分析を学んだ。好きな食べ物はお菓子。
また明日も遊んでもらえる
コンテンツを届けたい
- 運営フェーズとは何をするのでしょうか
- デザイナーKプランナーから上がってきた改修案に沿って作業を行います。良くあるのがUIの改善改修、イベントやコンテンツの追加などです。ユーザー獲得の面ではアプリアイコンの変更や広告制作なども行います。広告などのユーザー獲得に関する素材追加作業はアプリの勢いがあればあるほど増えていく傾向にありますね。
- プランナーM具体的なKPI項目は伏せますが、これらの値を改善できるような施策を考え、提案検討し、開発チームに工数確認などを行いスケジュールを立てていきます。また、機能の追加やユーザー様からのご意見を元に改善を進めていく事が多いです。担当プランナー以外からも改善案をもらったり他部署からのレビューを参考にしたりもします。
- プログラマーTプログラマーもデザイナー同様で改修案に沿って作業を行います。追加機能の場合は新規開発同様の流れになる事が多いですが、改善目的の場合はどういった意図でユーザー様にどんな体験を提供したいかを共有し取り組むようにしています。初めてインストールした方向けなのか、既に遊んで頂いている方に向けたものなのかなど、作業の目的によって何を要求されているのかを同じ視点で理解する事が大事だと思います。何よりも不具合をださず安定したゲーム体験をしていただく事が一番重要ですね。
- 管理部T管理部は基本的にリリースタイトルの収益パフォーマンスの向上をおこないます。広告収益面の最適化、集客のパフォーマンスが主です。実際の作業としては毎日の数値変動を見て施策を行い、更にその数値変動を見て・・・と日々改善できるよう同じ事を繰り返している感じです。対象タイトルや時期、競合他社の動きなどで再現性は無い事が多いので同じ事をやっていはいるけど対策や結果がいつも違います。
- 更新の流れを教えてください
- デザイナーKプランナーから更新概要を共有してもらい、内容の落とし込みと工数出しをして、更新日のスケジュールを決めて着手します運用におけるデザイン業務は、拡張や追加対応が多いので、既存のフォーマットに合わせた制作が多いです。
- プランナーM新規開発の時の流れに近いのですが、更新案作成→仕様作成→スケジュール調整→更新作業依頼→デバッグ→更新、大まかですがこういった流れになります。基本的に更新案は複数やりたい事があるのが普通で、更新作業を同時に進める事が多いです。なので進捗を確認しながら次の更新はここまでの機能や改修を入れよう、とかの調整になります。
- プログラマーT上がってきた内容をデザイナーとどんなスケジュールで進めるか決め、更新日程が決まってきます。急ぐべき更新内容を先に反映させるか、キリの良いところま反映させるかなどはプランナー判断にはなりますが、その判断材料になる情報をできるだけ渡すようにしています。渡す前にプログラマー内では、案をどう実現するのか、目標期間で開発可能なのか、既存の仕様と干渉して問題を起こさないかなど多方面から考えます。更に次々回や先々で、「こういう機能入れる予定、こういう変更する」が分かっていればそこも加味した設計にした方がいいので結構先のイメージ像をもとに設計を進めます。
- 管理部T管理部の方で流れは特になく、タイトルの更新に合わせて広告関係の更新や効果測定の為のツールの実装依頼をする事があります。タイミングを見計らう事が多いので今どんな更新作業をしているのかはチェックしていますね。
- 更新はどれくらいの頻度で行っていますか
- デザイナーKプロジェクトによりますが、サイクルが早いものは毎月対応を行っています。頻度低いものもあるので結構バラバラですね。複数タイトルに関わると更新作業自体はその分増えるので人によっても変わります。
- プランナーMユーザー様が多いタイトルやリリースしたばかりで集客が活発なタイトルは頻度が高くなる傾向ありますね。更新してそれが良かったか悪かったかの反応を貰いやすいっていうのが分かりやすいですしね。あと、どうしてもビジネス的な優先順位はあるので全てのアプリが一定の周期で更新するとはなりません。売上げが高ければ頻繁に、そうでないものは最低限、という感じでしょうか。
- プログラマーT体感的に更新頻度は1～2か月に1回程度のことが多いように感じます。ただし開発規模の大きい更新を行う場合に長めに期間が空いたり、反対にリリース直後のアプリに対して柔軟に対応するためにもう少し短い頻度で更新する場合もあります。複数タイトルにアサインしていると更新時期が近かったりする事があるんでそういう時のスケジュール管理は慎重になりますね。
- どのような方法で改善点を見つけ出していますか
- デザイナーKよくやるのが、ベンチマークタイトルをやりこんだり近いイメージのタイトルに触れて自社のものと比較をします。良く見えるのはなぜか、どうしてこのような印象になるのか、など研究をしてくようなイメージです。
- プランナーM数字でしっかり現状把握をし、自分の直感も併せて判断しています。直感は大切にしています。自分の直感は出したゲームの数値から調律していきます。そして最終ジャッジは直感で行うほうがいいと考えています。声のでかい人の意見より数字の方が正確に評価してくれるし、それ以上に自分の直感を信じて作り続けます。
- プログラマーTまず第一に自分がプレイヤーとなり、気になる点を探します。ベンチマークアプリや自分が遊んできたゲームなどを参考に、違和感を持つ部分や欲しくなった機能などを洗い出します。また、プレイデータを見て使用されている機能と使用されていない機能を分析したり、機能毎の実行時間を見て処理を軽くできる部分の検討を行ったりもします。
- 管理部Tアプリの改善目線ではなくビジネスとしてのパフォーマンス目線の改善をしますので、毎日の数値チェックしかありません。前日と比較するのか先月なのか去年なのか。他には国別タイトル別など比較対象は多岐に渡ります。全部毎日照らし合わせるのは大変なのである程度アタリを付けたり、経験から患部を探すような考え方はしていると思います。やったことの無い改善方法を試す事もあるので現在の状況分析する事だけでなく発想力が必要なんだな、という実感があります。そして常に様々なツールがリリースされたり、使っているツールの機能追加があるので情報をアップデートし続けなければいけないですね。
エントリー
