ビックデータ時代だからこそ学びなおす問題解決のやり方
中村竜太郎氏（以下、中村）：改めまして、今日はよろしくお願いいたします。
(会場拍手）
「ビックデータ時代だからこそ学びなおす問題解決のやり方」というテーマでお話します。自己紹介をさせていただくと、経歴を見ていただくとわかると思いますが、最初は新卒でシステムエンジニアになり、2009年に楽天のトラベル事業ですね。そちらでプリセールスと簡単なBIによる分析のような業務を行っていました。
そこで、全国の宿泊施設のデータを見ながらいかに売上を上げるかというところを片手間というか業務で携わっているときに、本格的に分析業務に携わってみたいなと思いました。
その後、1番データ量が多いところはどこかをいろいろ見ていて、ソーシャルゲーム業界で前職のドリコムに2012年4月に入りました。いちアプリの分析担当から入ってマネージャーを経験し、最後は分析部の部長と事業部側の副部長をやって事業を見させてもらっていました。
そして、去年の10月にセガから「セガでもう1度分析組織をしっかりとやっていきたい」と声をかけていただいたので、戦略支援部の副部長という立ち位置と、現在はデータアナリティクスラボという名前に変わっていますが、主に分析ですね。対象はソーシャルゲーム、プロダクト、あとはラボという名前が付いてますので市場を分析するチームと競合他社分析するメンバーが私の部下にいまして、そこを兼ねて今は課長も兼務させていただいています。
趣味は、楽天にもいましたので旅行ですね。あとはパッと見ると分析じゃなくて肉体関係の仕事をしているように見えると思いますが、システムエンジニアのときに体を動かしたいなと思っていろいろやっていた延長線でプロボクサーのライセンスを取ってみたり、ずっと総合格闘技をやっていたりとか……。
それも踏まえて今回のテーマの背景を話させていただくんですが、経歴をご紹介させていただいた通り、もともと分析経験がないところから入ってます。
なので、いちアナリストとして試行錯誤して一応管理職にもなり、もちろんアナリストのマネジメントもしていましたし、事業のほうも見ていたので、分析が主目的にならないように事業サイドで何が求められているのかを経験した中で、分析者視点と事業者視点の両方から見て、そもそも経験がなかったので、我流でやるよりも市場で認められているやり方とは何なのかということに関しては、相当数の書籍を読んで実務ではなんとかやれています。
その考え方はもちろん実体験も合わせていますし、私固有の考え方というより、書籍で学んだものを実体験に活かせたのであれば、今回お話させていただくことはこちらに書いてあるところから見ていただければ本質はこちらから学べると思いますので、そこに沿ってお話しいたします。
ビッグデータを用いた問題解決の現状
テーマの背景についてです。3つの歯車があります。
1番大きなところはベースとなる考え方、そこに論理的思考や問題解決思考がああり、第2の歯車として分析手法があり、第3の歯車としてビッグデータなど、技術的なところもありますし、BIでいろいろ可視化もできたりします。
私も2012年から分析の世界に入って飛躍的に技術も進化しているのが、第2と第3です。この歯車はテクノロジーのおかげで時間とお金を含めてコストと実行のハードルがすごく下がりました。ただ、下がったのはあくまでもコストと実行のハードルだけなので、他の歯車を生かすも殺すも第1の歯車次第というのが、私だけでなく他の優秀なアナリストも言われているところで、ここが重要だと考えています。
ただ、第1の歯車が機能していないとどうなるのかというと、よくあるのが手法ありきのアプローチになっていたり、BIがあるのでいろいろなデータが可視化できるようになりました。ビッグデータなので「可視化していろいろ見てアプローチしていきましょう」というところから、可視化だけして分析をした気分になったり、グラフを見て思ったことをいろいろ言って分析した気分になってしまうという事がありました。
確かにBIを入れると可視化は進むのですが、データが大量にあるので、取捨選択をしないとすべて可視化されてしまいます。そうすると、よく言うKPIは「Key Performance Indicator」の略なので、最重要の評価指標であるKeyがそんなにもあるはずがない。いろんなものの数字を可視化して数字＝指標のような感じになってしまうと、結局「いろいろ見ても何も変わらないじゃないか」みたいなことになってしまって、だんだん数字が軽視されてしまうのが、可視化が持っている1つの弊害だと思います。
今回はそうならないために「考え方」にフォーカスした話になります。とは言え、分析業務についてビジネスの話だけで例えても少しわかりにくいところがありますので、よりイメージをしていただくためにコックに例えてみます。
先ほどお話させていただいた通り、分析手法もビッグデータもBI、もすべては問題を解決するための手段でしかありません。例えば2人のコックがいました。問題解決を意識しないコックと、問題解決や顧客を意識するコックです。
この2人のアプローチがどう変わってくるかと言うと、顧客を意識していないコックは食材（データ）や作りたいものが基点になります。とにかく何でも千切り（可視化）という、調理方法（分析手法）に固執する。そして、料理を提供するまでがサービスで、集計や可視化など意見を報告して終わりです。
それに対して、顧客を意識したコックは、あくまでもお客の注文、ニーズ、問題が基点となります。必要なものだけを千切り（可視化）ですね。適したニーズや問題に対して、適した調理方法を実践する。お客が満足してお店を出ていくまで、問題が解決して最終的な意思決定をするところまでをサービスの範囲とするのが、問題を意識したコックです。 この勉強会で伝えたいことは、企画職や分析者が問題を定義して、問題解決の手段として企画を作られていると思います。ただ、あくまでも企画ベースで、分析も分析の示唆までなので、それをかたちにするのは、ここにいらっしゃる現場で活躍しているエンジニアの方々です。
だからこそ「その問題って本当に正しいの？」とか「その企画って本当にかたちにすべきなのか？」というところは、今回の問題解決の考え方を使って、現場のメンバーが企画を本質的に理解していただければと思っていますので、少しでもお役に立てればというところが背景としてあります。
「問題」とは何か？
では、そもそも「問題」とは？ ここは当たり前な話なのでサラッといきます。問題とは、現状とあるべき姿のギャップです。この2つをしっかりと定義して言語化されない限り、問題は定義されません。
「こんな当たり前なことを」と思われるかもしれませんが、これは昔から言われていることです。例えば有名な児童小説『不思議の国のアリス』にもこんな一節が登場します。アリスが「道を聞いてもいい？」と尋ねるんです。すると猫が「どこに行きたいかによるけど？」と答えます。それに対してアリスが「どこに行きたいか具体的にわからない」。そうすると「ならどうでもいいよ。どこに行きたいかわからないならどの道を選んでもどこかにたどり着けるんだから」と答えたんです。
よく、施策やプロダクトの問題を教えてほしいという話になりますが、「この施策はそもそもどこを目指しているんですか？ どこを1番重要課題として捉えているんですか？」と聞くと「具体的に決めていないのでとくにないです」という回答をされることがけっこうありました。
あるべき姿である目標を決めない限り問題も存在しないですし、間違いもないんです。さらに正解もありません。なので、いかに問題を定義するときに「あるべき姿をきっちり定義できるか」がポイントです。
じゃあ「すぐにあるべき姿を決めにいきましょう！」というとザックリになってしまうので、問題を明確化するために、まずは分類することからはじめましょう。
発生型問題と設定型問題
大きく分けて、問題は発生タイプと設定タイプの2種類に分けられます。
発生タイプは、あるべき姿は設定される受け身なものです。さらに細かく分けると、目標不達問題と異常発生問題があります。設定タイプは、自発的にここにいるみなさんや私自身が決めていくという能動的な問題です。
それぞれを簡単に説明していきます。おそらく目標不達問題というのが大きいと思います。業務の目標と現状のギャップが生み出す問題で、一定期間で設定された目標が達成できていないケースで起きる問題です。私やここにいるみなさんも同じだと思いますが、ビジネス的に最も発生する問題です。
よくあるのが、会社や事業サイドの上から課せられている売上目標に対して、今月目標が達成できなさそうだと。その場合、あるべき姿は会社から設定してもらっている売上目標であり、現状が届いていないというギャップで問題となるということです。
もう1つの異常発生問題は、過去の延長線上で問題が発生する場合です。維持すべき現状から逸脱してギャップが生まれるケースですね。早期に「こういう状態なのでなんとかしてください」とか「どういう状況か見てもらえますか？」といったことが出てきます。例えば、過去の延長線上なので、先週と今週のDAUを比較して、最近のトレンドからすると大きく落ち混んだ場合など、そのギャップが問題になります。
逆に私も含めてみなさん自身で設定していくタイプとして、設定型問題があります。現在の問題に対して、改善活動のように積極的に新たな到達目標を自分たちで設定していくかたちですね。
例えばDAUをただ使うというケースはもうなくなったと思いますが「DAUベースでちゃんとプレイをしてくれたり、イベントをやってくれている人は何パーセントだっけ？」と見たときに、現状が40パーセントとしたら「せっかくログインをしてくれているのに過半数を超えないのかどうなの？」というところから、「せめて過半数を超えて60パーセントぐらいまで持っていきたいよね」と、自分たちから設定をしていくようなケースが、この設定型問題です。
将来型問題というのは、私の経験上でもなかなか設定するのが難しいのですが、このゲームやプロダクトをこれからどうしたいのか、どこを目指していくべきなのかという「将来のあるべき姿」を描いて、それと今を比較して問題を定義するかたちです。
例えば現状の翌月継続率で推移すると、2年後には月間の売上規模が5億円ぐらいになってしまうと。8億円を目指すためには、継続率何パーセントを目指さないと到達できないだろう、みたいな、将来を見越してあるべき姿を置いて設定していくのが、この将来型問題となります。
目標値と現状値を明確にする
次にやるべきことは、これらの必要項目を必ず埋めましょう。
先ほどの問題のタイプが何なのか、そもそもあるべき姿とはどこを目指しているのか？ よほどトップダウンで豪腕を振るえる人だったり、1人で進めるのであればいいのですが、チームプレイをしているので「なぜそのあるべき姿を目指さなければいけないのか？」という理由をチームメンバーに説明する必要があります。
最も重要なのが、目標値と現状値です。ここが明確でないと、到達できたかどうかがわかりません。とは言え、これでギャップが明確になると難易度になるので、みんなの認識が揃います。なので、前職でも企画時に「どうしてこれをやりたいのか」ということで、これらの項目を埋めましょう、というアプローチをしていました。
最初に「問題だ！」と言われていたときにすぐに取りかかるのではなく、ここを明確にする。この項目が埋まってないと取りかかれないので、ここを徹底的に意識するのが重要です。
依頼者からの問題を整理する手法として「OPQ分析」というものがあり、ロジカルシンキング系の本でもよく書かれています。依頼者の状況や疑問が正しく理解することが重要なので、OPQ分析を使って問題を整理します。
OPQはそれぞれの頭文字を取っています。Objectiveが望ましい状況、依頼者が考えている達成すべき目標や改善後の姿です。例えば今月の売上目標を5億円達成しなければいけない。それに対するProblemとは何か？ 今のままだと2億着地になって3億円足りない。これが問題です。
じゃあ、Questionとして、プロブレムに直面した依頼者がどうやったらこれを埋められるのか。例えば当月は無理だけど今期であればまだ回収ができるとか、そういったことも含めて、依頼者が疑問を持っています。そのクエスチョンに沿ったかたちで、アンサー。それをどうすればいいのかというのが主メッセージです。さらに、レールをちゃんと意識しなければいけません。
この場合では、仮に置いたのが売上目標だとすると売上なので、トピックのテーマになっている軸をブラさずに、問題に対して分析をしていきます。これが最初の整理のやり方です。
「最も効果があるのは何か？」を考える
ここまで簡単に問題設定の話をしました。とは言え私も7年ぐらいしか分析職やっていませんが、いろいろ経験をして言えることは「何が最も効果があるのか」と問うのが重要です。
ゲームというドメインは「どうあるべきか？」とか「ユーザはこうあるべきだ」とか「このイベントはこうあるべきだよね」という哲学論や主観に陥りがちです。
どうしてそうなってしまうのかと言うと、その原因が大元のゴールである「どうしたいか」という目標とかを決められていないので、そういった議論が発散してしまっています。なので、そこが決まっていれば、「何がもっとも効果があった施策なのか」「何を検証しなければいけないのか」という本質的な議論に集中できます。
なので、事業サイドやゲームのプロダクトでロジカルに考えられる人がいると、良い意味で発散したあとにちゃんと本質に差し替えられると思うので、ここを1つパワーワードとして意識していただけると、今後の問題設定のキーになると思います。
ここまでの簡単なまとめとして、当たり前ですが問題解決なので、解決すべき問題を明確にするのが重要です。そのために目的、ゴールや、先ほど設定させていただいた項目をとくに明確にする必要があります。曖昧さを残さずここを明確にして、依頼者や関係者との認識をしっかり揃えることですね。
先ほどの参考図書でも、2つほどロジカル系の本を挙げさせていただきました。日本語は他の言語に比べていい意味で曖昧さを残すので会話が抽象的になってしまいがちなのが、日本人の抱えている問題だと思います。なので、いかに明確に、ロジカルに、端的にということを意識できるかが、問題設定において重要です。
問題解決の手順
ここからは、問題解決の大枠の手順を簡単に説明をさせていただきたいと思います。一段と実体験に基づいてというか、簡単な参考程度のエピソードを入れながら説明をさせていただきます。
例えば会議で「3ヶ月連続で売上目標達成で絶好調だったけど、今月の月初のガチャが見込みより5千万円くらい悪いんだよね。このままだと今月の目標達成が厳しい状況なんだよ」と。
みなさんが担当されているプロダクトでも話が出てきていると思います。こういった会議に参加されるとき、それぞれタイプが分かれるので、今度会議に出る際は、どういう発言をしているのかを意識していただければと思います。
例えば先ほどの発言に対して、1つは「すぐにセールをやりましょう」とか、「そもそもあのキャラは売れないよ」と話をする人もいますし、「そもそも計画対比でどこが一番ビハインドしたんですか？」という話があったりします。この場合、セールを提案した人はHowである対策の話をしていますし、キャラの話をした人は原因の話をしていますよね。最後の1人はWhereである問題の所在の話をしているので、それぞれ3タイプに分かれます。
それを踏まえて、問題解決の正しい手順としては、Whereで「問題はどこで起きているのか？」をまず確認します。その上でWhy、「その原因はどうして起きているのか？」を明確にします。それで初めてHowですね。「じゃあどう対処しましょうか？」という話ができるようになります。
そもそもこの手順でいかなければ解決できません。当たり前ですが、これは逆には戻れないので、原因がわからないと正しいHowにはなりませんし、問題の所在を絞らなければ、的確な原因に至ることができません。
ここで「スキーマ」という概念が出てきます。強くショックを受けた少数の代表例だけを記憶の中に残して、一人ひとりの頭の中に構築されるA＝Bという個人的な思い込みのことをスキーマといいます。
それを踏まえて、先ほどの「セールをやろう」という人たちは、スキーマで過去の経験でWhereとWhyを決めつけている状態です。売上が悪い所在もその原因がわかっていない状態で正しい案の提案ができないので、この人はダメです。
次にキャラに言及した人は、同じくスキーマで問題の所在を決めつけている状態ですね。売上が悪い所在がわからないまま原因の話をしても非効率です。唯一良かったのがこの人で、まず問題の所在がどこなのか。ギャップしか言われてないし、どこが問題なのかを特定しなければ先に進めないよね、というところを確認をしています。
How思考に気をつける
みなさまの会社でも、これもゲームドメイン特有ですが、おそらくHowの話をする人が多いのではないかと思います。それが決して悪いとはいいませんが、How思考には気をつけなければいけません。例えば「今期の売上をどう維持していこう」。これもあるあるネタです。よくあると思います。それに対して、すぐに「それなら新規・復帰の継続率を上げるアプローチでいきましょう」、これもよく出てくるフレーズです。
これはダメです。典型的にHow思考の人間です。どれぐらいの売上を維持する必要があるのか、定量的な量がわかりません。問題が明確ではない状態で具体的なアプローチが出てくる時点で、相当危険です。
問題が明確になったら、まずはWhereの基準で目標を達成するために効果的なのはどこなのかを明確にする必要があります。金額がわからないまま新規や復帰の話をするのは、私も含めて他のゲームもやっていたりします。もちろん新規のお客さんを大切にしたいですし、少し離反してしまったお客さんに戻ってきてもらいたいという気持ちもわかりますが、アプローチを付けていくために、まずはどこの優先順位が高いのか。そこが担保されてはじめて新規と復帰にもっと遊んでもらえるだろう、という考え方を持つためにも、ここは論理的に、How思考にならずに決められた手順通りにやっていくのが重要です。
簡単にそれぞれ3手順です。そもそも問題を設定をするということを含めると、Whatがあるので4手順あります。必ずこの順番で取り組んでください。最初に問題箇所はどこなのかを明確にして、先ほどと同じく全員の認識を必ず揃えてから次の工程にいきましょう。いきなりHowの打ち手の話をするHow思考にならないようにしていきましょう。
