ログ分析とデータ分析

ログ分析とは

むかしIT業界にいたころ、ログ分析という業務がありました。（今もありますが）

今でいうところの「データ分析」とは少し異なり、ITシステムのログを元に下記のような業務を行うことです。

・システムリソースが枯渇していないかの確認
・バッチ処理など定期的かつ自動的に実行される処理の稼働確認
・不正アクセスやイレギュラーな使用がされていないかの監視とその保全

目的はITシステムをユーザが適切に利用できる状態に維持すること（品質担保）で、分析を行うのもデータアナリストではなく、ITシステムの運用担当者です。

基本的には各種監視項目を自動検知してアラートを上げる仕組みが実装されていたり、ログの管理ツールで状況がわかりやすく可視化されていたりするので、担当者が生ログを目検で分析するということは何か異常がない限りあまりありません。

当然専門的な統計の知識も不要です。

特に現在の様々な業務はITシステムの利用がほぼセットになっているため、ITサービスが使えないと業務が停止してしまう恐れがあり、安定的な稼働・供給は欠かせません。そのためそれを支える（運用業務の一環としての）ログ分析も重要な仕事です。

ただ、ログ分析自体は通常売上増加などにつながるものではなく、なかなか投資対効果の図りにくい業務でもあります。

もちろん優秀な運用担当者であれば、何か問題が起こったときにいち早く要因を特定し問題解決を早期に実現することが可能なので、それが引いてはシステムの停止時間を短くし機会損失の極小化につながるという金銭的な効果も見込めます。

しかし、基本的にはそうした属人的な対策に費用をかけるよりも、最初から問題が起こらないように予防する仕組みにコストをかける方が実用的とされています。

ログ分析をデータ分析に取り入れる

一方データ分析においては、データマイニングのイメージのせいか、売上改善やコスト削減などが期待されることが多いです。

そのためマーケティング、広告・宣伝、販売（レコメンド）などの売上に直結する効果の最大化、あるいは製造・調達・流通などの領域のコスト削減のために使用されるケースが多いようです。

しかし、周知の通り上手く成果を出せていない企業も多々存在します。

そうした企業は、データ分析に問題があるのではなく、業務そのものに問題があるのではないかという気がします。

業務が属人化しており担当者によって成果が大きく変わる、しかもそれを形式知化できていないため横展開できないなどといった状況に覚えはないでしょうか。

そうだとすると売上も優秀な担当者の活躍や企画が偶々ヒットするかどうかといった偶発性の高い要因しか見込めなくなり、データ分析はあまり役に立ちません。

あるいは逆に業務のやり方やプロセスが過去の慣習からからずっと同じで、変えようとしてもリスクやコスト面で非常に変えにくくなっており、情勢の変化に柔軟に対応できないという状況であれば、おそらく戦略を練ったりデータ分析したりをいくら行ってもそれが実務に反映されないので、大した効果は出ないでしょう。

「一発当てる」のを狙うのもよいですが、それしかないとビジネスがただの博打になってしまうので、構造的な改革も合わせて取り組むべきではないかと思います。

そのためには、まず各種業務の進捗やプロセスが定量的に可視化されている状態が必要です。そしてPDCAを回していけば、構造的な面での改善も進めていけるのではないでしょうか。

とここでようやく冒頭のログ分析の話とつなげますが、ITシステムのログ分析のように、データ分析が期待される各種業務のログもきちんと収集・管理して分析する仕組みを実装することで、適切に回っている状態を維持できることが期待できないでしょうか。

また何か問題が発生したときに、その要因をつきとめ対策をとることもスムーズかつ柔軟に行うことも可能かもしれません。

データ分析にとって、ログ分析を参考にそれを取り入れることも有用ではないかという気がします。

しかし、特に売上に直結する業務などでは全てがシステム化されていないことが多く、ログを収集することでさえ一筋縄ではいかないことが多々あります。

顧客や案件等のリストをいまだにエクセルで属人的に管理しているところも多いでしょう。

昔からそうした領域で業務の標準化＆システム化を進めるためのソリューションとして、マーケティングオートメーション（MA）やCRM、SCM、SFAなどの導入も進められていますが、合わせてそのログの収集・管理・活用も進めていきたいところです。

データアナリストとしても、ありもののデータしか分析しないのではなく、業務改善等の目的に即して、新たなデータ収集の必要性を提案するなど広い視野を持ちたいものです。

データアナリストの今後のキャリアを考えてみる（定期イベント）

最近、機械学習を簡単に実行できるソフトウェアはあちこちで見かけるようになりました。

AI人材やデータサイエンティスト育成サービスも流行しているので、機械学習の知識を持つ人も今後増えていくことでしょう。

BIツールも相変わらずの状況です。使われないレポートや類似レポートが乱立したり課題もありますが、データ活用の第一歩として導入企業は増え続けています。新しい製品を開発する新興企業も出てきています。

またマーケティングの領域では、マーケティングオートメーションのソフトウェアやCRMのソフトウェアもたくさん世に出ています。

デジタルトランスフォーメーションによって、業務がどんどんデジタルのツールに置き換わると、データの処理や業務上でのデータ活用に慣れる人も増えていくと思われます。

こうして様々な業務においてデータを活用するということはさらに広がっていくことでしょう。

ただ一方で、データ分析を自動的に行ってくれるツールはまだ世の中にありません。（私の知る限り）

データ加工や集計を手軽にできるツールや、機械学習で使用する用に簡単な前処理や変数生成をある程度自動的にしてくれるツールは見かけますが、KPI設計を自動的に行ってくれるツールや数字の因果関係を自動的に判別してくれるツールなどはまだ出てきていないかと思います。

IBMのワトソンなどは、今後それに近いツールになっていくかもしれませんが、まだまだ時間はかかりそうです。

こうした現状と今後の見通しの中で、現在データ分析を生業にしている人間は、どのようにキャリアを考えていけば良いのでしょうか。

ざっくり考えると、３つほど方向性がありそうです。

１つ目は、データ活用を推進するためのソフトウェアの開発。

ただ、現在すでにレッドオーシャンに近い状況になってきているので、よほど他にない利便性の高い機能を備えるか、既存の高シェアツールを買収して多くの既存ユーザを最初から囲い込んだ状況で始めるか、あるいはまだ手作業の業務領域（ブルーオーシャン）を見つけてそこで先行者となるか、なかなか厳しい戦略を実現しなければならなさそうです。

2つ目は、まだ自動化などが難しい人手による業務で専門性を発揮すること。

先に述べたように、KPI設計や数字の因果関係の判別などはまだ人が行う業務なのでそうした領域で実績と経験を積んで仕事にありつくことはまだ可能かもしれません。ただし、どんどん便利なツールが開発され、それほど高い知見や専門性がなくとも業務をこなせる人が増えてくれば、単価が下がったり仕事を確保するのが難しくなる可能性もあります。また逆にそうした領域をカバーするソフトウェアを自らがいち早く開発できれば、1つ目の方向に転換して成功できるかもしれません。

3つ目は、データ活用がシステム化していく中で、それらをさらに推進・補完する役割。

現在ではシステムの提案・導入・開発・運用・教育などの事業を行っているSIerやソフトウェアベンダー、コンサルティングファームなどがそうです。市場としては今後拡大の見込みなので、彼らが引き続き大口の顧客との関係を維持し高シェアのソフトウェアやツールを手掛けることができれば今後もある程度仕事は確保できることでしょう。

その中でも競争や各社独自の動きは出てくるでしょう。コンサルファームなどはデータ活用のための組織設計や業務プロセスの整備など体制面のサポートから入るなど提案やサービスの間口を広げていますし、SIerは人手を確保しないとビジネスが拡大できないため、昨今のエンジニア不足の背景も相まって、利幅がよくコストもあまりかからない1つ目のソフトウェアビジネスの方も併せて手掛けるという方向に目が向いてるところもあるようですね。

いつまでもデータ加工しかできないとか、機械学習のモデリングしかできないなどと業務領域や学習領域を限定していると、そのうちコモディティ化が進めばツールや他の人に置き換えられる可能性が高くなります。

データ分析の実業務をこなしていれば、データ分析スキル以外にも様々なスキルが身に付きます。

担当する業界および業務知識に長けてくる、クライアントとの交渉や提案・ヒアリング等のコミュニケーションスキルが鍛えられる、プレゼン・報告書作成・会議のファシリテーション・プロジェクトマネジメントといったビジネススキルも身につくなどの副次的な効果も得られます。

データ分析スキルと別のスキルを掛け合わせてより希少な人材を目指すも良し、データ分析スキルを強みに他業務をキャリアの主軸に置くも良し、どうコモディティ化の流れに抗っていけるか、あるいはうまく波にのっていけるかを考えなくてはいけないのかもしれません。

特に2つ目においては、すでにジレンマを感じてきている人も増えているようです。私自身もそうです。まだ今のところは役に立てているのではないかと思っていますが、今後の見通しは不透明なので今のうちから何か考えておかねばと悩むことも少なくありません。

個人的には、いずれに方向に進むにせよ交渉や提案のスキルはなるべく経験を積んで磨いておくことは良いのではないかと思ってます。他で活かせる汎用性の高いスキルであるだけでなく、意味のあるデータ分析や、効果の見込めるデータ分析につなげられる確率も上がるからです。

とまあ、先週に引き続き同じようなテーマの記事になりましたが、今後も定期的にデータアナリストのキャリアについて少しずつ考えていきたいと思います。その時々の情勢などによって中身も変わっていくかもしれないですしね。

データアナリストの肩書きを外して仕事する

データ分析関連の仕事をしている人は、データアナリスト、データサイエンティスト、データ分析官など様々なジョブタイトルが名刺に入っていると思います。

おそらくその中に「データ」という単語が入っていないタイトルはほとんどないのではないでしょうか。

またそうした方々が所属する部署名やチーム名にも、「データ」という文字が入ってるところは多いかと思います。

社内外のクライアントがそうしたデータ○○の担当者に仕事を依頼するとき、アウトプットは「データ」で出てくると考えるであろうことは想像に難くありません。

これはつまりクライアントの課題解決の手段が暗黙のうちに限定されてしまっていることにもなりかねません。

あるいは課題解決というよりも、有用と思われる「データ」をいかにたくさん提供してもらうか、に目的がすり変わってしまうことすら起こりえます。

あまり例えはよくないかもしれませんが、株式投資をしていて保有銘柄が目標の株価に到達しても、もっと上がるかもと思って欲張ってしまう心理が働いてしまうようなものでしょうか。

クライアントと打ち合わせをしていると、途中でこんなデータを見たい、あんなデータを見たいという発言がよく出てきます。

どうも会議が進むと、目的が何だったのか、どんな課題を解決したかったのか、何を明らかにしたかったのかなどを忘れてしまいがちなようです。

いつのまにかデータマイニングをすることになって、その作業の洗い出しになってしまうこともよくあります。

もしそのように方向性がずれてきたら、こちらから逐一目的や課題を改めて再確認し、それに必要なデータはどういったものかを考えましょうという方向に軌道修正する必要が生じ、なかなか苦労します。

なんとか本当に必要なデータを理解してもらえたとしても、まだ安心はできません。

最後に「念のため」とか「一応」という枕詞をつけて、結局は最初に見たいと言っていたデータの提供も依頼されます。

本当に必要なデータはすでにクライアントの元にあったとか、あるいは諸条件により取得不可であったなど、我々が改めて作業する必要がないような場合であっても、我々に何かタスクをさせる＝データを提供させることをしないと気が済まないのか、どうしても何らかのデータも出すことが落としどころになってしまうこともあります。

なお、結果的に彼らの目的に照らして意味のないデータを提供するという余計な仕事をしてしまっても、それでクライアントが満足するのであれば無駄な仕事ではなかったということで良しとする考え方もありです。

ただこういう仕事が増えてくると、モチベーションに影響してくる担当者も少なくありません。

クライアントのデータリテラシーの問題なのか、データ○○担当に対する先入観のせいなのか、あるいはデータ○○担当がうまく彼らを納得させられていないためなのか、原因は色々考えられます。

データ○○担当としては、そうした原因をそれぞれ解決していくために、クライアント向けにデータ分析の仕事をより理解してもらうトレーニングや啓蒙活動を行うとか、自身のデータ分析スキルや交渉・ファシリテーション等のスキルを磨くなどの取り組みも考えられます。

前置きが長くなりましたが、一方でデータ○○担当としてはクライアントの課題解決に向けてはデータ分析という手段をとることが前提ですが、逆に自らが考え方をそう縛られてしまっていないかということも最近ふと考えます。

データ○○担当はデータ分析で課題を解決できるように、クライアントに目的をきちんと定めてほしいとか、エンジニアや会社にデータおよび分析環境を整えてほしいといったことをよく言います。

しかし、それは必ずしも別の誰かにまかせるべきタスクかというと、そうでもないのかもしれません。

対クライアントでは、データ○○担当も事業目的の理解や仮説出しにより関わろうとしてドメイン知識の習得に力を入れる人もいます。対会社では、データの利用者側としてフィードバックを行うなどエンジニアとともにデータ整備に取り組む担当者もいます。

データ分析周辺の業務に関わることで、よりそちらに主軸を置く判断をした人たちは、データ○○担当からプロダクトマネージャやマーケター、AIエンジニアあるいは専門コンサルタントなどにキャリアチェンジすることもあります。

例えばプロダクトの責任者になった人は、仕事領域は幅広くなり、分析以外のタスクも数多く抱えることになりますが、プロダクトに関して一番の裁量と権限を持つことができます。

また自ら効果的なデータ分析や活用を考えたり実践したりもできるので、分析スキルや経験のないプロダクトマネージャよりも強みを持っています。そのスキルや権限を活用し、プロダクトをより良いものにしていくことに注力できることにやりがいを感じるのも理解できます。

以前データサイエンティストとデータアナリストの違いとして、前者は専門性を高めることを重視し、後者はビジネスへの貢献を重視する傾向にあると考察したことがありましたが、特に後者のタイプの人は必ずしもデータ○○といった肩書に縛られなくても良いのかもしれません。

特にデータ分析スキルは様々な業務において役立つ汎用性の高いスキルだと思われますので、それを活かして次のキャリアをどう選ぶかは広い視点で考えたいところです。

顧客分析をやる前に必要なこと

顧客分析とは、基本的には以前の記事で紹介した通り、顧客をセグメントに分け、そのセグメント間の違いをデータで明らかにすることです。

custle.hatenablog.com

顧客分析を行うケースとは

では顧客分析を行う場面はどのようなときなのか？

例えば見込み客を初回購入客にしたい場合、見込み客から初回購入に至った顧客と、見込み客のままの顧客の違いを分析します。

もし前者の顧客に特徴的な行動などが見られた場合、それを後者の顧客にも促進させることで初回購入につながる可能性が上がる場合があります。

あるいは逆に初回購入につながりそうもない見込み客を見極めることで、不要な販促コストを削減するといったことも可能でしょう。

このように顧客との関係性を改善したい場合、既存顧客のデータから改善の前後のセグメントを分析してその違いを明らかにすることで、改善のためのヒントを見つけるのが顧客分析の一般的なやり方となります。

闇雲に顧客のデータを見て何か探そうとするのは非効率なのは言うまでもありませんが、もしそうした作業に陥ってしまいがちな場合は、その要因として顧客との関係性をきちんと整理できていないというのがよくある話です。

顧客との関係性の定義

顧客との関係性は、一般的には「潜在顧客」⇒「見込み客」⇒「新規客」といったように顧客化するまでの段階であったり、「一見客」⇒「リピート客」⇒「ロイヤル客」のように顧客のLTV（ライフタイムバリュー）を最大化させるための顧客の成長段階で区分されることがよくあります。

CRMに注力している企業などではこうした段階で顧客を区分けして管理されているところも多いでしょう。

こうした区分を設定するのは、顧客区分ごとにニーズやペルソナイメージなどが異なっていたりするためです。

例えば顧客数を増やすための施策を行う際などに、顧客全体に一律の条件や特典で実施するよりも、こうした区分を使って対象ごとに適切な設定を行ったほうが、さらに高い効果を出すことも可能になったりします。

唐突ですが、ソーシャルゲームなどでは新しいボスキャラを1種類しか出さないとすると、それが強いボスならばヘビーユーザは満足できるかもしれませんが、ライトユーザは全く歯が立たずに楽しめません。弱いボスならばライトユーザは楽しめるかもしれませんが、ヘビーユーザは物足りないでしょう。弱いボスから強いボスまで様々なランクのユーザが楽しめるように設定されるのが通常です。

この区分は非常に大事です。

もしマス向け（顧客全体）の施策1種類しか実施しないのであれば、顧客のセグメント間の違いを明らかにする顧客分析は不要といってもいいのかもしれませんが、そうでないのであればこうした区分を設定しないまま顧客分析に取り組んでもあまり成果は得られません。

ダメな例としてよくあるのは、顧客のニーズ等の違いがあることを認識しないままマス向け施策を実施したにも関わらず、結果を分析するときになってなぜか顧客を詳細に区分してデータを見ようとするなど、ちぐはぐなことをやってしまうケースです。

こうしたケースにおける顧客の区分も、かなり適当に行われることが多いです。

先ほど紹介した「顧客化するまでの段階」や「顧客の成長段階」といった区分ではなく、単なる性年代別とか、新規客と既存客に分けるだけとか（既存客も詳細に設定したがる人が多いですね、準既存とか復活とか）、ありもののデータを使った区分がよく使われるようです。

ちなみにこうした適当な区分でデータを見て、もし仮に新規客がたくさん獲得できたということが発見できたとしても、なぜ新規客に響いたのか理由が特定できないので、基本的に再現性もなく次の施策にも活かせないということで特に意味のない発見だったというのもよく聞く話です。

目的が顧客との関係性の改善であるならば、顧客との関係性が現状どうなっていて、それがどのようになれば良いのかということを具体的に定義しなければなりません。それをデータで定量的に示すのが顧客分析の使い方となります。

そのために、当たり前ですが、分析官自身も自社の商品・サービスについてきちんと理解する必要があります。

顧客のどのような課題を解決するものなのか、それはいつどのように利用すれば効果が出るのか、それをどのような顧客にどのように伝えれば響くのか、また顧客はどのように認知するのか、競合との違いなどなど。

とりあえずデータを見てみようではなく、まずはいち顧客として商品・サービスを試して顧客を知る、そして多様な顧客の視点を学び、顧客との関係性を具体的に整理することから始めてみるのも良いかと思います。

データ分析の失敗事例その３

今回は先々週に書いてたデータ分析の失敗事例の続きです。

分析結果が採用してもらえなかった

前回の「分析しただけで終わってしまった」とは少し似て非なる失敗です。

こちらは、分析目的は明確であるがそれを達成するのに十分な分析ができてなかったというケースです。

ふたつのケースがあるかと思います。

ひとつは分析設計が怪しい（間違っている）という場合です。

過去記事でもよく述べてますが、比較を行うときのコントロール（対照）設定は分析経験の少ないアナリストであれば非常に間違えやすいので、クライアントにある程度知見のある人がいると、怪しい分析設計は見抜かれてしまいます。

また、アナリストは分析をする際にデータが見れる分、細部にこだわってしまう傾向が見られるので、本来の目的とずれた分析をしてしまうことも時々あります。

例えばとある施策の効果を検証するのに、ある会員セグメントには効果があるが別の会員セグメントには効果がなかったという分析結果を報告して、そもそも肝心な施策全体としての効果を算出していないなどです。（木を見て森を見ずのイメージ）

あるいは施策全体で見たときに効果がなかったために、それで報告が終わると宜しくないと感じたのか、どこかに何らかの効果がないかデータマイニングに走ってしまい、誰も求めてない効果検証をしてしまうなどもよく見ます。

そもそもクライアントが求めているものを提供できていなかった場合は、当然それが採用されることもありません。

もうひとつのケースは伝え方の問題です。

分析結果をまとめた資料が分かりにくい、分析結果を報告するプレゼンが分かりにくいと言われてしまったという経験も多くのデータアナリストがしていることでしょう。

専門用語をわかりやすい言葉に翻訳せずにそのまま使ってしまったり、論旨の展開がきちんと整理されていなかったり、一枚のスライドに多量の情報やデータを詰め込みすぎて見づらかったり、グラフや表の見てもらいたい点にマークがついておらずにどこを見ればよいか気づきにくかったり、結論までに非常に回りくどい説明を延々と続けてしまって前の話を忘れられてしまったり、定義が定かではない抽象的な言葉を連発してしまったり、話に抑揚がなく伝えたいポイントとそうでないポイントが見分けにくかったり、、、、。

きりがないのでこの辺でストップしておきましょう。

分かりにくいと言われてさらに詳しく説明しようとして、より一層相手を混乱させてしまうというドツボにはまる場合もよくあります。

このような場合では、クライアントが分析結果をしっかり理解できていないため、当然次のアクションにもつながりません。クライアントにきちんと伝わっていないのであれば、十分な分析ができているとは言い難いのではないでしょうか。アナリストだけが理解している状態で終わるのではなく、クライアントや第三者にも理解できるような形に整理するところまでがデータ分析の役割ではないかと思います。

こうした課題は本人ではなかなか気づきにくい点も多いので、なるべくなら事前に誰かにレビューしてもらうのが良いのですが、なかなか簡単に改善できることでもないので、慣れるまでのそれなりの時間の事前レビューが必要になります。

時々チーム内でワークショップなどを行い、お互いレビューし合うなどの取り組みもおすすめです。

なお、クライアントから依頼された場合ならともかく、アナリスト側から提言を行おうとする場合などは、より一層分析結果を聞き入れてもらうハードルは上がります。

根気よく説得しようとしてもなかなかアウトプットを理解してもらえず結局諦めたとか、データで示しても納得してもらえず話を脱線させてうやむやにしようとされたなどの失敗を私も経験してきました。

このようなケースでは感情的になったり精神的に未熟な部分が原因という面もあるので、冷静かつ根気強い、でもこつこつ正確にこなせてマメで流されにくい人なら成功確率が上がるのかもしれません。自分もそうした精神面での成長は引き続き必要だと感じます。

あと余談ですが、データ分析の専門家という立場にいると、クライアントを含めその周りにいる人たちは自分よりも知識が少ないと見下してしまいがちな人も時々見かけます。そうした人たちが明らかに知らないであろう専門用語をあえて使ったり、専門家の自分が言うことは全て正しいと口を挟む余地も与えないような言い方をしたりされてます。自らの専門性に自信があるならまだましなのですが、素人よりも少し知識があるという程度でそうした振る舞いをしてしまう人もいました。そのような人は自分よりも経験者の前と未経験者の前で態度が180度変わるので、見ていてドン引きでしたね。

いずれにせよそうした傲岸な態度でいると失敗したときにより一層恥ずかしい思いをしますし、信用を一気に失いかねません。

データアナリストも人間なので100%間違いはないとはいえません。クライアント等仕事で関わる人たちの中にも、自分よりも知見のある人や自分では気づかなかった点を指摘してくれる人がいることもあります。一緒に仕事をする人には、いたずらに専門性をひけらかすようなことはせず、敬意をもって向き合いたいものです。

custle.hatenablog.com

custle.hatenablog.com

ヤフーとLINEの経営統合に伴うデータ分析環境

11/18にヤフーとLINEの経営統合が発表され、色々な関連ニュースが飛び交ってますね。

各社のユーザにとっては、この経営統合によって主に利用サービスがどう変わるのか、あるいは変わらないのかは気になることと思います。

私としてはデータ分析視点でどう変わるのか想像してみたいと思います。

※なお私は両社の関係者ではないので、あくまで勝手な想像に過ぎないことはご了承ください。

統合というものの範囲や領域がどこまでになるかはまだ不明ですが、データの統合もある程度は進められると思われます。

データを統合する上で、起点となるのは会員のIDです。

ユーザIDの紐付けと統合

まず最初に行われるのは両社のアカウントを持ってる会員の紐付けだと思います。

例えばAさんが元々LINEとヤフーのユーザであった場合、それぞれのIDが発行されています。

LINEやヤフー側は統合によってそれらIDデータ（およびその各種ログ）を入手できますが、それぞれのIDからそれが同じAさんのものであるということは通常わかりません。

各社の個人情報等のデータから同じ人であるかどうかの突合せはできないことはないかもしれませんが、情報が不十分であったり不確実である可能性もあります。

間違って別の人がAさんのデータを参照できてしまうようになったりすると大問題なので、多分同じ人であろうという推定で判断するわけにはいきません。

ではどうするかというと、Aさん自身に自分の持つLINEのIDとヤフーのIDは同じものであるという紐付けを実施してもらうことになると思います。

ユーザにとっては少々面倒な作業なので、おそらく何らかのインセンティブを付けて紐付けを推進するキャンペーンが実施されるのではないでしょうか。

もし紐付けができれば、LINEとヤフーで共通のユーザID（のようなもの）ができたということなので、個人情報の管理やポイントサービスなども共通化され、まとめて使えるようになるかもしれません。

ただし、これだと元々LINEとヤフー両方のサービスを利用していた会員しか対象になりません。

折角なのでこの機会にお互いの未会員も取り込みたいでしょうから、LINEしか使っていない人にはヤフーのアカウント作成を、ヤフーしか使っていない人にはLINEのダウンロードとアカウント登録も積極的に狙っていくと思います。

というか、この取り組みによってそれぞれの会員数を増やしたいというのが両社共通の第一目的でしょう。

ログデータの連携

そして、IDの紐付けができれば、データを連携することが可能になります。（もちろんユーザ側の許諾を得た状態が前提ですが）

例えば、最近LINEで最新家電について会話していたAさんが、実際にヤフーで家電について検索を行っていたり、あるいは実際にヤフーショッピングでその家電を購入していたかどうかまでわかるようになります。

これを１つのSQLで検索できれば、データアナリストにとっては大変便利でしょうね。

ただ、それができるにはデータの管理環境の統合まで進める必要があるので、それなりに時間がかかることでしょう。

また、さらにお互いの広告媒体にお互いのログを活用したレコメンドを実装するのも、それなりの時間がかかると思いますが、いずれできるようになるのを目指すと思います。

お互いのデータの活用方法

データがどのように活用されていくのかについては、新たなデータが増えることでこれまでにない分析が可能になり、そこから新たなサービスや機能が開発されていく、なんてことは理想ではあります。

ただ、基本的には会員数拡大が事業としての第一目標と思われるので、会員数拡大に向けてのサービスやインフラの統合がまず進められていくことと思われます。

その際にログデータも連携されるようになることで、新たなデータ活用を行うというよりは、これまでのデータ活用をさらに推し進めていく方向がまず基本でしょう。

おそらくこれまでも広告のターゲティングなどは行われていたでしょうから、それがログデータの量や種類が増えることで、さらに強化されることは想像されます。

特にLINEのチャットデータとヤフーの検索データは、それが統合して使えるとかなりの部分でユーザのその時点での興味・関心の方向性がとらえられるようになるのではないかと思うので、非常に有用性が高いことでしょう。

また、より両社のサービスをユーザに利用促進させるために、両社のサービスを使ったほうがお得であるという仕組みもどんどん開発されていくことでしょう。

基本的には、キャンペーンやポイントサービスなどでインセンティブがどんどんばらまかれる方針かと思いますので、行動経済学が好きな私としては、どれくらいのインセンティブをどのように宣伝すれば、どれくらいの会員がサービスを使ってくれるようになるのか、その塩梅の分析などは非常に興味があります。

ついでにユーザの需要喚起の起点として、友人たちとのチャットなのか、検索ワードなのか、それらは商品・サービスごとにどのように異なるのかも調べてみたいですね。

例えば「タピオカ」が流行っているのは、口コミ等で広がったのか、何かのニュースやWebサイトなどがきっかけなのか、また広がり方はどのようなパターンなのか、「タピオカ」以外のものだとどう広がるのか、など。

まああくまでデータの統合が進んでからの話ですが、特にヤフーでは検索データを使って選挙の予測など行われていたりするので、こうした研究のような分析もある程度独自に進められていたりするのかもしれませんね。

今後、両社から新たにデータや分析に関するニュースリリースや事例などの発表にも注目して期待したいところです。

データ分析の失敗事例その２

前回に続いて他の失敗事例の紹介です。

分析しただけで終わってしまった（次に何もつながらなかった）

これもよくある失敗事例かと思います。むしろこの経験のないデータアナリストなどいるのでしょうか？いや多分いないw

原因として非常に多いのは、「目的」がないままとりあえずデータ分析にとりかかってしまったというパターンですね。

クライアントと目的とすり合わせができていないとこの失敗に陥りやすいです。以前の記事でも書きましたが、クライアントは通常何らかの意思決定やアクションを行うに当たって、どのようなデータがあれば判断できるのか、そのデータの具体的な定義はどういうものか？にまで落とし込んだ状態でデータアナリストに依頼していくるということはほとんどありません。たいていは、例えばこんなデータがあれば何か気づくかも？とか何か役に立つかも？といったふわっとしたレベルで依頼をしてきます。仮説すら立てていない状態ということも少なくありません。

一応は何らかのリクエストが飛んでくるので、真面目な人ほどその依頼がそもそも必要なことであるのかどうかを確認するなどよりも、まずは依頼にきちんと対応しようとするのではないかと思います。特に依頼者がえらい人であったり、他部署のあまりよく知らない人であったりすると、なかなか「この依頼の目的は何なのでしょうか？」とか「そもそもなぜこうしたデータ／分析が必要なのでしょうか？」といった質問もしにくいのではないでしょうか。

もし仮に踏み込んでそうした質問をしたとしても、「とりあえずデータを出しさえすればよい」「必要だから依頼しているんだ」といったようなことを言われ、依頼事をごり押ししてくる人も少なからずいます。そうなるとより一層、躊躇してしまう受け身型のアナリストになっていってしまうことさえありえます。

私の場合はそのようなクライアントに対しては、2パターンの対応をします。1つはそれでもあくまで目的のすり合わせを行うことを主張する、もう一つは諦めて言われたことだけをやるというものです。

元々なるべく依頼された分析やデータの必要性についてクライアントとまず最初に議論し、本当に必要なデータや分析はどういったものかを明確にしてから作業に取り組むようにしたいと私は考えており、実際にそうしているので、前述のような最初の議論をしようとしない人々に対しても、まずは1のパターンの対応を試みます。

ここで非常に重要なのは、最初からけんか腰になったり相手を詰めている風に思われてしまうと、相手もより意固地になったりするので、言い方はマイルドになるように気を付けます。（以前はちょくちょくこちらも感情的になったりして、ヒートアップしてしまう失敗もよくやらかしましたw）

言い方や説得の仕方で相手を納得させられれば、「目的のすり合わせ」に到達できます。できない場合は自分の対応の仕方に課題があるのではないかと思って、どうすればうまく相手の理解を得られるかを考えて、コミュニケーションスキルの向上に取り組めばなんとかなる類のものかもしれませんね。

しかし世の中には、多少のコミュニケーションスキルでは如何ともしがたい聞く耳をもたない人たちもおられます。そのような人たちに納得させるには、優れたコミュニケーションスキルを持っているデータアナリストであれば問題ないかもしれませんが、自分ではなんともならないと感じると、諦めるのもひとつの手だと思ってます。そのようなことに労力をかけるよりもさっさと依頼に応じて次の仕事にとりかかったほうが生産的な場合が多いので、ある程度そうした割り切りや妥協も必要なことなのかもしれないと思います。

２つめの割り切りや妥協は失敗事例と呼んでもよいものかどうかは微妙ですが、最初のコミュニケーションの工夫は失敗が起こりやすい分野です。データ分析人材は分析スキルさえ高ければ良いというのではなく、そのスキルを活かす場や環境があってこそなので、そうした環境にたどり着く、あるいはそうした場を手繰り寄せるにもスキル・努力・運などは必要です。分析人材だけでビジネスは回りません。うまく他のメンバーとコラボレーションできるスキルも必要性を感じる場面は多々あります。最もそれは分析人材に限らずビジネスマン全般に言えることですけどね。