仮説の立て方3 原因を考える

以前に仮説の立て方について記事を書きました。

custle.hatenablog.com

custle.hatenablog.com


今回は何らかの問題解決のためにその原因を調べる場面での仮説立案ということで、しばらくぶりですが第三弾の記事になります。


事象の原因を調べる


・売上が急に下がった原因は何か?

・顧客の離脱が増えたがどうしてなのか?

・新規施策の効果が見られないのは何故だろう?


といった場面にて、原因と思われる仮説を色々考えて調査するといった経験のあるデータアナリストも多いのではないでしょうか。


事象を切り分けて問題点を絞り込む


原因を調べる場合は、正解となる仮説にたどり着くのが目的なので、無作為に仮説を考えて検証するよりも、まずは事象の切り分けや問題点の絞り込みにつながる仮説から検証するのが効率的です。


例えばテレビが映らないときに、故障かもしれないと思って修理業者を呼んだけれど、実はコンセントが抜けていただけで無駄足だったなんてことはよく聞く笑い話です。


まずはコンセントやアンテナ線が抜けていないか、リモコンの電池が切れてないかといった単純な見落としがないかなどを調べて、原因がそれ以外なのかを切り分ける方が一般的でしょう。


売上の減少などに関しても、例えば全ての商品で減少が見られるのかそうでないか等を確認しておくと、実は無関係である(減少傾向にない)商品の減少理由を考えてしまうといった無駄なことを避けられます。


事象の切り分け方


過去と同じ問題が再燃したというケースも結構多いので、まずは過去の問題の原因と同じかどうかを調べることから試してみても良いかもしれません。


しかし、もし過去の問題の原因とは別の原因であることが判明したら新たな仮説が必要になります。


その場合は、以前紹介したようにフレームワークを使うなどして漏れや重複のないようざっくりと切り分けていくことになります。


余談ですがITシステムのトラブルにおいても、原因を調べる場合はITシステムを構成するサーバ、ネットワーク、アプリケーション等のどこに問題があるのか切り分けながら範囲を絞り込んでいきます。


売上減少でいえば、マーケティングの4P(Product、Promotion、Price、Place)や3C(Company、Customer、Competitor)などを元に絞り込んでみるのも良いかもしれません。


4Pを元にした場合は以下のような感じでしょうか。

・商品による差
・プロモーションの有無あるいは種別による差
・商品の価格帯による差(競合と比べて相対的価格差が生じていないかも注意)
・エリアやチャネルによる差


例えば上記の差などを調べて、差があるところが見つかればそこを深堀りしていくと原因にたどり着けます。逆に差がないようであればそこは除外して別の個所を調べます。


3Cを使う場合は、自社側に原因があるのか、顧客側に原因があるのか、競合が原因を作り出していないかなどを切り分けるイメージです。


ただ自社側の場合は調査範囲が広くなりがちなので、まずは競合の動きや顧客の反応から調べてみるのが良いかもしれません。


ざっくり範囲を絞れてそこからさらに深堀りしていく際にも、フレームワークや構成要素などを元になるべく抜け漏れがないように調べていくのが基本的な流れとなります。


仮説検証時の注意点


問題点を切り分けようとしたが、実はそれは問題ではなかったということもたまにあります。


売上減少でいえば、例えば比較対象とした時期がキャンペーンなどをやっていて売上が好調な時期だったので、そこと比べて大幅に減少しているのを問題と見なしてしまうなどです。


また細かく切り分け過ぎて原因を勘違いしてしまうこともありえない話ではありません。


またまた売上減少でいえば、平均よりも大きく売上の下がっている商品を見つけたが、その減少額は全体の減少額から見るとほんの一部で、売上全体の減少にはあまり影響していなかったなどです。


あとケースによっては原因特定に至らないことも十分考えられます。これ以上仮説が思いつかない、検証できるデータがないなどで行き詰まるパターンです。


そのような場合はなかなか悩ましいかと思いますが、徒に時間や人のリソースをかけるよりもどこかの段階で諦めるのも選択肢のひとつです。


ただそのときの対応や知見を蓄積・共有したり、新たなデータの取得に取り組むなどなるべくなら次に活かせることにも目を向けたいですね。

アンケート設計のやり方

データを収集するやり方のひとつにアンケートがあります。


調査会社を通じたモニターや自社の会員等に質問をすることで、行動履歴ではわからない顧客のインサイトなどのデータを集めることが可能です。


ただし、裏付けのあるものではないため、嘘や適当に答えた回答データも混ざってしまうので信頼度はやや下がります。


客観的な設計


アンケートで難しいのは、客観的な設計です。


質問の仕方や選択肢のチョイスによっては、回答をある程度誘導してしまう恐れがあります。


アンケートにはある程度恣意的なデータを集めるために実施されるものもありますが、その類のものでは正に意図的にそうした設計が行われます。


しかし調査目的で行う場合でも、客観的な質問や選択肢を作ることができずに、意図せず偏りを生んでしまうこともよくあります。


例えば以下は回答者が答えに窮する可能性があり、結局「その他」や無難な選択肢に流れてしまいやすくなります。

・ひとつの質問に複数の論点がある
・選択肢に漏れがある


また以下のように回答者に負荷を強いると、適当な回答をされやすくなったり途中離脱されやすくなります。

・質問文が長くてわかりにくい
・選択肢が多い
・選択肢に似たものが複数あり迷う


意図せず回答を誘導してしまう情報を載せてしまうこともあります。

・補足情報などに情報の一側面のみしか入っていない
・補足情報などに意見や見解などが入っている
・選択肢のバランスが悪い(出題者の好ましい選択肢が多いなど)


尺度を問う質問でも選択肢の表現によっては偏ってしまう場合もあります。


例えば「満足したかどうか?」は総合的な印象を問うものですが、「役に立ったか?」とか「ためになったか?」だと何かひとつでもそう感じるものがあれば肯定の回答が得られやすくなります。(テーマ等にもよるので全てのケースで当てはまるわけでもないですが)


他にも選択肢が「満足・やや満足・普通」とした場合と「大変満足・満足・どちらともいえない」とした場合はおそらく同じ偏りにはならないでしょう。


少なくとも別のアンケート結果と比較するのであれば表現は統一する必要がありますし、本来聞きたいことは満足度なのか何なのかは予めきちんと検討した上で選択肢を作りたいものです。


深堀りの設計


アンケートでは普段のデータではわからないデータを集める折角の機会ということで、「なぜそう思うのか」や「なぜそう行動するのか」の理由を調査することをよくやります。


しかし、回答者に聞けば答えが出るだろうと気楽に思われているのか、あまりきちんと仮説を立てて選択肢を用意したり、直接的な質問しかしていないような設計のアンケートも多く、おそらく集計してもその結果を活かすことなく終わるというパターンも多いようです。


例:商品Xを購入しない理由を次からお教え下さい

1.価格が高いから 
2.品質が低いから 
3.好きなブランドでないから 
4.その他(  )


上記の質問にて仮に1の回答が最も多く「商品Xの弱みは価格の高さである」ということがわかったとして何に活かせるでしょうか?


まず価格が問題だとしてもアンケート結果から単純に値段を下げられるのか?という問題があります。


さらに、価格を下げることで同時に品質も下げても良いのか、品質を維持して価格を下げるならいくらならば良いのか、など結局悩みは解決されずに次の行動に起こすこともできないのであれば、「元々聞く必要のない質問」なのかもしれません。


そもそも価格はアンケートで聞くまでもなく競合商品と比較すればわかります。もし顧客が商品Xの価格が高いと感じているならば、同価格の競合商品よりも機能や量などの面でコストパフォーマンスが低いと感じているのか、付加価値(低価格の競合商品にない機能等)があまり評価されていないかどちらかでしょう。


質問も単純に「価格が高いかどうか」を問うのではなく例えば各機能の要不要などを聞けば、不要な機能を外してその分価格を下げるとか機能別に商品を分けることで競争力を上げることも可能かもしれません。


他の選択肢の「品質」や「ブランド」もただそれだけを購入しない理由として回答されても如何ともしがたいのは最初から自明なので、そのような質問をしても無駄に終わる可能性が高いでしょう。


ひとつの質問で大雑把な理由を聞くのではなく、知りたいこと/知って意味のあることをあらかじめきちんと整理してひとつひとつ問うのが良いかと思います。


また回答者の「購入しない理由」もひとつとは限りませんし、複数の選択肢を選べるようにしてもそれぞれ重要度が異なる可能性もあります。


さらに選択肢が多くなると上記でも述べたように回答者の読解の負荷が高くなり、回答の質が下がるかもしれません。(個人的には尺度以外の選択肢は「はい/いいえ/(どちらでもない)」の二択ないしは三択がベストかと思ってます)


そういった意味でも「理由」を問う質問のように選択肢が多くなりそうな質問は、分解や分岐によって複数の質問に分けて少ない選択肢になるように設計したほうがよい場合もあります。


例えば先ほどの商品Xの非購入理由の調査であれば、


・購入したことがあるか/ないか


・機能Aは必要と思うか/そうでないか(その他機能も同様の質問を行う)


・機能Aの品質は同価格帯の競合商品と比べて高いと思うか/低いと思うか


・商品Xのネーミングは購入に影響するか/しないか/わからないか


・商品Xのデザインは購入に影響するか/しないか/わからないか


・商品XのCMは購入に影響するか/しないか/わからない(見てない)か


・購入に影響すると回答したものの中でも最も影響の高いものは何か


・今後購入したいと思うか/思わないか/わからないか


などなど、とりあえずいくつか思いついたものをざっと挙げてみました。


他にも商品Xの認知状況の確認や購入経験者ならではの不満なども聞けると、販促手法や商品のユーザビリティにおける課題が見つかるかもしれませんね。


ちなみにインタビューなどでもいきなり核心の質問やオープンクエスチョン(どう思うか?のようにYes/Noで簡単に答えられない質問)をするということはあまりなく、最初にアイスブレイクを入れたり、簡単な質問から始めて段階的に深堀りした質問を重ねていくほうが主流かと思います。


アンケートの回答者もそもそも質問内容(考えや行動の理由)を常日頃から考えていて、いきなり聞かれてもパッと答えられる状態ということはあまりないので、ある程度考えを整理するためのステップ等があった方が回答の質も上がるのではないでしょうか。

データアナリストに必要なコンサル系スキル

データアナリストには最低限データの処理スキルが必要になります。


企業の分析環境にもよりますが、大体はSQLSASSPSSといったツールなどで自由自在にデータの抽出・集計・加工などができることが求められます。


しかし、それだけで十分かというとそうでもありません。


クライアントからどういったデータが必要なのか伝えられる際、そのアウトプットイメージはあまり具体的でなく抽象的なものが多いです。


要件があいまいだとデータ処理に落とし込めないので、まず要件定義をきちんと行えるスキルも必要になります。


例えば「先週のサービスAの顧客数を出してくれ」としか言われなかった場合、1週間の総計を出すのか、1週間分の日別のデータを出すのか、またサービスAの顧客数というのも全体の総計だけでよいのか店舗別や性年代別などのように何らかの内訳も必要なのかなどデータの粒度が不明です。仮に総計のみを出すと、追加で××別にも見てみたいと再依頼されて手戻りが発生してしまう可能性も高いです。


また顧客数そのものについても、のべ客数が必要なのか、ユニーク顧客数が必要なのか(DAUなのか、WAUなのか、現時点でのMAUなのか)、あるいはその両方が必要なのかも確認しておきたいところです。


さらに顧客の定義についても誤解が生じる可能性があります。新規獲得した顧客のことを指しているのか、サービス利用のあったアクティブな顧客を指しているのか、また仮登録などの見込み顧客は含めるのかなど、定義があいまいだとクライアントの求めるデータとは異なる値を集計してしまうことになりかねません。


データを出す場合は、メジャー(指標)とディメンション(切り口)が何かをきちんと定義・確認するのが基本でかつ重要なところです。

【指標】顧客数とは? 【指標】顧客とは? 【切り口】期間の粒度は? 【切り口】顧客の粒度は?
のべ客数?
ユニーク顧客数?(集約単位は?)
その両方?
新規顧客?
アクティブ顧客?
見込み顧客は?
期間総計のみ?
日別?
全体のみ?
性年代別?
店舗別?


最終的にはデータの検索条件にまで落とし込みたいところですが、クライアントはデータアナリストと違ってデータの仕様にまで必ずしも詳しいわけではないので、お互いの認識が合わせられるレベルまで何らかの共通ドキュメントを用意したり、あるいはアナリストが適切に翻訳したりすることも必要になってきます。


そして、できればさらに依頼されたデータがそもそも本当にクライアントの必要としているものかを見極められるスキルも欲しいところです。


言われたデータを出せばクライアントの要求を満たしたことになるのでそこで対応完了としても通常は問題ありませんが、それでクライアントの課題が解決しないということは非常によくあります。


先ほどの「先週のサービスAの顧客数を出してくれ」の例でいうと、実は本当にクライアントが知りたいのは「先週サービスAのプロモーションを実施したのでその効果が知りたい」とか、「先週トラブルがあって解約する顧客が増えたかもしれない。実際どうだったか知りたい」だったとすると、単純に先週の顧客数を出すだけではおそらく足りない可能性が高いです。


通常クライアントはデータアナリストを「課題解決してくれるコンサルタント」とは認識していません。多くは「データ分析してくれる人(単なる抽出・集計含む)」あるいは「データを出してくれる人」と見ています。


よってクライアントは自らの目的や課題解決のためにはおそらくこういうデータがあれば良いだろうと「自分で見積もって」、それをアナリストに抽出するよう依頼してくるというのがよくあるパターンです。


そのため彼らが毎度依頼の背景や目的、それに「なぜそのデータが必要と思ったのか」など詳細まで語ってくれるとは限りません。


彼らの課題解決につながるデータや分析結果を提供したいと思うなら、その部分を省略するわけにはいきません。クライアントが相談してくれないならこちらから聞き出すなどしていく必要があります。


ただ、いきなり「その依頼の目的は何でしょうか?なんのために必要なのか背景を説明して下さい(そうしないと対応しませんよ)」などと言うとクライアントも身構えてしまうので、クライアントの背景や課題をある程度推察してこちらから提案してみたり、依頼内容を確認する中でさりげなく背景や目的を聞き出したりするようなヒアリングスキルもあると良いですね。


こうしたスキルは場数を踏んで失敗しながら学んでいくのが結局は近道なのでなかなか簡単に身につくものでもないかもしれませんが、とりあえずお手軽なやり方として一つ紹介しておくと、私はクライアントには「どんなデータが見たいのか」ではなく「何が知りたいのか」という質問をよくします。すると背景などについても向こうから話してくれることが多いのでおすすめです。


またクライアントが本当に知りたいことは「良いのか悪いのか知りたい」「次にどうすれば良いのか知りたい」「原因が知りたい」などのように大体のところシンプルなものに帰着します。しかしシンプルゆえに詳細まで細かく具体化されていなくて抽象的でもあります。


その回答も関連しそうなデータをたくさん提示してレポート数十枚などになるのは大体NGです。簡潔にまとめないとそもそも読んでもらえませんし、理解もしてもらえません。シンプルな結論にまとめるには、それをデータでどう正しくかつ簡潔に表現できるかといったデザインスキルも必要になります。


先ほどの「先週サービスAのプロモーションを実施したのでその効果が知りたい」だと、平常時の週(先々週など)の顧客数と比較した伸び率を出すなどしたほうが良さそうです。プロモーション未実施の顧客群のデータがとれるならその顧客群の変動率と比較するとより良いです。また今後の実施についても検討したいならば、プラスで別プロモーション時期や別サービスとの比較も判断に必要でしょう。


ちなみにサービスの商品設計において特に性年代別などの分類が考慮されていないならば、性年代別に分けてみる必要はありません。must have のデータ(必要なデータ)とnice to haveのデータ(なくても良いデータ)をきちんと見極めることも簡潔にまとめるためには必要になります。


また「先週トラブルがあって解約する顧客が増えたかもしれない。実際どうだったか知りたい」だと、解約顧客数を解約理由別に集計してトラブルによる数とそうでない数をきちんと区別できるように集計した方が良いですね。ついでに過去と比べてそれらが顕著に増えたかどうかも明らかにするとトラブル影響が明確に把握できそうです。またこうしたトラブルが今後も起こりうるものであれば、事前に対策やフォローがとれるように影響を受けやすい顧客セグメントを分析しておくのも良いかと思います。

正しいデザイン シンプルなデザイン
適切な比較対象の選定・設定
ロジカルな展開の組み立て
must have/nice to haveの見極め
表現力、構成力、伝達力


他にもクライアント等との関係構築力や交渉力、チームワークのスキル、プロジェクト管理のスキルなど色々とありますが、きりがないのでひとまずここら辺までで終了します。


データアナリストがコンサル系のスキルも身に着けて実績を積むと、クライアントから単なる「データを出してくれる人」ではなく「課題を解決してくれるパートナー」と見なしてもらえるようになってきます。データや分析結果をクライアントの意思決定にきちんと活用してもらいたい、ビジネスに貢献できるデータ分析をやりたいという人にはこうしたスキルも必要になってくるのではないでしょうか。

データ集計者のキャリア

データ活用があまり進んでいない企業や組織では、「とりあえずデータを見るだけ」業務が多量に発生してしまいがちです。


そうした企業ではデータ活用のための適切なKPI設計を行える人も、そのために必要なデータの収集や管理を行う人もほとんどおらず、逆に「とりあえずデータを見たがる人」と「そのためのデータ集計を行う作業者」だけになっているというケースが多いようです。


もし前者の業務ができる人が入社したとしても、それらに取り組む以前にデータを見るだけ業務の対応で忙殺されるなどして嫌気をさして再び転職、結果として定着されずじまいなのではないでしょうか。


別途こうした課題を解決するというニーズはあるのでそうしたビジネスのマーケットはあるのですがそれはさておき、そうした企業にいるとデータアナリストの肩書があってもただ言われたデータを抽出するだけのデータ集計者として終ってしまう可能性が高くなります。


特にデータアナリストと名乗っている人であれば、自分たちの仕事はデータを分析することで、依頼者の代わりにデータを集計するだけの作業者ではないという思いから、そうした仕事を嫌がって避けるか、嫌々ながら取り組んでいるという人が散見されます。


今はまだデータを見るだけ業務もたくさんありますが、それに付加価値が伴わないと今後は縮小されていくかそれにかける費用が削減されていくのも想像に難くないでしょう。そしてそれはデータ集計者の収入にも跳ね返ってくることでしょう。


またそれなりの企業であればデータの仕様やツールなど環境面ではある程度整備されているので、数か月ほどかけてそれらに習熟すれば若手でも早期にデータ集計・抽出の業務において活躍することは可能です。(ある程度センスも必要ですが)


つまり多少経験あるアナリストであっても、データ集計・抽出だけの業務しかしていないと評価も上がりづらくなりますし、同じことができる人が増えてくると他との差別化も難しくなります。いずれ物足りなさやキャリアの先行きに不安を感じてきてもおかしくはありません。


必ずしも皆が皆ステップアップしていけるキャリアが用意されているわけではないのはどんな職業でも同じだと思いますが、データアナリストにおいては特にこうしたデータ集計業務に慣れてきたころがその先のキャリアにおいて結構大きな分水嶺になっている気がします。


そのころにはこの先行き詰まってしまいそうだからと転職やジョブチェンジを考える人も増えてきます。


ただ、安易な転職はあまりおすすめしません。ビッグデータがあってもデータ活用が進んでいない企業は意外とたくさんあるからです。環境を理由に転職しても、転職先がまた同じような環境であれば再び同じようなことで悩みを抱えることになるでしょう。


また現状のデータ集計・抽出業務に物足りなさを感じるようになったアナリストには、次に若手アナリストやエンジニアとの差別化につながるのではないかと「高度な分析」を身に着けることや「分析力の向上」を目指す人も時々います。


ちなみに「高度な分析」とか「分析力」って何?と思われるでしょうが、私もそういう言葉をよく使う人に聞いてみてもどうも要領を得ないことが多いのですが、どうやらメインは機械学習のことを指していたようでした。


「高度な分析」や「分析力の向上」とやらはさておき、何らかの差別化スキルを身に着けること自体は良いことでしょう。機械学習も昨今のAIブームや応用性の高さからニーズは高いですね。ただ、多くはチュートリアルを動かすか、セミナーや書籍・Web等で基本的な内容を学習したりすること止まりで、実業務に活かせるレベルにまで到達できる人はなかなか多くはいないようです。(当然ながら専門家と呼ばれるレベルにまで到達できる人も少数です)


実業務に活かすには業務やサービスの企画・設計・調整方面のスキルも必要になってくるので、アナリスト皆が向いているとは言い難いのでしょう。そうした分野が苦手な人は、既に実業務に機械学習を活用している企業に転職するか、(機械学習)エンジニアにジョブチェンジすることを目指す人もいます。


またスキル面で差別化するといっても、当然ニッチなスキルであれば何でも良いわけではなく、ビジネス的な付加価値につながらないとなかなか周りからは評価されません。(そういう意味でも「高度な分析」とか「分析力の向上」とか定義や理由があいまいなものが必要と思いこんだりするのは危険です)


特にそうした面を強く意識する人は、依頼者の意思決定により役立つデータを提供できるよう、彼らの業務や戦略を理解し、マクロなものからミクロのものまでKPIの設計をこなせるようになることにより注力します。さらに彼らの本来の課題を明らかにし解決方針を提示するなどコンサルのようなことまでする人もいます。しかしこれらも元々のデータハンドリングのスキルとは異なる類のものなので、データハンドリング経験を積めばできるようになるものでもなく、ハードルはやはり低くはないかと思います。


また技術者寄りの志向の方には、データ活用を支えるエンジニア方面にシフトする人もいます。どんな人でも気軽に求めるデータにアクセスできるようにレポート環境を整備したり、各種業務におけるログやデータを効率的に収集・管理できるように業務(あるいはその一部)をアプリケーション化したり、多量のデータを取り扱えるようにハイパフォーマンスなDWH環境を構築したり、複雑なデータ処理をしなくても良いように汎用性のあるデータマートを開発したりしています。


今は多くの企業でデータ活用に取り組んでいるので、こうしたニーズはたくさんありますし、そのためのツールやソフトウェアなども多くのベンダーから新たに開発されるなど技術的な革新も進んでおり、技術志向の人にとっても刺激を受ける機会も多くあることでしょう。


いずれにせよ、データハンドリングの経験をある程度積んだ後にもキャリアアップの道は開けていると思います。


ただハードルはその分高くなっていきますし、新たなスキルや経験を積むことも必要になってくるので簡単ではないでしょう。もちろん割り切ってデータ集計者としてやっていく人もいますし、その道も否定されるべきものではありません。ただ、嫌々ながら消極的にデータ集計業務をこなし続けていくくらいならあまりやりがいも得られないと思うので、少しでもクライアントの満足度を上げるにはどうしたら良いか、集計業務自体をより正確により効率的にするにはどうしたら良いかかなどを考えながら取り組むと道が開けてくる可能性もあるかもしれません。私も道半ばですし、行き詰まり感を感じることが全くないわけではないので引き続き色々模索していこうと思ってます。

新型コロナ影響下におけるデータ分析

新型コロナによる影響そのものについては、日々のニュース等によって感染者数の日次推移やエリア別の分析が紹介され、医療や感染症の専門家による今後の見通しなどが語られています。


さらにそうした環境においては、様々な商品やサービスも平常時とは異なる需給状況となっています。


マスクや消毒液などはずっと需要が供給を上回っていますし、一時期はトイレットペーパーや一部の食料品の買い占めが発生していました。


旅行や外食などの業界は自粛の影響もあり、大幅な売上ダウンとなっています。業種によってはお店を閉めたりオープン時間を短縮するなど、サービス提供形態まで変化しています。


一般企業では平常時においてはいかに売上を増加させられるか、コストを削減できるかといった収益面の改善が主たるビジネス目標ですが、今の状況では顧客や従業員の生命や健康をいかに守れるかを一番に考えてビジネスを行うところが多数になっていると思います。


そのため、顧客の来店や社員の出社を制限するなどの環境を前提とした上で、いかに事業としても継続性を保っていけるかというBCPが改めて注目されています。


そうした中データ分析の領域で求められるものは、現状の正しい把握や今後の予兆やリスクを分析することなどでしょう。


新型コロナ影響以前や昨年同時期と比べた需要の変動の確認、平時とは異なる環境下における今後の売上の見立てなどは早期に確認が必要となるでしょう。また今後の戦略を立てる上では、チャネル・商品・地域・体制などどういう形でリスク分散をしつつ事業継続が可能となるか検討されるでしょうから、その際のシミュレーション等において活用するために、現在の売上やコスト、リソース状況などを様々な粒度で分析することも求められるでしょう。


現在の状況では売上の落ち込みやコスト増加などマイナス要素があっても、それが新型コロナが要因であればこちらからのアクションによって改善できる見込みは薄いため、マイナス要素そのものをどうなくすかというよりも、マイナス要素を他でどうカバーするかがよりポイントになってきます。


そのための手がかりとなる客観的なデータを提示して、BCP観点での戦略立案にどう貢献できるかが今はデータアナリストにも求められてくると思います。


売上アップやコスト削減への貢献といったわかりやすい成果は出しにくい領域かもしれませんが、この状況を乗り切ることで大きなやりがいにもつながると思いますし、我々もできることをしっかり頑張っていきたいですね。

データアナリストにとってのやりがいとは

ビジネスマンなら誰しも仕事にやりがいを求めているのではないかと思います。


やりがいを感じられるとモチベーションも上がります。思考や行動もポジティブになります。また結果につながれば待遇や給与にも好影響をもたらす場合があります。


ではどうすればやりがいを得られるのでしょうか。


そもそもやりがいとは一定のハードルを越えた際にそれを自己あるいは他者からの評価によって実感することです。


ありがとうと感謝された、自分が成長できたと感じた、大きな結果を出すことができたなどの場面は正にやりがいを感じる瞬間だと思います。


さて、そうしたやりがいを得るためにはそれなりのハードルを越える必要があります。低いハードルであればなかなか自分や他者からの評価にはつながりにくいでしょう。


そのために自己研鑽やスキルアップが必要になります。


そこで新卒や若手のビジネスマンはまずはとにかくスキルアップできる環境を求める傾向が強いのではないでしょうか。


そしてある程度経験を積みスキルを身に着けてきた中堅になってくると、どのような種類のやりがいを重視するかタイプが分かれてきます。


ざっくり分類すると、高い評価を得たいか安定的に評価を得たいか、また他者からの評価か自己評価かどちらを重視するかで分けられるでしょうか。


f:id:custle:20200411194643j:plain


高評価×他者評価重視


こちらはコンサルタントタイプと思われます。クライアントの課題を解決したり、彼らに実利のあるメリットをもたらすことによって評価されることを好みます。


彼らはクライアントやその関係者から目の前で感謝や労いの言葉をたくさんもらえたり、上司や会社からの評価も上がって自らのリターンにつながるなど直接的かつ明解な評価を得ることでやりがいを感じます。


当然ながら成果の大小によって評価の大小も変わります。高い評価を得て多くのリターンにつなげたいとか直接的でわかりやすい評価を得たいという人はこのタイプでしょう。


安定評価×自己評価重視


こちらは高い評価を目指すというよりも、こつこつと評価を重ねていくことにやりがいを感じるタイプです。


日々の自己研鑽や目の前の課題をひとつひとつこなしていくことで経験を積み、自身の成長を実感したり経験値が上がっていくことに、よりやりがいを感じます。


こちらは技術者に多くみられるタイプかと思います。「継続は力なり」という言葉が好きな人が多そうです。



高評価×自己評価重視


こちらも他者よりも自己評価を重視するという点で技術者と似ていますが、非常に高い評価を得たいという点が異なります。おおげさにいうと、まだ世の中にないものを生み出したいとか、世紀の大発見をしたい、歴史に名前を残したいなどを目指して己を奮い立たせるタイプです。あえていえば、学者や研究者タイプとなるでしょうか。


安定評価×他者評価重視


最後はマネージャータイプです。彼らは個人としての仕事で大きな結果を出すとか自己の成長にこだわるなどよりも、小さなことでもチームに貢献することで周りの関係者などから評価・重用されることにやりがいを感じるタイプです。野球でいえばホームランを打って目立ちたいというよりも、チームの勝率を上げるためにバントや四球も厭わないイメージでしょうか。


このタイプは着実に結果を出して評価を積み重ねていきたいので、他のタイプよりもミスに過敏に反応しやすいかもしれません。しかしその分失敗が少なく信頼感を蓄積していくことができればやりがいや満足感も醸成されていくことでしょう。



それぞれのタイプを先ほどの分類図に貼ってみたものが下記となります。


f:id:custle:20200411194701j:plain


データアナリストにはいずれのタイプも存在します。


データ分析によってクライアントの課題解決や意思決定の支援をしたいコンサルタイプも、各ステークホルダーの縁の下の力持ちとなるような技術者タイプも、新たなアルゴリズムを開発したり予測精度の追求に力を注ぐ研究者タイプも、そして多数のデータアナリストを取りまとめてチームを運営するマネージャタイプもいます。


なお、こうした分け方は一例なので、さらに細かく分けたり別の分け方もできるでしょうが、みな何がしかのやりがいを得られるからこそ、その仕事をしているのだと思います。


もし今仕事にやりがいを感じられなくて環境を変えたいなどと悩んでいたとしても、その前にそもそも自分にとってどのような仕事がやりがいを感じるのかを改めて見直してみることはおすすめです。そして改めて周りを見渡してみると、必ずしも環境を変えなくても自分にとってやりがいを得られる仕事が見つかるかもしれませんよ。


また企業側にとっても、自社のビジネスモデルや各部署・ポジションがどのようなやりがいを重視している人に向いているのか理解することは、採用や育成面で重要です。


さらに企業・組織の成長につなげるためには、各社員のやりがいを充足できるような評価や環境なども合わせて必要になってくるのではないでしょうか。企業の理念やビジョン、コアバリューといった共通の価値観を整えるだけではなかなか十分ではないでしょう。