これは ドリコム Advent Calendar 2019の6日目です。
5日目は kyoji_hata さんによる、ブログKPI取得のためのデータを自前で集積・計測する方法 です。
どうもこんにちは、ドリコム新卒7年目の てらこ と申します。
enza というHTML5ゲームプラットフォームの開発プロジェクトで 企画メン をやらせていただいております。
最近は Google STADIA をはじめ 様々なゲームプラットフォームが勃興し、再びプラットフォーム群雄割拠の時代になってきました。
今回、私からは「ゲーム開発」から「ゲームプラットフォーム開発」への異動という、近いような遠いような異動で感じたことについてお話しさせていただこうと思います。
その異動って苦労するもんなの？
ていうかプラットフォームの企画って何やってるの？
という疑問にお答えできれば幸いです。
一言で言うと「リッチなブラウザゲームが遊べるプラットフォーム」です。
まずは enza.fun にアクセスし、好みのゲームを遊んでみてください。
アプリやソフトウェアのインストールは必要ありません。
全てブラウザ上で動作します。
私の所属する enza開発チーム は、このサービスのプラットフォーム部分の開発・運用を担っています。
例えば…
といった機能を、どのゲームでも使える共通機能として提供しています。
露骨な宣伝はこの辺にして、本題に移りましょう。
2013年にドリコムに新卒入社。
ブラウザゲームの運用チームに配属されたのが、ゲーム企画メンとしての人生の始まりでした。
GREE と mixi プラットフォームで展開していた、ポチポチゲー系のブラウザゲームです。
enza のHTML5ゲームと当時のゲームを比べると、随分と進化したものです。
その後、会社のネイティブシフトに伴って
いくつかの ネイティブアプリの開発・運用に携わってきました。
オリジナルタイトル・IPタイトル合わせ、
世に出なかったタイトルも含めると 5タイトル ほどでしょうか。
そんな生活が5年ほど続き、ある日 転機が訪れたのです。
経緯については話すと長くなりますが、今回は転生のお話ということで体裁上
隕石に当たって死んだ ということにしましょう。
気が付くと私は、
enzaのプラットフォーム企画メン として生まれ変わっていたのです！
リリース前に想定していた状況と、リリース後の状況の乖離に四苦八苦していました。
新規ユーザーの獲得単価であったり、継続率であったり、課金率であったりと、
ゲームのリリースに関わったことのある方なら誰もが経験のある状況かと思います。
そんなenzaに配属され、心機一転 プラットフォーム企画メン として仕事を始めたのですが、意外な壁にぶち当たりました。
それは、
異動して新しいチームに来た時、キャッチアップできるまであまり仕事がないというのはよくあることです。
しかし、ここでいう 仕事が無い というのはそういうことではなく、
同じサービス運用でありながら、ゲーム運用でやっていた仕事がほとんどないのです。
ゲーム運用なら当然あるはずの膨大な運用仕事がほとんど無く、
アップデート開発だけが走っている、そんなプロジェクトでした。
俺は何をすればいいんだ！俺の仕事はどこだ！私は誰だ！
それがプラットフォーム企画メンに生まれ変わった、最初の一ヶ月でした。
※あくまでゲーム企画メンと比較しての話です
1ヶ月も経つ頃にはそれなりに忙しくなりました。
プラットフォーム企画メンの仕事はだいたい以下の通りです。
ゲーム共通機能の企画・開発進行
これがメインです。
登録や課金といったゲームに組み込まれている共通機能や、
コミュニティなどのポータル機能の開発です。
プラットフォームKPI の改善企画
enzaメンバーの登録率や、課金フローの突破率といったプラットフォームならではのKPI を改善する仕事です。
デベロッパー支援の企画・進行
デベロッパーからいただいた色々な要望に応える仕事です。
キャンペーンの企画・進行
課金時にポイントを還元したり、ゲームのリリース記念キャンペーンなどを開催する仕事です。
この仕事が一番、ゲーム企画メンの仕事に近いかもしれません。
スクラムマスター
これは企画メンというよりスクラムマスタースキルを持っている人ですが…
enza開発チームは 5～10人程度の小さなスクラムチーム の集合体であり、チーム毎にスクラムマスターがいます。
ちなみに、デベロッパー開拓については私の所属する開発チームではなく、別のチームが担当しています。
せっかくなので、その一端を紹介していこうと思います。
KPI 分析
ゲーム企画メンは日々様々なKPI に触れ、分析し、それを元に施策を立てていく生活をしています。
そんな日々を続けていくうちに、何となく数字の「肌感」がつかめるようになっていくものですが、
プラットフォーム企画メンは見ているKPIがゲーム企画メンと全く違います。
例えば、ゲームの運用だと「課金率」が重要なKPIだったりします。
もちろん enza事業という規模で見れば「課金率」はとても大事なKPIですが、ゲームの施策によって変わる割合が大きいので、プラットフォーム企画メンが「課金率」をそのまま追ってもあまり意味がありません。
むしろ、「課金フローに入ったユーザーのうち、実際に課金完了までたどりついたユーザーの割合」つまり「課金実行率」がプラットフォーム企画メンにとってのKPIになったりします。
このように、追うべきKPIを定義する ところからがスタートとなるので、これまでの肌感はそのまま通用してくれません。
とはいえゲームの運用でも決まりきった KPI を追い続けているわけではなく、
その時々に応じてKPIを定義することはよくあるので、ゲーム運用経験があるとアタリは付けやすいのではないかと思います。
企画の提案
ゲームの企画提案なら、
開発チームのプロデューサーに提案して
イイネ！やったれ！となれば進めることができます。
大きいチームだと企画リーダーを通したり、
版元様がいる場合は監修があったりすると思いますが、
あくまで 1つのプロダクトの中で、意思決定の関所がいくつあるかの違いです。
（意識のずれは時々ありますが）
プラットフォームの企画提案でも、まずは開発チームのプロデューサーに提案しますが、その先にはデベロッパーがいます。
最終的にユーザーに価値を届けるのはデベロッパーであり、デベロッパーの方々はそれぞれの理念を持ってユーザー体験を提供しているので、それぞれの理念を尊重しなければなりません。
関係者間での意思統一というのは、基本的に無いことが前提なのです。
また、多数のデベロッパーがコミュニケーション相手となるので、
作成する企画資料は常に
・どこに出してもOK
・口頭の補足説明がなくても齟齬なく伝わる
・相手の前提知識に依存しない
といった精度を求められます。
社内の開発チームやQAチームが共有対象で、口頭での補足を前提にしたようなアジャイルチーム的な資料作りだとやっていけないわけです。
ただ、私の場合は転生前に IPタイトル の開発に携わらせていただいた時に
自分以外の人に資料を託して企画を通してもらうという仕事をしていたおかげで
なんとなく勘所が分かっていたので、そこそこやれているんじゃないかと思っています。
スクラム運用
enza開発チームはゲーム開発チームと比べてスクラム運用がやりやすく、
ちょうどスクラムマスターライセンスを取得したばかりの私にとって、スクラム運用を実践的に学ぶ場としては最適でした。
というのも、ゲーム開発プロジェクトは数十人規模でのスクラム運用が難しいという側面があります。
スクラムを数十人規模で回そうとすると動きが鈍るので、
5～10人程度の小チームに分けた方が生産性が高まるのですが、そうすると色々な課題が出てきます。
・複数の小チームに跨がらざるを得ない企画メンバー
・アジャイル的な進行がしづらいデザインチーム
・なんやかんやスケジュール基準で動く運用チーム
などの要因により
本来あるべきスクラムの形とは大きく異なる形にせざるを得ない、
というのがゲーム開発におけるスクラムでした。
enza開発チームの場合も、
サービスの安全性や信頼性にコミットする特殊部隊（SREチーム）はあります。
しかし、基本的には各職種がバランス良く揃った機能横断チームとなっているため、あまりイレギュラーな形にせずに運用できています。
また、弊社内で最初にスクラム原理主義を導入したチームということもあって、スクラムの考え方がそれなりに根付いているという側面もあります。
これが ゲーム企画メン だった私が プラットフォーム企画メン に転生した顛末です。
意外なところで試練が待っていましたが、
転生前のスキルは わりと活きているんじゃないかと感じています。
最後に悩みを挙げるならば
・ゲームについて語り合える人が少ないこと
・突如としてゲームを作りたい欲求に駆られることがあること
でしょうか。
ゲームを愛する皆様、どこかで出会ったらぜひゲームについて語りましょう。
ドリコムでは一緒に働くメンバーを募集しています！
もちろん、enza 開発チームのメンバーも絶賛募集中です。
募集一覧はコチラをご覧ください。
明日は onda さんの記事です。
5日目は kyoji_hata さんによる、ブログKPI取得のためのデータを自前で集積・計測する方法 です。
どうもこんにちは、ドリコム新卒7年目の てらこ と申します。
enza というHTML5ゲームプラットフォームの開発プロジェクトで 企画メン をやらせていただいております。
最近は Google STADIA をはじめ 様々なゲームプラットフォームが勃興し、再びプラットフォーム群雄割拠の時代になってきました。
今回、私からは「ゲーム開発」から「ゲームプラットフォーム開発」への異動という、近いような遠いような異動で感じたことについてお話しさせていただこうと思います。
その異動って苦労するもんなの？
ていうかプラットフォームの企画って何やってるの？
という疑問にお答えできれば幸いです。
enzaとは？
先に enza についての説明をしておきましょう。一言で言うと「リッチなブラウザゲームが遊べるプラットフォーム」です。
まずは enza.fun にアクセスし、好みのゲームを遊んでみてください。
アプリやソフトウェアのインストールは必要ありません。
全てブラウザ上で動作します。
私の所属する enza開発チーム は、このサービスのプラットフォーム部分の開発・運用を担っています。
例えば…
- アカウントの登録・ログイン機能
- 課金する時に使う決済機能
- ゲーム内アイテムと交換したり、ガシャ（ガチャ）が引けるenzaポイント
といった機能を、どのゲームでも使える共通機能として提供しています。
露骨な宣伝はこの辺にして、本題に移りましょう。
転生する前の人生
プラットフォーム企画メンに転生する前、私は ゲーム企画メン でした。2013年にドリコムに新卒入社。
ブラウザゲームの運用チームに配属されたのが、ゲーム企画メンとしての人生の始まりでした。
GREE と mixi プラットフォームで展開していた、ポチポチゲー系のブラウザゲームです。
enza のHTML5ゲームと当時のゲームを比べると、随分と進化したものです。
その後、会社のネイティブシフトに伴って
いくつかの ネイティブアプリの開発・運用に携わってきました。
オリジナルタイトル・IPタイトル合わせ、
世に出なかったタイトルも含めると 5タイトル ほどでしょうか。
そんな生活が5年ほど続き、ある日 転機が訪れたのです。
経緯については話すと長くなりますが、今回は転生のお話ということで体裁上
隕石に当たって死んだ ということにしましょう。
気が付くと私は、
enzaのプラットフォーム企画メン として生まれ変わっていたのです！
転生後の世界
私が転生した時の enza はリリースから一ヶ月経った頃です。リリース前に想定していた状況と、リリース後の状況の乖離に四苦八苦していました。
新規ユーザーの獲得単価であったり、継続率であったり、課金率であったりと、
ゲームのリリースに関わったことのある方なら誰もが経験のある状況かと思います。
そんなenzaに配属され、心機一転 プラットフォーム企画メン として仕事を始めたのですが、意外な壁にぶち当たりました。
それは、
異動して新しいチームに来た時、キャッチアップできるまであまり仕事がないというのはよくあることです。
しかし、ここでいう 仕事が無い というのはそういうことではなく、
同じサービス運用でありながら、ゲーム運用でやっていた仕事がほとんどないのです。
ゲーム運用なら当然あるはずの膨大な運用仕事がほとんど無く、
アップデート開発だけが走っている、そんなプロジェクトでした。
俺は何をすればいいんだ！俺の仕事はどこだ！私は誰だ！
それがプラットフォーム企画メンに生まれ変わった、最初の一ヶ月でした。
※あくまでゲーム企画メンと比較しての話です
enzaプラットフォーム企画メンの仕事
仕事が無い という前代未聞の状況に戸惑いもありましたが、1ヶ月も経つ頃にはそれなりに忙しくなりました。
プラットフォーム企画メンの仕事はだいたい以下の通りです。
ゲーム共通機能の企画・開発進行
これがメインです。
登録や課金といったゲームに組み込まれている共通機能や、
コミュニティなどのポータル機能の開発です。
プラットフォームKPI の改善企画
enzaメンバーの登録率や、課金フローの突破率といったプラットフォームならではのKPI を改善する仕事です。
デベロッパー支援の企画・進行
デベロッパーからいただいた色々な要望に応える仕事です。
キャンペーンの企画・進行
課金時にポイントを還元したり、ゲームのリリース記念キャンペーンなどを開催する仕事です。
この仕事が一番、ゲーム企画メンの仕事に近いかもしれません。
スクラムマスター
これは企画メンというよりスクラムマスタースキルを持っている人ですが…
enza開発チームは 5～10人程度の小さなスクラムチーム の集合体であり、チーム毎にスクラムマスターがいます。
ちなみに、デベロッパー開拓については私の所属する開発チームではなく、別のチームが担当しています。
転生後の試練
転生ものといえば 転生前のスキルを活かしてチートの如く無双するのがカタルシスでありますが、現実はそう上手くいかず、様々な試練にぶち当たりました。せっかくなので、その一端を紹介していこうと思います。
KPI 分析
ゲーム企画メンは日々様々なKPI に触れ、分析し、それを元に施策を立てていく生活をしています。
そんな日々を続けていくうちに、何となく数字の「肌感」がつかめるようになっていくものですが、
プラットフォーム企画メンは見ているKPIがゲーム企画メンと全く違います。
例えば、ゲームの運用だと「課金率」が重要なKPIだったりします。
もちろん enza事業という規模で見れば「課金率」はとても大事なKPIですが、ゲームの施策によって変わる割合が大きいので、プラットフォーム企画メンが「課金率」をそのまま追ってもあまり意味がありません。
むしろ、「課金フローに入ったユーザーのうち、実際に課金完了までたどりついたユーザーの割合」つまり「課金実行率」がプラットフォーム企画メンにとってのKPIになったりします。
このように、追うべきKPIを定義する ところからがスタートとなるので、これまでの肌感はそのまま通用してくれません。
とはいえゲームの運用でも決まりきった KPI を追い続けているわけではなく、
その時々に応じてKPIを定義することはよくあるので、ゲーム運用経験があるとアタリは付けやすいのではないかと思います。
企画の提案
ゲームの企画提案なら、
開発チームのプロデューサーに提案して
イイネ！やったれ！となれば進めることができます。
大きいチームだと企画リーダーを通したり、
版元様がいる場合は監修があったりすると思いますが、
あくまで 1つのプロダクトの中で、意思決定の関所がいくつあるかの違いです。
（意識のずれは時々ありますが）
プラットフォームの企画提案でも、まずは開発チームのプロデューサーに提案しますが、その先にはデベロッパーがいます。
最終的にユーザーに価値を届けるのはデベロッパーであり、デベロッパーの方々はそれぞれの理念を持ってユーザー体験を提供しているので、それぞれの理念を尊重しなければなりません。
関係者間での意思統一というのは、基本的に無いことが前提なのです。
また、多数のデベロッパーがコミュニケーション相手となるので、
作成する企画資料は常に
・どこに出してもOK
・口頭の補足説明がなくても齟齬なく伝わる
・相手の前提知識に依存しない
といった精度を求められます。
社内の開発チームやQAチームが共有対象で、口頭での補足を前提にしたようなアジャイルチーム的な資料作りだとやっていけないわけです。
ただ、私の場合は転生前に IPタイトル の開発に携わらせていただいた時に
自分以外の人に資料を託して企画を通してもらうという仕事をしていたおかげで
なんとなく勘所が分かっていたので、そこそこやれているんじゃないかと思っています。
逆にやりやすくなったこと
逆にプラットフォーム企画メンになって、やりやすくなったこともあります。スクラム運用
enza開発チームはゲーム開発チームと比べてスクラム運用がやりやすく、
ちょうどスクラムマスターライセンスを取得したばかりの私にとって、スクラム運用を実践的に学ぶ場としては最適でした。
というのも、ゲーム開発プロジェクトは数十人規模でのスクラム運用が難しいという側面があります。
スクラムを数十人規模で回そうとすると動きが鈍るので、
5～10人程度の小チームに分けた方が生産性が高まるのですが、そうすると色々な課題が出てきます。
・複数の小チームに跨がらざるを得ない企画メンバー
・アジャイル的な進行がしづらいデザインチーム
・なんやかんやスケジュール基準で動く運用チーム
などの要因により
本来あるべきスクラムの形とは大きく異なる形にせざるを得ない、
というのがゲーム開発におけるスクラムでした。
enza開発チームの場合も、
サービスの安全性や信頼性にコミットする特殊部隊（SREチーム）はあります。
しかし、基本的には各職種がバランス良く揃った機能横断チームとなっているため、あまりイレギュラーな形にせずに運用できています。
また、弊社内で最初にスクラム原理主義を導入したチームということもあって、スクラムの考え方がそれなりに根付いているという側面もあります。
こうしてゲーム企画メンはプラットフォーム企画メンに生まれ変わった
長くなりましたが、これが ゲーム企画メン だった私が プラットフォーム企画メン に転生した顛末です。
意外なところで試練が待っていましたが、
転生前のスキルは わりと活きているんじゃないかと感じています。
最後に悩みを挙げるならば
・ゲームについて語り合える人が少ないこと
・突如としてゲームを作りたい欲求に駆られることがあること
でしょうか。
ゲームを愛する皆様、どこかで出会ったらぜひゲームについて語りましょう。
ドリコムでは一緒に働くメンバーを募集しています！
もちろん、enza 開発チームのメンバーも絶賛募集中です。
募集一覧はコチラをご覧ください。
明日は onda さんの記事です。
