データリテラシーは人に教えられるのか？　メルカリのデータアナリストが語る、“ゆるふわBI ”によるリテラシー教育とは

データリテラシーをどう教育していくか

備前光隆氏（以下、備前）：ありがとうございます。お三方に共通してデータの民主化や環境という話が出ました。数字が出ているだけだと、（人によっては）数字の見方がわからなかったり、リテラシーが低さから間違った解釈をしたりする可能性はあるじゃないですか。

そのあたりの社員教育というか、社内・組織教育ってどういうことを取り組みとしてやられていますか？

牟田博和氏（以下、牟田）：難しそうですね。

備前：どんどん（マイクを）回していいですよ。しゃべれる方でぜんぜん大丈夫です。

樫田光氏（以下、樫田）：データリテラシーってすごく難しい問題かなと思っていて。さっき牟田さんもおっしゃったとおり、民主化って範囲をどこまで含めるかという問題が1つあるかと思います。

実は僕が今運営しているBIチームのなかには、『レ班』と『デ班』というものがつくられています。デ班とは何かと言うと、”Democratize班”の略称です。レ班というのは、”Reinforce班” です。

住み分けとして、レ班は “BIチーム自体をどうやったら強くできるか” ということを考えるチームで、デ班というのは “BIチームの外に分析をどうやって伝播していくか” ということを考えるチームです。ある程度人数を振って、オーナーシップを持ってやってもらっています。

実は今日、デモクラタイズ班のオーナーの松田（メルカリBIチームの 松田慎太郎氏）を連れてきているので、もし興味がある方は懇親会で話しかけてみていただければ、いろいろな話をしてくれるんじゃないかと思います。

階層構造で考えるデータリテラシー教育

さっきの話に戻ると、教育するといっても、ありとあらゆる社員のデータリテラシーを一気に上げようとすることではなくて。まずBIチームがあって、その周りに準BIみたいな人たちがいて、さらにその外側にはあまりデータリテラシーのない人がいる、といった階層構造をつくることかなと思っています。

外側の世界のタスクや依頼が、BIチームにぜんぶ集まるとけっこうキツいんです。僕らがやっていることというのは、すでにそれなりにデータリテラシーがあったりとか、分析したい欲求がすごく強くて、かつセンスがありそうな方々を優先的に教育していって。その方々が、さらにその外の世界にいる、あまりデータが得意じゃない人の依頼や相談を聞くというような形をとると。

（彼らのことを）僕らは「ゆるふわBI 」と呼んでいます。僕らBIチームが地球としたら、その周りにゆるふわBIをオゾン層のようなかたちでまとって、外からの依頼が来るのを防ぎつつ、自分たちの力でオゾン層をなるべく育てていく、ということをいま頑張ってやっています。

ですので、全社員のデータリテラシーを一気にガッと上げるというよりは、準BIというのを鍛えていって、その人たちから伝播していくかたちで全社員に広がればいいかな、というステップ・バイ・ステップで考えている状況です。

いろんな人が見るものだからこそ、データの定義が必要

備前：社員教育について、ほかにもなにかありますか？

鉄本環氏（以下、鉄本）：さっき「ゆるふわBI」ってお話があったと思うんですけど、うちの場合は、他チームのデータに興味がある人を「BIチームから派遣しているメンバー」ということにしてしまって、@bi-allというSlackのグループメンションをつくったりしています。

やっぱりデータに興味がある人って、勝手に入ってきてくれるんですよね。ですので、その人たちに1回権限を与えたり、一緒にペアワークしたりというところで、私たちの知見を渡していって、そこから伝搬させていくというのをやっています。

あとは組織的にデータの重要性を押し出すということもやっていますね。チームだけじゃなくて、例えば経営層とかも巻き込んで、どれくらい定量的に数字を見ることが大事なのか、というところは節目節目で押し出してやっています。

もう1つやっていることとして、データの定義がわからないと、すごくハードルが高くなってしまうと思うので、そこの定義や、何を重要視しているのかを明確に示すということをやっています。

そうすると、ハードルが1段下がって、定義についても深掘りして聞いてくれたり、何か作業をしようと思ったときに、この指標を見ていれば施策を進めていいんだというイメージが、具体的に湧いていくので。そこをとっかかりにまたBIチームに入ってきて、@bi-allのメンバーになっていくという流れが増えるかもと思っています。

備前：おっしゃるように、データの定義ってむちゃくちゃ大事ですよね。そこがふわふわしていると、出ている数字もまずもって定義の解釈が違うし、出ている数字の解釈自体がもう間違ってくるし。数字って、いろんな人が見るので、定義をしっかりするというのは、本当に大事なことですよね。

それから、ビジネスマンである以上、数字ってつきものじゃないですか。そんなに難しい話をしているわけではなくて、それはもうベーススキルとして身につけようよという感覚は、我々としてはつくっておきたいですよね。

データという機密情報の扱い方の啓発

備前：牟田さんのところは何かありますか？

牟田：私はちょっと違う視点でお話しするんですけど、弊社に特殊な事情として、ユーザーさんの機微な情報を扱っているんですよね。

なので、「機微情報を正しく取り扱う」「そもそも法律に触れない」という話は、めちゃくちゃ重要です。だから、その辺の啓発はすごく重視してやっているし、これからもやろうと思っています。

このあとの話は、先ほどの鉄本さんと似たような話ですが、我々はデータを広く使ってもらうための環境（yanagishima, OASISなど）を自社開発をしています。そういうものを使って、会社のデータ民主化を進めようとしています。

評価としてわかりやすいのは、ユーザーに与えたインパクトの大きさ

備前：ありがとうございます。話題を少しだけ変えて、今日いらっしゃっているみなさまも、なにかしらの組織に所属していると思いますし、その組織また経営しているみなさまからの評価もあると思います。僕らって、なにをしたら評価してもらえるんですかね？

牟田：すごく難しい話ですよね。

備前：これは僕もマネジメントでけっこう難しいなと思うところがあって。事業に直結するような意思決定を促すデータを整理提示して、動かすことはできますよね。実際に事業成果が出ましたっていうのは、出るケースも出ないケースももちろんあると。

そういうときに、なにを評価してもらったらいいんだろうっていうのが、ちょっとした話題なんですけど。そこって各社さんはどうですか？　これは牟田さんから戻っていきましょうか。

牟田：チームとして、例えば会社の経営陣とかにどう評価されたいかという話ですよね。はっきり言って、私たちの会社も整備されているわけでもなくて、視点がちゃんと共有されているわけでもありません。

ただ、そういう状況でも今の経営陣からは、機械学習チームとかData Labsの他の組織も含めて、データってすごく重要で、うまく活用してくれてるから、今も評価しているしこれからも頑張ってほしいんですよって話はしてもらっていて。じゃあどうやって評価しましょうかって話になると、やっぱり一番わかりやすいのはユーザーにどれだけインパクトを与えたかですよね。

売上を増やすだったり、アクティブユーザーを増やすだったりなんですけど、それだけだと測れない部分もすごくいっぱいあるので。私がメンバーに対して言っているのは、人をどれだけ動かしたか、というところを心がけて仕事をしてねということです。

人というのをユーザーとして見ると、アクティブユーザーや売上になります。社員、例えば同じプロジェクトのエンジニアや企画者として見ると、その人たちの意識変容をどれぐらいのインパクトで、何人ぐらいに対してできたか、というところで私はメンバー評価をしています。組織としての評価もそういったイメージにしたいなとは思っているのですが、それを定量化するのは難しく、やっぱり課題ではあります。

プロジェクトとして立ち上げられるかどうか

備前：お二方は、どうですか？

鉄本：評価ですよね。うちも正直すごく難しくて。前提として、私も常々悩んでいます。ただ、ミッションとして意思決定にどれだけ貢献したかを重視しています。見ているものとしては、どれだけ他チームからBIという名前がでてくるか、というところはわりと見ています。

横断チームとして動いているので、他のチームからどれだけ必要とされたかというところが、データ活用に組織として貢献してるところかなと思います。いかにいろんなチームとデータにまつわった施策ができるかどうかですね。

あとはプロジェクトとして立ち上げられるかどうか、というのも見ています。データ活用したいシーンは、いくらでもでてくると思っていて。それがどれだけ価値のあることかをきちんと見極めて、具体的に落とし込んで、プロジェクトとして発信できるかどうかで、本当にデータ活用できるかどうかが変わってくると思います。

ですので、関わっているチームなどの数と、プロジェクトとしてきちんと立ち上げて完遂しているかどうかを見ます。

備前：評価について、Sli.doがめちゃくちゃ盛り上がっているみたいです。みなさま、けっこう悩まれているんですかね。2部でも、もう少し具体的にお答えできればと思いますので、気になるところをどしどし投げてください。

データ分析を評価する3つのフェーズ

樫田さんとたぶん同じような話かもしれませんが、1個だけちょっとキャッチアップできたので（ご紹介します）。「行動量と成果量を◯対◯の割り合いで、データ分析という業務を評価していますか」。行動量と成果量は、なかなか難しい質問ですね。

樫田：1つ目の質問からお答えさせてもらうと、どう評価されるかというのは、けっこう難しい問題だと思っています。ただ、分けて考えると3つの段階があるんじゃないかなと思っているんですね。

ステップ1は、「言われた分析ができる」と評価される、というフェーズ。

次のレベルとして、ステップ2では「言われていないのに分析できる」というのがあると思います。要は、先回りして言われていないことをやっていたり、もしくは、もともと依頼したいと思っていた想像を上回るような切り口や見方で分析する、というのがあると思っているんですね。

これをクリアすると、すごくややこしいことが起きて、『分析官らしくないことをしているところが評価される』というステップ3のフェーズが来るかなと思うんですね。

これは大いなる矛盾かなとも思っています。

最近だと、経営陣から期待されたり、評価・フィードバックとしてもらうのは、データアナリストの枠に縮こまらずにとか、いろいろやってほしいというものです。人と人をつなげる役割を担ってほしいとか、成果責任を負ってほしいとか、施策を積極リードしてほしいとか言われる。

自分たちはなんとなくデータ分析をするんじゃなくて、データアナリストではない動きみたいなところが、逆に評価されるフェーズが来るかなと思っていて。

データ分析って何かと掛け合わせることに意味があるということを、経営陣がなんとなく感じている証拠かなとも思っていいます。データ分析と何かを掛け合わせる。例えば人を動かすだったり、むしろものを教えるだったり。それこそ人事などの評価もそうなんですけど、掛け合わせるってところにすごく重きを置いていて、単純に分析そのものを越えたものが、やっぱり最終的な分析の到達点だと。

その感覚が社内にあるのは、僕はそういうこと（経営陣の意識）かなと思っているので、分析官以外のことを言われると辛いんですけど、まあ、いいことだろうなとポジティブに受け止めてがんばっています。

上位10パーセントの人は誰からも評判がいい

2つ目の質問については、僕は分析のマネージャーなので、チームのメンバーを評価するときはどう評価しているかっていうと、2つ観点があります。

1つ目はまず、どういう観点で見て、どういうフィードバックをするかというのは、自分のなかでガチガチのフレームワークみたいな評価基準をつくって、それで考えています。ただ、最終的な評価というのは、敢えてはっきり言ってしまうと社内での雰囲気で決めています。

こう言ってしまうと身も蓋もないんですが、やっぱり人間の脳みそはそんなにうまくできていなくて。例えば100人を評価の良い順に上から並べてくれといったときに、それをちゃんと解像度高くするのは無理かなと思っている部分があって。僕の考えでは、こいつは間違いなくトップ10パーセントだっていう人は、たぶんわかると思っています。

逆に圧倒的に最下位10パーセントだっていう人もわかる。ただ、その間の人たちについてはそこまでグラデーションの区別がつかないんじゃないかなって正直思っています。

トップ10パーセントがなぜわかるかと言うと、トップは基本的には誰からも評判がいいからです。僕はそれを信じていて。評価ってすごく大事なんですけども、僕はやっぱりみんなにトップ10パーセントを目指してほしいって気持ちが強い。自分は上位55パーセントじゃなくて、上位45パーセントの人材なんだ、みたいなところで争うというのはしてほしくない、と身も蓋もないけど僕はそう思う。

それとは別に、きちんと評価するフレームワークは持っていて、それはちょっと話すと長いので、あとでスライドを投げておきます。

潜在化されたお題を発掘できるプレイヤーの価値

備前：ありがとうございます。鉄本さんのところも樫田さんところも、比較的社内の評判というか、そういう定性評価も加味されてる感じですかね。

樫田さんがおっしゃったみたいに、いい人って何をやらせてもいいんですよね。いい評判ってすぐ耳に入ってきて。なので、そのトップ10を見極めるっていうのもすごく必要だし。

先ほど環境整備の話もさせていただいたんですけど、僕のところはそれを標準化とすると、顕在化されたお題をいかに跳ね返していくのか、というのは比較的できるというか、やらなければいけないことで。潜在化されたお題をいかに発掘できるか、というところができるプレイヤーは、すごくいいなと思っています。

どういうことかと言うと、だいたい僕らの組織って経営直下なんですけど、経営陣からお題を渡され、それに対するアウトプットを出すのではなくて、一歩でも二歩でもいいので、先回りをして、「あ、そういうことがあったのね」と。実は自分は知らなかったけども、こういう気付きがあったわ、というところが先回りできているようなプレイヤーは、比較的評判がいいというか。経営陣からも支持される人材が多いかなという印象があります。

すみません、実は第1部が残りあと10分もないんですね。最後にぜひ、明日から各チームで活かせるような刷新的な取り組みについて……このパネルで言うと運営などになると思うんですが、そういった（ことについて）取り組んでいることってありますかね？

僕のところから言いましょうか。チームは各自散っていくので、チームのメンバーが一堂に会する機会というのは限りなく少ないんですよね。ですので、日頃やっているものをアウトプットする、共有する、横展開する場を意識的に、ほぼ強制的に設けてます。

そうでもしないと、事業ドメインも違うし、やっていることも違うので、そもそも横展開できるかどうかもわからない共通項が少ないものなんですが、そのなかでも1個でも2個でもピースがあって、それを他の事業に活かせるのであれば、それはすごくいいことかなと思いますので、そういう場を構成していくということはやっていますね。

牟田：その取り組みというのは、主な目的は何になるんですかね？　我々のところも同じようなことをやっていて、メンバーのスキルアップというのもあるし、分析の横展開で事業のレベルアップかな、という感じもあるんですけど。いかがでしょうか？

備前：やっぱり共有、横展開、気づき、メンバーの自己成長とか。人前でプレゼンするっていうのは、経営陣にプレゼンするのと同じかたちですから、そういうところからも訓練はできるわけですよね。

そういう場でプレゼンテーション形式をとって、ちゃんとわかりやすく伝えるというところも、僕は見ていたりしますね。

牟田：しっかりプレゼンテーションをするっていう形式をとっているんですね。

備前：スキルアップというところで言うと、自分たちが考えていることや、見つけたことを適切に情報として入れないと。やっぱり入れ方も気をつけないといけないと思うんですよね。

そこはメンバーにも口をすっぱくして言うところかもしれないです。そうしないと、結果的にやりたいことができないんですよね。

いいことづくしの依頼集約窓口

備前：セッションぽくなってきましたが、もう1部も終了間際なんですけれども。鉄本さんのところは、何かやられてますか？

鉄本：規模にもよると思いますが、うちのチームは今6人でやっているんですね。やっていて一番よかったなと思うのは、依頼の窓口を集約するというところですね。

備前：それ、僕らもやってます。

鉄本：やっぱりバラバラにしちゃうと知見もたまらないですし、同じような依頼をしてしまったりして。あとは依頼の窓口をちゃんとつくったことで、依頼側もどうやって依頼をすればいいのかというのがわかって助かるので、そもそも質の悪い依頼が入ってこなくなったりするんですよね。

依頼の窓口が1つだったら、チームで検知も分担もできます。チームでその依頼を見て、じゃあ誰がやりましょうかというのも、その場で一緒に決めてやっています。

ですので、ビジネススキルもアップできますし、どういう依頼が来ているのかという、会社としてのニーズやトレンドもチームで認識できますし、かなりいいことづくしだなと思っています。

備前：依頼の仕方が適切だったら適切な情報がでてくるので、それは教育上もけっこういいかもしれないですね。

鉄本：そうですね。また、依頼窓口が決まっているので、ほかの人もこの依頼をしようと思ったときに、過去にそういう依頼があったかなって見てくれるのでいいですよ。組織的なデータリテラシーを上げるという意味でも、やっぱり集約されてることって本当に大事だなと思います。

備前：あと依頼が多いものは、もう環境として用意すればいいんですね。最大公約数がとれるというか。僕ら運営サイドとしてのナレッジの蓄積にもなっていくんですよね。

鉄本：そうですね。2週間に1回振り返りをやっているんですけど、そのときにどういう依頼があったかとか、いろいろ見ているので、先回りの対応もできるようになっています。

最高のチームであることを、社内外にどうやって伝えていくか

備前：はい。じゃあ最後、樫田さん、お願いします。

樫田：けっこういろんな取り組みをやっているんですけど、さっきデ班（Democratize班）がやっていることを話したので、僕個人としてやっていることと、もう一方はレ班（Reinforce班）のほうでやっていることもお話ししたいかなと思います。

1つはマネージャーとかチームとしての観点で、もう1つはもう少し細かい分析作業の議論の話です。

マネージャーとして、僕が今一番、頑張ってやっていることっていうのは、まさに今日この場に登壇しているようなこと、もしくはこういったイベントなどを自分でつくっていくということかなと思っていて。

僕は、チームのブランディングやプレゼンスというのは、すごく大事だと思っています。もちろん採用という観点が一番大きいんですけども。社外で情報発信したりしていると、社外の人にも僕たちがいったいどういうことを考えていて、どういうことをしたくて、どういうことをしたくないのか、というのが伝わっていって、社内外のブランディングにもつながっていく、というのはすごくありますし。

あとチームとしてメルカリの分析チームって、まだまだ知名度とか社会からのプレゼンスというのが足りないなとは思っています。やっぱりメルカリの分析チームというのはすごいって、世界から思われているなかで働けると、メンバーとしても誇りになるし、仕事していておもしろいんじゃないかなと。

まず最高のチームであるっていうことを、社内外にどうやって伝えていくか。僕ができることって多くないんですけども、個人の発信や、こういったイベントをやらせてもらうなかでやっていくのも、すごく重要視しています。

分析作業に潜むバグや落とし穴をどうやって防ぐか

もう1つ、レ班のほうでやっているのは、例えば、分析事例の共有とかもあるんですけど、それも事業ドメインが違うと、同じようなスキームがぜんぜん通じなかったりとか、「けっこうおもしろいね」というので終わってしまうこともよくある。

なので、どのチームでも役に立つ最小公倍数的な粒度で、チーム全体の分析の質やクオリティを上げられる活動をテーマにやっています。

例えば、データのアウトプットがあったときに、本当にその数字が正しいか間違ってないかというのを、どうやったら簡単に見極められるかとか、クエリの落とし穴みたいなところをどうやって防ぐか、というところとか。

あと、今までつくったクエリとかをGitHubに嵌められるような仕組みをつくったりという、いわゆる分析そのものというより、分析作業のなかに潜むバグや落とし穴みたいなものをどうやって防ぐか。それによって分析の質を上げるということが、もっともレバレッジするかなと思ってやっています。

備前：ありがとうございました。第1部が時間になりました。けっこう、あっという間の45分だったと思います。これから司会の方からの案内もありますけれど、少しだけ休憩を挟んで第2部に入りたいと思います。

その間、1部の内容でもかまいませんし、こういうことを聞いてみたいというところがあれば、ぜひQAツールをお使いください。

そうしましたら、第1部はいったんこれで終了とさせていただきます。ありがとうございました。

（会場拍手）