「ダッシュボードもUI/UXありきで作る」　メルカリの分析チームリーダーが語った“愛されるダッシュボード”を作る意味

筋の良さ・人柄・仕事への姿勢は、教えることができない

備前光隆氏（以下、備前）：今の話で言うと、「採用で未経験者はどういうところを見てますか」とかどうですか。どこを見ていますか？

樫田光氏（以下、樫田）：それこそ、備前さんが答えた方がいいんじゃないですか？　僕は中途入社なんで（笑）。

備前：当社はだいぶ色合いが違うかもしれないんですけど、新卒の採用基準にしても、素直でいいやつを取りなさいという方針があります。やっぱりそれは一理あるかなと思っています。

先ほど樫田さんもおっしゃっていましたが、筋のいい・悪いや、人柄や仕事に取り組む姿勢を、僕はすごく重視しています。そういうところは、教えてあげられないんですよね。

SQLとかそういう手先の器用さは、勉強してやらせたら、それなりに身についていくものではあるんですが、人格や人間力は、組織・チームで仕事をする以上はすごく大事な要素になっている。それさえあれば、もう手先の器用さなんかあとで学べばいい、とけっこう割り切っていますね。

鉄本環氏（以下、鉄本）：うちもけっこう似たようなところがあって、ミッション、ビジョンへの共感をかなり押し出しています。

うちは事業会社で1つのサービスというのもあるかもしれないんですけど、会社やサービスが目指しているところへの共感があれば、自ずと、自分に必要なものに対して動けるようになると思っています。

手先のスキルや、そういったものはいくらでもあとからつけられます。でも、自分で考えて何か新しいことをやろうというのは、会社の向かっている方向に対して共感があるかどうか、というのがないと、違った方向に動いていってしまうということもあり得る。ミッションへの共感はとても重視しています。

各社共通するのは「データ活用による意思決定」

備前：ちなみに、鉄本さんの部門のミッションは何かあるんですか？　共通言語として、「僕たち・私たちの部門は、こういうことをやる部門だよ」ということや、ミッションやビジョンといったものは言語化されていますか？

鉄本：データチームに関しては、「データを活用して意思決定に携わる」というところを見ていますね。

備前：けっこうそこは各社共通ですかね。言葉尻の違いはあれど、同じようなかたちなんですかね。

鉄本：意思決定はわりと、共通ワードでけっこう出てくるワードという認識がありますね。

備前：そうですね。ありがとうございます。牟田さんは何かありますか？

牟田博和氏（以下、牟田）：我々は最初のほうでも申し上げたように、特徴としてデータが大きくて複雑だというところがあるので、基礎的な統計は、少なくとも入社したあとで勉強してほしいとは思っているんですね。

なので、その辺の（数理系の）素養はそれなりには重視しています。その他は、実際に面接でどういうことをやっているかという話を通して回答します。面接のときに、いわゆるケース面接をよくやっています。

コンサルでやっているようなフェルミ推定のようなものではなくて、「こういうときにどう分析しますか」というのをシチュエーションを変えていくつもやります。「この人は数字でものごとを考えられる人だな」「自分がこうやりたいという主体性がある人かな」というようなところを見ています。

現場主導でつくる採用のフレーム

備前：たしかに事前の打ち合わせでも、やっぱりLINEさんはその辺が一番厳しそうですよね。狭き門というか。採用のフレームは、人事主導で作ったのか、それとも牟田さんが主導で作られたんですか？

牟田：私とチームの同僚で作りました。

備前：そうなんだ。なんか外資系のエンジニア採用みたいですね（笑）。コードがこれをクリアしないとだめみたいな。

牟田：そうですね。厳しめに見ていると言われると、もしかしたらそうなのかもしれないです。というのも今は事業の数に対して人がぜんぜん足りない状況で、それぞれの方にはリーダーになってほしい。だから、厳しめに見ているということです。もうちょっと人が増えると、もしかしたら変わるかもしれないとは思います。

1個言うのを忘れていたんですが、実はデータ分析チームは我々以外のところにもあって、その辺を今、整備しようとは思っています。我々はData Labsという組織で、会社全体を横串で見るデータ専門組織の中の分析チームです。

実は、事業部がそれぞれの判断でアナリストの採用を進めているところもあります。データ活用の意識が高いチームが進んでやっているという状況なんです。そこではちょっと違うスキルセットの人材を求めています。採用の一本化や分析体制の整備は、今まさにがんばってやっているところです。

ナレッジ活用のベストプラクティス

備前：ありがとうございます。けっこう時間も限られてきました。あと15分なんですが、お題を変えまして、仕組み化で工夫していることや、ナレッジの蓄積・活用・一般化が気になっているという方が、けっこう多いです。まずは実務的なところからいきましょうか。

「クエリの管理方法を知りたいです。昔こういうクエリをやったから、これを見てという流れを作りたいけれども、どういうことをしていくべきなんでしょうか」。これは、普通にクエリを管理していますよね。

鉄本：そうですね。うちはレビューとかもしやすいので、Git（注：GitHub）を使っています。ただ、本当に簡単なアドホックのものだと、Redashにそのまま登録してしまうので、Git化しないものもあります。けっこう何回も使うものや重要なものを（Git化します）。

備前：あと、ベースの定義のところとか。

鉄本：そうですね、ベースとして利用するものはGit、アドホックのものはRedashっていうかたちで（管理しています）。

樫田：うちも同じくGitを使ってます。クエリレシピというディレクトリを作って、そこに必要なものとして意識的にためていくっていう感じです。

鉄本さんと同じで、アドホックなものに関しては、そこにちゃんとコミットされるいうよりは、スプレッドシートや、アウトプットのWikiのほうにペタッと貼られるということがけっこう多いかな。

クエリを貯めてさらにそれを再活用する仕組みをがんばってはいます。例えば、Slackからコマンドで「/query_search sales」と打つと、salesというキーワードが入っているクエリがSlack上でバッと返ってくるようにやってはいます。

クエリを投入してくれる人は思った以上に多くはないので、もっと簡単な仕組み、走らせたクエリの中で、本当にワンボタンでそれをためられるようにするとか、もしくは全部一旦ためてしまって、それをうまく機械的に抽出して必要なものだけぶち込むとか、という仕組みにしないとだめかなと思っています。

話としては難しいかなとは思っているんですけど、ありとあらゆる場面に対応したいというレベルのニーズを1回下げれば、一番ベーシックなもの、ちょっと変えればOKというものを、Gitで管理するというのが今のところはベストプラクティスなんですかね。

アナリストが全員Gitを使えるわけじゃないという問題

牟田：私たちのチームにルールはあまりないんですが、設立当初からの数少ないルールがまさにその話です。分析レポートをいつもWikiで作るんですが、分析レポートに紐づける形で、分析に使ったSQLクエリやRスクリプトを必ず管理してください、というルールにしています。

分析レポートに紐づけてやると、なにがいいかというと、再現性が必ず担保できますよね。だから、そこをすごく重要視しています。

さっきの教育の話にも繋がってくるんですが、こういうクエリを流したらこういう結果が出て、こういう考察ができるんだというのが一連の流れでわかると、それを見るだけで、先人の肩の上に立てる。そういったことを意識していますね。

ただし、同じようなクエリがいろんなところに保管されているという状況があるのは課題で、何とかならないかなというのはすごく思ってます。

備前：各社とも、自分たちのチーム以外の人たちも、そこのWikiにアクセスして勝手にクエリを回すという感じになっていますね。

牟田：それに近い状況にはなりそうですね。

樫田：ちなみに今、追加質問で、「アナリストが全員Gitを使えるわけじゃない問題」という感じのがありまして。うちの会社は普通にWeb GUIで編集するというか貼り付けて、セーブして終わっています。

クエリレシピのディレクトリに関しては、プッシュもコミットもせずに、直書きだけするというのもOKにしています。それはドキュメントを書く感覚とは変わらないのかな、というぐらいで使っていますね。

愛されて利用しやすいネーミングの価値

樫田：たしかに、この「全員がGitを使えるわけじゃない。アナリスト以外はどうなんだ」という話は、けっこう大きい問題かなと思っています。そこは、あまりGitコマンドと言わずに……僕らはなるべくGitとかじゃなくって、そのディレクトリの名前自体を認識させたくて、クエリレシピという名前をつけています。

備前：クエリレシピというワーディングがいいですよね。

樫田：そうですね、いくつか候補はあったんですが、そこにいる僕のチームメンバーの松田が考えてくれました。

備前：愛されるというか利用しやすいネーミングは、けっこういいかもね。

樫田：そうですね、ただ、まだまだ普及率足りないと思っているので、さらなる仕組み化とか（が必要）。人間ってやっぱり怠惰な生き物だなと思うので、そこはもう一歩、松田さん頑張ってください（笑）。

備前：松田さんいらっしゃいますか？　……頑張ってください。

（会場笑）

鉄本：うちはPMがあまりSQLを書かないんです。というかSQLを書いているのは、ほとんどデータチームだけなんです。他の人たちがどうしているかというと、Redashがすごく便利です。プレースホルダーを設定してクエリを補完できるんですね。

例えばURLで「デバイス=iOS」という指定もできます。メインのSQLだけを作ってしまって、それを渡しておけば、一部補完するだけで、ほしいデータが出せるという状況を作っていますね。

そこからさらに踏み込んだことをしたいときには、SQLを見て、ここを書き換えればほしいものが出せるよということを、一緒にやりながら教育もしています。

備前：人にもよりますよね。どこか怪しい人には、クエリすらも渡せないですもんね。

鉄本：そうですね。SQLを書かせるというのが、ちょっとまだ負けだなと思っているところはあります。なので、SQLを書けるに越したことはないんですが、書かなくてもデータを出せる環境を作っていきたいなと思いながらやっています。

備前：そうですね。それがけっこう大事かもしれないですね。ありがとうございます。

中央集権化か民主化か？　仕組み化の難しさとは

備前：今の仕組み化とかナレッジの話で言うと、各社ともに、会社の規模、組織の規模、関わる人たちがとにかく大きいところなんですけど、そのときの仕組み化する難しさは何かありますか？　僕は関わる人がけっこう多くて、説明責任もすごく面倒なので、とにかく中央集権的に、そこさえ見ておけばいいんだよというのを作るように心掛けています。

例えばTableauの構成を、誰もが扱えるようにはしていないんですよ。僕らのチームだけの、限られたメンバーで構成をして、それでやっていく。でも、すぐに依頼はなくならないので、とにかく草の根活動的にそこに誘導していく。そこを見ればいいからというのを、草の根活動的にやっていくというのを今がんばっているところですね。各社さんは、難しさを感じているところはありますか？

樫田：人数も多いのでけっこう難しいかなと思っていて、さっき言っていた民主化の話も同じかなと思っています。いきなり全員にガーッとやるのも難しいと思っています。

トップダウンというやり方もあるのかもしれませんが、そうは言っても分析って、トップダウンであまり上手くいくというイメージがほとんどない。さらに、事業とかエンジニアリング関連の人だと経営レイヤーにその専門の人がいると思うんですが、分析を専業に扱っている人ってなると、弊社の場合、社内で一番ポジションが上なのが僕なんですよね。

全社にトップダウンするほどの権力が僕にはあるわけじゃないし、難しいかなと思っています。最初に言った、ゆるふわBIみたいな活動の延長で考えていますね。

一番いい分析のツールややり方を、自分たちの周りにいる、ゆるふわBIのメンバーや、なんとなく分析に対して唾をつけておいている人たちにパイロット版として伝播していく。

その人たちを取り込んだあとに、その人たちからさらに伝播をけっこうがんばるっていう感じかなと思っていますね。半分は組織的な仕組みで解決して、もう半分は全体的に一気にいくという感じのことを諦める、という感覚で間違ってはいないかなと思います。

備前：牟田さんは何かありますか？　

牟田：本当に、難しさしか感じていないです。私も樫田さんの仰ることとすごく似ているんですが、わかりそうな人からデータ分析の活用方法をちゃんとわかっていただく、というところが重要だなと思っています。

とくによく言われていることだと思うんですが、データ分析を広めるにはトップダウンが重要だというのはすごくその通りです。ボトムアップはもちろん必要なんですが、トップがわかっていないと、やっぱり最終的には厳しいなと私も思っています。

なので、前半にもお話がありましたように、データのわかるトップを味方につけるというのが、すごく重要かなとは思っています。

目的を見失わないダッシュボードの管理の仕方

備前：ありがとうございます。会場のみなさんには申し訳ないですが、たぶん全部は拾いきれないので、テーマをなるべく幅広くいこうかと思っているんですけど、お時間があと5分に迫って参りまして……。

樫田：質問、あと20個ぐらい詰まっていますよ（笑）。

備前：そうなんですよ。たぶんこれは運営側がキャッチアップしてくれているものだけなので、それ以外もたぶんあるとは思います。たぶん最後の1～2つぐらいの質問になってしまいますので、できればおもしろいものをピックアップしたいなと思います。

あと5分なんですけど、もし、これだけは絶対聞いておきたいんだけど、という質問がある方はいらっしゃいますか？　

（会場挙手）

質問者：自分が書いたものではないんですが、ダッシュボードの管理をどうやっているかが気になるという質問が出ていて、それをぜひ聞いてみたいと（思います）。

備前：管理と言うと、具体的にどういうことを（指しますか）？　誰がやるのかとか、どういうふうにやってるのかとか？

質問者：いろいろ作っていくと、本来見たいものって何だったんだっけという状況になりがちなのかなと思っていて。そこをどうやってコントロールしているのかというところを（うかがいたいです）。

牟田：目的を見失うという話は、私は正直ないというか、それはあってはいけないことだと思っています。「このダッシュボードの目的はなんですか」「どう使うんですか」というのは、少なくとも使う人の間で認識が一致してることが大前提だと思っています。

なので、我々だと一緒にWikiを用意して、それをダッシュボードに貼ったりしています。そこはボトムラインとして守らなければいけないところかな、と思いました。

備前：的を得た回答になるかわかりませんが、管理という観点で僕がすごく気を付けているのは、管理を一元化することです。僕の言葉で、中央集権的にツールやダッシュボードを管理するということをしています。

いろんな人が使えるようになってしまうと、いろんなダッシュボードができあがっていくんですよね。そうすると、自分たちの知らないものが出回るのが一番怖くて。なので管理は、僕ら以外にはやらせないということを徹底していますね。

目指すは「愛される」ダッシュボード

備前：鉄本さんは何かありますか？

鉄本：うちはもはや、ほとんどダッシュボードがないですね。週1で絶対に定点観測しているものがあるんですけど、それはレポートに組み込んでしまっていて。そのレポート自体を自動で更新できるように仕組み化したので、もうダッシュボードというものが存在しなくなりました。

一応かたちとして残っているものも、あると言えばあるんですが、今はダッシュボードを作るような仕事はほとんどしていないですね。ただ一部、例えば障害があったときにここだけは見なければいけないとか、そういったものに関してだけは、明確に決めてダッシュボード化はしています。

なので、目的があったときに絶対に見るものに関してだけはダッシュボードを作っているんですが、それ以外の定点観測などで使うであろうものはレポートのみですね。

備前：それで言うと、樫田さんところは、愛されるダッシュボードを目指していらっしゃるから……。

樫田：はい（笑）。

備前：やっぱり、見られないと意味がないというところがコンセプトで、管理が徹底されていますよね。

樫田：そうですね、僕らが使っているダッシュボードはLookerというツールなんですが、それに移行する前に、別のツールを使っていました。それはけっこう、どなたでもデータをいじってダッシュボードを作ることができるものでした。

（そのため、）ものすごい数のダッシュボードが氾濫しておりまして、けっこう僕たちBIチームも全ての状況を管理できていなかった。実際にダッシュボードが何十何百とあっても、頻繁に見られているものは両手に収まるような状況だった。そこの反省を生かして、新しいLookerというツールに移行しました。

そのLookerというツールが、さっき備前さんが言った中央集権にすごく向いているタイプのツールで。データの元を作るのは、基本的にBIチームのような権限のある人にしかできなくしていて。さらに、その上にダッシュボードを作れる権利がある人もある程度人数を絞って作りました。

ダッシュボードづくりの考え方はプロダクトと同じ

樫田：ダッシュボードを見る人数はすごく多いんですが、実際にデータの中身の編集などは少数の人しかできないという形にしました。あともう1つは……愛ですね（笑）。

（会場笑）

一個一個のダッシュボードを作るときに、BIチームのメンバーが、「これを毎日見られるといいなあ」とか（考える)。それがすごく大事なアウトプットになるんです。「これを元に事業を変えられるといいな」と思いながら作っていれば大丈夫、と言うと、すごく宗教的なんですが、たくさんダッシュボードを作っても本当にしょうがない。見られるダッシュボードは基本的にはそんなに多くない。

早い話よく見られるものって数個しか生き残らないという世界だと思っているので、一個一個けっこう丹精を込めて作る。それで、どうやったら見られるかというのを、けっこうがんばる……というかなり精神論になってしまったんですが、「どういうふうにしたら見られるダッシュボードになるのか」というのは、いくつかテクニックがあると思います。ちょっと時間なので、よかったら懇親会で聞いてください（笑）。

備前：そうですね。愛されるというのは、本当にアグリーです。けっきょく、UI・UXが本当にだめだと、同じ数字を出しているのに、ものの見事に見られなくなってくるんですよね。

樫田：本当にそれですね。色とか形とか、系列の数とか、置く場所とか、もしくはどのデータを上に置いて、どのデータを下に置くのか、というのは、ものすごく繊細に考えないとファーストページが（だめになる）。これはプロダクトを作るのと一緒ですよね。ファーストページがみづらかったり、ボタンの色が嫌だったりすると、そもそもそのサービス使う気をなくすじゃないですか。

見た目の時点で使う気をなくされたら、「内容はすごくいいサービスなのに」と言っても、ぶっちゃけゴミ同然じゃないですか。ダッシュボードにしても、中に入っている数字がよくても、基本的にファーストページで、「これは見たい」「毎日見たい」と思えるような、UIやUXありきで作るんです。

本当にサービスを作るような感覚で作らないと、「世の中にたくさんあるダメなサービス」の1個にしかならないと思います。けっこう目的を見失うときもあるかもしれないんですが、そこはただ、愛でがんばる。

データサイエンスを事業や経営の判断に活かしたい

備前：ありがとうございます（笑）。すみません、まだまだお話を聞きたいところかと思います。ご質問をたくさんいただいているんですけども、お時間がきてしまいましたので、最後に各パネラーのみなさまから、一言いただきたいと思います。

みなさんに今日、持ち帰っていただきたいことや、明日からがんばってもらえるような（ことについて）、一言何かいただければと思います。じゃあ牟田さんから、お願いいたします。

牟田：今日いろいろとお話をさせていただいたんですが、時間が経つのが早くて、お話ししたいと思っていたことがまだたくさんあるので、ぜひ懇親会のほうでよろしくお願いします。お話しできていなかったことの1つに、我々の目指しているところは、データサイエンスを事業や経営の判断にきちんと活かしたいということがあります。

やっぱり、我々が重視しているところの1つに、技術がすごくあるんですよ。もちろん技術だけではだめですが、それをきちんとユーザーの理解に生かしたり、会社の発展に生かしたりすることを真面目に目指しているチームです。

なので、ご興味ある方がご友人の方にもいらっしゃったら、カジュアル面談でもぜんぜんオーケーですので、ぜひよろしくお願いします。

（会場笑）

定性データと定量データのバランスをいかに取れるかが重要

備前：ありがとうございます。鉄本さん、お願いいたします。

鉄本：今日は、かなりデータ、データ、データという話をしてしまったんですが、サービスは定性もすごく大事だと思っています。定性と定量のバランスをいかに取れるかが、データを扱う人としてはものすごく重要だと思っています。ということを一言、言いたかったです（笑）。

その辺の話や、ふだんどういうふうに考えて仕事をしているのか、どういうふうにチームを作っていこうと思っているのかについて、いくらでも話したいことがいっぱいあったので、懇親会でぜひお声がけいただければと思います。よろしくお願いします。

採用は長いスパンで考えたい

備前：ありがとうございます。樫田さん、お願いいたします。

樫田：あまり時間がないようなのでひとことで言うと、めちゃくちゃ積極採用をしています、興味のある方はぜひ申し込んでください。ということくらいですかね（笑）。

（会場笑）

本当にこういう場の繋がりはすごく大事だなと思っています。こういったイベント経由で繋がった方と仲良くなって、たとえばそのあとに長いスパンで一緒に働くことになった人もいますし。こういうイベントの運営サイドで一緒にやっていて、入ってくれる人とかもいます。

たまたまTwitterで絡んでくれた人とそのあとに飲みに行って、その人を採用できたというのもある。ちょっとした機会や興味があって、繋がってさえいれば、いつかのタイミングでメルカリが1つの選択肢になるときが来ればいいかな、というぐらいの気持ちで採用はやっています。

今すぐ来てくれるというのが一番うれしいですが、採用ってそんなに簡単なものではないかな、と思っていて。みなさんはすごく優秀だと思うし、みなさんにはみなさんの都合があって、会社もなかなか離してくれないと思うので、長いスパンで考えるのが重要かなと思っています。

その長いスパンの第一歩というのが、まずは繋がりを作るということ。そして、僕やメルカリに興味を持ってもらうことかなと思っています。第一歩として繋がりを作らせていただいて、メルカリに興味を持っていただくという部分は、僕やチームメンバーで頑張ってやらせていただきます。そういうかたちで採用をすごく頑張っているのでよろしくお願いします。

同じ仕事をしていれば、似たような悩みを持っていたりするもの

備前：ありがとうございます。長い時間、45分を2セット、司会してきました。採用にしろ育成にしろ、仕組み化にしろ、データをどう扱うのかよりも、事業を成功に導くために、適切な意思決定や適切な解釈をさせるというところがゴールです。各パネラー共通して、事前の打ち合わせも含めてすごく大事なところなんだなと思いました。

また、先ほど樫田さんも言っていましたように、意外と僕らも話していまして。各社さんが悩んでいることや課題、取り組んでいることは、比較的似たような悩みを持っているんですね。

強制はしませんが、ライトなかたちで、「こういうところ、どうやっていますか？」「こういう課題に対して、どう解決しましたか？」というような関係性を、今日いらっしゃった方々で、ぜひ作ってもらえればと思います。このあと懇親会もご用意してますから、お時間の許す限り、ぜひみなさん奮ってご参加いただければと思います。

少し時間が伸びてしまいましたが、これでパネルディスカッションを終わりとさせていただきたいと思います。拙い進行でありましたが、お付き合いいただきまして、ありがとうございました。

（会場拍手）