ソーシャルゲーム開発で直面する“問題”との向き合い方　解決に導くためにやるべきこと

問題の全体像を捉える

中村竜太郎氏（以下、中村）：ここからやっとそれぞれの手順に入ります。まずはWhereで、問題の所在の把握です。その中でも、さらに3ステップあります。

まずは、問題の全体を正しく捉えましょう。これは広義の話にはなりますが、そもそもなぜ全体を把握しなければいけないかというと、問題の全体を把握しなければ問題の所在を見落とす可能性があるからです。問題の所在を見落としてしまうと、解決ができません。そもそも全体が決まらなければ、漏れが決まらないので、抜け漏れも決まりません。

聞いたことがあるかもしれませんが、MECEの「漏れなく、ダブりなく」ですね。検討に入る前に、考えることの全体を定義することが必須です。

言うは易しなので、どうやって設定をしていくのかというところですが、ここからは比較的ビジネスライクな考え方になります。周囲からの期待、とくに自分の上司や経営視点まで持てれば理想ですが、直近は自分の上司、依頼者の視点からさらに1つ上ぐらいですね。その人たちに任される自分たちのことを報告しないといけないので、そこを意識して取り組みましょう。

なので全体を決めた時点で、依頼者や上司に必ず報告する際の「にぎり」ですね。「そもそもそこじゃないんだよね」と言われてしまうと工数がもったいないので、そうならないために、にぎることがポイントです。「なぜ視座を1個上に上げる必要があるのか？」ということについて、有名な人が言っている言葉があります。

あのアインシュタインも言っています。

「いかなる問題も、それをつくりだした同じ意識によって解決することはできません」。要は「これが問題なんだよね」とか「これに悩んでるんだよね」と言っている人と同じレベル感で取りかかる時点で、問題は解決できません。

依頼者が暗黙的に持っている問題を背景まで全部言ってくれることはないので、依頼者が暗黙的に想定しているスコープや目的のまま取りかかろうとすると、ただいろいろなデータを見て少し感想を言う、みたいなことにになってしまいます。なので、視座を1個上げる。あとはゲームだからこそビジネスライクな考え方で全体観を捉えてどこに問題があるかを意識することがとても重要です。

問題の全体を正しく捉える例として、これも過去にいろいろな人と話をしていてよく出てきたケースです。例えば復帰ユーザの定着率を上げたい。どこに改善ポイントがあるのか分析してもらえないか」と。そこで「わかりました」と言うのではなく「復帰ユーザの定着率を上げることで、その上位にある改善したい指標と目標値は具体的に何ですか？」ということを確認する。

例えば「今月の予算の月5億円の達成が危ぶまれているから、そこに対してのアプローチだよ」という場合「それなら、問題自体を予算の月5億円の達成のためにどこに伸びしろがあるのか、というアプローチをとらせてください」と、データや依頼人に踊らされずに1回冷静になるのがポイントです。

なので、依頼者の視点から良い意味で一歩引いてさらに1段視座を上げて、まずは問題を捉え直すことがポイントになります。

問題の所在を見つける

そこまでいくと全体観の問題が把握できたので、問題の所在を見つけなければいけません。ここからは適切に絞り込む必要があります。

例えば「DAUが落ちているので、維持のためにログインボーナスの石の配布量を増やしましょう」みたいな話になったときに、確かにDAUは減っているけれど、具体的にどの層が抜けているのかもわからないまま石の配布量を増やすのは適切なのか。とりあえずできることとなるとログボだったり「何か盛ります」みたいな話になりますよね。

ですがそれでは広く浅い話にしかならず、根本原因の特定にもなりません。さらに言うと、これはDAUが落ちているのが問題なので、その上位は何なのか。先ほどのように視座を上げてみると、減っている層が直近の売上に寄与する層なのかもわからずに石の配布量を増やすと、優良顧客に対しても石の配布量が増えるので、買わなくても使える石が多くなった結果、最終的に売上がマイナスになるアプローチも経験上多々見てきました。

こういったケースがあるので、問題を絞り込まずに取れるアプローチを取らなければいけません。あとは、ここもご存知だと思いますが、適切に絞り込む際のポイントは「切り口」と「切れ目」です。

ゲームユーザを切るのであれば、プレイ日数や購買履歴を見るのが切り口ですね。切れ目というのはプレイ日数の場合は1day、3day、7dayという継続率の日数で切るとか。

購買履歴で言えば、今までの総課金額などですね。1,000円未満でライトで遊んでいただいたり、3,000円未満とか、ここも切れ目です。

これもデジタルに切るより意味のある切れ目にしなければいけないので、インストール後のプレイ日数はこれで切っても概ね問題ないと思いますが、購買履歴や総課金額はアプリに依存するので、ここも現場と会話をしながら、「どういった提案を打っているの？」「月にどれくらいの金額を買っていただけるととどう遊べるのか」というところがポイントで切れ目が変わっていきます。

ここはどちらかというと、問題解決の中にある4Wの切り口を意識しましょう。

When「いつ」ですね。日付を切るのであれば、朝、昼、夜で1日8時間ごとに3つに切ってみたり、月の上旬、中旬、下旬で切ったり。朝、昼、夜で見るポイントとしては、今までの経験をお話しすると、3つに切ったときに1日2回以上、例えば朝と夜にログインする人のほうが翌日継続率が高まるということがデータで見えているのであれば、ログインの「1日」を切り変えるタイミングなんかも、競合のところに入っていると思います。

それももちろんデータを見ながらアプローチをしていますが、こういったかたちで朝、昼、夜であったり、時間帯で区切ることです。

あとはWhereです。これを使ったケースはあまりありませんが、日本だけでなく海外展開をしているところで、日本と海外を比べて海外全体の売上が下がったときに、まずどの地域のどの国の売上が落ちているのかを見る際に使った経験があります。

あとはWho、誰に起きている問題なのか。これは一番使うケースが多いと思います。新規、既存、復帰やプレイ日数。RFMは「Recency / Frequency / Monetary」ですね。お客さんの買っていただいた頻度とか総課金額、直近でいつ利用したのかというところでセグメントを決めます。

Whatも品目別であって、体力回復やガチャですね。ソーシャルゲームは売上のほとんどをガチャで作っているので、ここは見る項目と言ってもほとんどがガチャになります。あとはイベントごとに切って、どこで参加額が落ちたのかを見るのもWhatです。

論拠をつけて問題を特定する

さまざまな切り口を洗い出したら、一定の場所だけが問題となる切り口を選びます。問題が固まっているところですね。

左の図の場合は、左右の現象学がどちらも同じくらいなので、この切り口と切れ目はダメということですね。右の図だと問題が固まっているので、これは感度の良い状態です。

ここまでが、簡単とまではいきませんができるところです。私も仕事をしていて、3番ができていないケースをよく見るので「論拠をつけて問題を特定する」ということまできちんとやらなければ、自分の見たいものだけを見て、データで無理矢理理由を付けているだけになってしまいます。

「論拠」という言葉の意味を辞書から引っ張ってくると「論証において、ある事実を判定する根拠となる事柄」。もう少し噛み砕いて言うと、問題テーマに対してWhereで特定した箇所を解決すると、問題解決に対するインパクトが大きいと言える理由です。

これはざっくりした例ですが、今回のガチャが前回と比較して問題だったという話になったとしたら、「全体で2,000万円下がった件ですが、減少額をいろいろな切り口で比較した結果、1,000円から3,000円未満の購入者が大きく減少して、問題になっている2,000万円と同じ額が下がっています」と。

ここまで綺麗に固まることはあまりありませんが、前回比の減少額とほぼ一致します、と説明したとしたら、正にこれが根拠ですよね。

「ここが問題です」と明確に言えるかがポイントになります。

論拠と混同されがちなのが原因との違いです。先ほどもいいましたが、問題が問題であると言える理由が論拠で、問題が発生してしまう理由が原因です。「そんなのわかってるよ」と思われるかもしれませんが、仕事をしていると、混在されたまま会話に出てきたりします。

例えば「DAUが一昨日から3万人減少しているのは低レベル帯のユーザが3万人抜けているからです」という話になったときに、こ問題の原因と所在のどちらを伝えているかと言うと、もちろん問題の所在です。

ですが、これも日本語的な表現の問題になってしまいますが「〇〇だから」と表現をすると原因のように聞こえてしまいます。これは間違いで、原因であれば3万人が抜けてしまっている理由を言わない限り、これは問題の所在を言っているだけです。

これもよく会議で聞きますが「売上目標に対して4千万円ビハインドしたのは高レベル帯のユーザのARPPUが想定と大きく乖離したからです。それが原因です」みたいな言い方をしますが、これもあくまで問題所在でしかありません。

日常的に「ARPPUが低いのが原因です」という会話をけっこう聞きますが、これは大きな間違いで、この場合はARPPUが低くなった理由をセットで話さなければ所在レベルの会話しかしていないことになります。

論拠の王道3パターン

では、論拠付けにはどんな物があるのか？　これも経験上、この3つさえあれば大概は言えると思います。

「増加または減少が大きい」「改善の可能性が高い」「全体に占める割合が大きい」というのが王道の3パターンです。この論拠のどれを使うのかは、もちろん問うべき問題によって変わります。

今までの経験上も合わせて簡単に例を挙げさせてもらいます。まず、売上が減少しているという問題に対して、「先月比で今月の売上が大きく下がっている」のであれば、これは当たり前ですが「増加または減少が大きい」パターンです。なので、売上が下がったという問題を解決したいので、減少が大きいところが問題箇所として特定するのが一般的です。これが論拠になります。

全体で見た場合、最も売上が減少している箇所を特定して、そこに歯止めを掛けるというアプローチになります。全体の売上が伸び悩んでいる問題の場合、例えば「今年に入ってから売上が伸び悩んでいる」とか「前年は良かったんだけど」という話であれば、基本的には改善の可能性が高いです。

これは減少と似ていますが、伸び悩んでいるのであってべつに下がっているわけではないので、改善の可能性が高いです。

全体に占める割合が大きいパターンでも売上が減少しているわけではないので、どうにかして伸ばさなければいけない場合は「改善の可能性が高い」か論拠として使われるケースが多いです。

全体のイベントの参加率が悪いというケースです。「先日やった××イベントの参加率が悪い」となると、改善の可能性が高い場合もありますが、比較的全体の話になるのでここになります。ここでは全体に対する比率が高いところにアプローチしなければ、全体に対して売上が上がらないので、インパクトが大きいところに対してアプローチをしていきます。

ここまでがWhereですね。少し長くなりましたが、論理的思考でしっかりと論拠付けさえできいれば、ここが大きく間違っていなければ、決められた手順通りにやればそれほど間違うことはないので、ここがすべての基点になります。

最後のHowも難しいんです。これはクリエイティブなところですし、エンジニアやデザイナー、アナリスト、企画職の人はもちろんゲームが好きなので、自分もプレイしているからこそ「こうなんじゃないか」と決め打ちになってしまいがちなんです。ここも王道のやり方というのがあるのでそのお話をさせていただきます。

1つは「コインの裏返しというところに基本的に注意をしましょう」です。表面的に起きている問題を、そのまま裏返して対策にすることです。どういうことかというと、例えば今回のガチャが前回比で大きく売上がビハインドしたとします。1,000円から3,000円未満の購入者の減少が大きかった。これが問題の所在です。

そうすると「購入者を増やすというところの対策を考えましょう。例えばおまけを付けるとか、10連初回の代わりにこんなのどうだろう」という意見が出たりします。これは先ほどから出ているHow思考なので、なぜ購入者の減少が起きているのかを特定しない限り、Howの話は一切できないことになります。

ロジックツリーで原因を探る

では、ここからはどんな手法でやっていくのか。1つは、自分もユーザとなってプレイするのは当たり前なんですが、よくやるのがロジックツリーや因果の構造図というものです。

上に1つの問題を書き、下に深く掘っていくほど原因に近づくというかたちです。なのでそもそも購入者数が減少した理由を最初のレイヤーに書いていって、それに対して検証すべき項目は何かを四角で括り、それを実際に検証して事実だったのかそうでなかったのかは点線などでわかりやすくします。

仮にここの「石の在庫がガタついていた」という事実があり、確認をしたらやはりそうだった。もう1段深く掘っていくと、直近のガチャの引き自体が悪かったので、使われずに残ったということがあった。「それってどうしてだろう？」となったときに、ここでやめてしまうケースが多いんです。会社の事業部サイドの報告でよく聞きますが、直前のガチャでのが石の消費が悪かった。石を溜められてしまった。それは原因じゃないんですよね。

それってそもそもどうしてだろう。「石在庫のトレンドさえ見ていればわかる話なんじゃないの？」という話ですし、「どうして石在庫のトレンドを確認しないの？　そもそも見込みの段階で石の在庫量を考慮して見込みを立てていないのが本質的な原因だよね」ということで、問題の原因をユーザやお客様に向けずに、自分たちの考え方やアプローチにすべての問題があると考えるのが重要です。

なので、因果の構造図でのポイントはこの7つです。

とくに4番の「自分を主語として考える」。あとは当たり前ですが「事実で確認をとる」。他には「問題の固有原因を確認」です。これはさっき言った「ログインボーナスをまけばいいよね」みたいな話と一緒で「本当に固有なのか」といったところです。

4番を常に意識すると、楽しんでいただいているお客様を原因にするのではなく、そのゲームを作って運用している自分たちに問題があると考えると、取れるアプローチがいくらでもある、というのでここの一番のポイントです。

そこまで決めたら、手を打つべき原因はどうやって決めるのか？　これもなかなか現場のコストやいろいろなことを加味しなければいけないのですが、1つの評価の基準としては、メインの原因に手を打つということと、そこ以外にもいろいろなことに派生して、少しでも可能性のある原因を潰せるような広範囲なアプローチはないのか、あとは先ほど言った通り「根本の深いところへのアプローチはないのか？」と、原因に手を入れるというかたちです。

あとは純粋に「競合他社がやっているけど、うちではやっていないだけなんだよね」というところはバンバンやるべきです。基本的に、いくつかの原因に対する行動を複数に打てるようにアプローチすることがポイントです。

私はアナリストに、まずこれを書いてもらいます。問題自体をどう捉えているのか、合っている・合っていないではなく、抜け漏れがないのかということで、いきなり「何が原因だったの？」と聞くよりは、どこまで幅広く考えたのかを確認します。あとは手書きで書いてちゃんとレビューすることが重要なので、いかに抜け漏れがなく可能性となる原因を洗い出して、常に問題の原因を自分たちの考え方や行動にあると捉えて深堀りをしていくことが大切です。

原因を課題化し、解決した状態を数値で定義する

ここでようやく、データと論拠です。裏付けを取ってどう特定していくのか。ここまでできて、やっとHowの話に入れます。

改めて、Howは対策です。これは別にゲームだけでなくよくある話で、これも当たり前なんですが、意図を持ってこれまでと違うことをやりましょう。これまでと同じことを一生懸命やったり、もう少しログボを盛ったり「もうちょっと何かをします」というのは対策とは呼べません。

現状の問題がどんな構造で起きているのか、構造を変え得る新しい手を打たなければいけないので、単なる思い付きではなく適切に、原因に対して考え抜かれたこれまでと違うことをやる必要があります。

ですので、ここまで来たらやることは基本的に2つです。原因を課題化することと、課題が解決した状態を数値で定義することです。

これも簡単なソーシャルゲームの中のお話ですが、例えば目玉イベントの報酬獲得率の現状が20パーセントで、これを40パーセントまで引き上げたいという問題に対して、問題解決のアプローチで分析をした結果、所在と原因がここでした。

そもそもの問題は、現状20パーセントのところを40パーセントに引き上げたい。全体を引き上げたいので、問題の所在をどこかと見たらミドル層になります。その論拠として、他の層と比べて報酬獲得率が低く、改善の可能性があるということ。そしてユーザの全体数に占める割合も大きいということで、論拠付けをします。

原因が報酬獲得の難易度がミドル層にとっては高いというところまでわかったとしたら、ここでやっと1つやることが、原因を課題化するということです。ミドル層に対する報酬獲得までの難易度を適正化する。適正化という表現は抽象的過ぎてよくありませんが、まずはこういったかたちで取り組むべき課題はなんなのかを明確にします。

対策は決め打ちではなく複数案用意する

課題化までしたので、課題が解決した状態としては報酬獲得の難易度が適正のため、ミドル層の獲得率が向上します。そもそもの目標としては獲得率を40パーセントにしたいということなので、解決した状態と目標値を明確にしました。

それを含めてHowに取りかかるには、大概はHowは企画になるので、みなさんにそれを実装していただく事になった時、確実にこれが全部あるかをぜひ確認をしていただきたいなと思います。

これも経験上、課題管理表が必ず悪いとは言いませんが「課題化されているのであればあるべき姿や現状があって、そのギャップである問題まで定義される。さらに問題の所在は今では明確になっているはずですが、ただExcelに書かれた課題管理表をよく見ます。

大概その確認をしてもこういった項目に関することは出てこないんです。それは課題ではなくて、そのいち担当者がなんとなく「不都合はそこだと思うんだよね」というレベルのものが列挙されているケースが多いので、アプローチとしては危険性もあるかなと思います。

あと他は理想論になりますが、対策案は決め打ちではなく複数案を置いたほうがよいです。そもそもの原因がわかっているのであれば、それ1択しかないというのはないと思います。失敗したしてもまだ別のアプローチが取れるはずなので、理想としては3つや4つぐらいとよく言われますね。

「そうは言っても3つは大変だし」って考えるかもしれませんが、そもそも対策案が1つしかないというのもゲームから一旦離れて他のことで例えてみると確かにと感じてもら得るかもしれません。例えば物件を探していて、渋谷から徒歩10分以内、広さは2LDKで家賃が20万円以内という感じで検討するとします。これは条件ですよね。

こうなったときに「わかりました。じゃあ、この物件がおすすめなのでこの一択ですね」みたいな感じで言われたときに、「検討したい条件はこれだけあるのに一択しかないのはおかしくないか？」となると思います。

これは自分たちに利害関係があるときに一択で出されたら「おかしいだろ」と思われると思いますが、先ほどの分析的にも、原因がわかっていたら「決め打ちの施策はこれが一番いいです」というのは相当危険ですね。正直成り立つのか？　という気がするので、最悪でも3つ出してもらって「他の2案よりそれが勝っているのはなぜなのか」ということを議論すべきなので、そこをぜひ意識してもらえると良いと思います。

複数案を挙げてもらって初めて「この感じで検討してどれが一番良いのか」が検討できます。これはHowの話だけではなく、前職のドリコムにいたときに分析をして上司に報告をするとき「これが今最も取り組むべき問題のテーマだと思います」と言ったら「わかった。それじゃあ企画したけど選ばなかった他の2案を教えてくれ」と。「どうしてそれを選んだのか、他の2案と比較すればインパクトも含めて検討できるから」と言わたんですね。

私もその当時は分析のやり方もぜんぜんわかっていなかったので、決め打ちの一択でいっていたのが大きな反省点です。

同じく施策でもこういったケースは散見されるので、ここを意識しておくというのが大事だと思います。

解決までのプロセスを考える

最後は、解決されるプロセスを明確にするということです。対策を実施した場合、先ほどの例でお話しすると、全体の獲得率が40パーセントになるのがどういったプロセスで解決されていくのかを考える必要があります。プロセスごとに指標を設定しておいて、そんな流れで解決するのか。ここまで書いて企画ですね。

全体のKGIが獲得率40パーセントであるとしたら、これもひとつのアプローチですが、イベントの特効キャラを配布すれば、ミドル層がイベントの特攻キャラを獲得して、それがすぐに使える状態ではなかったとしたら、まずは育成しなければいけないので育成して、育成をしてくれた状態で特攻キャラを使ってイベントに参加します。

そうしてミドル層が報酬を獲得して、この特攻の恩恵を受けたとなったとき、それぞれにどんな標を置いて質を取るのか。どこまでがよかったのか、それが達成できたから最終的なKGIが達成できたのか、というところを含めて記載します。ここまでできて初めて対策になります。

最後に、全体的にはHowが企画にあたる部分ですが、もちろんWhat、Where、Whyが明確になっていることが前提です。企画も分析も、本当に正しい手順なのか、実装に値するプロセスをちゃんと踏んでいるのかを、エンジニアの方も含めて改めて確認をしていただければと思います。

私自身も、そうやって突っ込んでいただける現場のエンジニアの方がいるととても助かるので、問題解決の確度を上げて本当に実装すべきことに集中できる環境を、企画もエンジニアもデザイナーも分析者も含めて作っていければいいなというのが今回のテーマです。

以上になります。ありがとうございました。

(会場拍手）